JP4519812B2 - 接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラム - Google Patents
接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラム Download PDFInfo
- Publication number
- JP4519812B2 JP4519812B2 JP2006178404A JP2006178404A JP4519812B2 JP 4519812 B2 JP4519812 B2 JP 4519812B2 JP 2006178404 A JP2006178404 A JP 2006178404A JP 2006178404 A JP2006178404 A JP 2006178404A JP 4519812 B2 JP4519812 B2 JP 4519812B2
- Authority
- JP
- Japan
- Prior art keywords
- user device
- information
- payment
- connection control
- connection
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Description
この発明は、接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラムに関する。
従来より、ダイヤルＱ２サービスに代表されるように、電気通信事業者などによる料金回収代行サービスが普及している。一般に、料金回収代行サービスでは、有料情報や物財などの提供を受けて対価を支払う『支払いユーザ』に利用される「支払いユーザ装置」と、有料情報や物財などを提供して対価を受け取る『受け取りユーザ』に利用される「受け取りユーザ装置」とのネットワークを介した接続を、電気通信事業者などのネットワークに設置された「接続制御装置」が制御する。そして、制御した接続に基づいて、電気通信事業者によって支払いユーザに課金がなされ、課金された料金が電気通信事業者によって支払いユーザから回収され、回収された料金のうち対価に相当する料金が電気通信事業者によって受け取りユーザに支払われることで、支払いユーザと受け取りユーザとの間における決済が実行される。
ここで、支払いユーザと受け取りユーザとの間における決済に関しては、さまざまな形態の決済（例えば、課金金額が異なる決済や、従量課金や定額課金など課金方式が異なる決済など）が考えられる。このため、このようなさまざまな形態の決済に対応する料金回収代行サービスを実現することを目的として、特許文献１では、「支払いユーザ装置」を指定の回線に指定の時間（もしくは指定の回数）接続させる専用の装置を利用する手法が提案されている。具体的に説明すると、「支払いユーザ装置」に専用の装置が別途備えられ、「接続制御装置」がこの専用の装置に制御情報を送信し、「支払いユーザ装置」がこの制御情報に制御されて「受け取りユーザ装置」に接続する結果、支払いユーザと受け取りユーザとの間における決済が実行される。例えば、支払いユーザによって代金５２０円の商品が受け取りユーザから購入されると、「接続制御装置」がこの専用の装置に「１分あたり１００円の回線に５分間、１分あたり１０円の回線に２分間接続させる制御情報」を送信し、「支払いユーザ装置」がこの制御情報に制御されて「受け取りユーザ装置」に接続する結果、「接続制御装置」は、５２０円を支払いユーザに課金する。
また、特許文献２では、さまざまな形態の決済ごとに対応づけられた電話番号を利用する手法が提案されている。具体的に説明すると、電気通信事業者において、さまざまな形態の決済ごとに対応づけられた電話番号が払い出され、「接続制御装置」が、特定の決済に対応づけられた電話番号に「支払いユーザ装置」を接続する結果、支払いユーザと受け取りユーザとの間における決済が実行される。例えば、支払いユーザによって代金１９８，０００円の商品が受け取りユーザから購入されると、「接続制御装置」において、「１９８，０００円」の決済に対応づけられた電話番号「１１１１１１」が払い出され、「支払いユーザ装置」のモニタに「１１１１１１」が表示される。そして、支払いユーザによって電話番号「１１１１１１」がダイヤルされ、「接続制御装置」が「１１１１１１」に「支払いユーザ装置」を接続する結果、「接続制御装置」は、１９８，０００円を支払いユーザに課金する。
ところで、上記した従来の技術では、以下に説明するように、さまざまな形態の決済を適切に実行することができず、また、支払いユーザにとって予期せぬ決済が実行される危険を回避できず、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することもできなくなるという課題がある。
すなわち、特許文献１に開示された手法では、接続の時間や接続の回数などに応じて課金されるので、例えば、「支払いユーザ装置」が専用の装置によって制御されている途中に（指定の回線に接続している途中に）通信エラーなどが発生すると、「支払いユーザ装置」に対する課金が途中で停止し、意図した課金金額通りに課金されないことから、さまざまな形態の決済を適切に実行することができない。また、特許文献２に開示された手法では、接続の時間や接続の回数などに応じて課金されるわけではないので、確かに、さまざまな形態の決済を適切に実行することができるが、支払いユーザによって決済の形態が認知されない（例えば、電話番号「１１１１１１」を認知することはできても、決済金額「１９８，０００円」を認知することはできないなど）ことから、支払いユーザにとって予期せぬ決済（例えば、予期した金額よりも高額な決済など）が実行される危険がある。
さらに、例えば、特定の電話番号に対応づけられた課金金額の変更や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態を変更すると、支払いユーザにとって予期せぬ決済が実行される危険はより大きくなると想定されることから、電気通信事業者において、決済用通信番号（電話番号）に対応づけられた決済の形態が変更されることはない。その結果、有限な決済用通信番号（電話番号）がさまざまな形態の決済ごとに払い出されることから、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することもできなくなる。
そこで、この発明は、上記した従来技術の課題を解決するためになされたものであり、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラムを提供することを目的とする。
上記した課題を解決し、目的を達成するため、請求項１に係る発明は、支払いユーザ装置と当該支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、当該支払いユーザ装置と当該受け取りユーザ装置との接続を制御する接続制御装置であって、前記決済用通信番号で識別される前記受け取りユーザ装置に対する接続要求を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置に対する課金内容を示す情報として、当該決済用通信番号に対応づけられた課金情報を取得して当該支払いユーザ装置に送信する課金情報送信手段と、前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置の課金額を管理する管理部の当該課金額に当該課金情報に基づく課金額を加算するように格納する課金情報格納手段と、前記同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続する接続手段と、を備えたことを特徴とする。
また、請求項２に係る発明は、上記の発明において、前記課金情報送信手段は、前記決済用通信番号に対応づけて管理する課金ポリシーに基づいて前記課金情報を決定する課金情報データベースに通信可能に接続され、当該課金情報データベースから当該課金情報を取得して前記支払いユーザ装置に送信することを特徴とする。
また、請求項３に係る発明は、上記の発明において、前記課金情報データベースは、前記課金ポリシーの変更指示を受け付け、当該変更指示に従って当該課金ポリシーを更新するものであって、前記課金情報送信手段は、前記課金情報データベースが管理する課金ポリシーが更新された後に前記接続要求を前記支払いユーザ装置から受信した場合に、更新された後の課金ポリシーに基づいて決定された課金情報を取得して当該支払いユーザ装置に送信し、前記課金情報格納手段は、前記更新された後の課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、前記管理部の当該支払いユーザ装置の課金額に当該更新された後の課金情報に基づく課金額を加算するように格納し、前記接続手段は、前記更新された後の課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続することを特徴とする。
また、請求項４に係る発明は、上記の発明において、前記受け取りユーザ装置は、前記決済用通信番号に対応づけて課金ポリシーを管理し、前記接続制御装置からの要求に応じて当該課金ポリシーに基づいて前記課金情報を決定し、決定した当該課金情報を当該接続制御装置に送信するものであって、前記課金情報送信手段は、前記課金情報の提供を前記受け取りユーザ装置に要求し、当該受け取りユーザ装置において決定された課金情報を当該受け取りユーザ装置から受信して前記支払いユーザ装置に送信することを特徴とする。
また、請求項５に係る発明は、上記の発明において、前記受け取りユーザ装置は、前記課金ポリシーとして、前記決済用通信番号の配下で所定の識別子ごとに区分けされた課金ポリシーを管理し、当該所定の識別子を前記接続制御装置から受信した場合に、当該所定の識別子を用いて決定した課金情報を前記接続制御装置に送信するものであり、前記支払いユーザ装置は、前記接続要求とともに前記所定の識別子を前記接続制御装置に送信するものであって、前記課金情報送信手段は、前記接続要求とともに前記所定の識別子を前記支払いユーザ装置から受信した場合に、当該所定の識別子を前記受け取りユーザ装置に送信することで、前記課金情報の提供を当該受け取りユーザ装置に要求することを特徴とする。
また、請求項６に係る発明は、上記の発明において、前記受け取りユーザ装置は、前記決済用通信番号で識別される決済の対象である決済対象の状況を管理し、前記支払いユーザ装置からの接続要求があることを示す接続情報を前記接続制御装置から受信した場合に、当該決済対象の状況を用いて当該接続要求を受け付けるか否かを判断し、判断した判断結果を当該接続制御装置に送信するものであって、前記課金情報格納手段は、前記接続要求を受け付けることを示す判断結果を前記受信ユーザ装置から受信した場合に、前記管理部の前記支払いユーザ装置の課金額に前記課金情報に基づく課金額を加算するように格納し、前記接続手段は、前記接続要求を受け付けることを示す判断結果を当該受信ユーザ装置から受信した場合に、当該支払いユーザ装置と当該受け取りユーザ装置とを接続することを特徴とする。
また、請求項７に係る発明は、上記の発明において、前記課金情報は、所定の接続条件をさらに含むものであって、前記課金情報送信手段は、前記所定の接続条件をさらに含む前記課金情報を取得して前記支払いユーザ装置に送信し、前記課金情報格納手段は、前記所定の接続条件をさらに含む前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置の課金額を管理する管理部の当該管理額に当該課金情報に基づく課金額を加算するように格納し、前記接続手段は、前記所定の接続条件をさらに含む前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続することを特徴とする。
また、請求項８に係る発明は、上記の発明において、前記管理部は、前記支払いユーザ装置の課金額を管理するとともに前記受け取りユーザ装置の課金額を管理するものであって、前記課金情報格納手段は、前記課金情報に基づく課金額を、前記管理部が管理する前記支払いユーザ装置の課金額に加算するように格納するとともに、当該管理部が管理する前記受け取りユーザ装置の課金額から減算するように格納することを特徴とする。
また、請求項９に係る発明は、上記の発明において、前記支払いユーザ装置は、前記同意情報とともに電子署名を前記接続制御装置に送信するものであって、前記課金情報格納手段は、前記同意情報とともに前記電子署名を前記支払いユーザ装置から受信し、当該電子署名の正当性が検証された場合に、前記管理部の当該支払いユーザ装置の課金額に前記課金情報に基づく課金額を加算するように格納し、前記接続手段は、前記同意情報とともに前記電子署名を前記支払いユーザ装置から受信し、当該電子署名の正当性が検証された場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続することを特徴とする。
また、請求項１０に係る発明は、決済用通信番号で識別される受け取りユーザ装置に接続制御装置を介して通信可能に接続する支払いユーザ装置であって、課金内容を示す情報として、前記決済用通信番号に対応づけられた課金情報を前記接続制御装置から受信して、当該課金情報を所定の出力部に出力する課金情報出力手段と、前記課金情報出力手段によって出力された前記課金情報に同意することを示す同意情報の入力を所定の入力部において受け付ける同意情報受付手段と、前記同意情報受付手段によって受け付けられた前記同意情報を、当該同意情報の受信を条件に前記受け取りユーザ装置との接続を許可する前記接続制御装置に送信する同意情報送信手段と、を備えたことを特徴とする。
また、請求項１１に係る発明は、上記の発明において、前記課金情報に対応づけて所定の接続ポリシーを保持する接続ポリシー保持手段をさらに備え、前記同意情報送信手段は、前記同意情報受付手段によって前記同意情報の入力を受け付けると、前記接続ポリシー保持手段によって保持された前記所定の接続ポリシーを参照し、当該所定の接続ポリシーを充たす場合に、当該同意情報を前記接続制御装置に送信することを特徴とする。
また、請求項１２に係る発明は、支払いユーザ装置において決済用通信番号で識別され、接続制御装置を介して当該支払いユーザ装置に通信可能に接続する受け取りユーザ装置であって、前記決済用通信番号に対応づけて課金ポリシーを管理し、前記接続制御装置からの要求に応じて当該課金ポリシーに基づいて課金内容を示す情報として課金情報を決定する課金情報決定手段と、前記課金情報決定手段によって決定された課金情報を、当該課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信することを条件に当該支払いユーザ装置との接続を許可する前記接続制御装置に送信する課金情報送信手段と、を備えたことを特徴とする。
また、請求項１３に係る発明は、支払いユーザ装置と当該支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、当該支払いユーザ装置と当該受け取りユーザ装置との接続を制御する方法を接続制御装置としてのコンピュータに実行させる接続制御プログラムであって、前記決済用通信番号で識別される前記受け取りユーザ装置に対する接続要求を前記支払いユーザ装置から受信した場合に、当該決済用通信番号に対応づけられた課金情報を取得して当該支払いユーザ装置に送信する課金情報送信手順と、前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置の課金額を管理する管理部の当該課金額に当該課金情報に基づく課金額を加算するように格納する課金情報格納手順と、前記同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続する接続手順と、を接続制御装置としてのコンピュータに実行させることを特徴とする。
また、請求項１４に係る発明は、決済用通信番号で識別される受け取りユーザ装置に接続制御装置を介して通信可能に接続する方法を支払いユーザ装置としてのコンピュータに実行させる支払いユーザプログラムであって、前記決済用通信番号に対応づけられた課金情報を前記接続制御装置から受信して、当該課金情報を所定の出力部に出力する課金情報出力手順と、前記課金情報出力手順によって出力された前記課金情報に同意することを示す同意情報の入力を所定の入力部において受け付ける同意情報受付手順と、前記同意情報受付手順によって受け付けられた前記同意情報を前記接続制御装置に送信する同意情報送信手順と、を支払いユーザ装置としてのコンピュータに実行させることを特徴とする。
また、請求項１５に係る発明は、支払いユーザ装置において決済用通信番号で識別され、接続制御装置を介して当該支払いユーザ装置に通信可能に接続する方法を受け取りユーザ装置としてのコンピュータに実行させる受け取りユーザプログラムであって、前記決済用通信番号に対応づけて課金ポリシーを管理し、前記接続制御装置からの要求に応じて当該課金ポリシーに基づいて課金情報を決定する課金情報決定手順と、前記課金情報決定手順によって決定された課金情報を前記接続制御装置に送信する課金情報送信手順と、を受け取りユーザ装置としてのコンピュータに実行させることを特徴とする。
請求項１または１３の発明によれば、支払いユーザ装置と支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、支払いユーザ装置と受け取りユーザ装置との接続を制御する接続制御装置であって、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、支払いユーザ装置に対する課金内容を示す情報として、決済用通信番号に対応づけられた課金情報を取得して支払いユーザ装置に送信し、課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の課金額に課金情報に基づく課金額を加算するように格納し、同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、「支払いユーザ装置」に指定の時間（もしくは指定の回数）接続させる専用の装置を利用する従来の手法では、「支払いユーザ装置」は、接続の時間や接続の回数などに応じて課金される。これに対して、この発明に係る接続制御システムのように、「支払いユーザ装置」が課金情報を「接続制御装置」から受信し、課金情報に同意することを示す同意情報を「接続制御装置」に送信する手法では、接続の時間や接続の回数などに応じて課金されるわけではないので、従来の手法に比較して、さまざまな形態の決済を適切に実行することが可能になる。
また、「接続制御装置」が、決済用通信番号（電話番号）に対応づけられた課金情報（例えば、課金金額や課金方式など）を「支払いユーザ装置」に送信し、次に、「支払いユーザ装置」において、「接続制御装置」によって送信された課金情報が所定の出力部（例えば、モニタ、スピーカーなど）に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知され、そして、「支払いユーザ装置」によって受け付けられた『支払いユーザ』による同意を「接続制御装置」が受信した場合に、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続することから、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になる。
ひいては、特定の電話番号に対応づけられた課金金額や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態が変更された場合であっても、その都度、「支払いユーザ装置」において、「接続制御装置」によって送信された課金情報が所定の出力部に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知されるので、支払いユーザにとって予期せぬ決済が実行される危険を回避する結果、決済用通信番号（電話番号）に対応づけられた決済の形態を変更することもできることから、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
また、請求項２の発明によれば、接続制御装置が、決済用通信番号に対応づけて管理する課金ポリシーに基づいて課金情報を決定する課金情報データベースに通信可能に接続され、課金情報データベースから課金情報を取得して支払いユーザ装置に送信するので、「受け取りユーザ装置」に課金情報を要求して取得しなければならない手法に比較して、さまざまな形態の決済を簡易かつ適切に実行することが可能になる。
すなわち、「接続制御装置」において課金情報を取得するにあたり、「受け取りユーザ装置」に課金情報を要求して取得しなければならない手法では、「受け取りユーザ装置」に課金情報を管理する仕組みが必要になり、また、「受け取りユーザ装置」に処理の負荷がかかるおそれがあり、さらに、同意情報を「支払いユーザ装置」から受信しない場合にも、「接続制御装置」と「受け取りユーザ装置」との間で課金情報の送受信を行わなければならない。これに対して、「接続制御装置」と同じく網内（例えば、電気通信事業者によるネットワーク内など）に設置される課金情報データベースから課金情報を取得する手法では、「受け取りユーザ装置」に課金情報を管理する仕組みが不要になり、また、「受け取りユーザ装置」に処理の負荷がかかるおそれを回避でき、さらに、同意情報を「支払いユーザ装置」から受信しない場合には、網内で接続制御処理を完結できることから、さまざまな形態の決済を簡易かつ適切に実行することが可能になる。
また、請求項３の発明によれば、課金情報データベースは、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新するものであって、接続制御装置は、課金情報データベースが管理する課金ポリシーが更新された後に接続要求を支払いユーザ装置から受信した場合に、更新された後の課金ポリシーに基づいて決定された課金情報を取得して支払いユーザ装置に送信し、更新された後の課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、管理部の支払いユーザ装置の課金額に更新された後の課金情報に基づく課金額を加算するように格納し、更新された後の課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、特定の電話番号に対応づけられた課金金額や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態が変更されても、「接続制御装置」が、更新後の課金情報を「支払いユーザ装置」に送信し、次に、「支払いユーザ装置」において、「接続制御装置」によって送信された更新後の課金情報が所定の出力部に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって更新後の決済の形態が認知され、そして、「支払いユーザ装置」によって受け付けられた『支払いユーザ』による同意を「接続制御装置」が受信した場合に、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続することから、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
また、請求項４の発明によれば、受け取りユーザ装置は、決済用通信番号に対応づけて課金ポリシーを管理し、接続制御装置からの要求に応じて課金ポリシーに基づいて課金情報を決定し、決定した課金情報を接続制御装置に送信するものであって、接続制御装置は、課金情報の提供を受け取りユーザ装置に要求し、受け取りユーザ装置において決定された課金情報を受け取りユーザ装置から受信して支払いユーザ装置に送信するので、接続制御装置が課金情報を決定する課金情報データベースに通信可能に接続され、この課金情報データベースから課金情報を取得する手法に比較して、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になる。
すなわち、接続制御装置が課金情報を決定する課金情報データベースに通信可能に接続され、この課金情報データベースから課金情報を取得する手法では、『受け取りユーザ』による課金ポリシー（課金情報を決定するロジック）の変更などは、接続制御装置が接続される課金情報データベースに課金ポリシーの変更指示などを受け付けてもらうことによって対応される。これに対して、受け取りユーザ装置において課金情報を決定し、接続制御装置が受け取りユーザ装置において決定された課金情報を受け取りユーザ装置から受信して取得する手法では、『受け取りユーザ』による課金ポリシーの変更などに自由かつより柔軟に対応することから、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になる。
また、請求項５の発明によれば、受け取りユーザ装置は、課金ポリシーとして、決済用通信番号の配下で所定の識別子ごとに区分けされた課金ポリシーを管理し、所定の識別子を接続制御装置から受信した場合に、所定の識別子を用いて決定した課金情報を接続制御装置に送信するものであり、支払いユーザ装置は、接続要求とともに所定の識別子を接続制御装置に送信するものであって、接続制御装置は、接続要求とともに所定の識別子を支払いユーザ装置から受信した場合に、所定の識別子を受け取りユーザ装置に送信することで、課金情報の提供を受け取りユーザ装置に要求するので、決済用通信番号（電話番号）が不足するという事態をより回避することが可能になる。
すなわち、支払いユーザ装置と受け取りユーザ装置との間で、所定の識別子を共有するので、ひとつの決済用通信番号（電話番号）に対して、所定の識別子で識別される複数の決済を実行することができることから、決済用通信番号（電話番号）が不足するという事態をより回避することが可能になる。
また、請求項６の発明によれば、受け取りユーザ装置は、決済用通信番号で識別される決済の対象である決済対象の状況を管理し、支払いユーザ装置からの接続要求があることを示す接続情報を接続制御装置から受信した場合に、決済対象の状況を用いて接続要求を受け付けるか否かを判断し、判断した判断結果を接続制御装置に送信するものであって、接続制御装置は、接続要求を受け付けることを示す判断結果を受信ユーザ装置から受信した場合に、管理部の支払いユーザ装置の課金額に課金情報に基づく課金額を加算するように格納し、接続要求を受け付けることを示す判断結果を受信ユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を適切に実行することが可能になる。
すなわち、例えば、「支払いユーザ装置」と「受け取りユーザ装置」との間で物財の販売およびその決済が実行される際に、「受け取りユーザ装置」においては、決済対象の状況を用いて、「支払いユーザ装置」からの接続要求を受け付けるか否かを判断し、判断した判断結果を「接続制御装置」に送信する。例えば、「受け取りユーザ装置」において、物財の在庫の有無が確認され、在庫がある場合には、「支払いユーザ装置」からの接続要求を受け付ける旨の判断結果が「接続制御装置」に送信され、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続するが、在庫がない場合には、「支払いユーザ装置」からの接続要求を受け付けない旨の判断結果が「接続制御装置」に送信され、「接続制御装置」は、「支払いユーザ装置」に課金せず、「支払いユーザ装置」と「受け取りユーザ装置」とを接続しないなど、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を適切に実行することが可能になる。
また、請求項７の発明によれば、課金情報は、所定の接続条件をさらに含むものであって、接続制御装置は、所定の接続条件をさらに含む課金情報を取得して支払いユーザ装置に送信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の管理額に課金情報に基づく課金額を加算するように格納し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を高度かつ効率的かつ適切に実現することが可能になる。
すなわち、例えば、「接続制御装置」が、接続条件として、「２０歳以上であること」、「大人の監督下で接続すること」などの条件を含む課金情報を「支払いユーザ装置」に送信し、これらの条件を含む課金情報に同意することを示す同意情報を「支払いユーザ装置」から受信した場合に、「接続制御装置」が、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続するなど、さまざまな形態の決済を高度かつ適切に実行することが可能になる。
また、例えば、「支払いユーザ装置」と「受け取りユーザ装置」との間で、通信販売およびその決済が実行される際に、「接続制御装置」が、接続条件として、支払いユーザの属性情報（例えば、住所、メールアドレス、年齢など）の開示を要求する情報開示要求を含む課金情報を「支払いユーザ装置」に送信し、情報開示要求を含む課金情報に同意することを示す同意情報を「支払いユーザ装置」から受信した場合に、「接続制御装置」が、支払いユーザの属性情報（例えば、住所など）を取得して「受け取りユーザ装置」に送信することで、「受け取りユーザ装置」における住所などの属性情報の取得を効率化することから、さまざまな形態の決済を効率的かつ適切に実行することが可能になる。
また、請求項８の発明によれば、管理部は、支払いユーザ装置の課金額を管理するとともに受け取りユーザ装置の課金額を管理するものであって、接続制御装置は、課金情報に基づく課金額を、管理部が管理する支払いユーザ装置の課金額に加算するように格納するとともに、管理部が管理する受け取りユーザ装置の課金額から減算するように格納するので、少額の決済などを含むさまざまな形態の決済を単純な手続で適切に実行することが可能になる。
すなわち、例えば、「支払いユーザ装置」と「受け取りユーザ装置」との間で実行される決済が、１回限りのものであり、かつ、少額の決済である場合など（Consumer to Consumerの取引など）には、電気通信事業者によって回収された料金から対価に相当する料金が受け取りユーザに支払われる手続を踏むよりも、少額の課金金額を「支払いユーザ装置」の課金額に加算するとともに、「受け取りユーザ装置」の課金額に減算する手続をとる方が、少額の決済などを含むさまざまな形態の決済を単純な手続で適切に実行することが可能になる。
また、請求項９の発明によれば、支払いユーザ装置は、同意情報とともに電子署名を接続制御装置に送信するものであって、接続制御装置は、同意情報とともに電子署名を支払いユーザ装置から受信し、電子署名の正当性が検証された場合に、管理部の支払いユーザ装置の課金額に課金情報に基づく課金額を加算するように格納し、同意情報とともに電子署名を支払いユーザ装置から受信し、電子署名の正当性が検証された場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を安全かつ適切に実行することが可能になる。
すなわち、決済の当事者である『支払いユーザ』を証明する電子署名が「支払いユーザ装置」によって「接続制御装置」に送信され、「接続制御装置」において、その電子署名の正当性が検証された場合に（すなわち、決済の当事者である『支払いユーザ』本人であることが検証され、また、同意情報に改竄が行われていないことが検証され、さらに、支払いユーザが同意情報を送信した事実を否認するおそれを回避した場合に）、「接続制御装置」は、「支払いユーザ」装置に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続し、例えば、『支払いユーザ』になりすました別のユーザが同意情報を「接続制御装置」に送信した場合には、「接続制御装置」は、「支払いユーザ」装置に課金せず、「支払いユーザ装置」と「受け取りユーザ装置」とを接続しないことから、さまざまな形態の決済を安全かつ適切に実行することが可能になる。
また、請求項１０または１４の発明によれば、決済用通信番号で識別される受け取りユーザ装置に接続制御装置を介して通信可能に接続する支払いユーザ装置であって、課金内容を示す情報として、決済用通信番号に対応づけられた課金情報を接続制御装置から受信して、課金情報を所定の出力部に出力し、出力された課金情報に同意することを示す同意情報の入力を所定の入力部において受け付け、受け付けられた同意情報を、同意情報の受信を条件に受け取りユーザ装置との接続を許可する接続制御装置に送信するので、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話
番号）が不足するという事態を回避することも可能になる。
番号）が不足するという事態を回避することも可能になる。
すなわち、「支払いユーザ装置」に指定の時間（もしくは指定の回数）接続させる専用の装置を利用する従来の手法では、「支払いユーザ装置」は、接続の時間や接続の回数などに応じて課金される。これに対して、この発明に係る接続制御システムのように、「支払いユーザ装置」が課金情報を「接続制御装置」から受信し、課金情報に同意することを示す同意情報を「接続制御装置」に送信する手法では、接続の時間や接続の回数などに応じて課金されるわけではないので、従来の手法に比較して、さまざまな形態の決済を適切に実行することが可能になる。
また、「接続制御装置」によって、決済用通信番号（電話番号）に対応づけられた課金情報（例えば、課金金額や課金方式など）が「支払いユーザ装置」に送信され、次に、「支払いユーザ装置」が、「接続制御装置」から送信された課金情報を所定の出力部（例えば、モニタ、スピーカーなど）に出力することで、「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知され、そして、『支払いユーザ』による同意を「支払いユーザ装置」が受け付け「接続制御装置」に送信した場合に、「接続制御装置」によって、「支払いユーザ装置」が課金され、「支払いユーザ装置」と「受け取りユーザ装置」とが接続されることから、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になる。
ひいては、特定の電話番号に対応づけられた課金金額や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態が変更された場合であっても、支払いユーザにとって予期せぬ決済が実行される危険を回避する結果、決済用通信番号（電話番号）に対応づけられた決済の形態を変更することもできることから、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
また、請求項１１の発明によれば、支払いユーザ装置は、課金情報に対応づけて所定の接続ポリシーをさらに保持し、同意情報の入力を受け付けると、保持された所定の接続ポリシーを参照し、所定の接続ポリシーを充たす場合に、同意情報を接続制御装置に送信するので、所定の接続ポリシーを参照することなく同意情報を接続制御装置に送信する手法に比較して、支払いユーザにとって予期せぬ決済が実行される危険をより確実に回避することが可能になる。
すなわち、所定の接続ポリシーを参照することなく同意情報を接続制御装置に送信する手法では、「接続制御装置」から送信された課金情報が「支払いユーザ装置」の所定の出力部に出力されたとしても、「支払いユーザ装置」を利用する『支払いユーザ』によって、課金金額や接続条件（例えば、支払いユーザの属性情報の開示など）など決済の形態が充分に認知されないまま、同意情報を接続制御装置に送信してしまうおそれがある。これに対して、所定の接続ポリシーを参照してから同意情報を接続制御装置に送信する手法では、例えば、課金金額１，０００円以上の決済については、『支払いユーザ』に暗証番号を入力させることを接続ポリシーとすることで、『支払いユーザ』に決済の形態を充分に認知させることから、支払いユーザにとって予期せぬ決済が実行される危険をより確実に回避することが可能になる。
また、請求項１２または１５の発明によれば、支払いユーザ装置において決済用通信番号で識別され、接続制御装置を介して当該支払いユーザ装置に通信可能に接続する受け取りユーザ装置であって、決済用通信番号に対応づけて課金ポリシーを管理し、接続制御装置からの要求に応じて課金ポリシーに基づいて課金内容を示す情報として課金情報を決定し、決定された課金情報を、課金情報に同意することを示す同意情報を支払いユーザ装置から受信することを条件に支払いユーザ装置との接続を許可する接続制御装置に送信するので、接続制御装置が接続される課金情報データベースで課金ポリシー（課金情報を決定するロジック）を管理する手法に比較して、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、接続制御装置が接続される課金情報データベースで課金ポリシーを管理する手法では、『受け取りユーザ』による課金ポリシーの変更などは、接続制御装置が接続される課金情報データベースに課金ポリシーの変更指示などを受け付けてもらうことによって対応される。これに対して、『受け取りユーザ』に利用される「受け取りユーザ装置」が課金ポリシーを管理する手法では、『受け取りユーザ』による課金ポリシーの変更などに自由かつより柔軟に対応する。このような「受け取りユーザ装置」が「接続制御装置」を介して「支払いユーザ装置」に接続することから、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
以下に添付図面を参照して、この発明に係る接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラムの実施例を詳細に説明する。なお、以下では、この発明に係る接続制御装置、支払いユーザ装置、および受け取りユーザ装置で構成される接続制御システムを実施例として説明する。また、以下の実施例で用いる主要な用語、実施例１における接続制御システムの概要および特徴、実施例１における接続制御システムの構成および処理の手順、実施例１の効果を順に説明し、続いて、他の実施例について説明する。
［用語の説明］
まず最初に、以下の実施例で用いる主要な用語を説明する。「接続制御システム」とは、電気通信事業者などのネットワークに設置された「接続制御装置」が、「支払いユーザ装置」と「受け取りユーザ装置」とに通信可能に接続されて、「支払いユーザ装置」と「受け取りユーザ装置」との接続を制御するシステムである。「支払いユーザ装置」と「受け取りユーザ装置」との接続を制御する目的は、「支払いユーザ装置」を利用する『支払いユーザ』と、「受け取りユーザ装置」を利用する『受け取りユーザ』との間における決済を実行することにある。具体的には、「接続制御装置」が制御した接続に基づいて、「接続制御装置」が「支払いユーザ装置」に課金し、課金された料金が電気通信事業者などによって『支払いユーザ』から回収され、回収された料金が電気通信事業者などによって『受け取りユーザ』に支払われることで、決済を実行する。
まず最初に、以下の実施例で用いる主要な用語を説明する。「接続制御システム」とは、電気通信事業者などのネットワークに設置された「接続制御装置」が、「支払いユーザ装置」と「受け取りユーザ装置」とに通信可能に接続されて、「支払いユーザ装置」と「受け取りユーザ装置」との接続を制御するシステムである。「支払いユーザ装置」と「受け取りユーザ装置」との接続を制御する目的は、「支払いユーザ装置」を利用する『支払いユーザ』と、「受け取りユーザ装置」を利用する『受け取りユーザ』との間における決済を実行することにある。具体的には、「接続制御装置」が制御した接続に基づいて、「接続制御装置」が「支払いユーザ装置」に課金し、課金された料金が電気通信事業者などによって『支払いユーザ』から回収され、回収された料金が電気通信事業者などによって『受け取りユーザ』に支払われることで、決済を実行する。
ここで、電気通信事業者などのネットワークとは、具体的には、公衆交換電話網、移動体通信網、次世代電話網（ＩＰ網：Internet Protocol網）などの電話網や、インターネット（ＩＰ網としての利用を除く）などのことである。例えば、電気通信事業者などのネットワークとしてＩＰ網を前提とすると、接続制御システムは、ＩＰ網に設置された「接続制御装置」が、ＩＰ電話端末である「支払いユーザ装置」と「受け取りユーザ装置」との接続を制御するシステムになる。なお、実施例１においては、電気通信事業者などのネットワークとしてＩＰ網を前提とし、「支払いユーザ装置」と「受け取りユーザ装置」としてＩＰ電話端末（例えば、電話機、情報家電、ファクシミリ、パーソナルコンピュータ、電話機およびホームゲートウェイなどの組合せなど）を前提とするシステム構成を説明するが、この発明はこれに限られるものではなく、例えば、電気通信事業者などのネットワークとして公衆交換電話網を前提とし、「支払いユーザ装置」と「受け取りユーザ装置」として通常の電話端末を前提とするシステム構成や、電気通信事業者などのネットワークとしてインターネットを前提とし、「支払いユーザ装置」と「受け取りユーザ装置」としてパーソナルコンピュータを前提とするシステム構成などにも、この発明を同様に適用することができる。
このように、実施例１における接続制御システムでは、ＩＰ網に設置された「接続制御装置」が、ＩＰ電話端末である「支払いユーザ装置」と「受け取りユーザ装置」との接続を制御して、「支払いユーザ装置」と「受け取りユーザ装置」との間の決済を実行するが、決済を実行するにあたっては、電気通信事業者によって、決済の形態ごとに対応づけられた「決済用通信番号」（例えば、ある商品の代金を支払うという決済の形態に対応づけられたひとつの電話番号など）が払い出される必要がある。この「決済用通信番号」は、ＩＰ電話端末である「受け取りユーザ装置」を識別するものであり、「支払いユーザ装置」において「決済用通信番号」が入力されると、「接続制御装置」は、「支払いユーザ装置」と、「決済用通信番号」で識別される「受け取りユーザ装置」との決済を実行するべく、接続を制御することになる。また、決済を実行するにあたっては、決済金額や決済の方式など、決済の形態に関する情報が利用されることになるが、接続制御システムでは、「接続制御装置」が「支払いユーザ装置」に課金することで決済を実行するので、以下では、決済の形態に関する情報のことを、「課金情報」という。
ところで、「支払いユーザ装置」と「受け取りユーザ装置」との間における決済は、すなわち、『支払いユーザ』と『受け取りユーザ』との間における決済であることから、決済は、決済金額や決済の方式など、決済の形態に関する情報が、『支払いユーザ』によって認知された上で実行されるべきである。したがって、接続制御システムを構築するにあたっては、「決済用通信番号」をどのように払い出し、管理するべきであるのか、また、「課金情報」をどのように取り扱うべきであるのかが、特に重要な点になる。
［実施例１における接続制御システムの概要および特徴］
続いて、図１を用いて、実施例１における接続制御システムの概要および特徴を説明する。図１は、実施例１における接続制御システムの概要および特徴を説明するための図である。なお、以下の実施例では、ひとつの「接続制御装置」が、ひとつの「支払いユーザ装置」と、ひとつの「受け取りユーザ装置」とに通信可能に接続されて、ひとつの「支払いユーザ装置」と、ひとつの「受け取りユーザ装置」との接続を制御する構成を説明するが、この発明はこれに限られるものではなく、ひとつまたは複数の「接続制御装置」が、ひとつまたは複数の「支払いユーザ装置」と、ひとつまたは複数の「受け取りユーザ装置」とに通信可能に接続されて、ひとつまたは複数の「支払いユーザ装置」と、ひとつまたは複数の「受け取りユーザ装置」との接続を制御する構成にも、この発明を同様に適用することができる。
続いて、図１を用いて、実施例１における接続制御システムの概要および特徴を説明する。図１は、実施例１における接続制御システムの概要および特徴を説明するための図である。なお、以下の実施例では、ひとつの「接続制御装置」が、ひとつの「支払いユーザ装置」と、ひとつの「受け取りユーザ装置」とに通信可能に接続されて、ひとつの「支払いユーザ装置」と、ひとつの「受け取りユーザ装置」との接続を制御する構成を説明するが、この発明はこれに限られるものではなく、ひとつまたは複数の「接続制御装置」が、ひとつまたは複数の「支払いユーザ装置」と、ひとつまたは複数の「受け取りユーザ装置」とに通信可能に接続されて、ひとつまたは複数の「支払いユーザ装置」と、ひとつまたは複数の「受け取りユーザ装置」との接続を制御する構成にも、この発明を同様に適用することができる。
実施例１における接続制御システムは、上記したように、接続制御装置が、支払いユーザ装置と、支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、支払いユーザ装置と受け取りユーザ装置との接続を制御することを概要とし、さまざまな形態の決済を簡易に実行し、また、支払いユーザにとって予期せぬ決済が実行される危険を回避し、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することを主たる特徴とする。
この主たる特徴について簡単に説明すると、実施例１における接続制御システムの接続制御装置は、決済用通信番号（電話番号）に対応づけて管理する課金ポリシーに基づいて課金情報を決定する『着ＩＤ ＤＢ』（特許請求の範囲に記載の「課金情報データベース」に対応する）に通信可能に接続される。具体的には、『着ＩＤ ＤＢ』は、図１に示すように、決済用通信番号（図１の『着ＩＤ ＤＢ』の「着ＩＤ」列を参照）として、例えば、「０５０−ＥＥＥＥ−ＸＸＸＸ」といった電話番号を保持し、この決済用通信番号に対応づけて、課金ポリシー（図１の『着ＩＤ ＤＢ』の「課金額」の列を参照）を管理する。課金情報は、課金ポリシーに基づいて決定されるので、例えば、決済用通信番号「０５０−ＥＥＥＥ−ＸＸＸＸ」の決済の課金情報は、「課金額は４，５００円である」という情報である。なお、実施例１における接続制御システムの『着ＩＤ ＤＢ』は、決済用通信番号として電話番号を保持する手法であるが、この発明はこれに限られるものではなく、システム構成によって、決済用通信番号としてＵＲＬ（Uniform Resource Locator）を保持する手法や、その他の識別子を保持する手法などにも、この発明を同様に適用することができる。
また、実施例１における接続制御システムの接続制御装置は、支払いユーザ装置の課金額を管理する『アカウントシステム』（特許請求の範囲に記載の「管理部」に対応する）に通信可能に接続される。具体的には、『アカウントシステム』は、図１に示すように、支払いユーザ装置を識別するＩＤ（図１の『アカウントシステム』の「課金対象ユーザＩＤ」の列を参照）ごとに、課金額（図１の『アカウントシステム』の「課金額」の列を参照）を管理する。例えば、ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」の支払いユーザ装置の課金額は、「１，９２０円」である。なお、実施例１における接続制御システムの『アカウントシステム』は、支払いユーザ装置を識別する電話番号ごとに課金額を管理するデータベースを保持する手法であるが、この発明はこれに限られるものではなく、支払いユーザ装置の課金額を管理するシステムであれば、その構築手法はいずれでもよい。
また、実施例１において、受け取りユーザは、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者からひとつまたは複数の着ＩＤ（決済用通信番号）を払い出されている。例えば、受け取りユーザは、受け取りユーザ装置を識別する決済用通信番号として、電話番号「０５０−ＥＥＥＥ−ＸＸＸＸ」を払い出されているものとする。一方、支払いユーザは、支払いユーザ装置を識別する電話番号として、電話番号「０５０−ＹＹＹＹ−ＸＸＸＸ」を払い出されているものとする。さらに、実施例１において、支払いユーザは、受け取りユーザからある物財を購入したものとし、その物財の代金を支払うという決済の形態に対応づけられた決済用通信番号として、受け取りユーザ装置を識別する電話番号「０５０−ＥＥＥＥ−ＸＸＸＸ」を知らされているものとする。なお、実施例においては、説明の便宜上から、電話番号を、例えば「０５０−ＥＥＥＥ−ＸＸＸＸ」のように、アルファベットを組み合わせて表記するが、実際は、電気通信事業者から払い出される一般的な電話番号（数字）であって、アルファベットの選択や組み合わせに何ら特別の意味があるものではない。
このような構成のもと、実施例１に係る支払いユーザ装置は、まず、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を、接続制御装置に送信する（図１の（１）を参照）。具体的には、支払いユーザ装置は、決済用通信番号「０５０−ＥＥＥＥ−ＸＸＸＸ」で識別される受け取りユーザ装置に対する接続要求を送信する。
すると、実施例１に係る接続制御装置は、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、決済用通信番号に対応づけられた課金情報を取得して、支払いユーザ装置に送信する（図１の（２）および（３）を参照）。具体的には、接続制御装置は、『着ＩＤ ＤＢ』から決済用通信番号「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金情報「４，５００円」を取得して、支払いユーザ装置に送信する。
次に、実施例１に係る支払いユーザ装置は、決済用通信番号に対応づけられた課金情報を接続制御装置から受信して、課金情報を所定の出力部に出力する（図１の（４）を参照）。具体的には、支払いユーザ装置は、決済用通信番号「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金情報「４，５００円」を接続制御装置から受信して、課金情報として、例えば、「課金額は４，５００円です。課金に同意される場合には、１と＃（シャープ）を押してください。」の音声をスピーカーに出力する。
そして、支払いユーザ装置は、出力された課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付ける（図１の（５）を参照）。具体的には、支払いユーザ装置は、スピーカーに出力された音声「課金額は４，５００円です。」に同意することを示す同意情報の入力を、ＩＰ電話端末のプッシュボタンにおいて受け付ける。
続いて、支払いユーザ装置は、受け付けられた同意情報を、接続制御装置に送信する（図１の（６）を参照）。例えば、支払いユーザ装置は、「１」および「＃」がプッシュボタンによって入力されたことを契機として、通話制御プロトコルのひとつであるＳＩＰ（Session Initiation Protocol）に基づく接続要求メッセージ（INVITEメッセージ）に、同意情報を含めるなどして、接続制御装置に送信する。
すると、実施例１に係る接続制御装置は、課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の課金額に、課金情報に基づく課金額を加算するように格納する（図１の（７）を参照）。具体的には、接続制御装置は、支払いユーザ装置（「０５０−ＹＹＹＹ−ＸＸＸＸ」）の課金額を管理する『アカウントシステム』の課金額「１，９２０円」に、課金情報に基づく課金額「４，５００円」を加算するように格納する。
また、実施例１に係る接続制御装置は、同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続する（図１の（８）を参照）。具体的には、接続制御装置は、電話番号「０５０−ＹＹＹＹ−ＸＸＸＸ」で識別される支払いユーザ装置と、電話番号「０５０−ＥＥＥＥ−ＸＸＸＸ」で識別される受け取りユーザ装置とを接続する。
このようにして、実施例１における接続制御システムは、さまざまな形態の決済を簡易に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
ところで、実施例１における接続制御システムの『着ＩＤ ＤＢ』（課金情報データベース）は、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを変更するものであって、実施例１に係る接続制御装置は、上記した主たる特徴の他に、課金情報データベースが管理する課金ポリシーが更新された後に接続要求を支払いユーザ装置から受信した場合に、更新された後の課金ポリシーに基づいて決定された課金情報を取得して支払いユーザ装置に送信し、更新された後の課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、『アカウントシステム』（管理部）の支払いユーザ装置の課金額に、更新された後の課金情報に基づく課金額を加算するように格納し、また、支払いユーザ装置と受け取りユーザ装置とを接続することにも特徴がある。
［実施例１における接続制御システムの構成］
次に、図２〜図７を用いて、実施例１における接続制御システムを説明する。図２は、実施例１における接続制御システムの構成を示すブロック図であり、図３は、実施例１における課金同意確認ＵＩ部を説明するための図であり、図４は、課金情報を説明するための図であり、図５は、同意情報を説明するための図であり、図６は、実施例１における着ＩＤ ＤＢを説明するための図であり、図７は、実施例１におけるアカウントシステムを説明するための図である。
次に、図２〜図７を用いて、実施例１における接続制御システムを説明する。図２は、実施例１における接続制御システムの構成を示すブロック図であり、図３は、実施例１における課金同意確認ＵＩ部を説明するための図であり、図４は、課金情報を説明するための図であり、図５は、同意情報を説明するための図であり、図６は、実施例１における着ＩＤ ＤＢを説明するための図であり、図７は、実施例１におけるアカウントシステムを説明するための図である。
図２に示すように、実施例１における接続制御システムは、支払いユーザ装置１０と、接続制御装置２０と、着ＩＤ ＤＢ３０と、アカウントシステム４０と、受け取りユーザ装置５０とから構成される。
実施例１における支払いユーザ装置１０は、ＩＰ電話端末（例えば、電話機、情報家電、ファクシミリ、パーソナルコンピュータ、電話機およびホームゲートウェイなどの組合せなど）であり、特にこの発明に密接に関連するものとしては、図２に示すように、接続起動ＵＩ部１１と、通信部１２と、課金同意確認ＵＩ部１３と、課金情報受信部１４と、同意送信部１５とを備える。なお、課金同意確認ＵＩ部１３および課金情報受信部１４は、特許請求の範囲に記載の「課金情報出力手段」に対応し、課金同意確認ＵＩ部１３は、特許請求の範囲に記載の「同意情報受付手段」にも対応し、また、同意送信部１５は、特許請求の範囲に記載の「同意情報送信手段」に対応する。
接続起動ＵＩ部１１は、支払いユーザ装置１０を利用する支払いユーザによる着ＩＤ（決済用通信番号）の入力を受け付け、着ＩＤで識別される受け取りユーザ装置５０に対する接続要求を行う。具体的には、接続起動ＵＩ部１１は、支払いユーザによる着ＩＤ（決済用通信番号）の入力を受け付け、受け付けられた着ＩＤ（決済用通信番号）を、通信部１２を介して接続制御装置２０に送信する。
例えば、接続起動ＵＩ部１１は、番号キーおよび接続ボタンを備え、番号キーによる番号入力および接続ボタンの押し下げを検知して、番号入力された着ＩＤ（決済用通信番号）で識別される受け取りユーザ装置５０に対する接続要求を起動する。具体的に例を挙げて説明すると、接続起動ＵＩ部１１は、番号キーによる番号入力「０５０−ＥＥＥＥ−ＸＸＸＸ」および接続ボタンの押し下げを検知して、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」で識別される受け取りユーザ装置５０に対する接続要求を起動する。また、例えば、接続起動ＵＩ部１１は、接続要求として、通話制御プロトコルのひとつであるＳＩＰ（Session Initiation Protocol）に基づく接続要求メッセージ（INVITEメッセージ）を、通信部１２を介して接続制御装置２０に送信する。
通信部１２は、接続制御装置２０や受け取りユーザ装置５０とデータを送受信する。具体的には、通信部１２は、接続起動ＵＩ部１１によって受け付けられた接続要求を接続制御装置２０に送信し、また、接続制御装置２０から受信した課金情報を課金情報受信部１４に送信し、さらに、同意送信部１５によって送信された同意情報を接続制御装置２０に送信するなどする。例えば、通信部１２は、ＩＰ（Internet Protocol）通信用の一般的なインタフェースおよびライブラリを備え、接続に関する制御メッセージを送受信する機能を備える。また、例えば、通信部１２は、接続制御装置２０から課金情報を含む制御メッセージを受信した場合に、課金情報受信部１４を起動するなどする。
課金同意確認ＵＩ部１３は、着ＩＤ（決済用通信番号）に対応づけられた課金情報を接続制御装置２０から受信した場合に、課金情報をプレゼンテーション（所定の出力部に出力）する。また、課金同意確認ＵＩ部１３は、プレゼンテーションされた課金情報に同意することを示す同意情報の入力を所定の入力部において受け付ける。具体的には、課金同意確認ＵＩ部１３は、課金情報を通信部１２を介して接続制御装置２０から受信した場合に、課金情報をプレゼンテーション（所定の出力部に出力）し、支払いユーザに同意情報の入力を促す。また、課金同意確認ＵＩ部１３は、支払いユーザによる同意情報の入力を所定の入力部において受け付け、受け付けた同意情報を、同意送信部１５に送信する。
例えば、課金同意確認ＵＩ部１３は、図３の（Ａ）に示すように、支払いユーザ装置１０が電話機である場合に、課金情報として、「課金額は４，５００円です。課金に同意される場合には、１と＃（シャープ）を押してください。」の音声をスピーカーに出力し、同意情報として、「１」および「＃」を番号キーにおいて受け付ける。また、例えば、課金同意確認ＵＩ部１３は、図３の（Ｂ）に示すように、支払いユーザ装置１０がパーソナルコンピュータである場合に、課金情報として、「課金額は４，５００円です。」の文字をモニタに出力し、同意情報として、「同意する」のアイコンをマウスなどによってクリックされた情報を受け付ける。
課金情報受信部１４は、着ＩＤ（決済用通信番号）に対応づけられた課金情報を接続制御装置２０から受信する。具体的には、課金情報受信部１４は、着ＩＤ（決済用通信番号）に対応づけられた課金情報を、通信部１２を介して接続制御装置２０から受信し、受信した課金情報を、課金同意確認ＵＩ部１３に送信する。例えば、課金情報受信部１４は、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金情報「４，５００円」を、通信部１２を介して接続制御装置２０から受信する。また、例えば、課金情報受信部１４は、通信部１２を介して接続制御装置２０から課金情報を含む制御メッセージを受信した場合に、制御メッセージから課金情報を抽出するなどする。
具体的に例を挙げて説明すると、課金情報受信部１４は、図４に示すような課金情報を受信する。図４は、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）に対する拒否応答（４０１ Unauthorized）に添付されるコンテンツデータに、課金情報を含めるなどした場合を示すものである。図４の１行目「PaymentNumber：050-EEEE-XXXX」は、決済用通信番号が『０５０−ＥＥＥＥ−ＸＸＸＸ』であることを示しており、２行目「Money：4500」は、課金額が『４，５００』であることを示しており、３行目「Currency：Yen」は、通貨単位が『円』であることを示しており、４行目「PaidTo：ABC Company」は、受け取りユーザの名称が『ABC Company』であることを示している。
同意送信部１５は、同意情報を接続制御装置２０に送信する。具体的には、同意送信部１５は、課金同意確認ＵＩ部１３によって受け付けられた同意情報を、通信部１２を介して接続制御装置２０に送信する。例えば、同意送信部１５は、同意情報として、「１」および「＃」が番号キーによって入力されたことを契機として、同意情報を通信部１２を介して接続制御装置２０に送信する。また、例えば、同意送信部１５は、同意情報として、「同意する」のアイコンをマウスなどによってクリックされたことを契機として、同意情報を通信部１２を介して接続制御装置２０に送信する。
具体的に例を挙げて説明すると、同意情報送信部１５は、図５に示すような同意情報を受信する。図５は、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ情報に加えて、同意情報を含めるなどした場合の、ひとつのパートを示すものである。図５の１行目「PaymentNumber：050-EEEE-XXXX」は、決済用通信番号が『０５０−ＥＥＥＥ−ＸＸＸＸ』であることを示しており、２行目「Money：4500」は、課金額が『４，５００』であることを示しており、３行目「Currency：Yen」は、通貨単位が『円』であることを示しており、４行目「PaidTo：ABC Company」は、受け取りユーザの名称が『ABC Company』であることを示しており、５行目「PaidBy：Tokyo Ichiro」は、支払いユーザの名称（氏名）が『Tokyo Ichiro』であることを示しており、６行目「Date：2006/06/22 10:00:00」は、日時を示しており、７行目「TransactionID：0243231」は、送信を識別する番号を示しており、８行目「AgreedBy：Tokyo Ichiro」は、『Tokyo Ichiroが、上記の情報に同意すること』を示している。
実施例１における接続制御装置２０は、汎用的なコンピュータで構築されるサーバ装置であり、特にこの発明に密接に関連するものとしては、図２に示すように、ユーザ装置向け通信部２１と、課金情報送信部２２と、課金情報取得部２３と、同意確認部２４と、接続処理部２５と、課金指示部２６とを備える。なお、課金情報送信部２２および課金情報取得部２３は、特許請求の範囲に記載の「課金情報送信手段」に対応し、同意確認部２４および課金指示部２６は、特許請求の範囲に記載の「課金情報格納手段」に対応し、また、同意確認部２４および接続処理部２５は、特許請求の範囲に記載の「接続手段」に対応する。
ユーザ装置向け通信部２１は、支払いユーザ装置１０および受け取りユーザ装置５０とデータを送受信する。具体的には、ユーザ装置向け通信部２１は、支払いユーザ装置１０から受信した受け取りユーザ装置５０に対する接続要求を同意確認部２４に送信し、また、課金情報送信部２２によって送信された課金情報を支払いユーザ装置１０に送信し、さらに、支払いユーザ装置１０から受信した同意情報を同意確認部２４に送信するなどする。例えば、ユーザ装置向け通信部２１は、ＩＰ（Internet Protocol）通信用の一般的なインタフェースおよびライブラリを備え、接続に関する制御メッセージを送受信する機能を備える。
課金情報送信部２２は、着ＩＤ（決済用通信番号）に対応づけられた課金情報を支払いユーザ装置１０に送信する。具体的には、課金情報送信部２２は、課金情報取得部２３によって取得された課金情報を、ユーザ装置向け通信部２１を介して支払いユーザ装置１０に送信する。例えば、課金情報送信部２２は、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金情報として「４，５００円」を、ユーザ装置向け通信部２１を介して支払いユーザ装置１０に送信する。また、例えば、課金情報送信部２２は、課金情報を、同意確認部２４において受信された接続要求に対する拒否応答（４０１ Unauthorized）に添付されるコンテンツデータとして送信するなどする。
ここで、実施例１における課金情報送信部２２は、実施例１における着ＩＤ ＤＢ３０が、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新するものであることから、課金情報取得部２３において、着ＩＤ ＤＢ３０が管理する課金ポリシーが更新された後の課金ポリシーに基づいて決定された課金情報が取得された場合には、更新された後の課金ポリシーに基づいて決定された課金情報を支払いユーザ装置１０に送信する。
課金情報取得部２３は、着ＩＤ（決済用通信番号）に対応づけられた課金情報を取得する。具体的には、課金情報取得部２３は、着ＩＤ（決済用通信番号）で識別される受け取りユーザ装置５０に対する接続要求が支払いユーザ装置１０から受信された場合（接続要求を受信したことを示す情報を同意確認部２４から受信した場合）に、着ＩＤ（決済用通信番号）に対応づけられた課金情報を着ＩＤ ＤＢ３０からＳＱＬ（Structured Query Language）参照などで取得し、取得した情報を、課金情報送信部２２に送信する。
例えば、課金情報取得部２３は、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金情報として「４，５００円」を着ＩＤ ＤＢ３０から取得する。ここで、実施例１における課金情報取得部２３は、実施例１における着ＩＤ ＤＢ３０が、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新するものであることから、着ＩＤ ＤＢ３０が管理する課金ポリシーが更新された後に接続要求が支払いユーザ装置１０から受信された場合には、更新された後の課金ポリシーに基づいて決定された課金情報を取得する。
同意確認部２４は、接続要求または同意情報を支払いユーザ装置１０から受信した場合に、受信した接続要求が同意情報を含むか否かを確認し、確認の結果に基づき、確認の結果を課金情報取得部２３または接続処理部２５に送信する。具体的には、同意確認部２４は、着ＩＤ（決済用通信番号）で識別される受け取りユーザ装置５０に対する接続要求を支払いユーザ装置１０から受信した場合に、接続要求を受信したことを示す情報（同意情報を受信していないことを示す情報）を課金情報取得部２３に送信し、課金情報に同意することを示す同意情報を支払いユーザ装置１０から受信した場合に、同意情報を受信したことを示す情報を接続処理部２５に送信する。例えば、同意確認部２４は、ＳＩＰに基づく接続要求メッセージのボディ部に、同意情報が含まれているか否かを確認する。
接続処理部２５は、支払いユーザ装置１０と受け取りユーザ装置５０とを接続する。具体的には、接続処理部２５は、同意情報が支払いユーザ装置１０から受信された場合（同意情報を受信したことを示す情報を同意確認部２４から受信した場合）に、支払いユーザ装置１０と受け取りユーザ装置５０とを接続する。例えば、接続処理部２５は、通話制御プロトコルのひとつであるＳＩＰに基づく制御によって、支払いユーザ装置１０と受け取りユーザ装置５０とを接続する。
課金指示部２６は、支払いユーザ装置１０の課金額を管理するアカウントシステム４０の課金額に、課金情報に基づく課金額を加算するように格納する。具体的には、課金指示部２６は、課金情報に同意することを示す同意情報が支払いユーザ装置１０から受信された場合（同意情報を受信したことを示す情報を、接続処理部２５を介して同意確認部２４から受信した場合）に、支払いユーザ装置１０の課金額を管理するアカウントシステム４０に、課金情報に基づく課金額および課金対象ユーザＩＤ（支払いユーザ装置１０のＩＤ）を送信する。例えば、課金指示部２６は、課金情報（「４，５００円」）に基づく課金額（４，５００円）および課金対象ユーザＩＤ（「０５０−ＹＹＹＹ−ＸＸＸＸ」）を、アカウントシステム４０に送信する。
ここで、実施例１における課金指示部２６は、実施例１における着ＩＤ ＤＢ３０が、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新するものであることから、着ＩＤ ＤＢ３０が管理する課金ポリシーが更新された後に接続要求が支払いユーザ装置１０から受信された場合には、アカウントシステム４０に、更新された後の課金情報に基づく課金額および課金対象ユーザＩＤを送信する。
着ＩＤ ＤＢ３０は、着ＩＤ（決済用通信番号）に対応づけて管理する課金ポリシーに基づいて課金情報を決定する。具体的には、着ＩＤ ＤＢ３０は、課金情報取得部２３から着ＩＤ（決済用通信番号）を受信し、受信した着ＩＤに対応づけて管理する課金ポリシーに基づいて課金情報を決定し、決定した課金情報を課金情報取得部２３に送信する。また、実施例１における着ＩＤ ＤＢ３０は、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新する。
例えば、着ＩＤ ＤＢ３０は、汎用的なコンピュータに、ＲＤＢＭＳ（Relational DataBase Management System）プログラムを稼動させ、「着ＩＤ」や「課金額」などを列とするテーブルを定義することによって実現される。具体的に例を挙げて説明すると、着ＩＤ ＤＢ３０は、図６の（Ａ）に示すように、「着ＩＤ（受け取りユーザ装置）」、「発ＩＤ（支払いユーザ装置）」、および「課金額」を列とするテーブルを定義する。図６の（Ａ）の着ＩＤ「０５０−ＡＡＡＡ−ＸＸＸＸ」に対応づけて管理する課金ポリシーは、「発ＩＤによって区別することなく（Ａｎｙ）、課金額は５００円である。」であり、このような課金ポリシーに基づいて課金情報（「５００円」）を決定することを示す。
また、図６の（Ａ）の着ＩＤ「０５０−ＣＣＣＣ−ＸＸＸＸ」に対応づけて管理する課金ポリシーは、「発ＩＤが『０１１−＊＊＊−＊＊＊＊』である場合には、課金額は２，０００円である。発ＩＤが『０２２−＊＊＊−＊＊＊＊』である場合には、課金額は１，５００円である。発ＩＤが『０３−＊＊＊＊−＊＊＊＊』である場合には、課金額は１，０００円である。・・・」であり、このような課金ポリシーに基づいて課金情報（「２，０００円」、「１，５００円」、「１，０００円」など）を決定することを示す。このような課金ポリシーが管理される場面としては、例えば、支払いユーザが受け取りユーザから物財を購入し、受け取りユーザから支払いユーザに対して物財の配送が行われるような取引の決済において、受け取りユーザが支払いユーザに対する物財の配送料金を回収するにあたり、地域ごとに課金金額を異なるものにしたい場面などが想定される。
また、図６の（Ａ）の着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけて管理する課金ポリシーは、「発ＩＤによって区別することなく（Ａｎｙ）、課金額は１，２６０円である。」であり、このような課金ポリシーに基づいて課金情報（「１，２６０円」）を決定することを示す。ここで、実施例１における着ＩＤ ＤＢ３０は、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新する。図６の（Ｂ）は、変更指示に従って課金ポリシーを更新した着ＩＤ ＤＢ３０を示すものであるが、図６の（Ｂ）の着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけて管理する課金ポリシーは、「発ＩＤによって区別することなく（Ａｎｙ）、課金額は４，５００円である。」であり、このような課金ポリシーに基づいて課金情報（「４，５００円」）を決定することを示しており、更新される前の課金ポリシーに基づいて決定された課金情報（「１，２６０円」）と、更新された後の課金ポリシーに基づいて決定された課金情報（「４，５００円」）とでは、課金ポリシーに基づいて決定される課金情報が異なることになる。
同様に、図６の（Ｂ）の着ＩＤ「０５０−ＣＣＣＣ−ＸＸＸＸ」に対応づけて管理する課金ポリシーは、「発ＩＤによって区別することなく（Ａｎｙ）、課金額は１，０００円である。」であり、このような課金ポリシーに基づいて課金情報（「１，０００円」）を決定することを示しており、更新される前の課金ポリシーに基づいて決定された課金情報（「２，０００円」、「１，５００円」、「１，０００円」など）と、更新された後の課金ポリシーに基づいて決定された課金情報（「１，０００円」）とでは、課金ポリシーに基づいて決定される課金情報が異なることになる。
このように、実施例１における着ＩＤ ＤＢ３０は、例えば、Ｗｅｂサーバの技術などを用いて、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新するものであることから、接続制御装置２０は、着ＩＤ ＤＢ３０が管理する課金ポリシーが更新された後に、接続要求を支払いユーザ装置１０から受信した場合には、課金情報取得部２３において、更新された後の課金ポリシーに基づいて決定された課金情報を着ＩＤ ＤＢ３０から取得して支払いユーザ装置１０に送信する。また、接続制御装置２０は、同様に、課金指示部２６において、更新された後の課金ポリシーに基づいて決定された課金情報に基づく課金額を加算するようにアカウントシステム４０に格納する。
なお、実施例１においては、図６に示すように、着ＩＤ ＤＢ３０が、「着ＩＤ（受け取りユーザ装置）」、「発ＩＤ（支払いユーザ装置）」、および「課金額」を列とするテーブルを定義し、発ＩＤ（支払いユーザ装置）によって決定される課金情報が異なる課金ポリシーなどを含んで管理する手法を説明したが、この発明はこれに限られるものではなく、「着ＩＤ（受け取りユーザ装置）」および「課金額」を列とするテーブルを定義し、発ＩＤ（支払いユーザ装置）によって課金情報が異ならない課金ポリシーのみを管理する手法など、着ＩＤ（決済用通信番号）に対応づけて管理する課金ポリシーに基づいて課金情報を決定するデータベースであれば、その定義手法はいずれでもよい。
アカウントシステム４０は、支払いユーザ装置１０の課金額を管理する。具体的には、アカウントシステム４０は、課金指示部２６から課金情報に基づく課金額および課金対象ユーザＩＤ（支払いユーザ装置１０のＩＤ）を受信し、管理する課金対象ユーザＩＤ（支払いユーザ装置１０のＩＤ）の課金額に、受信した課金額を加算する。
例えば、アカウントシステム４０は、汎用的なコンピュータにこのような機能を有するプログラムを稼動させることによって実現される。具体的に例を挙げて説明すると、アカウントシステム４０は、図７に示すように、「発ＩＤ（支払いユーザ装置）」、「着ＩＤ（受け取りユーザ装置）」、および「課金額」を列とするテーブルを定義する。図７の発ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」の課金額は、着ＩＤ「０５０−ＢＢＢＢ−ＸＸＸＸ」に接続した際に「１，９２０円」であり、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に接続した際に「４，５００円」であり、課金額合計が、「６，４２０円」であることを示す。
なお、実施例１においては、図７に示すように、アカウントシステム４０が、「発ＩＤ（支払いユーザ装置）」、「着ＩＤ（受け取りユーザ装置）」、および「課金額」を列とするテーブルを定義し、発ＩＤ（支払いユーザ装置）ごと、かつ、着ＩＤ（受け取りユーザ装置）ごとの課金額を管理する手法を説明したが、この発明はこれに限られるものではなく、「発ＩＤ（支払いユーザ装置）」および「課金額」を列とするテーブルを定義し、発ＩＤ（支払いユーザ装置）ごとの課金額合計のみを管理する手法など、支払いユーザ装置１０の課金額を管理するシステムであれば、その構築手法はいずれでもよい。
実施例１における受け取りユーザ装置５０は、ＩＰ電話端末（例えば、電話機、情報家電、ファクシミリ、パーソナルコンピュータ、電話機およびホームゲートウェイなどの組合せなど）であり、特にこの発明に密接に関連するものとしては、図２に示すように、通信部５１を備える。
通信部５１は、支払いユーザ装置１０や接続制御装置２０とデータを送受信する。具体的には、通信部５１は、接続制御装置２０によって接続された支払いユーザ装置１０とデータを送受信する。例えば、通信部５１は、ＩＰ（Internet Protocol）通信用の一般的なインタフェースおよびライブラリを備え、接続に関する制御メッセージを送受信する機能を備える。
［実施例１における接続制御システムによる処理の手順］
次に、図８を用いて、実施例１における接続制御システムによる処理の手順を説明する。図８は、実施例１における接続制御システムによる処理の手順を示すシーケンス図である。ここで、実施例１において、受け取りユーザは、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者から着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」（以下、「Ｒ」という）を払い出されているものとする。一方、支払いユーザは、支払いユーザを識別する電話番号として、電気通信事業者から発ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」（以下、「Ｓ」という）を払い出されているものとする。また、実施例１において、支払いユーザは、受け取りユーザからある物財を購入したものとし、その物財の代金を支払うという決済の形態に対応づけられた決済用通信番号として、受け取りユーザを識別する着ＩＤ「Ｒ」を知らされているものとする。
次に、図８を用いて、実施例１における接続制御システムによる処理の手順を説明する。図８は、実施例１における接続制御システムによる処理の手順を示すシーケンス図である。ここで、実施例１において、受け取りユーザは、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者から着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」（以下、「Ｒ」という）を払い出されているものとする。一方、支払いユーザは、支払いユーザを識別する電話番号として、電気通信事業者から発ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」（以下、「Ｓ」という）を払い出されているものとする。また、実施例１において、支払いユーザは、受け取りユーザからある物財を購入したものとし、その物財の代金を支払うという決済の形態に対応づけられた決済用通信番号として、受け取りユーザを識別する着ＩＤ「Ｒ」を知らされているものとする。
まず、支払いユーザ装置１０における接続起動ＵＩ部１１は、支払いユーザによる着ＩＤ（Ｒ）の入力を受け付け、接続を起動される（ステップＳ１１）。具体的には、支払いユーザ装置１０における接続起動ＵＩ部１１は、支払いユーザによる番号キーおよび接続ボタンの押し下げを検知して、番号入力された着ＩＤ（Ｒ）で識別される受け取りユーザ装置５０に対する接続要求を起動する。
そして、支払いユーザ装置１０における接続起動ＵＩ部１１は、番号入力された着ＩＤ（Ｒ）で識別される受け取りユーザ装置５０に対する接続要求を送信する（ステップＳ１２）。具体的には、支払いユーザ装置１０における接続起動ＵＩ部１１は、番号入力された着ＩＤ（Ｒ）を、通話制御プロトコルのひとつであるＳＩＰ（Session Initiation Protocol）に基づく接続要求メッセージ（INVITEメッセージ）に含めて、通信部１２を介して接続制御装置２０に送信する。
すると、接続制御装置２０における同意確認部２４は、接続要求または同意情報を支払いユーザ装置１０から受信した場合に、受信した情報が接続要求であるのか同意情報であるのかを確認する（ステップＳ２１）。具体的には、接続制御装置２０における同意確認部２４は、着ＩＤ（Ｒ）で識別される受け取りユーザ装置５０に対する接続要求を支払いユーザ装置１０から受信した場合に、接続要求を受信したことを示す情報を課金情報取得部２３に送信する。
次に、接続制御装置２０における課金情報取得部２３は、着ＩＤ ＤＢ３０から着ＩＤ（Ｒ）に対応づけられた課金情報を取得する（ステップＳ２２）。具体的には、接続制御装置２０における課金情報取得部２３は、着ＩＤ（Ｒ）で識別される受け取りユーザ装置５０に対する接続要求が支払いユーザ装置１０から受信された場合に、着ＩＤ（Ｒ）に対応づけられた課金情報（例えば、「４，５００円」など）を着ＩＤ ＤＢ３０から取得し、取得した情報を、課金情報送信部２２に送信する。
続いて、接続制御装置２０における課金情報送信部２２は、着ＩＤ（Ｒ）に対応づけられた課金情報を支払いユーザ装置１０に送信する（ステップＳ２３）。具体的には、接続制御装置２０における課金情報送信部２２は、着ＩＤ（Ｒ）に対応づけられた課金情報（例えば、「４，５００円」など）を、同意確認部２４において受信された接続要求に対する拒否応答（４０１ Unauthorized）に添付されるコンテンツデータなどとして、ユーザ装置向け通信部２１を介して支払いユーザ装置１０に送信する。
すると、支払いユーザ装置１０における課金情報受信部１４は、着ＩＤ（Ｒ）に対応づけられた課金情報を接続制御装置２０から受信する（ステップＳ３１）。具体的には、支払いユーザ装置１０における課金情報受信部１４は、課金情報を含む制御メッセージを通信部１２を介して接続制御装置２０から受信し、制御メッセージから着ＩＤ（Ｒ）に対応づけられた課金情報（例えば、「４，５００円」など）を抽出し、抽出した課金情報を課金同意確認ＵＩ部１３に送信する。
そして、支払いユーザ装置１０における課金同意確認ＵＩ部１３は、着ＩＤ（Ｒ）に対応づけられた課金情報を接続制御装置２０から受信した場合に、課金情報をプレゼンテーションし、支払いユーザに同意情報の入力を促す（ステップＳ３２）。具体的には、支払いユーザ装置１０における課金同意確認ＵＩ部１３は、着ＩＤ（Ｒ）に対応づけられた課金情報（例えば、「４，５００円」など）を通信部１２を介して受信した場合に、課金情報として、例えば、「課金額は４，５００円です。課金に同意される場合には、１と＃（シャープ）を押してください。」の音声をスピーカーに出力する。
すると、支払いユーザによって同意情報が入力され（ステップＳ４１）、支払いユーザ装置１０における課金同意確認ＵＩ部１３は、プレゼンテーションされた課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付ける。具体的には、支払いユーザ装置１０における課金同意確認ＵＩ部１３は、「１」および「＃」を番号キーにおいて受け付ける。
次に、支払いユーザ装置１０における同意送信部１５は、同意情報を接続制御装置２０に送信する（ステップＳ４２）。具体的には、支払いユーザ装置１０における同意送信部１５は、課金同意確認ＵＩ部１３において、「１」および「＃」が番号キーによって入力されたことを契機として、同意情報を接続制御装置２０に送信する。例えば、同意送信部１５は、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ情報に加えて同意情報をボディ部に含めるなどして、通信部１２を介して接続制御装置２０に送信する。
続いて、接続制御装置２０における同意確認部２４は、接続要求を支払いユーザ装置１０から受信した場合に、受信した接続要求が同意情報を含むか否かを確認する（ステップＳ５１）。具体的には、接続制御装置２０における同意確認部２４は、課金情報に同意することを示す同意情報を支払いユーザ装置１０から受信した場合に、同意情報を受信したことを示す情報を接続処理部２５に送信する。
すると、接続制御装置２０における接続処理部２５は、支払いユーザ装置１０と受け取りユーザ装置５０とを接続するために、支払いユーザ装置１０からの接続要求があることを示す接続メッセージを、受け取りユーザ装置５０に送信する（ステップＳ５２）。具体的には、接続制御装置２０における接続処理部２５は、接続メッセージとして、接続要求メッセージ（INVITEメッセージ）を、ユーザ装置向け通信部２１を介して受け取りユーザ装置５０に送信する。
そして、受け取りユーザ装置５０は、接続制御装置２０から接続メッセージを受信する（ステップＳ５２１）。具体的には、受け取りユーザ装置５０は、接続要求メッセージ（INVITEメッセージ）を、通信部５１を介して接続制御装置２０から受信する。ここで、実施例１における受け取りユーザ装置５０は、接続要求を受け付けるか否かの応答判断を行わず、常に正常応答を返すものであるので、応答を接続制御装置２０に送信する（ステップＳ５２２）。
次に、接続制御装置２０における課金指示部２６は、受け取りユーザ装置５０から応答を受信して（ステップＳ５３）、支払いユーザ装置１０の課金額を管理するアカウントシステム４０の課金額に、課金情報に基づく課金額を加算するように格納する（ステップＳ５４）。具体的には、接続制御装置２０における課金指示部２６は、受け取りユーザ装置５０からの応答が受信された場合に、課金情報（「４，５００円」）に基づく課金額（４，５００円）および課金対象ユーザＩＤ（Ｓ）を、アカウントシステム４０に送信する。ここで、課金情報については、ステップＳ２２と同じ手順により取得する場合や、ステップＳ４２で送信される同意情報に課金情報を含めるようにして取得する場合などが考えられる。また、課金対象ユーザＩＤ（Ｓ）については、支払いユーザ装置１０の電話番号から取得する。
また、接続制御装置２０における接続処理部２５は、受け取りユーザ装置５０から応答を受信して、支払いユーザ装置１０と受け取りユーザ装置５０とを接続し、支払いユーザ装置１０に接続完了通知を送信する（ステップＳ５５）。具体的には、接続制御装置２０における接続処理部２５は、受け取りユーザ装置５０から応答を受信して、通話制御プロトコルのひとつであるＳＩＰに基づく制御によって、支払いユーザ装置１０と受け取りユーザ装置５０とを接続し、支払いユーザ装置１０に接続完了通知を送信する。
このようにして、実施例１における接続制御システムは、さまざまな形態の決済を簡易に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
なお、実施例１においては、接続制御装置２０が受け取りユーザ装置５０から応答を受信して、まず、支払いユーザ装置１０の課金額をアカウントシステム４０に格納し、次に、支払いユーザ装置１０と受け取りユーザ装置５０とを接続する処理の手順を説明したが、この発明はこれに限られるものではなく、接続制御装置２０が受け取りユーザ装置５０から応答を受信して、まず、支払いユーザ装置１０と受け取りユーザ装置５０とを接続し、次に、支払いユーザ装置１０の課金額をアカウントシステム４０に格納する処理の手順など、支払いユーザ装置１０の課金額をアカウントシステム４０に格納する処理および支払いユーザ装置１０と受け取りユーザ装置５０とを接続する処理が行われる処理の手順であれば、その順序はいずれでもよい。
［実施例１の効果］
上記してきたように、実施例１によれば、支払いユーザ装置と支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、支払いユーザ装置と受け取りユーザ装置との接続を制御する接続制御装置であって、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、支払いユーザ装置に対する課金内容を示す情報として、決済用通信番号に対応づけられた課金情報を取得して支払いユーザ装置に送信し、課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の課金額に課金情報に基づく課金額を加算するように格納し、同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
上記してきたように、実施例１によれば、支払いユーザ装置と支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、支払いユーザ装置と受け取りユーザ装置との接続を制御する接続制御装置であって、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、支払いユーザ装置に対する課金内容を示す情報として、決済用通信番号に対応づけられた課金情報を取得して支払いユーザ装置に送信し、課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の課金額に課金情報に基づく課金額を加算するように格納し、同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、「支払いユーザ装置」に指定の時間（もしくは指定の回数）接続させる専用の装置を利用する従来の手法では、「支払いユーザ装置」は、接続の時間や接続の回数などに応じて課金される。これに対して、この発明に係る接続制御システムのように、「支払いユーザ装置」が課金情報を「接続制御装置」から受信し、課金情報に同意することを示す同意情報を「接続制御装置」に送信する手法では、接続の時間や接続の回数などに応じて課金されるわけではないので、従来の手法に比較して、さまざまな形態の決済を適切に実行することが可能になる。
また、「接続制御装置」が、決済用通信番号（電話番号）に対応づけられた課金情報（例えば、課金金額や課金方式など）を「支払いユーザ装置」に送信し、次に、「支払いユーザ装置」において、「接続制御装置」によって送信された課金情報が所定の出力部（例えば、モニタ、スピーカーなど）に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知され、そして、「支払いユーザ装置」によって受け付けられた『支払いユーザ』による同意を「接続制御装置」が受信した場合に、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続することから、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になる。
ひいては、特定の電話番号に対応づけられた課金金額や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態が変更された場合であっても、その都度、「支払いユーザ装置」において、「接続制御装置」によって送信された課金情報が所定の出力部に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知されるので、支払いユーザにとって予期せぬ決済が実行される危険を回避する結果、決済用通信番号（電話番号）に対応づけられた決済の形態を変更することもできることから、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
また、実施例１によれば、決済用通信番号で識別される受け取りユーザ装置に接続制御装置を介して通信可能に接続する支払いユーザ装置であって、課金内容を示す情報として、決済用通信番号に対応づけられた課金情報を接続制御装置から受信して、課金情報を所定の出力部に出力し、出力された課金情報に同意することを示す同意情報の入力を所定の入力部において受け付け、受け付けられた同意情報を、同意情報の受信を条件に受け取りユーザ装置との接続を許可する接続制御装置に送信するので、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、「支払いユーザ装置」に指定の時間（もしくは指定の回数）接続させる専用の装置を利用する従来の手法では、「支払いユーザ装置」は、接続の時間や接続の回数などに応じて課金される。これに対して、この発明に係る接続制御システムのように、「支払いユーザ装置」が課金情報を「接続制御装置」から受信し、課金情報に同意することを示す同意情報を「接続制御装置」に送信する手法では、接続の時間や接続の回数などに応じて課金されるわけではないので、従来の手法に比較して、さまざまな形態の決済を適切に実行することが可能になる。
また、「接続制御装置」によって、決済用通信番号（電話番号）に対応づけられた課金情報（例えば、課金金額や課金方式など）が「支払いユーザ装置」に送信され、次に、「支払いユーザ装置」が、「接続制御装置」から送信された課金情報を所定の出力部（例えば、モニタ、スピーカーなど）に出力することで、「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知され、そして、『支払いユーザ』による同意を「支払いユーザ装置」が受け付け「接続制御装置」に送信した場合に、「接続制御装置」によって、「支払いユーザ装置」が課金され、「支払いユーザ装置」と「受け取りユーザ装置」とが接続されることから、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になる。
ひいては、特定の電話番号に対応づけられた課金金額や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態が変更された場合であっても、支払いユーザにとって予期せぬ決済が実行される危険を回避する結果、決済用通信番号（電話番号）に対応づけられた決済の形態を変更することもできることから、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
また、実施例１によれば、接続制御装置が、決済用通信番号に対応づけて管理する課金ポリシーに基づいて課金情報を決定する課金情報データベースに通信可能に接続され、課金情報データベースから課金情報を取得して支払いユーザ装置に送信するので、「受け取りユーザ装置」に課金情報を要求して取得しなければならない手法に比較して、さまざまな形態の決済を簡易かつ適切に実行することが可能になる。
すなわち、「接続制御装置」において課金情報を取得するにあたり、「受け取りユーザ装置」に課金情報を要求して取得しなければならない手法では、「受け取りユーザ装置」に課金情報を管理する仕組みが必要になり、また、「受け取りユーザ装置」に処理の負荷がかかるおそれがあり、さらに、同意情報を「支払いユーザ装置」から受信しない場合にも、「接続制御装置」と「受け取りユーザ装置」との間で課金情報の送受信を行わなければならない。これに対して、「接続制御装置」と同じく網内（例えば、電気通信事業者によるネットワーク内など）に設置される課金情報データベースから課金情報を取得する手法では、「受け取りユーザ装置」に課金情報を管理する仕組みが不要になり、また、「受け取りユーザ装置」に処理の負荷がかかるおそれを回避でき、さらに、同意情報を「支払いユーザ装置」から受信しない場合には、網内で接続制御処理を完結できることから、さまざまな形態の決済を簡易かつ適切に実行することが可能になる。
また、実施例１によれば、課金情報データベースは、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新するものであって、接続制御装置は、課金情報データベースが管理する課金ポリシーが更新された後に接続要求を支払いユーザ装置から受信した場合に、更新された後の課金ポリシーに基づいて決定された課金情報を取得して支払いユーザ装置に送信し、更新された後の課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、管理部の支払いユーザ装置の課金額に更新された後の課金情報に基づく課金額を加算するように格納し、更新された後の課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、特定の電話番号に対応づけられた課金金額や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態が変更されても、「接続制御装置」が、更新後の課金情報を「支払いユーザ装置」に送信し、次に、「支払いユーザ装置」において、「接続制御装置」によって送信された更新後の課金情報が所定の出力部に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって更新後の決済の形態が認知され、そして、「支払いユーザ装置」によって受け付けられた『支払いユーザ』による同意を「接続制御装置」が受信した場合に、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続することから、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
ところで、これまで実施例１として、接続制御装置が課金情報を決定する課金情報データベースに通信可能に接続され、この課金情報データベースから課金情報を取得する手法を説明したが、この発明はこれに限られるものではなく、受け取りユーザ装置において課金情報を決定し、接続制御装置が受け取りユーザ装置において決定された課金情報を受け取りユーザ装置から受信して取得する手法にも、この発明を同様に適用することができる。以下では、実施例２として、接続制御装置が受け取りユーザ装置において決定された課金情報を受け取りユーザ装置から受信して取得する手法を、図９〜図１２を用いて説明する。
［実施例２における接続制御システムの概要および特徴］
まず、図９を用いて、実施例２における接続制御システムの概要および特徴を説明する。図９は、実施例２における接続制御システムの概要および特徴を説明するための図である。
まず、図９を用いて、実施例２における接続制御システムの概要および特徴を説明する。図９は、実施例２における接続制御システムの概要および特徴を説明するための図である。
実施例２における接続制御システムの接続制御装置は、実施例１と同様、支払いユーザ装置の課金額を管理する『アカウントシステム』に通信可能に接続されるが、実施例１と異なり、決済用通信番号（電話番号）に対応づけて管理する課金ポリシーに基づいて課金情報を決定する『着ＩＤ ＤＢ』に接続されない。
一方、実施例２における接続制御システムの受け取りユーザ装置は、実施例１と異なり、決済用通信番号に対応づけて課金ポリシーを管理する。具体的には、受け取りユーザ装置は、図９に示すように、受け取りユーザ装置を識別する着ＩＤ（図９の受け取りユーザ装置の『着ＩＤ（受け取りユーザ装置）』の列を参照）ごとに、課金額（図９の受け取りユーザ装置の『課金額』の列を参照）を管理する。なお、受け取りユーザ装置を識別する着ＩＤが複数であるのは、受け取りユーザによって複数の受け取りユーザ装置が運用されている場合を想定しているものであり、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者から複数の着ＩＤを払い出されていることを示す。
また、実施例２に係る受け取りユーザ装置は、図９に示すように、支払いユーザ装置を識別する発ＩＤ（図９の受け取りユーザ装置の『発ＩＤ（支払いユーザ装置）』の列を参照）ごとに、顧客ＩＤや購入履歴（図９の受け取りユーザ装置の『顧客ＩＤ』や『購入履歴』の列を参照）を管理する。さらに、実施例２における受け取りユーザ装置は、図９に示すように、購入履歴（図９の受け取りユーザ装置の『購入履歴』の列を参照）ごとに、割引率（図９の受け取りユーザ装置の『割引率』の列を参照）を管理する。
実施例２に係る受け取りユーザ装置は、このように、着ＩＤごとの通常の課金額と、発ＩＤ（顧客ＩＤ）ごとの購入履歴と、購入履歴ごとの割引率とを課金ポリシーとして管理し、これらの課金ポリシーに基づいて課金情報を決定する。また、受け取りユーザ装置は、これらの課金ポリシーを自由かつ柔軟に変更することができる。なお、実施例２においては、受け取りユーザ装置が、着ＩＤごとの通常の課金額と、発ＩＤ（顧客ＩＤ）ごとの購入履歴と、購入履歴ごとの割引率とを課金ポリシーとして管理する手法を説明したが、この発明はこれに限られるものではなく、着ＩＤごとの課金額のみを課金ポリシーとして管理する手法など、決済用通信番号に対応づけて課金ポリシーを管理する手法であれば、課金ポリシーの構成はいずれでもよい。
このような構成のもと、実施例２に係る支払いユーザ装置は、実施例１と同様、まず、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を、接続制御装置に送信する（図９の（１）を参照）。
すると、実施例２に係る接続制御装置は、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、実施例１と同様、決済用通信番号に対応づけられた課金情報を取得して、支払いユーザ装置に送信するが、実施例１と異なり、受け取りユーザ装置において決定された課金情報を受け取りユーザ装置から受信して支払いユーザ装置に送信する（図９の（２）および（３）を参照）。具体的には、接続制御装置は、課金情報の提供を受け取りユーザ装置に要求し、受け取りユーザ装置において決定された課金情報「４，２７５円」を取得して、支払いユーザ装置に送信する。
この時、実施例２に係る受け取りユーザ装置は、接続制御装置からの要求に応じて課金ポリシーに基づいて課金情報を決定し、決定された課金情報を接続制御装置に送信している。具体的には、受け取りユーザ装置は、発ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」に対応づけられた顧客「１」の購入履歴が「９回」で、割引率が「５％」であることから、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金額「４，５００円」から「５％」を割り引いた「４，２７５円」を、課金情報として決定し、接続制御装置に送信している。
次に、実施例２に係る支払いユーザ装置は、実施例１と同様、決済用通信番号に対応づけられた課金情報を接続制御装置から受信して、課金情報を所定の出力部に出力する（図９の（４）を参照）。そして、支払いユーザ装置は、実施例１と同様、出力された課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付ける（図９の（５）を参照）。続いて、支払いユーザ装置は、実施例１と同様、受け付けられた同意情報を、接続制御装置に送信する（図９の（６）を参照）。
すると、実施例２に係る接続制御装置は、課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、実施例１と同様、支払いユーザ装置の課金額を管理する管理部の課金額に、課金情報に基づく課金額を加算するように格納する（図９の（７）を参照）。また、接続制御装置は、同意情報を支払いユーザ装置から受信した場合に、実施例１と同様、支払いユーザ装置と受け取りユーザ装置とを接続する（図９の（８）を参照）。
このようにして、実施例２における接続制御システムは、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を簡易に実現することが可能になる。
なお、実施例２においては、受け取りユーザ装置が、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金額「４，５００円」から「５％」を割り引いた「４，２７５円」を、課金情報として決定し、支払いユーザ装置において、「４，２７５円」を所定の出力部に出力する場合を説明したが、この発明はこれに限られるものではなく、例えば、「定価は４，５００円ですが、５％割引価格の４，２７５円でご提供します。」など、支払いユーザ装置において、通常の課金額、割引率などを含めた課金情報を所定の出力部に出力する場合などにも、この発明を同様に適用することができる。
［実施例２における接続制御システムの構成］
次に、図１０および図１１を用いて、実施例２における接続制御システムを説明する。図１０は、実施例２における接続制御システムの構成を示すブロック図であり、図１１は、実施例２における課金情報決定部を説明するための図である。
次に、図１０および図１１を用いて、実施例２における接続制御システムを説明する。図１０は、実施例２における接続制御システムの構成を示すブロック図であり、図１１は、実施例２における課金情報決定部を説明するための図である。
図１０に示すように、実施例２における接続制御システムは、支払いユーザ装置１０については、実施例１と同様に構成される。一方、実施例２における接続制御システムは、接続制御装置２０に接続する着ＩＤ ＤＢ３０が存在しない点で実施例１と異なり、また、受け取りユーザ装置５０が、通信部５１の他に、課金情報送信部５２および課金情報決定部５３を備える点で、実施例１と異なる。以下では、実施例１と同様に構成される装置および部については説明を省略することとし、接続制御装置２０における課金情報取得部２３と、受け取りユーザ装置５０における課金情報送信部５２および課金情報決定部５３とについてのみ説明する。なお、課金情報送信部５２は、特許請求の範囲に記載の「課金情報送信手段」に対応し、課金情報決定部５３は、特許請求の範囲に記載の「課金情報決定手段」に対応する。
接続制御装置２０における課金情報取得部２３は、実施例１と同様、着ＩＤ（決済用通信番号）に対応づけられた課金情報を取得するが、実施例１と異なり、課金情報の提供を受け取りユーザ装置５０に要求し、受け取りユーザ装置５０において決定された課金情報を受け取りユーザ装置５０から受信して取得する。具体的には、実施例２における課金情報取得部２３は、着ＩＤ（決済用通信番号）で識別される受け取りユーザ装置５０に対する接続要求が支払いユーザ装置１０から受信された場合（接続要求を受信したことを示す情報を同意確認部２４から受信した場合）に、着ＩＤ（決済用通信番号）に対応づけられた課金情報の提供を受け取りユーザ装置５０に要求し、受け取りユーザ装置５０から受信した課金情報を、課金情報送信部２２に送信する。例えば、実施例２における課金情報取得部２３は、支払いユーザ装置１０から受信した接続要求メッセージ（INVITEメッセージ）を、受け取りユーザ装置５０に再送信するなどして、課金情報の提供を受け取りユーザ装置５０に要求する。
受け取りユーザ装置５０における課金情報送信部５２は、課金情報を接続制御装置２０に送信する。具体的には、課金情報送信部５２は、課金情報決定部５３によって決定された課金情報を、通信部５１を介して接続制御装置２０に送信する。例えば、課金情報送信部５２は、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」および発ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」に対応づけられた課金情報として「４，２７５円」を、通信部５１を介して接続制御装置２０に送信する。また、例えば、課金情報送信部５２は、課金情報を、課金情報決定部５３において受信された接続要求に対する拒否応答（４０１ Unauthorized）に添付されるコンテンツデータとして送信するなどする。
課金情報決定部５３は、課金ポリシーに基づいて課金情報を決定する。具体的には、課金情報決定部５３は、決済用通信番号に対応づけて課金ポリシーを管理し、通信部５１を介して受信した接続制御装置２０からの要求に応じて、課金ポリシーに基づいて課金情報を決定し、決定した課金情報を、課金情報送信部５２に送信する。例えば、課金情報決定部５３は、受け取りユーザ装置５０に対する支払いユーザ装置１０による接続要求メッセージ（INVITEメッセージ）を接続制御装置２０から受信した場合に、受信した接続要求が同意情報を含むか否かを確認し、同意情報を含んでいなければ、課金ポリシーに基づいて課金情報を決定する。
ここで、課金情報決定部５３は、汎用的なコンピュータである受け取りユーザ装置５０に、ＲＤＢＭＳ（Relational DataBase Management System）プログラムやその他のプログラムを稼働させることによって実現される。具体的に例を挙げて説明すると、課金情報決定部５３は、図１１の（Ａ）に示すように、受け取りユーザ装置を識別する着ＩＤ（図１１の（Ａ）の『着ＩＤ（受け取りユーザ装置）』の列を参照）ごとに、課金額（図１１の（Ａ）の『課金額』の列を参照）を管理する。図１１の（Ａ）の着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけて管理する課金額は「４，５００円」であることを示す。なお、受け取りユーザ装置を識別する着ＩＤが複数であるのは、受け取りユーザによって複数の受け取りユーザ装置が運用されている場合を想定しているものであり、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者から複数の着ＩＤを払い出されていることを示す。
また、課金情報決定部５３は、図１１の（Ｂ）に示すように、支払いユーザ装置を識別する発ＩＤ（図１１の（Ｂ）の『発ＩＤ（支払いユーザ装置）』の列を参照）ごとに、顧客ＩＤや購入履歴（図１１の（Ｂ）の『顧客ＩＤ』や『購入履歴』の列を参照）を管理する。図１１の（Ｂ）の発ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」に対応づけられた顧客「１」は、購入履歴が「９回」であることを示す。さらに、課金情報決定部５３は、図１１の（Ｃ）に示すように、購入履歴（図１１の（Ｃ）の『購入履歴』の列を参照）ごとに、割引率（図１１の（Ｃ）の『割引率』の列を参照）を管理する。図１１の（Ｃ）の購入履歴「１〜９回」は、割引率が「５％」であることを示す。すなわち、課金情報決定部５３が決済用通信番号に対応づけて管理する課金ポリシーは、例えば、発ＩＤ「０５０−ＹＹＹＹ−ＸＸＸＸ」に対応づけられた顧客「１」の購入履歴が「９回」で、割引率が「５％」であることから、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金額「４，５００円」から「５％」を割り引いた「４，２７５円」を、課金情報として決定するものである。
なお、実施例２においては、受け取りユーザ装置が、着ＩＤごとの通常の課金額と、発ＩＤ（顧客ＩＤ）ごとの購入履歴と、購入履歴ごとの割引率とを課金ポリシーとして管理する手法を説明したが、この発明はこれに限られるものではなく、着ＩＤごとの課金額のみを課金ポリシーとして管理する手法など、決済用通信番号に対応づけて課金ポリシーを管理する手法であれば、課金ポリシーの構成はいずれでもよい。
［実施例２における接続制御システムによる処理の手順］
次に、図１２を用いて、実施例２における接続制御システムによる処理の手順を説明する。図１２は、実施例２における接続制御システムによる処理の手順を示すシーケンス図である。図１２に示すように、実施例２における接続制御システムによる処理の手順は、実施例１における接続制御システムによる処理の手順とほぼ同様である（図８を参照）が、接続制御装置２０が課金情報を取得する処理の手順（ステップＳ２２）が、実施例１における接続制御システムによる処理の手順と異なる。以下では、主に、接続制御装置２０が課金情報を取得する処理の手順（ステップＳ２２）について説明する。
次に、図１２を用いて、実施例２における接続制御システムによる処理の手順を説明する。図１２は、実施例２における接続制御システムによる処理の手順を示すシーケンス図である。図１２に示すように、実施例２における接続制御システムによる処理の手順は、実施例１における接続制御システムによる処理の手順とほぼ同様である（図８を参照）が、接続制御装置２０が課金情報を取得する処理の手順（ステップＳ２２）が、実施例１における接続制御システムによる処理の手順と異なる。以下では、主に、接続制御装置２０が課金情報を取得する処理の手順（ステップＳ２２）について説明する。
ステップＳ２２において、接続制御装置２０における課金情報取得部２３は、課金情報の提供を受け取りユーザ装置５０に要求する。具体的には、接続制御装置２０における課金情報取得部２３は、受け取りユーザ装置５０に対する支払いユーザ装置１０による接続要求メッセージ（INVITEメッセージ）を、受け取りユーザ装置５０に再送信するなどする。
すると、受け取りユーザ装置５０における課金情報決定部５３は、課金情報の要求を接続制御装置２０から受信する（ステップＳ２２１）。具体的には、受け取りユーザ装置５０における課金情報決定部５３は、受け取りユーザ装置５０に対する支払いユーザ装置１０による接続要求メッセージ（INVITEメッセージ）を、通信部５１を介して接続制御装置２０から受信する。
次に、受け取りユーザ装置５０における課金情報決定部５３は、課金ポリシーに基づいて課金情報を決定する（ステップＳ２２２）。具体的には、受け取りユーザ装置５０における課金情報決定部５３は、ステップＳ２２１において受信した接続要求が、同意情報を含むか否かを確認し、同意情報を含んでいなければ、課金ポリシーに基づいて課金情報（例えば、「４，２７５円」など）を決定し、課金情報送信部５２に送信する。
すると、受け取りユーザ装置５０における課金情報送信部５２は、課金情報決定部５３から受信した課金情報を、通信部５１を介して接続制御装置２０に送信する（ステップＳ２２３）。具体的には、受け取りユーザ装置５０における課金情報送信部５２は、課金情報（例えば、「４，２７５円」など）を、課金情報決定部５３において受信された接続要求に対する拒否応答（４０１ Unauthorized）に添付されるコンテンツデータなどとして、通信部５１を介して接続制御装置２０に送信する。
このようにして、実施例２における接続制御システムは、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を簡易に実現することが可能になる。
［実施例２の効果］
上記してきたように、実施例２によれば、支払いユーザ装置と支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、支払いユーザ装置と受け取りユーザ装置との接続を制御する接続制御装置であって、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、支払いユーザ装置に対する課金内容を示す情報として、決済用通信番号に対応づけられた課金情報を取得して支払いユーザ装置に送信し、課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の課金額に課金情報に基づく課金額を加算するように格納し、同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
上記してきたように、実施例２によれば、支払いユーザ装置と支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、支払いユーザ装置と受け取りユーザ装置との接続を制御する接続制御装置であって、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、支払いユーザ装置に対する課金内容を示す情報として、決済用通信番号に対応づけられた課金情報を取得して支払いユーザ装置に送信し、課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の課金額に課金情報に基づく課金額を加算するように格納し、同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、「支払いユーザ装置」に指定の時間（もしくは指定の回数）接続させる専用の装置を利用する従来の手法では、「支払いユーザ装置」は、接続の時間や接続の回数などに応じて課金される。これに対して、この発明に係る接続制御システムのように、「支払いユーザ装置」が課金情報を「接続制御装置」から受信し、課金情報に同意することを示す同意情報を「接続制御装置」に送信する手法では、接続の時間や接続の回数などに応じて課金されるわけではないので、従来の手法に比較して、さまざまな形態の決済を適切に実行することが可能になる。
また、「接続制御装置」が、決済用通信番号（電話番号）に対応づけられた課金情報（例えば、課金金額や課金方式など）を「支払いユーザ装置」に送信し、次に、「支払いユーザ装置」において、「接続制御装置」によって送信された課金情報が所定の出力部（例えば、モニタ、スピーカーなど）に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知され、そして、「支払いユーザ装置」によって受け付けられた『支払いユーザ』による同意を「接続制御装置」が受信した場合に、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続することから、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になる。
ひいては、特定の電話番号に対応づけられた課金金額や課金方式の変更など、決済用通信番号（電話番号）に対応づけられた決済の形態が変更された場合であっても、その都度、「支払いユーザ装置」において、「接続制御装置」によって送信された課金情報が所定の出力部に出力されることで「支払いユーザ装置」を利用する『支払いユーザ』によって決済の形態が認知されるので、支払いユーザにとって予期せぬ決済が実行される危険を回避する結果、決済用通信番号（電話番号）に対応づけられた決済の形態を変更することもできることから、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
また、実施例２によれば、受け取りユーザ装置は、決済用通信番号に対応づけて課金ポリシーを管理し、接続制御装置からの要求に応じて課金ポリシーに基づいて課金情報を決定し、決定した課金情報を接続制御装置に送信するものであって、接続制御装置は、課金情報の提供を受け取りユーザ装置に要求し、受け取りユーザ装置において決定された課金情報を受け取りユーザ装置から受信して支払いユーザ装置に送信するので、接続制御装置が課金情報を決定する課金情報データベースに通信可能に接続され、この課金情報データベースから課金情報を取得する手法に比較して、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になる。
すなわち、接続制御装置が課金情報を決定する課金情報データベースに通信可能に接続され、この課金情報データベースから課金情報を取得する手法では、『受け取りユーザ』による課金ポリシー（課金情報を決定するロジック）の変更などは、接続制御装置が接続される課金情報データベースに課金ポリシーの変更指示などを受け付けてもらうことによって対応される。これに対して、受け取りユーザ装置において課金情報を決定し、接続制御装置が受け取りユーザ装置において決定された課金情報を受け取りユーザ装置から受信して取得する手法では、『受け取りユーザ』による課金ポリシーの変更などに自由かつより柔軟に対応することから、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になる。
また、実施例２によれば、支払いユーザ装置において決済用通信番号で識別され、接続制御装置を介して当該支払いユーザ装置に通信可能に接続する受け取りユーザ装置であって、決済用通信番号に対応づけて課金ポリシーを管理し、接続制御装置からの要求に応じて課金ポリシーに基づいて課金内容を示す情報として課金情報を決定し、決定された課金情報を、課金情報に同意することを示す同意情報を支払いユーザ装置から受信することを条件に支払いユーザ装置との接続を許可する接続制御装置に送信するので、接続制御装置が接続される課金情報データベースで課金ポリシー（課金情報を決定するロジック）を管理する手法に比較して、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
すなわち、接続制御装置が接続される課金情報データベースで課金ポリシーを管理する手法では、『受け取りユーザ』による課金ポリシーの変更などは、接続制御装置が接続される課金情報データベースに課金ポリシーの変更指示などを受け付けてもらうことによって対応される。これに対して、『受け取りユーザ』に利用される「受け取りユーザ装置」が課金ポリシーを管理する手法では、『受け取りユーザ』による課金ポリシーの変更などに自由かつより柔軟に対応する。このような「受け取りユーザ装置」が「接続制御装置」を介して「支払いユーザ装置」に接続することから、課金ポリシーの変更などに自由かつより柔軟に対応しつつ、さまざまな形態の決済を適切に実行することが可能になり、また、支払いユーザにとって予期せぬ決済が実行される危険を回避することが可能になり、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することも可能になる。
ところで、上記した実施例１および実施例２においては、支払いユーザ装置と受け取りユーザ装置との間で、決済用通信番号の配下の所定の識別子（例えば、物財販売の決済における物財の識別子など）を共有することなく決済を実行する手法を説明したが、この発明はこれに限られるものではなく、支払いユーザ装置と受け取りユーザ装置との間で、決済用通信番号の配下の所定の識別子を共有して決済を実行する手法にも、この発明を同様に適用することができる。ここで、支払いユーザ装置と受け取りユーザ装置との間で、決済用通信番号の配下の所定の識別子を共有して決済を実行する手法は、実施例１における接続制御システムの構成（課金情報が課金情報データベースにおいて決定される構成、図１および図２を参照）、または、実施例２における接続制御システムの構成（課金情報が受け取りユーザ装置において決定される構成、図９および図１０を参照）のいずれの構成を前提にしても適用することができる。以下では、実施例３として、実施例２における接続制御システムの構成を前提に、支払いユーザ装置と受け取りユーザ装置との間で、決済用通信番号の配下の所定の識別子を共有して決済を実行する手法を、図１３〜図１５を用いて説明する。
［実施例３における接続制御システムの構成］
まず、図１３を用いて、実施例３における接続制御システムを説明する。図１３は、実施例３における課金情報決定部を説明するための図である。上記したように、実施例３における接続制御システムは、実施例２における接続制御システムと同様に構成される（図９および図１０を参照）が、実施例３における課金情報決定部５３は、実施例２における課金情報決定部５３が管理する課金ポリシー（図１１を参照）とは異なる内容の課金ポリシーを管理する。以下では、実施例２と同様に構成される装置および部については説明を省略することとし、支払いユーザ装置１０における接続起動ＵＩ部１１、接続制御装置２０における課金情報取得部２３、および受け取りユーザ装置５０における課金情報決定部５３について説明する。
まず、図１３を用いて、実施例３における接続制御システムを説明する。図１３は、実施例３における課金情報決定部を説明するための図である。上記したように、実施例３における接続制御システムは、実施例２における接続制御システムと同様に構成される（図９および図１０を参照）が、実施例３における課金情報決定部５３は、実施例２における課金情報決定部５３が管理する課金ポリシー（図１１を参照）とは異なる内容の課金ポリシーを管理する。以下では、実施例２と同様に構成される装置および部については説明を省略することとし、支払いユーザ装置１０における接続起動ＵＩ部１１、接続制御装置２０における課金情報取得部２３、および受け取りユーザ装置５０における課金情報決定部５３について説明する。
支払いユーザ装置１０における接続起動ＵＩ部１１は、実施例２と同様、支払いユーザ装置１０を利用する支払いユーザによる着ＩＤ（決済用通信番号）の入力を受け付け、着ＩＤで識別される受け取りユーザ装置５０に対する接続要求を行うが、実施例２と異なり、接続要求とともに決済用通信番号の配下の所定の識別子を接続制御装置２０に送信する。具体的には、接続起動ＵＩ部１１は、支払いユーザによる着ＩＤ（決済用通信番号）および決済用通信番号の配下の所定の識別子（例えば、物財の識別子など）の入力を受け付け、受け付けられた着ＩＤおよび所定の識別子を、通信部１２を介して接続制御装置２０に送信する。
例えば、接続起動ＵＩ部１１は、ＳＩＰ（Session Initiation Protocol）に基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ（Session Description Protocol）情報に加えて、決済用通信番号の配下の所定の識別子（物財の識別子）をボディ部に含めるなどして、接続制御装置２０に送信する。
接続制御装置２０における課金情報取得部２３は、実施例２と同様、課金情報の提供を受け取りユーザ装置５０に要求するが、実施例２と異なり、決済用通信番号の配下の所定の識別子を受け取りユーザ装置５０に送信することで、課金情報の提供を受け取りユーザ装置５０に要求する。
例えば、課金情報取得部２３は、支払いユーザ装置１０から受信した接続要求メッセージ（INVITEメッセージ）のボディ部には、決済用通信番号の配下の所定の識別子（物財の識別子）が含められているので、この接続要求メッセージ（INVITEメッセージ）を受け取りユーザ装置５０に再送信するなどして、決済用通信番号の配下の所定の識別子（物財の識別子）を受け取りユーザ装置５０に送信する。
受け取りユーザ装置５０における課金情報決定部５３は、実施例２と同様、課金ポリシーに基づいて課金情報を決定するが、実施例２と異なり、課金ポリシーとして、決済用通信番号の配下で所定の識別子ごとに区分けされた課金ポリシーを管理し、所定の識別子を接続制御装置２０から受信した場合に、所定の識別子を用いて決定した課金情報を、接続制御装置２０に送信する。例えば、課金情報決定部５３は、「物財の識別子」ごとに区分けされた課金ポリシーを管理し、「物財の識別子」を接続制御装置２０から受信した場合に、「物財の識別子」を用いて決定した課金情報を、課金情報送信部５２に送信する。
具体的に例を挙げて説明すると、課金情報決定部５３は、図１３に示すように、受け取りユーザ装置を識別する着ＩＤ（図１３の『着ＩＤ（受け取りユーザ装置）』の列を参照）と、物財の識別子（図１３の『物財の識別子』の列を参照）と、課金額（図１３の『課金額』の列を参照）と、在庫（図１３の『在庫』の列を参照）とを対応づけて課金ポリシーを管理する。このなかで、物財の識別子が、所定の識別子である。なお、受け取りユーザ装置を識別する着ＩＤが複数であるのは、受け取りユーザによって複数の受け取りユーザ装置が運用されている場合を想定するものであり、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者から複数の着ＩＤを払い出されていることを示す。
例えば、課金情報決定部５３は、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた物財の識別子として「『ＩＳＢＮ−１１１１１１１』、『ＩＳＢＮ−２２２２２２２』、『ＩＳＢＮ−３３３３３３３』・・・」と、課金額として「『２，０００』、『１，５００』、『１，０００』・・・」と、在庫として「『有り』、『有り』、『有り』・・・」とを対応づけて課金ポリシーを管理する。これらの課金ポリシーは、例えば、決済用通信番号「０５０−ＥＥＥＥ−ＸＸＸＸ」の取引で、物財の識別子が「ＩＳＢＮ−１１１１１１１」の取引については、在庫が「有り」で、課金額は「２，０００円」であることを示す。したがって、課金情報決定部５３が、物財の識別子を用いて決定した課金情報は、例えば「課金額２，０００円」などの情報である。
また、例えば、課金情報決定部５３は、着ＩＤ「０５０−ＥＥＥＥ−ＥＥＥＥ」に対応づけられた物財の識別子として「『１１１１１（「１月号」を示すものとする）』、『２２２２２（「２月号」を示すものとする）』、『３３３３３（「３月号」を示すものとする）』・・・」と、課金額として「『６２０』、『６２０』、『６２０』・・・」と、在庫として「『無し』、『有り』、『有り』・・・」とを対応づけて課金ポリシーを管理する。これらの課金ポリシーは、例えば、決済用通信番号「０５０−ＥＥＥＥ−ＥＥＥＥ」の取引で、物財の識別子が「１１１１１」の取引（「１月号」の取引）については、在庫が「無し」で、課金額は「６２０円」であることを示す。したがって、課金情報決定部５３が、物財の識別子を用いて決定した課金情報は、例えば「完売」などの情報である。
［実施例３における接続制御システムによる処理の手順］
次に、図１４および図１５を用いて、実施例３における接続制御システムによる処理の手順を説明する。図１４および図１５は、実施例３における接続制御システムによる処理の手順を示すシーケンス図であり、図１４が、物財の識別子で識別される物財の在庫が残っている場合の処理の手順を示し、図１５が、物財の識別子で識別される物財の在庫が残っていない場合の処理の手順を示す。
次に、図１４および図１５を用いて、実施例３における接続制御システムによる処理の手順を説明する。図１４および図１５は、実施例３における接続制御システムによる処理の手順を示すシーケンス図であり、図１４が、物財の識別子で識別される物財の在庫が残っている場合の処理の手順を示し、図１５が、物財の識別子で識別される物財の在庫が残っていない場合の処理の手順を示す。
図１４に示すように、実施例３における接続制御システムによる処理の手順は、実施例２における接続制御システムによる処理の手順とほぼ同様である（図１２を参照）が、支払いユーザ装置１０から接続制御装置２０に送信する接続要求の内容（ステップＳ１２）と、接続制御装置２０から受け取りユーザ装置５０に送信する課金情報の提供要求の内容（ステップＳ２２）と、受け取りユーザ装置５０が課金情報を決定する処理の内容（ステップＳ２２２）とが、実施例２における接続制御システムによる処理の手順と異なる。以下では、主に、ステップＳ１２からステップＳ２２３まで（ステップＳ１２、ステップＳ２２、およびステップＳ２２２を含む）について説明する。
ステップＳ１２において、支払いユーザ装置１０における接続起動ＵＩ部１１は、実施例２と同様、番号入力された着ＩＤ（Ｒ）で識別される受け取りユーザ装置５０に対する接続要求を送信するが、実施例２と異なり、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ情報に加えて、決済用通信番号の配下の所定の識別子（物財の識別子）をボディ部に含めるなどして、接続制御装置２０に送信する。
すると、接続制御装置２０における同意確認部２４は、実施例２と同様、接続要求を支払いユーザ装置１０から受信した場合に、受信した接続要求が同意情報を含むか否かを確認する（ステップＳ２１）。
次に、接続制御装置２０における課金情報取得部２３は、実施例２と同様、課金情報の提供を受け取りユーザ装置５０に要求するが、実施例２と異なり、支払いユーザ装置１０から受信した接続要求メッセージ（INVITEメッセージ）のボディ部には、所定の識別子（物財の識別子）が含められているので、この接続要求メッセージ（INVITEメッセージ）を受け取りユーザ装置５０に再送信するなどして、所定の識別子（物財の識別子）を受け取りユーザ装置５０に送信する（ステップＳ２２）。
すると、受け取りユーザ装置５０における課金情報決定部５３は、実施例２と同様、課金情報の要求を接続制御装置２０から受信する（ステップＳ２２１）。
次に、受け取りユーザ装置５０における課金情報決定部５３は、実施例２と異なり、所定の識別子を用いて課金情報を決定する（ステップＳ２２２）。具体的には、受け取りユーザ装置５０における課金情報決定部５３は、ステップＳ２２１において受信した接続要求が、同意情報を含むか否かを確認し、同意情報を含んでいなければ、所定の識別子を用いて課金情報を決定し、決定した課金情報を、課金情報送信部５２に送信する。
例えば、受け取りユーザ装置５０における課金情報決定部５３は、決済用通信番号「０５０−ＥＥＥＥ−ＸＸＸＸ」の取引で、物財の識別子が「ＩＳＢＮ−１１１１１１１」の取引については、在庫が「有り」で、課金額は「２，０００円」であることを示す課金ポリシーに基づいて、課金情報として例えば「課金額２，０００円」などを決定し、決定した課金情報を、課金情報送信部５２に送信する。
すると、受け取りユーザ装置５０における課金情報送信部５２は、実施例２と同様、課金情報決定部５３から受信した課金情報を、通信部５１を介して接続制御装置２０に送信する（ステップＳ２２３）。
このようにして、実施例３における接続制御システムは、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を簡易に実行することが可能になる。
ところで、これまで、図１４を用いて、物財の識別子で識別される物財の在庫が残っている場合の処理の手順を説明したが、次に、図１５を用いて、物財の識別子で識別される物財の在庫が残っていない場合の処理の手順を簡単に説明する。
受け取りユーザ装置５０における課金情報決定部５３は、例えば、図１３に示す決済用通信番号「０５０−ＥＥＥＥ−ＥＥＥＥ」の取引で、物財の識別子が「１１１１１」の取引（「１月号」の取引）については、在庫が「無し」で、課金額は「６２０円」であることを示す課金ポリシーに基づいて、課金情報として例えば「完売」などを決定し、決定した課金情報を、課金情報送信部５２に送信する場合もある。
このような場合にも、図１５のステップＳ２２３に示すように、受け取りユーザ装置５０における課金情報送信部５２は、課金情報（「完売」）を接続制御装置２０に送信することになるが、このような場合には、例えば、ＳＤＰ（Session Description Protocol）による音声チャネルを確立し（例えば、図１４で示すところのステップＳ４２、ステップＳ５２、ステップＳ５２２、およびステップＳ５５で送信されるＳＩＰメッセージにＳＤＰを含めることにより確立し）、「申し訳ありません。ご注文の商品は完売しました。」といった音声を出力する手法や、ステップＳ２２３において、課金情報が添付されていない応答を接続制御装置２０に送信する手法などによって、支払いユーザ装置１０に、物財の在庫が残っていないことを知らせることが考えられる。
なお、実施例３においては、所定の識別子として、物財販売の決済における物財の識別子を用いる手法を説明したが、この発明はこれに限られるものではなく、例えば、受け取りユーザによって提供される番組が支払いユーザによってダウンロードされる取引の決済などにおいて、支払いユーザ装置１０の回線情報などを所定の識別子として用いる手法など、決済用通信番号の配下の所定の識別子を用いる手法であれば、いずれでもよい。
［実施例３の効果］
上記してきたように、実施例３によれば、受け取りユーザ装置は、課金ポリシーとして、決済用通信番号の配下で所定の識別子ごとに区分けされた課金ポリシーを管理し、所定の識別子を接続制御装置から受信した場合に、所定の識別子を用いて決定した課金情報を接続制御装置に送信するものであり、支払いユーザ装置は、接続要求とともに所定の識別子を接続制御装置に送信するものであって、接続制御装置は、接続要求とともに所定の識別子を支払いユーザ装置から受信した場合に、所定の識別子を受け取りユーザ装置に送信することで、課金情報の提供を受け取りユーザ装置に要求するので、決済用通信番号（電話番号）が不足するという事態をより回避することが可能になる。
上記してきたように、実施例３によれば、受け取りユーザ装置は、課金ポリシーとして、決済用通信番号の配下で所定の識別子ごとに区分けされた課金ポリシーを管理し、所定の識別子を接続制御装置から受信した場合に、所定の識別子を用いて決定した課金情報を接続制御装置に送信するものであり、支払いユーザ装置は、接続要求とともに所定の識別子を接続制御装置に送信するものであって、接続制御装置は、接続要求とともに所定の識別子を支払いユーザ装置から受信した場合に、所定の識別子を受け取りユーザ装置に送信することで、課金情報の提供を受け取りユーザ装置に要求するので、決済用通信番号（電話番号）が不足するという事態をより回避することが可能になる。
すなわち、支払いユーザ装置と受け取りユーザ装置との間で、所定の識別子を共有するので、ひとつの決済用通信番号（電話番号）に対して、所定の識別子で識別される複数の決済を実行することができることから、決済用通信番号（電話番号）が不足するという事態をより回避することが可能になる。
なお、実施例３によれば、例えば、「支払いユーザ装置」と「受け取りユーザ装置」との間で物財の販売およびその決済が実行される際に、「支払いユーザ装置」から所定の識別子として物財の識別子が送信されると、「接続制御装置」は、この物財の識別子を「受け取りユーザ装置」に送信することで、課金情報の提供を「受け取りユーザ装置」に要求する。この結果、「受け取りユーザ装置」においては、物財の識別子を用いて決定された課金情報が「接続制御装置」に送信されることになる。例えば、「受け取りユーザ装置」において、物財の在庫の有無が確認され、在庫がある場合には、課金情報として課金金額が「接続制御装置」に送信され、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続するが、在庫がない場合には、課金情報として在庫がないことを示す情報が「接続制御装置」に送信され、「接続制御装置」は、「支払いユーザ装置」に課金せず、「支払いユーザ装置」と「受け取りユーザ装置」とを接続しないなど、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を適切に実行することも可能になる。
ところで、実施例１〜３においては、受け取りユーザ装置が、決済用通信番号で識別される決済の対象である決済対象の状況を用いて接続要求を受け付けるか否かを判断しない場合を説明したが、この発明はこれに限られるものではなく、受け取りユーザ装置が、決済対象の状況を用いて接続要求を受け付けるか否かを判断する場合にも、この発明を同様に適用することができる。以下では、実施例４として、受け取りユーザ装置が、決済対象の状況を用いて接続要求を受け付けるか否かを判断する場合について、図１６〜図１８を用いて説明する。
［実施例４における接続制御システムの構成］
まず、図１６を用いて、実施例４における接続制御システムを説明する。図１６は、実施例４に係る受け取りユーザ装置を説明するための図である。実施例４における接続制御システムは、支払いユーザ装置１０および接続制御装置２０については、実施例１と同様に構成される（図１および図２を参照）が、実施例４における受け取りユーザ装置５０は、図１６に示すように、通信部５１の他に、判断結果送信部５４、判断部５５、および在庫ＤＢ６０を備える点で、実施例１と異なる。以下では、実施例１と同様に構成される装置および部については説明を省略することとし、受け取りユーザ装置５０における判断結果送信部５４、判断部５５、在庫ＤＢ６０、およびこれらの部に関連する部について説明する。
まず、図１６を用いて、実施例４における接続制御システムを説明する。図１６は、実施例４に係る受け取りユーザ装置を説明するための図である。実施例４における接続制御システムは、支払いユーザ装置１０および接続制御装置２０については、実施例１と同様に構成される（図１および図２を参照）が、実施例４における受け取りユーザ装置５０は、図１６に示すように、通信部５１の他に、判断結果送信部５４、判断部５５、および在庫ＤＢ６０を備える点で、実施例１と異なる。以下では、実施例１と同様に構成される装置および部については説明を省略することとし、受け取りユーザ装置５０における判断結果送信部５４、判断部５５、在庫ＤＢ６０、およびこれらの部に関連する部について説明する。
支払いユーザ装置１０における同意送信部１５は、実施例１と同様、同意情報を接続制御装置２０に送信するが、実施例１と異なり、同意情報とともに物財の識別子を送信する。例えば、同意送信部１５は、ＳＩＰ（Session Description Protocol）に基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ（Session Description Protocol）情報に加えて、同意情報および物財の識別子をボディ部に含めるなどして、接続制御装置２０に送信する。
接続制御装置２０における接続処理部２５は、実施例１と同様、支払いユーザ装置１０と受け取りユーザ装置５０とを接続するために、支払いユーザ装置１０からの接続要求があることを示す接続情報を受け取りユーザ装置５０に送信するが、実施例１と異なり、接続情報とともに物財の識別子を送信する。例えば、接続処理部２５は、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ情報に加えて、物財の識別子をボディ部に含めるなどして、接続制御装置２０に送信する。
受け取りユーザ装置５０における判断結果送信部５４は、接続要求を受け付けるか否かが判断された判断結果を接続制御装置２０に送信する。具体的には、判断結果送信部５４は、判断部５５によって決定された判断結果を、通信部５１を介して接続制御装置２０に送信する。例えば、判断結果送信部５４は、判断部５５において、支払いユーザ装置１０からの接続要求を受け付けることが判断された判断結果を、接続制御装置２０に送信する。この時、判断結果送信部５４は、判断結果として、課金同意が添付された応答を送信するなどする（接続制御装置２０における課金指示部２６は、課金同意が添付された応答を受信した場合に、アカウントシステム４０の課金額に、課金情報に基づく課金額を加算するように格納する）。
また、例えば、判断結果送信部５４は、支払いユーザ装置１０からの接続要求を受け付けないことが判断された判断結果を、接続制御装置２０に送信する。この時、判断結果送信部５４は、判断結果として、課金同意が添付されていない応答を送信するなどする（接続制御装置２０における課金指示部２６は、課金同意が添付されていない応答を受信した場合には、アカウントシステム４０の課金額に、課金情報に基づく課金額を加算しない）。
判断部５５は、決済対象の状況を用いて、接続要求を受け付けるか否かを判断する。具体的には、判断部５５は、接続情報とともに物財の識別子を、通信部５１を介して接続制御装置２０から受信し、決済対象の状況を用いて接続要求を受け付けるか否かを判断し、判断した判断結果を、判断結果送信部５４に送信する。例えば、判断部５５は、接続情報とともに物財の識別子を含んだ支払いユーザ装置１０による接続要求メッセージ（INVITEメッセージ）を接続制御装置２０から受信した場合に、在庫ＤＢ６０によって管理される決済対象の状況を用いて、接続要求を受け付けるか否かを判断する。
具体的に例を挙げて説明すると、判断部５５は、接続情報とともに物財の識別子を接続制御装置２０から受信すると、決済対象の状況を管理する在庫ＤＢ６０を参照する。そして、判断部５５は、在庫ＤＢ６０によって管理された物財の識別子「ＩＳＢＮ−２２２２２２２」（図１６の『物財の識別子』の列を参照）に対応づけられた在庫「２５」（図１６の『在庫』の列を参照）を参照し、物財の在庫が残っていることから、支払いユーザ装置１０からの接続要求を受け付けることを判断する。あるいは、判断部５５は、物財の識別子「ＩＳＢＮ−１１１１１１１」に対応づけられた在庫「０」を参照し、物財の在庫が残っていないことから、支払いユーザ装置１０からの接続要求を受け付けないことを判断する。
在庫ＤＢ６０は、決済対象の状況を管理する。具体的には、在庫ＤＢ６０は、決済用通信番号で識別される決済の対象である決済対象の状況を管理し、管理する情報は、判断部５５による判断処理などに利用される。例えば、在庫ＤＢ６０は、図１６に示すように、物財の識別子（図１６の『物財の識別子』の列を参照）に対応づけて、決済対象の状況である在庫（図１６の『在庫』の列を参照）を管理するなどする。
［実施例４における接続制御システムによる処理の手順］
次に、図１７および図１８を用いて、実施例４における接続制御システムによる処理の手順を説明する。図１７および図１８は、実施例４における接続制御システムによる処理の手順を示すシーケンス図であり、図１７が、決済の対象である物財の在庫が残っている場合の処理の手順を示し、図１８が、決済の対象である物財の在庫が残っていない場合の処理の手順を示す。
次に、図１７および図１８を用いて、実施例４における接続制御システムによる処理の手順を説明する。図１７および図１８は、実施例４における接続制御システムによる処理の手順を示すシーケンス図であり、図１７が、決済の対象である物財の在庫が残っている場合の処理の手順を示し、図１８が、決済の対象である物財の在庫が残っていない場合の処理の手順を示す。
図１７に示すように、実施例４における接続制御システムによる処理の手順は、実施例１における接続制御システムによる処理の手順とほぼ同様である（図８を参照）が、ステップＳ４２以降が、実施例１における接続制御システムによる処理の手順と異なる。以下では、主に、ステップＳ４２以降について説明する。
まず、ステップＳ４２において、支払いユーザ装置１０における同意送信部１５は、実施例１と同様、同意情報を接続制御装置２０に送信するが、実施例１と異なり、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ情報に加えて、同意情報および物財の識別子をボディ部に含めるなどして、接続制御装置２０に送信する。
続いて、接続制御装置２０における同意確認部２４は、実施例１と同様、接続要求を支払いユーザ装置１０から受信した場合に、受信した接続要求が、同意情報を含むか否かを確認する（ステップＳ５１）。
すると、接続制御装置２０における接続処理部２５は、実施例１と同様、支払いユーザ装置１０と受け取りユーザ装置２０とを接続するために、支払いユーザ装置１０からの接続要求があることを示す接続メッセージを、受け取りユーザ装置５０に送信するが、実施例１と異なり、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、Multipart MIME形式に指定して分割し、通常のＳＤＰ情報に加えて、物財の識別子をボディ部に含めるなどして、受け取りユーザ装置５０に送信する（ステップＳ５２）。
そして、受け取りユーザ装置５０は、実施例１と同様、接続制御装置２０から接続メッセージを受信するが、実施例１と異なり、受け取りユーザ装置５０の判断部５５が、通信部５１を介して接続メッセージを受信する（ステップＳ５２１）。
次に、受け取りユーザ装置５０の判断部５５は、決済対象の状況を用いて、接続要求を受け付けるか否かを判断する。具体的には、判断部５５は、接続メッセージから物財の識別子を抽出し（ステップＳ５２２）、決済用通信番号で識別される決済の対象である決済対象の状況を管理する在庫ＤＢ６０を参照して物財の在庫数を確認し（ステップＳ５２３）、物財の在庫が残っている場合には、在庫ＤＢ６０における物財の在庫数を「１」減算するなどしてから（ステップＳ５２４）、支払いユーザ装置１０からの接続要求を受け付けることを判断し、判断結果を判断結果送信部５４に送信する。
すると、受け取りユーザ装置５０の判断結果送信部５４は、判断結果として、受け取りユーザ装置５０が、支払いユーザ装置１０からの接続要求を受け付けることを、接続制御装置２０に送信する（ステップＳ５２５）。具体的には、判断結果送信部５４は、判断結果として、課金同意が添付された応答を送信するなどする。
続いて、接続制御装置２０における課金指示部２６は、実施例１と異なり、課金同意が添付された応答を受信した場合に（ステップＳ５３）、アカウントシステム４０の課金額に、課金情報に基づく課金額を加算するように格納する（ステップＳ５４）。
また、接続制御装置２０における接続処理部２５は、実施例１と異なり、受け取りユーザ装置５０から、課金同意が添付された応答を受信した場合に、支払いユーザ装置１０と受け取りユーザ装置５０とを接続し、支払いユーザ装置１０に接続完了通知を送信する（ステップＳ５５）。
このようにして、実施例４における接続制御システムは、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を簡易に実現することが可能になる。
ところで、これまで、図１７を用いて、決済の対象である物財の在庫が残っている場合の処理の手順を説明したが、次に、図１８を用いて、決済の対象である物財の在庫が残っていない場合の処理の手順を簡単に説明する。
受け取りユーザ装置５０における判断部５５は、例えば、図１６に示す物財の識別子「ＩＳＢＮ−１１１１１１１」の取引については、在庫が「０」で、物財の在庫がないことから、支払いユーザ装置１０からの接続要求を受け付けないことを判断する場合もある。
このような場合にも、図１８のステップＳ５２４に示すように、受け取りユーザ装置５０における判断結果送信部５４は、判断結果を接続制御装置２０に送信することになるが、このような場合には、例えば、判断結果として、課金同意が添付されていない応答を送信し、支払いユーザ装置１０からの接続要求を受け付けないことを接続制御装置２０に知らせることなどが考えられる。
なお、実施例４においては、物財販売の決済における物財の識別子を用いる手法を説明したが、この発明はこれに限られるものではなく、受け取りユーザ装置が、決済対象の状況を用いて接続要求を受け付けるか否かを判断する手法であれば、いずれでもよい。
［実施例４の効果］
上記してきたように、実施例４によれば、受け取りユーザ装置は、決済用通信番号で識別される決済の対象である決済対象の状況を管理し、支払いユーザ装置からの接続要求があることを示す接続情報を接続制御装置から受信した場合に、決済対象の状況を用いて接続要求を受け付けるか否かを判断し、判断した判断結果を接続制御装置に送信するものであって、接続制御装置は、接続要求を受け付けることを示す判断結果を受信ユーザ装置から受信した場合に、管理部の支払いユーザ装置の課金額に課金情報に基づく課金額を加算するように格納し、接続要求を受け付けることを示す判断結果を受信ユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を適切に実行することが可能になる。
上記してきたように、実施例４によれば、受け取りユーザ装置は、決済用通信番号で識別される決済の対象である決済対象の状況を管理し、支払いユーザ装置からの接続要求があることを示す接続情報を接続制御装置から受信した場合に、決済対象の状況を用いて接続要求を受け付けるか否かを判断し、判断した判断結果を接続制御装置に送信するものであって、接続制御装置は、接続要求を受け付けることを示す判断結果を受信ユーザ装置から受信した場合に、管理部の支払いユーザ装置の課金額に課金情報に基づく課金額を加算するように格納し、接続要求を受け付けることを示す判断結果を受信ユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を適切に実行することが可能になる。
すなわち、例えば、「支払いユーザ装置」と「受け取りユーザ装置」との間で物財の販売およびその決済が実行される際に、「受け取りユーザ装置」においては、決済対象の状況を用いて、「支払いユーザ装置」からの接続要求を受け付けるか否かを判断し、判断した判断結果を「接続制御装置」に送信する。例えば、「受け取りユーザ装置」において、物財の在庫の有無が確認され、在庫がある場合には、「支払いユーザ装置」からの接続要求を受け付ける旨の判断結果が「接続制御装置」に送信され、「接続制御装置」は、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続するが、在庫がない場合には、「支払いユーザ装置」からの接続要求を受け付けない旨の判断結果が「接続制御装置」に送信され、「接続制御装置」は、「支払いユーザ装置」に課金せず、「支払いユーザ装置」と「受け取りユーザ装置」とを接続しないなど、「受け取りユーザ装置」による高度な判断を実現しつつ、さまざまな形態の決済を適切に実行することが可能になる。
ところで、上記した実施例１〜実施例４においては、支払いユーザ装置が、課金情報として課金額を接続制御装置から受信し、課金額に同意することを示す同意情報を接続制御装置に送信する場合を説明したが、この発明はこれに限られるものではなく、課金額の他に所定の接続条件をさらに含む課金情報を接続制御装置から受信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を接続制御装置に送信する場合にも、この発明を同様に適用することができる。以下では、実施例５として、課金額の他に所定の接続条件をさらに含む課金情報を接続制御装置から受信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を接続制御装置に送信する場合を、図１９および図２０を用いて説明する。
［実施例５における接続制御システムの概要および特徴］
まず、図１９を用いて、実施例５における接続制御システムの概要および特徴を説明する。図１９は、実施例５における接続制御システムの概要および特徴を説明するための図である。なお、以下では、実施例２における接続制御システムの構成（課金情報が受け取りユーザ装置において決定される構成）を前提に、課金額の他に所定の接続条件をさらに含む課金情報を接続制御装置から受信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を接続制御装置に送信する場合を説明する。
まず、図１９を用いて、実施例５における接続制御システムの概要および特徴を説明する。図１９は、実施例５における接続制御システムの概要および特徴を説明するための図である。なお、以下では、実施例２における接続制御システムの構成（課金情報が受け取りユーザ装置において決定される構成）を前提に、課金額の他に所定の接続条件をさらに含む課金情報を接続制御装置から受信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を接続制御装置に送信する場合を説明する。
実施例５における接続制御システムの接続制御装置は、実施例２と同様、支払いユーザ装置の課金額を管理する『アカウントシステム』に接続されるが、実施例２と異なり、支払いユーザ装置を利用する支払いユーザの氏名や住所などを管理する『顧客ＤＢ』にも接続される。一方、実施例５における接続制御システムの受け取りユーザ装置は、実施例２と同様、決済用通信番号に対応づけて課金ポリシーを管理するが、実施例２と異なり、決済用通信番号に対応づけて所定の接続条件をさらに管理する。
具体的には、受け取りユーザ装置は、図１９に示すように、受け取りユーザ装置を識別する着ＩＤ（図１９の受け取りユーザ装置の『着ＩＤ（受け取りユーザ装置）』の列を参照）ごとに、課金額（図１９の受け取りユーザ装置の『課金額』の列を参照）および接続条件（図１９の受け取りユーザ装置の『接続条件』の列を参照）を管理する。なお、受け取りユーザ装置を識別する着ＩＤが複数であるのは、受け取りユーザ装置によって複数の受け取りユーザ装置が運用されている場合を想定しているものであり、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者から複数の着ＩＤを払い出されていることを示す。
このような構成のもと、実施例５に係る支払いユーザ装置は、実施例２と同様、まず、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を、接続制御装置に送信する（図１９の（１）を参照）。
すると、実施例５に係る接続制御装置は、決済用通信番号で識別される受け取りユーザ装置に対する接続要求を支払いユーザ装置から受信した場合に、実施例２と同様、決済用通信番号に対応づけられた課金情報を取得して、支払いユーザ装置に送信するが、実施例２と異なり、課金情報として、所定の接続条件をさらに含む課金情報を取得して、支払いユーザ装置に送信する（図１９の（２）および（３）を参照）。具体的には、接続制御装置は、課金情報の提供を受け取りユーザ装置に要求し、受け取りユーザ装置において決定された課金情報として、課金額「４，５００円」および接続条件「住所の開示」を取得して、支払いユーザ装置に送信する。
この時、実施例５に係る受け取りユーザ装置は、接続制御装置からの要求に応じて課金ポリシーに基づいて課金情報を決定し、決定された課金情報を接続制御装置に送信している。具体的には、受け取りユーザ装置は、着ＩＤ「０５０−ＥＥＥＥ−ＸＸＸＸ」に対応づけられた課金額「４，５００円」および接続条件「住所の開示」を、課金情報として決定し、接続制御装置に送信している。
次に、実施例５に係る支払いユーザ装置は、実施例２と同様、決済用通信番号に対応づけられた課金情報を接続制御装置から受信して、課金情報を所定の出力部に出力するが、実施例２と異なり、所定の接続条件をさらに含む課金情報を所定の出力部に出力する（図１９の（４）を参照）。具体的には、支払いユーザ装置は、課金情報として、例えば、「課金額は４，５００円です。また、住所の開示が必要となります。課金額および住所の開示に同意される場合には、１と＃（シャープ）を押してください。」の音声をスピーカーに出力する。
そして、支払いユーザ装置は、実施例２と同様、出力された課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付けるが、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付ける（図１９の（５）を参照）。
続いて、支払いユーザ装置は、実施例２と同様、受け付けられた同意情報を、接続制御装置に送信する（図１９の（６）を参照）。すると、実施例５に係る接続制御装置は、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の課金額に、課金情報に基づく課金額を加算するように格納する（図１９の（７）を参照）。
また、接続制御装置は、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続する（図１９の（８）を参照）。
なお、この時、実施例５に係る接続制御装置は、『顧客ＤＢ』から支払いユーザ装置を利用する支払いユーザの住所情報を取得し、その住所情報を、受け取りユーザ装置に対する接続メッセージに含めてもよい。この場合には、受け取りユーザ装置は、接続メッセージを受信することで、支払いユーザの住所情報を取得することができるので、例えば、通信販売注文時、商品配送先に関する情報が、支払いユーザから受け取りユーザに効率的に伝達されるなどの効果が得られる。
このようにして、実施例５における接続制御システムは、さまざまな形態の決済を高度かつ効率的かつ簡易に実現することが可能になる。
なお、実施例５においては、所定の接続条件として「住所の開示」の場合を説明したが、この発明はこれに限られるものではなく、例えば、「年齢の開示」、「２０歳以上であること」、「大人の監督下で接続すること」など、いずれでもよい。
また、実施例５においては、実施例２における接続制御システムの構成（課金情報が受け取りユーザ装置において決定される構成）を前提に、課金額の他に所定の接続条件をさらに含む課金情報を接続制御装置から受信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を接続制御装置に送信する場合を説明したが、この発明はこれに限られるものではなく、実施例１における接続制御システムの構成（課金情報が課金情報データベースにおいて決定される構成）を前提にする場合にも、この発明を同様に適用することができる。
［実施例５における接続制御システムによる処理の手順］
次に、図２０を用いて、実施例５における接続制御システムによる処理の手順を説明する。図２０は、実施例５における接続制御システムによる処理の手順を示すシーケンス図である。図２０に示すように、実施例５における接続制御システムによる処理の手順は、実施例２における接続制御システムによる処理の手順とほぼ同様である（図１２を参照）が、受け取りユーザ装置５０と接続制御装置２０との間で送受信されるデータの内容や、支払いユーザ装置１０と接続制御装置２０との間で送受信されるデータの内容などが、実施例２における接続制御システムによる処理の手順と異なる。以下では、主に、実施例２と異なるデータの内容に着目して説明する。
次に、図２０を用いて、実施例５における接続制御システムによる処理の手順を説明する。図２０は、実施例５における接続制御システムによる処理の手順を示すシーケンス図である。図２０に示すように、実施例５における接続制御システムによる処理の手順は、実施例２における接続制御システムによる処理の手順とほぼ同様である（図１２を参照）が、受け取りユーザ装置５０と接続制御装置２０との間で送受信されるデータの内容や、支払いユーザ装置１０と接続制御装置２０との間で送受信されるデータの内容などが、実施例２における接続制御システムによる処理の手順と異なる。以下では、主に、実施例２と異なるデータの内容に着目して説明する。
まず、ステップＳ２２３において、受け取りユーザ装置５０における課金情報送信部５２は、実施例２と同様、課金情報決定部５３から受信した課金情報を接続制御装置２０に送信するが、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報を送信する。すると、接続制御装置２０における課金情報取得部２３は、実施例２と同様、課金情報を取得するが、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報を取得する（ステップＳ２２）。
続いて、接続制御装置２０における課金情報送信部２２は、実施例２と同様、課金情報を支払いユーザ装置１０に送信するが、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報を支払いユーザ装置１０に送信する（ステップＳ２３）。
すると、支払いユーザ装置１０における課金情報受信部１４は、実施例２と同様、課金情報を接続制御装置２０から受信するが、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報を接続制御装置２０から受信する（ステップＳ３１）。
そして、支払いユーザ装置１０における課金同意確認ＵＩ部１３は、実施例２と同様、課金情報をプレゼンテーションするが、実施例２と異なり、所定の接続条件（住所の開示）をさらに含む課金情報をプレゼンテーションする（ステップＳ３２）。例えば、「課金額は４，５００円です。また、住所の開示が必要となります。課金額および住所の開示に同意される場合には、１と＃（シャープ）を押してください。」の音声をスピーカーに出力する。
すると、支払いユーザによって同意情報が入力され（ステップＳ４１）、支払いユーザ装置１０における課金同意確認ＵＩ部１３は、実施例２と同様、プレゼンテーションされた課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付けるが、実施例２と異なり、所定の接続条件（住所の開示）を含む課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付ける。
次に、支払いユーザ装置１０における同意送信部１５は、実施例２と同様、同意情報を接続制御装置２０に送信するが、実施例２と異なり、所定の接続条件（住所の開示）を含む課金情報に同意することを示す同意情報を、接続制御装置２０に送信する（ステップＳ４２）。
また、ステップＳ５２において、接続制御装置２０の接続処理部２５は、実施例２と異なり、顧客ＤＢ７０を参照し、支払いユーザ装置を利用する支払いユーザの住所情報を取得する。そして、接続制御装置２０の接続処理部２５は、実施例２と同様、支払いユーザ装置１０と受け取りユーザ装置５０とを接続するために、支払いユーザ装置１０からの接続要求があることを示す接続メッセージを、受け取りユーザ装置５０に送信するが、実施例２と異なり、支払いユーザの住所情報を含む接続メッセージを送信する（ステップＳ５３）。
すると、受け取りユーザ装置５０は、実施例２と同様、接続制御装置２０から接続メッセージを受信するが、実施例２と異なり、住所情報を含む接続メッセージを受信する（ステップＳ５３１）。
このようにして、実施例５における接続制御システムは、さまざまな形態の決済を高度かつ効率的かつ簡易に実現することが可能になる。
［実施例５の効果］
上記してきたように、実施例５によれば、課金情報は、所定の接続条件をさらに含むものであって、接続制御装置は、所定の接続条件をさらに含む課金情報を取得して支払いユーザ装置に送信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の管理額に課金情報に基づく課金額を加算するように格納し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を高度かつ効率的かつ適切に実現することが可能になる。
上記してきたように、実施例５によれば、課金情報は、所定の接続条件をさらに含むものであって、接続制御装置は、所定の接続条件をさらに含む課金情報を取得して支払いユーザ装置に送信し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置の課金額を管理する管理部の管理額に課金情報に基づく課金額を加算するように格納し、所定の接続条件をさらに含む課金情報に同意することを示す同意情報を支払いユーザ装置から受信した場合に、支払いユーザ装置と受け取りユーザ装置とを接続するので、さまざまな形態の決済を高度かつ効率的かつ適切に実現することが可能になる。
すなわち、例えば、「接続制御装置」が、接続条件として、「２０歳以上であること」、「大人の監督下で接続すること」などの条件を含む課金情報を「支払いユーザ装置」に送信し、これらの条件を含む課金情報に同意することを示す同意情報を「支払いユーザ装置」から受信した場合に、「接続制御装置」が、「支払いユーザ装置」に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続するなど、さまざまな形態の決済を高度かつ適切に実行することが可能になる。
また、例えば、「支払いユーザ装置」と「受け取りユーザ装置」との間で、通信販売およびその決済が実行される際に、「接続制御装置」が、接続条件として、支払いユーザの属性情報（例えば、住所、メールアドレス、年齢など）の開示を要求する情報開示要求を含む課金情報を「支払いユーザ装置」に送信し、情報開示要求を含む課金情報に同意することを示す同意情報を「支払いユーザ装置」から受信した場合に、「接続制御装置」が、支払いユーザの属性情報（例えば、住所など）を取得して「受け取りユーザ装置」に送信することで、「受け取りユーザ装置」における住所などの属性情報の取得を効率化することから、さまざまな形態の決済を効率的かつ適切に実行することが可能になる。
ところで、上記した実施例１〜実施例５においては、支払いユーザ装置が、所定の接続ポリシーを参照することなく同意情報を接続制御装置に送信する手法を説明したが、この発明はこれに限定されるものではなく、支払いユーザ装置が、同意情報を接続制御装置に送信するにあたり所定の接続ポリシーを参照する手法にも、この発明を同様に適用することができる。以下では、実施例６として、支払いユーザ装置が、同意情報を接続制御装置に送信するにあたり所定の接続ポリシーを参照する手法を、図２１および図２２を用いて説明する。
［実施例６における接続制御システムの構成］
まず、図２１を用いて、実施例６における接続制御システムを説明する。図２１は、実施例６に係る支払いユーザ装置を説明するための図である。実施例６に係る支払いユーザ装置１０は、実施例１〜実施例５に係る支払いユーザ装置１０とほぼ同様の構成であるが、接続許可ポリシー記憶部１６をさらに備える点で、実施例１〜実施例５と異なる。以下では、実施例１〜実施例５と同様に構成される装置および部については説明を省略することとし、支払いユーザ装置１０における接続許可ポリシー記憶部１６および接続許可ポリシー記憶部１６と関連する同意送信部１５について説明する。なお、接続許可ポリシー記憶部１６は、特許請求の範囲に記載の「接続ポリシー保持手段」に対応する。
まず、図２１を用いて、実施例６における接続制御システムを説明する。図２１は、実施例６に係る支払いユーザ装置を説明するための図である。実施例６に係る支払いユーザ装置１０は、実施例１〜実施例５に係る支払いユーザ装置１０とほぼ同様の構成であるが、接続許可ポリシー記憶部１６をさらに備える点で、実施例１〜実施例５と異なる。以下では、実施例１〜実施例５と同様に構成される装置および部については説明を省略することとし、支払いユーザ装置１０における接続許可ポリシー記憶部１６および接続許可ポリシー記憶部１６と関連する同意送信部１５について説明する。なお、接続許可ポリシー記憶部１６は、特許請求の範囲に記載の「接続ポリシー保持手段」に対応する。
なお、以下では、実施例１における接続制御システムの構成（課金情報が課金情報データベースにおいて決定される構成、図１および図２を参照）を前提に、支払いユーザ装置１０が、接続許可ポリシー記憶部１６をさらに備える場合を説明するが、この発明はこれに限られるものではなく、実施例２における接続制御システムの構成（課金情報が受け取りユーザ装置において決定される構成、図９および図１０を参照）を前提にする場合にも、この発明を同様に適用することができる。
支払いユーザ装置１０の接続許可ポリシー記憶部１６は、課金情報に対応づけて所定の接続許可ポリシー（接続ポリシー）を保持する。具体的には、接続許可ポリシー記憶部１６は、課金情報（例えば、課金額など）に対応づけて所定の接続許可ポリシー（例えば、「接続禁止」、「暗証番号入力」など）を保持し、保持した接続許可ポリシーは、同意送信部１５によって参照される。
例えば、接続許可ポリシー記憶部１６は、図２１に示すように、課金額（図２１の『課金額』の列を参照）ごとに、接続許可ポリシー（図２１の『接続許可ポリシー』の列を参照）を保持する。すなわち、図２１に示す接続許可ポリシーは、例えば、「課金額１万円以上の決済は禁止する」や、「課金額１，０００円以上の決済は暗証番号の入力を促す」などを示す。
同意送信部１５は、課金同意確認ＵＩ部１３によって同意情報の入力を受け付けると、接続許可ポリシー記憶部１６に保持された所定の接続許可ポリシーを参照し、所定の接続許可ポリシーを充たす場合に、同意情報を接続制御装置２０に送信する。例えば、支払いユーザ装置１０には、接続許可ポリシーに対応させた端末動作が記憶されており、同意送信部１５は、課金同意確認ＵＩ部１３によって同意情報の入力を受け付けると、接続許可ポリシー記憶部１６に保持された所定の接続許可ポリシーを参照し、所定の接続許可ポリシーに対応させた端末動作を行った後（例えば、暗証番号の入力を支払いユーザに促し、支払いユーザによる正しい暗証番号の入力を受け付けた後）、同意情報を接続制御装置２０に送信する。なお、支払いユーザ装置１０において、所定の接続許可ポリシーに対応させた端末動作は、ソフトウェアプログラムなどによって実現される。
［実施例６における接続制御システムによる処理の手順］
次に、図２２を用いて、実施例６における接続制御システムによる処理の手順を説明する。図２２は、実施例６における接続制御システムによる処理の手順を示すシーケンス図である。図２２に示すように、実施例６における接続制御システムによる処理の手順は、実施例１における接続制御システムによる処理の手順とほぼ同様である（図８を参照）が、支払いユーザ装置１０が同意情報の入力を所定の入力部において受け付ける処理（ステップＳ４１）から、支払いユーザ装置１０が同意情報を接続制御装置２０に送信する処理（ステップＳ４４）までが、実施例１における接続制御システムによる処理の手順と異なる。以下では、主に、ステップＳ４１〜ステップＳ４４について説明する。
次に、図２２を用いて、実施例６における接続制御システムによる処理の手順を説明する。図２２は、実施例６における接続制御システムによる処理の手順を示すシーケンス図である。図２２に示すように、実施例６における接続制御システムによる処理の手順は、実施例１における接続制御システムによる処理の手順とほぼ同様である（図８を参照）が、支払いユーザ装置１０が同意情報の入力を所定の入力部において受け付ける処理（ステップＳ４１）から、支払いユーザ装置１０が同意情報を接続制御装置２０に送信する処理（ステップＳ４４）までが、実施例１における接続制御システムによる処理の手順と異なる。以下では、主に、ステップＳ４１〜ステップＳ４４について説明する。
まず、ステップＳ４１において、支払いユーザによって同意情報が入力され、支払いユーザ装置１０における課金同意確認ＵＩ部１３は、実施例１と同様、プレゼンテーションされた課金情報に同意することを示す同意情報の入力を、所定の入力部において受け付ける。
次に、支払いユーザ装置１０における同意送信部１５は、実施例１と異なり、接続許可ポリシー記憶部１６によって保持された所定の接続許可ポリシーを参照する（ステップＳ４２）。ここで、接続許可ポリシー記憶部１６は、課金情報に対応づけて所定の接続許可ポリシーを保持するものであるので、支払いユーザ装置１０における同意送信部１５は、課金同意確認ＵＩ部１３によって入力を受け付けられた同意情報が、例えば、課金情報「４，５００円」に同意することを示す情報である場合には、課金情報「４，５００円」に対応する所定の接続許可ポリシーを参照する。
続いて、支払いユーザ装置１０は、実施例１と異なり、所定の接続許可ポリシーに対応させた端末動作を行う（ステップＳ４３）。例えば、課金情報「４，５００円」に対応する所定の接続許可ポリシーが、「課金額１，０００円以上の決済は暗証番号の入力を促す」である場合には、支払いユーザ装置１０は、暗証番号の入力を支払いユーザに促し、支払いユーザによる暗証番号の入力を受け付ける。
そして、支払いユーザ装置１０における同意送信部１５は、実施例１と異なり、所定の接続許可ポリシーを充たす場合に、同意情報を接続制御装置２０に送信する（ステップＳ４４）。例えば、支払いユーザ装置１０における同意送信部１５は、支払いユーザによって正しい暗証番号の入力を受け付けた後、ステップＳ４１において課金同意確認ＵＩ部１３によって受け付けられた同意情報を、接続制御装置２０に送信する。
このようにして、実施例６における接続制御システムは、所定の接続ポリシーを参照することなく、同意情報を接続制御装置２０に送信する手法に比較して、支払いユーザにとって予期せぬ決済が実行される危険をより確実に回避することが可能になる。
［実施例６の効果］
上記してきたように、実施例６によれば、支払いユーザ装置は、課金情報に対応づけて所定の接続ポリシーをさらに保持し、同意情報の入力を受け付けると、保持された所定の接続ポリシーを参照し、所定の接続ポリシーを充たす場合に、同意情報を接続制御装置に送信するので、所定の接続ポリシーを参照することなく同意情報を接続制御装置に送信する手法に比較して、支払いユーザにとって予期せぬ決済が実行される危険をより確実に回避することが可能になる。
上記してきたように、実施例６によれば、支払いユーザ装置は、課金情報に対応づけて所定の接続ポリシーをさらに保持し、同意情報の入力を受け付けると、保持された所定の接続ポリシーを参照し、所定の接続ポリシーを充たす場合に、同意情報を接続制御装置に送信するので、所定の接続ポリシーを参照することなく同意情報を接続制御装置に送信する手法に比較して、支払いユーザにとって予期せぬ決済が実行される危険をより確実に回避することが可能になる。
すなわち、所定の接続ポリシーを参照することなく同意情報を接続制御装置に送信する手法では、「接続制御装置」から送信された課金情報が「支払いユーザ装置」の所定の出力部に出力されたとしても、「支払いユーザ装置」を利用する『支払いユーザ』によって、課金金額や接続条件（例えば、支払いユーザの属性情報の開示など）など決済の形態が充分に認知されないまま、同意情報を接続制御装置に送信してしまうおそれがある。これに対して、所定の接続ポリシーを参照してから同意情報を接続制御装置に送信する手法では、例えば、課金金額１，０００円以上の決済については、『支払いユーザ』に暗証番号を入力させることを接続ポリシーとすることで、『支払いユーザ』に決済の形態を充分に認知させることから、支払いユーザにとって予期せぬ決済が実行される危険をより確実に回避することが可能になる。
ところで、これまで実施例１〜実施例６における接続制御システムについて説明したが、この発明は上記した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、実施例７における接続制御システムとして、異なる実施例を説明する。
［Ｃ２Ｃ（Consumer to Consumer）］
上記した実施例１〜実施例６においては、アカウントシステム４０が、支払いユーザ装置１０の課金額を管理するものであって、接続制御装置２０の課金指示部２６が、アカウントシステム４０が管理する支払いユーザ装置１０の課金額に、課金情報に基づく課金額を加算するように格納する手法を説明したが、この発明はこれに限られるものではなく、アカウントシステム４０が、支払いユーザ装置１０の課金額を管理するとともに受け取りユーザ装置５０の課金額を管理するものであって、接続制御装置２０の課金指示部２６が、課金情報に基づく課金額を、アカウントシステム４０が管理する支払いユーザ装置１０の課金額に加算するように格納するとともに、アカウントシステム４０が管理する受け取りユーザ装置５０の課金額から減算するように格納する手法にも、この発明を同様に適用することができる。
上記した実施例１〜実施例６においては、アカウントシステム４０が、支払いユーザ装置１０の課金額を管理するものであって、接続制御装置２０の課金指示部２６が、アカウントシステム４０が管理する支払いユーザ装置１０の課金額に、課金情報に基づく課金額を加算するように格納する手法を説明したが、この発明はこれに限られるものではなく、アカウントシステム４０が、支払いユーザ装置１０の課金額を管理するとともに受け取りユーザ装置５０の課金額を管理するものであって、接続制御装置２０の課金指示部２６が、課金情報に基づく課金額を、アカウントシステム４０が管理する支払いユーザ装置１０の課金額に加算するように格納するとともに、アカウントシステム４０が管理する受け取りユーザ装置５０の課金額から減算するように格納する手法にも、この発明を同様に適用することができる。
例えば、実施例１における接続制御システムによる処理の手順（図８を参照）を用いて説明すると、実施例７に係る受け取りユーザ装置５０は、ステップＳ５２２において接続制御装置２０に応答を送信する際に、応答を送信するとともに受け取りユーザ装置５０のＩＤを送信するなどする。そして、接続制御装置２０における課金指示部２６は、受け取りユーザ装置５０から応答を受信するとともに受け取りユーザ装置５０のＩＤを受信し、アカウントシステム４０が管理する受け取りユーザ装置５０の課金額に、課金情報に基づく課金額を減算するように格納する。
このようにして、実施例７における接続制御システムは、少額の決済などを含むさまざまな形態の決済を単純な手続で適切に実行することが可能になる。すなわち、例えば、「支払いユーザ装置」と「受け取りユーザ装置」との間で実行される決済が、１回限りのものであり、かつ、少額の決済である場合など（Consumer to Consumerの取引など）には、電気通信事業者によって回収された料金から対価に相当する料金が受け取りユーザに支払われる手続を踏むよりも、少額の課金金額を「支払いユーザ装置」の課金額に加算するとともに、「受け取りユーザ装置」の課金額に減算する手続をとる方が、少額の決済などを含むさまざまな形態の決済を単純な手続で適切に実行することが可能になる。
なお、上記においては、課金情報に基づく課金額を、アカウントシステム４０が管理する受け取りユーザ装置５０の課金額から減算するように格納する手法を、実施例１における接続制御システムの構成に適用する場合を説明したが、この発明はこれに限られるものではなく、実施例２における接続制御システムの構成などにも、この発明を同様に適用することができる。
［電子署名］
また、上記した実施例１〜実施例６においては、支払いユーザ装置１０の同意送信部１５が同意情報を接続制御装置２０に送信する際に、通常のＳＤＰ（Session Description Protocol）情報に加えて同意情報のみを送信する手法や、通常のＳＤＰ情報に加えて同意情報および所定の識別子を送信する手法などについて説明したが、この発明はこれに限られるものではなく、同意情報とともに電子署名を送信する手法にも、この発明を同様に適用することができる。
また、上記した実施例１〜実施例６においては、支払いユーザ装置１０の同意送信部１５が同意情報を接続制御装置２０に送信する際に、通常のＳＤＰ（Session Description Protocol）情報に加えて同意情報のみを送信する手法や、通常のＳＤＰ情報に加えて同意情報および所定の識別子を送信する手法などについて説明したが、この発明はこれに限られるものではなく、同意情報とともに電子署名を送信する手法にも、この発明を同様に適用することができる。
例えば、支払いユーザ装置１０の同意送信部１５は、同意情報を接続制御装置２０に送信する際に、同意情報とともに電子署名（例えば、発ＩＤに対応する秘密鍵で署名した電子署名など）を送信する。すると、接続制御装置２０の課金指示部２６は、同意情報とともに電子署名を支払いユーザ装置１０から受信し、同意確認部２４などによって電子署名の正当性が検証された場合に、アカウントシステム４０の支払いユーザ装置１０の課金額に課金情報に基づく課金額を加算するように格納する。また、接続制御装置２０の接続処理部２５は、同意情報とともに電子署名を支払いユーザ装置１０から受信し、同意確認部２４などによって電子署名の正当性が検証された場合に、支払いユーザ装置１０と受け取りユーザ装置５０とを接続する。なお、課金情報とともに電子署名を送信する場合にも、この発明を同様に適用することができる。この場合には、確かに接続制御装置（または受け取りユーザ装置）から送信された課金情報であることが検証され、また、課金情報に改竄が行われていないことが検証され、さらに、接続制御装置（受け取りユーザ）が課金情報を送信した事実を否認するおそれを回避することができる。
具体的に例を挙げて説明すると、接続制御装置２０は、図２３に示すような課金情報を送信する。図２３に示す課金情報は、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）に対する拒否応答（４０１ Unauthorized）に添付されるコンテンツデータに課金情報を含めるなどした場合を示すものである。図２３の１行目「PaymentNumber：050-EEEE-XXXX」は、決済用通信番号が『０５０−ＥＥＥＥ−ＸＸＸＸ』であることを示しており、２行目「Money：4500」は、課金額が『４，５００』であることを示しており、３行目「Currency：Yen」は、通貨単位が『円』であることを示しており、４行目「PaidTo：ABC Company」は、受け取りユーザの名称が『ABC Company』であることを示しており、５行目「ValidUntil：2006/06/22 10:05:00」は、有効期限を示しており、６行目「PaymentInfoSignature：wgeghh92sf3rz4b3」は、例えば、１行目から５行目までの情報のハッシュ値を求め、秘密鍵で暗号化するなどした電子署名である。
また、支払いユーザ装置１０は、図２４に示すような同意情報を送信する。図２４に示す同意情報は、ＳＩＰに基づく接続要求メッセージ（INVITEメッセージ）のボディ部を、MultipartMIME形式に指定して分割し、通常のＳＤＰ情報に加えて、同意情報を含めるなどした場合の、ひとつのパートを示すものである。図２４の１行目「PaymentNumber：050-EEEE-XXXX」は、決済用通信番号が『０５０−ＥＥＥＥ−ＸＸＸＸ』であることを示しており、２行目「Money：4500」は、課金額が『４，５００』であることを示しており、３行目「Currency：Yen」は、通貨単位が『円』であることを示しており、４行目「PaidTo：ABC Company」は、受け取りユーザの名称が『ABC Company』であることを示しており、５行目「ValidUntil：2006/06/22 10:05:00」は、有効期限を示しており、６行目「PaymentInfoSignature：wgeghh92sf3rz4b3」は、例えば、１行目から５行目までの情報のハッシュ値を求め、秘密鍵で暗号化するなどした電子署名である。また７行目「PaidBy：Tokyo Ichiro」は、支払いユーザの名称（氏名）が『Tokyo Ichiro』であることを示しており、８行目「Date：2006/06/22 10:00:00」は、日時を示しており、９行目「TransactionID：0243231」は、送信を識別する番号を示しており、１０行目「AgreedBy：Tokyo Ichiro」は、『Tokyo Ichiroが、上記の情報に同意すること』を示しており、１１行目「PayerSignatuer：jw34aisj89sbw4i2」は、例えば、１行目から１０行目までの情報のハッシュ値を求め、秘密鍵で暗号化するなどした電子署名である。
ここで、発ＩＤに対応する秘密鍵で署名した電子署名の正当性の検証は、接続制御装置２０が、支払いユーザ装置１０の発ＩＤに対応した公開鍵を取得することによって行われる。例えば、接続制御装置２０が、発ＩＤに対応した公開鍵を保持するディレクトリサーバに接続されるなどする。なお、上記の実施例においては、電子署名として、発ＩＤに対応する秘密鍵で署名した電子署名を送信する手法を説明したが、例えば、接続制御装置２０が支払いユーザ装置１０にチャレンジコード（乱数）を送信し、支払いユーザ装置１０がチャレンジコードを秘密鍵で暗号化した電子署名を送信する手法など、同意情報とともに電子署名を送信する手法であれば、いずれでもよい。
このようにして、実施例７における接続制御システムは、さまざまな形態の決済を安全かつ適切に実行することが可能になる。すなわち、決済の当事者である『支払いユーザ』を証明する電子署名が「支払いユーザ装置」によって「接続制御装置」に送信され、「接続制御装置」において、その電子署名の正当性が検証された場合に（すなわち、決済の当事者である『支払いユーザ』本人であることが検証され、また、同意情報に改竄が行われていないことが検証され、さらに、支払いユーザが同意情報を送信した事実を否認するおそれを回避した場合に）、「接続制御装置」は、「支払いユーザ」装置に課金し、「支払いユーザ装置」と「受け取りユーザ装置」とを接続し、例えば、『支払いユーザ』になりすました別のユーザが同意情報を「接続制御装置」に送信した場合には、「接続制御装置」は、「支払いユーザ」装置に課金せず、「支払いユーザ装置」と「受け取りユーザ装置」とを接続しないことから、さまざまな形態の決済を安全かつ適切に実行することが可能になる。
［課金情報データベース］
また、上記した実施例１〜実施例６においては、課金情報が、接続制御装置２０とは別に設置される着ＩＤ ＤＢ３０（課金情報データベース）において決定される構成や、受け取りユーザ装置５０において決定される構成を説明したが、この発明はこれに限られるものではなく、例えば、接続制御装置２０の記憶部に、決済用通信番号に対応づけられた課金情報が記憶される構成などにも、この発明を同様に適用することができる。
また、上記した実施例１〜実施例６においては、課金情報が、接続制御装置２０とは別に設置される着ＩＤ ＤＢ３０（課金情報データベース）において決定される構成や、受け取りユーザ装置５０において決定される構成を説明したが、この発明はこれに限られるものではなく、例えば、接続制御装置２０の記憶部に、決済用通信番号に対応づけられた課金情報が記憶される構成などにも、この発明を同様に適用することができる。
また、上記した実施例１、実施例４および実施例６においては、着ＩＤ ＤＢ３０（課金情報データベース）が、課金ポリシーの変更指示を受け付け、変更指示に従って課金ポリシーを更新する手法を説明したが、この発明はこれに限られるものではなく、着ＩＤ ＤＢ３０（課金情報データベース）が、課金ポリシーの変更指示を受け付けず、課金ポリシーを更新しない手法にも、この発明を同様に適用することができる。
［課金情報］
また、上記した実施例１〜実施例６においては、課金情報として、課金額を支払いユーザ装置１０に送信する場合を説明したが、この発明はこれに限られるものではなく、例えば、「３００円／３分間あたり」という従量課金方式など、課金情報として課金方式を支払いユーザ装置１０に送信する場合や、「定価は４，５００円ですが、５％割引価格の４，２７５円でご提供します。」という付加的な情報を含めて課金情報として支払いユーザ装置１０に送信する場合などにも、この発明を同様に適用することができる。
また、上記した実施例１〜実施例６においては、課金情報として、課金額を支払いユーザ装置１０に送信する場合を説明したが、この発明はこれに限られるものではなく、例えば、「３００円／３分間あたり」という従量課金方式など、課金情報として課金方式を支払いユーザ装置１０に送信する場合や、「定価は４，５００円ですが、５％割引価格の４，２７５円でご提供します。」という付加的な情報を含めて課金情報として支払いユーザ装置１０に送信する場合などにも、この発明を同様に適用することができる。
［システム構成等］
また、上記した実施例１〜実施例６においては、電気通信事業者などのネットワークとしてＩＰ網を前提とし、「支払いユーザ装置」と「受け取りユーザ装置」としてＩＰ電話端末（例えば、電話機、情報家電、ファクシミリ、パーソナルコンピュータ、電話機およびホームゲートウェイなどの組合せなど）を前提とするシステム構成を説明したが、この発明はこれに限られるものではなく、例えば、電気通信事業者などのネットワークとして公衆交換電話網を前提とし、「支払いユーザ装置」と「受け取りユーザ装置」として通常の電話端末を前提とするシステム構成や、電気通信事業者などのネットワークとしてインターネットを前提とし、「支払いユーザ装置」と「受け取りユーザ装置」としてパーソナルコンピュータを前提とするシステム構成などにも、この発明を同様に適用することができる。
また、上記した実施例１〜実施例６においては、電気通信事業者などのネットワークとしてＩＰ網を前提とし、「支払いユーザ装置」と「受け取りユーザ装置」としてＩＰ電話端末（例えば、電話機、情報家電、ファクシミリ、パーソナルコンピュータ、電話機およびホームゲートウェイなどの組合せなど）を前提とするシステム構成を説明したが、この発明はこれに限られるものではなく、例えば、電気通信事業者などのネットワークとして公衆交換電話網を前提とし、「支払いユーザ装置」と「受け取りユーザ装置」として通常の電話端末を前提とするシステム構成や、電気通信事業者などのネットワークとしてインターネットを前提とし、「支払いユーザ装置」と「受け取りユーザ装置」としてパーソナルコンピュータを前提とするシステム構成などにも、この発明を同様に適用することができる。
また、上記した実施例１〜実施例６においては、接続制御システムの着ＩＤ ＤＢ３０が、決済用通信番号として電話番号を保持する手法を説明したが、この発明はこれに限られるものではなく、システム構成によっては、決済用通信番号としてＵＲＬ（Uniform Resource Locator）を保持する手法や、その他の識別子を保持する手法などにも、この発明を同様に適用することができる。
また、上記した実施例１〜実施例６においては、受け取りユーザ装置を識別する決済用通信番号として、電気通信事業者から複数の決済用通信番号が受け取りユーザに払い出される場合を説明したが、この発明はこれに限られるものではなく、電気通信事業者からひとつの決済用通信番号が受け取りユーザに払い出される手法にも、この発明を同様に適用することができる。
また、上記の実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理（例えば、実施例１の受け取りユーザ装置５０が接続制御装置２０から接続メッセージを受信した際に、常に正常応答を返すものであるとして、応答を接続制御装置２０に送信した処理など）の全部または一部を手動的におこなう（例えば、受け取りユーザ装置５０を利用する受け取りユーザによる同意を受け付けてから、応答を接続制御装置２０に送信するなど）こともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示（例えば、図２や図１０など）のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
なお、上記の実施例で説明した接続制御方法（図８、図１２、図１４、図１５、図１７、図１８、図２０、および図２２）は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
以上のように、この発明に係る支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラムは、支払いユーザ装置と支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続された接続制御装置が、支払いユーザ装置と受け取りユーザ装置との接続を制御することに有用であり、特に、さまざまな形態の決済を簡易に実行し、また、支払いユーザにとって予期せぬ決済が実行される危険を回避し、ひいては、決済用通信番号（電話番号）が不足するという事態を回避することに適する。
１０ 支払いユーザ装置
１１ 接続起動ＵＩ部
１２ 通信部
１３ 課金同意確認ＵＩ部
１４ 課金情報受信部
１５ 同意送信部
１６ 接続許可ポリシー記憶部
２０ 接続制御装置
２１ ユーザ装置向け通信部
２２ 課金情報送信部
２３ 課金情報取得部
２４ 同意確認部
２５ 接続処理部
２６ 課金指示部
３０ 着ＩＤ ＤＢ
４０ アカウントシステム
５０ 受け取りユーザ装置
５１ 通信部
５２ 課金情報送信部
５３ 課金情報決定部
５４ 判断結果送信部
５５ 判断部
６０ 在庫ＤＢ
１１ 接続起動ＵＩ部
１２ 通信部
１３ 課金同意確認ＵＩ部
１４ 課金情報受信部
１５ 同意送信部
１６ 接続許可ポリシー記憶部
２０ 接続制御装置
２１ ユーザ装置向け通信部
２２ 課金情報送信部
２３ 課金情報取得部
２４ 同意確認部
２５ 接続処理部
２６ 課金指示部
３０ 着ＩＤ ＤＢ
４０ アカウントシステム
５０ 受け取りユーザ装置
５１ 通信部
５２ 課金情報送信部
５３ 課金情報決定部
５４ 判断結果送信部
５５ 判断部
６０ 在庫ＤＢ
Claims (15)
- 支払いユーザ装置と当該支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、当該支払いユーザ装置と当該受け取りユーザ装置との接続を制御する接続制御装置であって、
前記決済用通信番号で識別される前記受け取りユーザ装置に対する接続要求を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置に対する課金内容を示す情報として、当該決済用通信番号に対応づけられた課金情報を取得して当該支払いユーザ装置に送信する課金情報送信手段と、
前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置の課金額を管理する管理部の当該課金額に当該課金情報に基づく課金額を加算するように格納する課金情報格納手段と、
前記同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続する接続手段と、
を備えたことを特徴とする接続制御装置。 - 前記課金情報送信手段は、前記決済用通信番号に対応づけて管理する課金ポリシーに基づいて前記課金情報を決定する課金情報データベースに通信可能に接続され、当該課金情報データベースから当該課金情報を取得して前記支払いユーザ装置に送信することを特徴とする請求項１に記載の接続制御装置。
- 前記課金情報データベースは、前記課金ポリシーの変更指示を受け付け、当該変更指示に従って当該課金ポリシーを更新するものであって、
前記課金情報送信手段は、前記課金情報データベースが管理する課金ポリシーが更新された後に前記接続要求を前記支払いユーザ装置から受信した場合に、更新された後の課金ポリシーに基づいて決定された課金情報を取得して当該支払いユーザ装置に送信し、
前記課金情報格納手段は、前記更新された後の課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、前記管理部の当該支払いユーザ装置の課金額に当該更新された後の課金情報に基づく課金額を加算するように格納し、
前記接続手段は、前記更新された後の課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続することを特徴とする請求項２に記載の接続制御装置。 - 前記受け取りユーザ装置は、前記決済用通信番号に対応づけて課金ポリシーを管理し、前記接続制御装置からの要求に応じて当該課金ポリシーに基づいて前記課金情報を決定し、決定した当該課金情報を当該接続制御装置に送信するものであって、
前記課金情報送信手段は、前記課金情報の提供を前記受け取りユーザ装置に要求し、当該受け取りユーザ装置において決定された課金情報を当該受け取りユーザ装置から受信して前記支払いユーザ装置に送信することを特徴とする請求項１に記載の接続制御装置。 - 前記受け取りユーザ装置は、前記課金ポリシーとして、前記決済用通信番号の配下で所定の識別子ごとに区分けされた課金ポリシーを管理し、当該所定の識別子を前記接続制御装置から受信した場合に、当該所定の識別子を用いて決定した課金情報を前記接続制御装置に送信するものであり、
前記支払いユーザ装置は、前記接続要求とともに前記所定の識別子を前記接続制御装置に送信するものであって、
前記課金情報送信手段は、前記接続要求とともに前記所定の識別子を前記支払いユーザ装置から受信した場合に、当該所定の識別子を前記受け取りユーザ装置に送信することで、前記課金情報の提供を当該受け取りユーザ装置に要求することを特徴とする請求項４に記載の接続制御装置。 - 前記受け取りユーザ装置は、前記決済用通信番号で識別される決済の対象である決済対象の状況を管理し、前記支払いユーザ装置からの接続要求があることを示す接続情報を前記接続制御装置から受信した場合に、当該決済対象の状況を用いて当該接続要求を受け付けるか否かを判断し、判断した判断結果を当該接続制御装置に送信するものであって、
前記課金情報格納手段は、前記接続要求を受け付けることを示す判断結果を前記受信ユーザ装置から受信した場合に、前記管理部の前記支払いユーザ装置の課金額に前記課金情報に基づく課金額を加算するように格納し、
前記接続手段は、前記接続要求を受け付けることを示す判断結果を当該受信ユーザ装置から受信した場合に、当該支払いユーザ装置と当該受け取りユーザ装置とを接続することを特徴とする請求項１〜５のいずれかひとつに記載の接続制御装置。 - 前記課金情報は、所定の接続条件をさらに含むものであって、
前記課金情報送信手段は、前記所定の接続条件をさらに含む前記課金情報を取得して前記支払いユーザ装置に送信し、
前記課金情報格納手段は、前記所定の接続条件をさらに含む前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置の課金額を管理する管理部の当該管理額に当該課金情報に基づく課金額を加算するように格納し、
前記接続手段は、前記所定の接続条件をさらに含む前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続することを特徴とする請求項１〜６のいずれかひとつに記載の接続制御装置。 - 前記管理部は、前記支払いユーザ装置の課金額を管理するとともに前記受け取りユーザ装置の課金額を管理するものであって、
前記課金情報格納手段は、前記課金情報に基づく課金額を、前記管理部が管理する前記支払いユーザ装置の課金額に加算するように格納するとともに、当該管理部が管理する前記受け取りユーザ装置の課金額から減算するように格納することを特徴とする請求項１〜７のいずれかひとつに記載の接続制御装置。 - 前記支払いユーザ装置は、前記同意情報とともに電子署名を前記接続制御装置に送信するものであって、
前記課金情報格納手段は、前記同意情報とともに前記電子署名を前記支払いユーザ装置から受信し、当該電子署名の正当性が検証された場合に、前記管理部の当該支払いユーザ装置の課金額に前記課金情報に基づく課金額を加算するように格納し、
前記接続手段は、前記同意情報とともに前記電子署名を前記支払いユーザ装置から受信し、当該電子署名の正当性が検証された場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続することを特徴とする請求項１〜８のいずれかひとつに記載の接続制御装置。 - 決済用通信番号で識別される受け取りユーザ装置に接続制御装置を介して通信可能に接続する支払いユーザ装置であって、
課金内容を示す情報として、前記決済用通信番号に対応づけられた課金情報を前記接続制御装置から受信して、当該課金情報を所定の出力部に出力する課金情報出力手段と、
前記課金情報出力手段によって出力された前記課金情報に同意することを示す同意情報の入力を所定の入力部において受け付ける同意情報受付手段と、
前記同意情報受付手段によって受け付けられた前記同意情報を、当該同意情報の受信を条件に前記受け取りユーザ装置との接続を許可する前記接続制御装置に送信する同意情報送信手段と、
を備えたことを特徴とする支払いユーザ装置。 - 前記課金情報に対応づけて所定の接続ポリシーを保持する接続ポリシー保持手段をさらに備え、
前記同意情報送信手段は、前記同意情報受付手段によって前記同意情報の入力を受け付けると、前記接続ポリシー保持手段によって保持された前記所定の接続ポリシーを参照し、当該所定の接続ポリシーを充たす場合に、当該同意情報を前記接続制御装置に送信することを特徴とする請求項１０に記載の支払いユーザ装置。 - 支払いユーザ装置において決済用通信番号で識別され、接続制御装置を介して当該支払いユーザ装置に通信可能に接続する受け取りユーザ装置であって、
前記決済用通信番号に対応づけて課金ポリシーを管理し、前記接続制御装置からの要求に応じて当該課金ポリシーに基づいて課金内容を示す情報として課金情報を決定する課金情報決定手段と、
前記課金情報決定手段によって決定された課金情報を、当該課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信することを条件に当該支払いユーザ装置との接続を許可する前記接続制御装置に送信する課金情報送信手段と、
を備えたことを特徴とする受け取りユーザ装置。 - 支払いユーザ装置と当該支払いユーザ装置において決済用通信番号で識別される受け取りユーザ装置とに通信可能に接続されて、当該支払いユーザ装置と当該受け取りユーザ装置との接続を制御する方法を接続制御装置としてのコンピュータに実行させる接続制御プログラムであって、
前記決済用通信番号で識別される前記受け取りユーザ装置に対する接続要求を前記支払いユーザ装置から受信した場合に、当該決済用通信番号に対応づけられた課金情報を取得して当該支払いユーザ装置に送信する課金情報送信手順と、
前記課金情報に同意することを示す同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置の課金額を管理する管理部の当該課金額に当該課金情報に基づく課金額を加算するように格納する課金情報格納手順と、
前記同意情報を前記支払いユーザ装置から受信した場合に、当該支払いユーザ装置と前記受け取りユーザ装置とを接続する接続手順と、
を接続制御装置としてのコンピュータに実行させることを特徴とする接続制御プログラム。 - 決済用通信番号で識別される受け取りユーザ装置に接続制御装置を介して通信可能に接続する方法を支払いユーザ装置としてのコンピュータに実行させる支払いユーザプログラムであって、
前記決済用通信番号に対応づけられた課金情報を前記接続制御装置から受信して、当該課金情報を所定の出力部に出力する課金情報出力手順と、
前記課金情報出力手順によって出力された前記課金情報に同意することを示す同意情報の入力を所定の入力部において受け付ける同意情報受付手順と、
前記同意情報受付手順によって受け付けられた前記同意情報を前記接続制御装置に送信する同意情報送信手順と、
を支払いユーザ装置としてのコンピュータに実行させることを特徴とする支払いユーザプログラム。 - 支払いユーザ装置において決済用通信番号で識別され、接続制御装置を介して当該支払いユーザ装置に通信可能に接続する方法を受け取りユーザ装置としてのコンピュータに実行させる受け取りユーザプログラムであって、
前記決済用通信番号に対応づけて課金ポリシーを管理し、前記接続制御装置からの要求に応じて当該課金ポリシーに基づいて課金情報を決定する課金情報決定手順と、
前記課金情報決定手順によって決定された課金情報を前記接続制御装置に送信する課金情報送信手順と、
を受け取りユーザ装置としてのコンピュータに実行させることを特徴とする受け取りユーザプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006178404A JP4519812B2 (ja) | 2006-06-28 | 2006-06-28 | 接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006178404A JP4519812B2 (ja) | 2006-06-28 | 2006-06-28 | 接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008011075A JP2008011075A (ja) | 2008-01-17 |
| JP4519812B2 true JP4519812B2 (ja) | 2010-08-04 |
Family
ID=39068904
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006178404A Expired - Fee Related JP4519812B2 (ja) | 2006-06-28 | 2006-06-28 | 接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4519812B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101442260B1 (ko) * | 2008-12-10 | 2014-09-23 | 주식회사 케이티 | 정책관리시스템에서의 정책정보 동기화 방법 |
| JP6901181B1 (ja) * | 2020-11-20 | 2021-07-14 | 株式会社アクリート | 決済方法及びプログラム |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002259878A (ja) * | 2001-03-05 | 2002-09-13 | Nippon Telegr & Teleph Corp <Ntt> | 料金代行徴収方法 |
| JP2002325136A (ja) * | 2001-04-26 | 2002-11-08 | Nippon Telegr & Teleph Corp <Ntt> | コンテンツ配信・課金決済代行システム、ネットワーク管理センタ、および情報流通センタ |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3295886B2 (ja) * | 1996-01-17 | 2002-06-24 | 日本電信電話株式会社 | 課金システムおよびディジタル端末ならびに課金信号送出装置 |
-
2006
- 2006-06-28 JP JP2006178404A patent/JP4519812B2/ja not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002259878A (ja) * | 2001-03-05 | 2002-09-13 | Nippon Telegr & Teleph Corp <Ntt> | 料金代行徴収方法 |
| JP2002325136A (ja) * | 2001-04-26 | 2002-11-08 | Nippon Telegr & Teleph Corp <Ntt> | コンテンツ配信・課金決済代行システム、ネットワーク管理センタ、および情報流通センタ |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2008011075A (ja) | 2008-01-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102573112B (zh) | 电信网络能力开放方法、系统及联盟支撑平台 | |
| CN109801049B (zh) | 资源转移方法和装置、计算机设备和存储介质 | |
| US20080279347A1 (en) | Destination device billing according to call recipient | |
| JP5095689B2 (ja) | 情報提供システム | |
| JP4519812B2 (ja) | 接続制御装置、支払いユーザ装置、受け取りユーザ装置、接続制御プログラム、支払いユーザプログラム、および受け取りユーザプログラム | |
| US8260679B2 (en) | System and method of event triggered voice call origination | |
| US9785927B2 (en) | Telephonic payment processing method for online services | |
| KR20120082644A (ko) | 휴대 단말을 이용한 결제 처리 방법 및 서버 | |
| JP5002675B2 (ja) | サーバ装置及び通信システム及びサーバ装置で使用される制御方法 | |
| KR100806501B1 (ko) | 개인정보 중계 시스템 및 이를 이용한 상품 거래 방법 | |
| JP2006285444A (ja) | 決済・料金回収代行システム | |
| JP5156064B2 (ja) | 個人特定ｉｄ管理システム | |
| KR101781636B1 (ko) | 공유아이디 이용하는 유선온라인상거래 카드결제 시스템 및 방법 | |
| JP2002342592A (ja) | コンテンツサーバおよびコンテンツ配信システムにおける課金方法 | |
| JP3902602B2 (ja) | サーバ装置およびこれを用いる非同期電子決済のサービス方法 | |
| JP2009218633A (ja) | プリペイド型決済システムおよび方法 | |
| WO2011140764A1 (zh) | 一种实现服务提供者外呼的系统及方法 | |
| KR20050106209A (ko) | 전화 주문에 따른 대금 결제 시스템 및 그 방법 | |
| JP4113038B2 (ja) | 通信システム、通信機器の機能設定方法及びセンタ装置並びにユーザ装置 | |
| KR101124645B1 (ko) | 수신자 부담 메시지 서비스 제공장치 및 방법 | |
| KR20100136041A (ko) | 질문/답변 인터페이스를 이용한 휴대폰 소액결제 처리방법 및 시스템 | |
| KR20100136038A (ko) | 질문/답변 인터페이스를 이용한 휴대폰 소액결제 처리방법 및 시스템 | |
| KR101218685B1 (ko) | 양방향 미디어기기에서의 대금 결제 방법 및 시스템 | |
| JP2002094699A (ja) | 電話サービスの提供方法及び提供システム | |
| KR20170052544A (ko) | 휴대폰의 프로그램을 이용한 결제 처리 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080731 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100119 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100518 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100519 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130528 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140528 Year of fee payment: 4 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |