JP2009059148A - 情報処理システム及び情報処理プログラム - Google Patents

Abstract

【課題】サービス提供の契約に基づいて、認可すべきサービスを特定し、そのサービスの利用者登録を組織に基づいて行うようにした情報処理システムを提供する。
【解決手段】情報処理システムの契約情報記憶手段は、契約識別子、認可対象サービス識別子、課金条件識別子を対応させて記憶し、組織情報記憶手段は、組織識別子、利用者識別子を対応させて記憶し、利用者認可情報記憶手段は、契約識別子、利用者識別子、サービス識別子を対応させて記憶し、認可対象サービス取得手段は、契約識別子に基づいて、契約情報記憶手段に記憶されている認可対象サービス識別子を取得し、組織受付手段は、その認可対象サービスを利用できる組織の組織識別子を受け付け、利用者認可手段は、その組織識別子に基づいて、組織情報記憶手段に記憶されている利用者識別子を取得し、利用者識別子及び認可対象サービス識別子を利用者認可情報記憶手段に記憶させる。
【選択図】図１

Description

本発明は、情報処理システム及び情報処理プログラムに関する。

対価を得るために電子的なサービスを提供する場合には、契約、最終債務者、サービス認可、課金、組織情報等を関連づけ、効率的に維持していく必要がある。電子的なサービスを効率的に提供するためには、契約から利用認可、課金、そして最終的な債権回収プロセスまでを、一貫して管理・運用しなければならないからである。

電子的な契約処理を扱うための技術は、いくつか提案されている。
例えば、特許文献１に記載の技術は、第三者を通じて消費者と商人の間で商品及びサービスに関する購入契約をする方法を提供することを課題とし、消費者は契約に関する第１見解を生成し、第三者に送信し、商人は、別途、契約に関する第２見解を生成し、第三者に送信し、セキュア取引サーバーよりなる第三者は契約に関する消費者及び商人の見解を受信すると、商人及び消費者の身元を確認し、互いに独立に生成された契約の各見解の詳細が合致することを確認し、条件が満たされる場合に購入契約を交わし、消費者及び商人の間で無線通信を利用して購入取引を行うコンピュータシステムであって、消費者が操作する移動装置、商人が操作する装置、セキュア取引サーバー（ＳＴＳ）装置、支払サービス装置、消費者の装置及び商人の装置との無線通信ネットワーク、商人の装置及びＳＴＳ装置との通信ネットワーク、ＳＴＳ装置及び支払サービス装置との通信ネットワークよりなることが開示されている。つまり、消費者と商人との間の電子的な契約の信頼性を高めるために、契約を仲介する第三者を設け、契約の成立をより確かなものにするものである。

また、例えば、特許文献２に記載の技術は、電子契約文書をデジタルに署名するための方法及びシステムであって、電子通信は、識別子、その文書を含むメッセージ、及び非対称鍵の対の秘密鍵を用いて生成されたデジタル署名を含み、この識別子を使用して対応する公開鍵及びそのメッセージの送信側に関するアカウント情報を取り出し、この公開鍵を使用して送信側及びメッセージを認証し、秘密鍵を含むデバイスを使用してデバイスのプライバシーを保護し、さらにこのデバイスは、デバイスへの検証データ入力に対応する検証ステータスインジケータを生成し、さらにこのインジケータは、契約文書の送信側がデジタルに署名されるべき電子通信が生じる明らかな実施を履行した証拠として使用され、安全なデータベースにおける公開鍵にリンクされたセキュリティプロフィールは、このデバイスのセキュリティ特徴を示すことが開示されている。つまり、契約に関する一連の処理プロセスを安全に実施するための技術である。

電子的なサービスを提供する際のユーザー管理については、いくつかの方法が提案されている。
例えば、特許文献３に記載の技術は、サービス提供サイトでのユーザー認証をユーザーＩＤ／パスワード（認証情報）により行う場合、認証情報はサービス提供サイトごとに管理されているため、ユーザーはサービス提供サイトごとの認証情報を記憶する必要があり、また、ユーザーが認証情報を忘れた場合、サービス提供サイトへのアクセス中止や認証情報再入手手続きなど、サービス提供サイトでの運用コスト負担も問題となることを課題とし、ユーザー認証管理サイトを設け、各サービス提供サイトで管理しているユーザー認証情報を統合管理することで、ユーザーは１つの認証情報により常にサービス提供サイトへアクセスできるようにすることが開示されている。つまり、ＩＤフェデレーション技術を使用すれば、１人のユーザーが複数のサービスを利用することができる環境が提供されるが、特許文献３に記載の技術は、このＩＤフェデレーションの基本的な流れに関するものである。

また、例えば、特許文献４に記載の技術は、利用者が各種サービス機関のサービス提供を受けようとする際に必要となる個人情報の管理を効率化し、利用者の利便性を向上させることを課題とし、情報管理機関が各種サービス機関との間及び利用者との間に個人情報授受の契約を締結し、前記利用者の個人情報を一括管理するとともに、前記利用者が前記サービス機関のサービス提供を受ける際に必要に応じて前記サービス機関に対して個人情報を提供することが開示されている。つまり、登録した個人情報を他のサービスと共有するための機構に関するものである。そして、これらの技術に基づいて、個々のサービスの利用に対する認可が行われ、サービスの利用が開始される。

特開２００４−１６４５９７号公報 特表２００４−５１７３８１号公報 特開２００４−０７８６２２号公報 特開２００１−３４４３７９号公報

しかしながら、これらの技術は、電子的な契約行為の信頼性を高めるためのもの、又はユーザー管理を効率化するためのものであり、サービスの提供契約に関する一連の処理を効率的に実施するものではない。
本発明は、サービス提供の契約に基づいて、認可すべきサービスを特定し、そのサービスの利用者登録を組織に基づいて行うようにした情報処理システム及び情報処理プログラムを提供することを目的としている。

かかる目的を達成するための本発明の要旨とするところは、次の各項の発明に存する。
［請求項１］ 契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
組織を識別する組織識別子、該組織に所属する利用者を識別する利用者識別子を対応させて記憶する組織情報記憶手段と、
前記契約識別子、前記利用者識別子、該契約識別子の契約において該利用者識別子の利用者に認可されたサービスを識別するサービス識別子を対応させて記憶する利用者認可情報記憶手段と、
利用者に対してサービスの認可処理を行う対象となる契約の契約識別子を受け付ける契約受付手段と、
前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている認可対象サービス識別子を取得する認可対象サービス取得手段と、
前記認可対象サービス取得手段によって取得された認可対象サービス識別子の認可対象サービスを利用できる組織の組織識別子を受け付ける組織受付手段と、
前記組織受付手段によって受け付けられた組織識別子に基づいて、前記組織情報記憶手段に記憶されている利用者識別子を取得し、該利用者識別子及び前記認可対象サービス取得手段によって取得された認可対象サービス識別子を前記利用者認可情報記憶手段に記憶させる利用者認可手段
を具備することを特徴とする情報処理システム。

［請求項２］ 契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
前記契約識別子、利用者を特定する利用者識別子、サービスを特定するサービス識別子、該サービスの利用量を表すサービス利用量を対応させて記憶する利用履歴記憶手段と、
前記課金条件識別子、課金の条件を対応させて記憶する課金条件記憶手段と、
サービスの利用料金の計算処理の対象となる契約の契約識別子を受け付ける契約受付手段と、
前記契約受付手段によって受け付けられた契約識別子に基づいて、前記利用履歴記憶手段に記憶されているサービス利用量を取得するサービス利用量取得手段と、
前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている課金条件識別子を取得し、該課金条件識別子に基づいて、前記課金条件記憶手段に記憶されている課金の条件を取得する課金条件取得手段と、
前記サービス利用量取得手段によって取得されたサービス利用量及び前記課金条件取得手段によって取得された課金の条件に基づいて、前記契約におけるサービスの利用料金を計算するサービス利用料金計算手段
を具備することを特徴とする情報処理システム。

［請求項３］ 前記契約識別子、前記利用者識別子、該契約識別子の契約において該利用者識別子の利用者に認可されたサービスを識別するサービス識別子、該利用者識別子の利用者によるサービスの利用料金を請求する請求先を識別する請求先識別子を対応させて記憶する利用者認可情報記憶手段
をさらに具備し、
前記サービス利用料金計算手段は、前記利用者認可情報記憶手段に記憶されている請求先識別子に基づいて、該請求先識別子に対応する前記利用者識別子の利用者によるサービスの利用料金を合算する
ことを特徴とする［請求項２］に記載の情報処理システム。

［請求項４］ コンピュータを、
契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
組織を識別する組織識別子、該組織に所属する利用者を識別する利用者識別子を対応させて記憶する組織情報記憶手段と、
前記契約識別子、前記利用者識別子、該契約識別子の契約において該利用者識別子の利用者に認可されたサービスを識別するサービス識別子を対応させて記憶する利用者認可情報記憶手段と、
利用者に対してサービスの認可処理を行う対象となる契約の契約識別子を受け付ける契約受付手段と、
前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている認可対象サービス識別子を取得する認可対象サービス取得手段と、
前記認可対象サービス取得手段によって取得された認可対象サービス識別子の認可対象サービスを利用できる組織の組織識別子を受け付ける組織受付手段と、
前記組織受付手段によって受け付けられた組織識別子に基づいて、前記組織情報記憶手段に記憶されている利用者識別子を取得し、該利用者識別子及び前記認可対象サービス取得手段によって取得された認可対象サービス識別子を前記利用者認可情報記憶手段に記憶させる利用者認可手段
として機能させることを特徴とする情報処理プログラム。

［請求項５］ コンピュータを、
契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
前記契約識別子、利用者を特定する利用者識別子、サービスを特定するサービス識別子、該サービスの利用量を表すサービス利用量を対応させて記憶する利用履歴記憶手段と、
前記課金条件識別子、課金の条件を対応させて記憶する課金条件記憶手段と、
サービスの利用料金の計算処理の対象となる契約の契約識別子を受け付ける契約受付手段と、
前記契約受付手段によって受け付けられた契約識別子に基づいて、前記利用履歴記憶手段に記憶されているサービス利用量を取得するサービス利用量取得手段と、
前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている課金条件識別子を取得し、該課金条件識別子に基づいて、前記課金条件記憶手段に記憶されている課金の条件を取得する課金条件取得手段と、
前記サービス利用量取得手段によって取得されたサービス利用量及び前記課金条件取得手段によって取得された課金の条件に基づいて、前記契約におけるサービスの利用料金を計算するサービス利用料金計算手段
として機能させることを特徴とする情報処理プログラム。

請求項１記載の情報処理システムによれば、サービス提供の契約に基づいて、認可すべきサービスを特定し、そのサービスの利用者登録を組織に基づいて行うことができるようになる。

請求項２記載の情報処理システムによれば、サービス提供の契約に基づいて、課金すべき履歴を特定し、そのサービスの利用料金を計算することができるようになる。

請求項３記載の情報処理システムによれば、さらに、請求先における利用者のサービスの利用料金を計算することができるようになる。

請求項４記載の情報処理プログラムによれば、サービス提供の契約に基づいて、認可すべきサービスを特定し、そのサービスの利用者登録を組織に基づいて行うことができるようになる。

請求項５記載の情報処理プログラムによれば、サービス提供の契約に基づいて、課金すべき履歴を特定し、そのサービスの利用料金を計算することができるようになる。

以下、図面に基づき本発明を実現するにあたっての好適な一実施の形態を説明する。
本実施の形態は、電子的なサービスを提供するために、契約からサービス提供、課金・請求に至る処理を効率的に実施するための基盤を提供するものである。
具体的には、サービスを提供し対価を得る契約において、契約における合意内容としての最終債務者・サービス内容・課金条件、サービス提供処理情報としてのユーザー利用権・料金請求先、サービス提供処理情報の効率的な変更のための組織情報、を構造的に管理する。そして、この構造に基づいて、サービス提供、課金計算、料金請求、債権回収、といったサービス提供にかかわる一連の業務を効率的に運営するための基盤を提供するものである。

（装置の全体構成）
図１は、本発明の一実施の形態の概念的なモジュール構成図を示している。
なお、モジュールとは、一般的に論理的に分離可能なソフトウェア（コンピュータ・プログラム）、ハードウェア等の部品を指す。したがって、本実施の形態におけるモジュールはコンピュータ・プログラムにおけるモジュールのことだけでなく、ハードウェア構成におけるモジュールも指す。それゆえ、本実施の形態は、コンピュータ・プログラム、システム及び方法の説明をも兼ねている。ただし、説明の都合上、「記憶する」、「記憶させる」、これらと同等の文言を用いるが、これらの文言は、実施の形態がコンピュータ・プログラムの場合は、記憶装置に記憶させること、又は記憶装置に記憶させるように制御するの意である。また、モジュールは機能にほぼ一対一に対応しているが、実装においては、１モジュールを１プログラムで構成してもよいし、複数モジュールを１プログラムで構成してもよく、逆に１モジュールを複数プログラムで構成してもよい。また、複数モジュールは１コンピュータによって実行されてもよいし、分散又は並列環境におけるコンピュータによって１モジュールが複数コンピュータで実行されてもよい。なお、１つのモジュールに他のモジュールが含まれていてもよい。また、以下、「接続」とは物理的な接続の他、論理的な接続（データの授受、指示、データ間の参照関係等）を含む。
また、システム又は装置とは、複数のコンピュータ、ハードウェア、装置等がネットワーク（一対一対応の通信接続を含む）等の通信手段で接続されて構成されるほか、１つのコンピュータ、ハードウェア、装置等によって実現される場合も含まれる。

以下、利用者として、法人、個人であるユーザーを主に例示して説明する。そして、記載を簡便にするために、ユーザー等が主体となって動作するように記載する場合もあるが、これはそのユーザーによる操作に応じて、システムが動作するものである。
また、管理という用語を用いるが、これは文脈に応じて、制御する、マネジメントする、制御又はマネジメントするためのデータ、そのデータを記憶するの意で用い、その役割又は動作を指す。

本実施の形態は、図１に示すように、契約管理サーバー１１１、組織管理サーバー１１４、ユーザー認証サーバー１１７、サービス提供サーバー１１９、履歴収集サーバー１２３、ユーザー端末１１５を備え、これらを通信回線であるネットワーク１２４によってそれぞれ接続している。なお、契約管理サーバー１１１、組織管理サーバー１１４、ユーザー認証サーバー１１７等の各サーバーは、独立して構成しているが、例えば契約管理サーバー１１１、組織管理サーバー１１４とを組み合わせて１つのサーバーとしてもよく、その組み合わせは任意である。

契約管理サーバー１１１は、法的人格者ＤＢ（ＤａｔａＢａｓｅ）１０１、サービス管理ＤＢ１０２、課金条件ＤＢ１０３、契約文言ＤＢ１０４、契約ＤＢ１０５、契約管理モジュール１０６、ユーザー認可管理モジュール１０７、ユーザーＤＢ１０８、利用認可ＤＢ１０９、請求先ＤＢ１１０を有している。

法的人格者ＤＢ１０１は、契約ＤＢ１０５と接続されており、契約締結先の法人又は自然人情報を記憶する。
サービス管理ＤＢ１０２は、契約ＤＢ１０５と接続されており、提供サービスの情報を記憶する。
課金条件ＤＢ１０３は、契約ＤＢ１０５と接続されており、提供サービスに対する課金条件を記憶する。つまり、課金条件識別子、課金の条件を対応させて記憶する。具体的には、図９に示した課金条件テーブル９０を用いて説明する。
契約文言ＤＢ１０４は、契約ＤＢ１０５と接続されており、契約文言を記憶する。

契約ＤＢ１０５は、法的人格者ＤＢ１０１、サービス管理ＤＢ１０２、課金条件ＤＢ１０３、契約文言ＤＢ１０４と接続されており、契約管理モジュール１０６、ユーザー認可管理モジュール１０７からアクセスされ、法的人格者、提供サービス、課金条件、契約文言を関連づけて管理する。つまり、契約を識別する契約識別子、その契約において認可対象とされているサービスを識別する認可対象サービス識別子、そのサービスにおける課金の条件を識別する課金条件識別子等を対応させて記憶する。具体的には、図５に示した契約情報テーブル５０を用いて説明する。
契約管理モジュール１０６は、契約ＤＢ１０５と接続されており、契約ＤＢ１０５を管理する。

ユーザーＤＢ１０８は、ユーザー認可管理モジュール１０７と接続されており、ユーザー情報を記憶する。
請求先ＤＢ１１０は、ユーザー認可管理モジュール１０７と接続されており、請求先を記憶する。
利用認可ＤＢ１０９は、ユーザー認可管理モジュール１０７からアクセスされ、契約ＤＢ１０５において管理されている契約と、ユーザーＤＢ１０８において管理されているユーザーの中のサービスを認可するユーザーと、請求先ＤＢ１１０に管理されている請求先情報とを関連づけて管理する。つまり、契約識別子、利用者識別子、その契約識別子の契約においてその利用者識別子の利用者に認可されたサービスを識別するサービス識別子、その利用者識別子の利用者によるサービスの利用料金を請求する請求先を識別する請求先識別子等を対応させて記憶する。具体的には、図１３に示したユーザー認可情報テーブル１３００を用いて説明する。

ユーザー認可管理モジュール１０７は、契約ＤＢ１０５、ユーザーＤＢ１０８、利用認可ＤＢ１０９、請求先ＤＢ１１０と接続されており、利用認可ＤＢ１０９等のＤＢを管理する。つまり、利用者に対してサービスの認可処理を行う対象となる契約の契約識別子をユーザー端末１１５から受け付け、その受け付けられた契約識別子に基づいて、契約ＤＢ１０５に記憶されている認可対象サービス識別子を取得し、その取得された認可対象サービス識別子の認可対象サービスを利用できる組織の組織識別子をユーザー端末１１５から受け付け、その受け付けられた組織識別子に基づいて、組織管理モジュール１１３を介して組織ＤＢ１１２に記憶されている利用者識別子を取得し、その利用者識別子及び認可対象サービス識別子を利用認可ＤＢ１０９に記憶させる。

組織管理サーバー１１４は、組織ＤＢ１１２、組織管理モジュール１１３を有している。
組織ＤＢ１１２は、組織管理モジュール１１３からアクセスされ、ユーザーＤＢ１０８のグループとして定義される組織情報を記憶する。つまり、組織を識別する組織識別子、その組織に所属する利用者を識別する利用者識別子等を対応させて記憶する。具体的には、図１４に示した組織情報テーブル１４００を用いて説明する。
組織管理モジュール１１３は、組織ＤＢ１１２と接続されており、組織ＤＢ１１２を管理する。

ユーザー認証サーバー１１７は、ユーザー認証モジュール１１６を有しており、ユーザー認証モジュール１１６は、ユーザー認証を実施する。

サービス提供サーバー１１９は、サービス提供モジュール１１８を有しており、サービス提供モジュール１１８は、サービスを提供するモジュール群（１つであってもよい）である。
ユーザー端末１１５は、ユーザーが使用する端末であり、１台であっても複数あってもよい。

履歴収集サーバー１２３は、履歴収集モジュール１２０、課金・請求処理モジュール１２１、利用履歴ＤＢ１２２を有している。
履歴収集モジュール１２０は、利用履歴ＤＢ１２２と接続されており、ユーザーによるサービスの利用履歴を収集する。
利用履歴ＤＢ１２２は、履歴収集モジュール１２０、課金・請求処理モジュール１２１からアクセスされ、履歴収集モジュール１２０が収集した履歴を記憶する。つまり、契約識別子、利用者を特定する利用者識別子、サービスを特定するサービス識別子、そのサービスの利用量を表すサービス利用量等を対応させて記憶する。具体的には、図１９に示したサービス利用履歴テーブル１９００を用いて説明する。

課金・請求処理モジュール１２１は、利用履歴ＤＢ１２２と接続されており、利用履歴ＤＢ１２２に記憶されている利用履歴を集計し、契約ＤＢ１０５の契約に基づいて課金条件ＤＢ１０３に記憶されている課金条件を適用して請求金額を計算する。つまり、サービスの利用料金の計算処理の対象となる契約の契約識別子をユーザー端末１１５から受け付け、その受け付けられた契約識別子に基づいて、利用履歴ＤＢ１２２に記憶されているサービス利用量を取得し、また、契約管理モジュール１０６を介して契約ＤＢ１０５に記憶されている課金条件識別子を取得し、その課金条件識別子に基づいて、契約管理モジュール１０６を介して課金条件ＤＢ１０３に記憶されている課金の条件を取得し、取得されたサービス利用量及び課金の条件に基づいて、契約におけるサービスの利用料金を計算する。

（管理構造）
図２は、本実施の形態において管理される契約に関する情報の構造例を示したものである。
サービス提供契約２０を中心にして、サービス提供契約２０と接続して法的人格者（自然人・法人）２１、認可対象サービス２２、課金条件２３、契約書文言２４、認可対象ユーザー２５、請求先２６、組織２７を管理する。
サービス提供契約２０で管理される対象は、社会的及び法的な行為としての契約行為である。契約は、主に、最終債務者に関する契約条件（法的人格者（自然人・法人）２１）、役務（サービス）提供範囲に関する契約条件（認可対象サービス２２）、役務提供の対価に関する契約条件（課金条件２３）によって規定される。
つまり、この契約における合意内容として、契約締結先である法的人格者（自然人・法人）２１が管理される。この法的人格者（自然人・法人）２１は、サービス提供に対する最終債務者となる。
また、このサービス提供契約２０において提供される認可対象サービス２２、つまり役務の提供範囲も規定される。
最後に、役務提供の対価を計算するための課金条件２３が規定される。
また、実際の契約には、紛争の解決方法といった詳細な合意内容や１つ１つの契約に特有の条項等が含まれるため、契約書文言２４も関連づけて管理する。
以上の法的人格者（自然人・法人）２１、認可対象サービス２２、課金条件２３、契約書文言２４については、契約に含まれる合意内容であり、図２では実線で関連づけが示されている。

さらに、サービス提供契約２０に関連づけて、実際にサービス提供を認可される認可対象ユーザー２５が管理される。つまり、サービス提供における実務処理上の指定によって行われる。
また、サービス提供契約２０に関連づけて、認可対象ユーザー２５ごとのサービス利用に対する課金の請求先２６が管理される。つまり、請求事務処理上の指定によって行われる。
認可対象ユーザー２５や請求先２６は、契約者からの指定に基づく管理情報である。図２では、波線で関連づけが示されている。

部門や部署といった組織２７は、契約対象等から独立したユーザー群を管理するグループとして記憶される。このことにより、法人を超えた組織を定義することも可能である。この組織２７の情報は、契約には直接関連しておらず、認可対象ユーザー２５や請求先２６の設定・変更等の事務処理を効率的に実行するために利用される。図２では、一点鎖線で関連づけが表現されている。

図３は、図２における各種情報管理単位を、本実施の形態における管理基盤内においてＩＤ（ＩＤｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ、識別子）で管理するためのＩＤ構造例を示したものである。
ＩＤ種別として、契約（契約ＤＢ１０５に記憶される契約）、自然人（法的人格者ＤＢ１０１に記憶される自然人）、法人（法的人格者ＤＢ１０１に記憶される法人）、サービス（サービス提供サーバー１１９で提供され、サービス管理ＤＢ１０２で管理されるサービス）、課金条件（課金条件ＤＢ１０３に記憶される課金ロジック）、契約書文言（契約文言ＤＢ１０４に記憶される契約文言）、ユーザー（ユーザーＤＢ１０８に記憶され、サービスの利用認可対象となるユーザー）、請求先（請求先ＤＢ１１０に記憶される請求書の送付先情報）、組織（組織ＤＢ１１２に記憶される組織）がある。
ＩＤの構造としては、ＩＤの種別を示すヘッダ（４文字、例えば、契約は「ＣＯＮＴ」等）と６桁の数値で表現されるものとする。もちろん、種別が判別可能でＩＤの同定が保証されていれば、どのようなＩＤ形式であってもかまわない。

図４は、図２で示した構造例を図３で示したＩＤ表現形式例を用いて表現したものである。つまり、図２で示した構造例に、具体的なデータを当てはめたものである。矢印で表現される関連づけは、ＩＤ同士の関連づけを用いて表現される。

（データ構造）
図５に示す契約情報テーブル５０は、契約ＤＢ１０５に記憶される契約管理情報の例である。
この例では、契約ＩＤ欄５１には契約行為を同定する契約ＩＤ、契約法的人格者ＩＤ欄５２には契約対象つまり最終債務者情報を管理する契約法的人格者ＩＤ、認可対象サービスＩＤ欄５３には認可の対象となるサービスを管理する認可対象サービスＩＤ、課金条件ＩＤ欄５４にはサービスに対する課金条件を管理する課金条件ＩＤ、契約文言ＩＤ欄５５には契約文言を管理する契約文言ＩＤ、そして契約締結時刻欄５６には契約の締結時刻が記憶される。なお、契約ＩＤ欄５１〜契約文言ＩＤ欄５５には、図３で示したＩＤ表現形式のＩＤが記憶され、契約締結時刻欄５６には時刻（年月日のみでもよい）が記憶される。

図６は、法的人格者ＤＢ１０１に記憶される法人情報６００の例である。
ここでは、法人を同定する法人ＩＤ６０１（ＪＰＳＮ−００００００）に基づき、法人登記情報に基づいた情報が記憶される。例えば、法人情報６００は、法人ＩＤ６０１、会社法人等番号欄６０２、商号・名称欄６０３、ヨミカナ欄６０４、本店所在地欄６０５、支配人氏名欄６０６、支配人住所欄６０７、連絡先住所欄６０８、連絡先電話番号欄６０９、連絡先担当者欄６１０を有している。

図７は、法的人格者ＤＢ１０１に記憶される自然人情報７００の例である。
ここでは、自然人を同定する自然人ＩＤ７０１（ＮＰＳＮ−００００００）に基づき、自然人の戸籍あるいは住民登録に基づいた情報が記憶される。例えば、自然人情報７００は、自然人ＩＤ７０１、氏名欄７０２、生年月日欄７０３、本籍地欄７０４、住所欄７０５、電話番号欄７０６、携帯電話番号欄７０７、電子メール欄７０８を有している。

図８に示すサービス情報テーブル８０は、サービス管理ＤＢ１０２に記憶される提供サービスに関する情報の例である。
ここでは、サービスを同定するサービスＩＤ（例えば、ＳＥＲＶ−００００００）に基づき、サービス提供サーバー１１９のサービス提供モジュール１１８において提供されるサービスに関する情報が管理される。この例では、サービスＩＤ欄８１にはサービスＩＤ、サービスリソースアドレス欄８２にはサービスのリソースへのアクセスＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）、説明欄８３にはサービスの説明が記憶されている。サービス提供モジュール１１８の行うサービスとして、特許検索サービス、大量印刷配送サービス等がある。

図９に示す課金条件テーブル９０は、課金条件ＤＢ１０３に記憶される課金条件の例である。
ここでは、課金条件を同定する課金条件ＩＤ（例えば、ＢＬＬＧ−００００００）に基づき、対象サービスＩＤ及び課金方法が管理されている。この例では、課金条件ＩＤ欄９１には課金条件ＩＤ、課金対象サービスＩＤ欄９２には課金対象であるサービスＩＤ、課金条件欄９３には課金条件が記憶されている。課金条件として、「１０，０００円／ユーザーＩＤ・月」等がある。

図１０は、契約文言ＤＢ１０４に記憶される契約書文言情報１０００の例である。
ここでは、契約文言を同定する契約書文言ＩＤ１００１（ＣＦＲＭ−００００００）に基づき、契約文言が管理されている。例えば、契約書文言情報１０００は、契約書文言ＩＤ１００１、サービスＩＤ欄１００２、サービス名称欄１００３、内容欄１００４を有している。

図１１は、ユーザーＤＢ１０８に記憶されるユーザー情報１１００の例である。
ここでは、ユーザーを同定するユーザー情報ＩＤ１１０１（ＵＳＥＲ−００００００）に基づき、ログインの際のハンドル名やパスワード、コンタクト情報等のユーザー情報が管理されている。例えば、ユーザー情報１１００は、ユーザー情報ＩＤ１１０１、ハンドル名欄１１０２、パスワード欄１１０３、氏名欄１１０４、会社名欄１１０５、業種欄１１０６、部署名欄１１０７、役職欄１１０８、住所欄１１０９、電話番号欄１１１０、携帯電話番号欄１１１１、ＦＡＸ番号欄１１１２、Ｅ−ｍａｉｌ欄１１１３、ＵＲＬ欄１１１４、備考欄１１１５を有している。

図１２は、請求先ＤＢ１１０に記憶される請求先情報１２００の例である。
ここでは、請求先を同定する請求先情報ＩＤ１２０１（ＡＤＤＲ−００００００）に基づき、請求書の送付先の住所が管理されている。請求先は、一般的には郵便物としての請求書の送付先であるが、電子的な方法で請求情報をやりとりする場合には、請求先との電子情報の交換方法等が記述される。例えば、請求先情報１２００は、請求先情報ＩＤ１２０１、会社名欄１２０２、請求書送付先住所欄１２０３、担当者名欄１２０４、経理部欄１２０５、電話番号欄１２０６、携帯電話番号欄１２０７、ＦＡＸ番号欄１２０８、Ｅ−ｍａｉｌ欄１２０９、備考欄１２１０を有している。

図１３に示すユーザー認可情報テーブル１３００は、利用認可ＤＢ１０９に記憶されるユーザーに対する利用認可情報及びその認可に対する請求先管理のための情報の例である。
ここでは、契約ＩＤ欄１３０１には請求行為の根拠となる契約を同定する契約ＩＤ、ユーザーＩＤ欄１３０２には認可対象となるユーザーＩＤ、サービスＩＤ欄１３０３には認可対象となるサービスＩＤ、請求先ＩＤ欄１３０４には請求先ＩＤ、利用認可開始時刻欄１３０５には認可の開始時刻、利用認可終了時刻欄１３０６には認可の終了時刻が記憶される。なお、契約ＩＤ欄１３０１〜請求先ＩＤ欄１３０４には、図３で示したＩＤ表現形式のＩＤが記憶され、利用認可開始時刻欄１３０５、利用認可終了時刻欄１３０６には時刻が記憶される。

図１４に示す組織情報テーブル１４００は、組織ＤＢ１１２に記憶される組織情報の例である。
ここでは、組織ＩＤ欄１４０１には組織を同定する組織ＩＤ、組織名称欄１４０２にはその組織名称、所属ユーザーＩＤ欄１４０３にはその組織に所属するユーザーＩＤ群が記憶される。
所属ユーザーＩＤは、ユーザーＩＤの他に組織ＩＤを含むことにより、階層的な組織をも管理する。また、法人をまたがった組織や法人と個人とをセットにした組織を定義するために、この組織情報は、法的人格者ＤＢ１０１に記憶される法人情報と直接的に関連づけられていない（もちろん事務処理等の便宜を図る目的で、参考情報として法人ＩＤを付加的に管理するようにしてもよい）。

（契約管理処理）
図１５に示すフローチャートを用いて、サービス提供契約の締結を受け、契約関連情報を入力する処理の例を説明する。契約管理モジュール１０６が、本処理を行って契約情報テーブル５０を生成する。
まず、管理者による検索指示の操作に応じて、法的人格者ＤＢ１０１の中の法人情報又は自然人情報から、契約締結の対象となる法的人格者を検索する（ステップＳ１５０２）。
対象となる法的人格者が法的人格者ＤＢ１０１に登録されているか否かを判断する（ステップＳ１５０４）。登録済みの場合（ＹＥＳ）はステップＳ１５０８へ進み、登録されていない場合（ＮＯ）はステップＳ１５０６へ進む。

ステップＳ１５０６で、対象となる法的人格者を法的人格者ＤＢ１０１に登録する。一般的には、この時点で、その法的人格者である法人又は個人に対して与信処理が実施され、サービス提供に十分な与信が得られない場合には、登録しないことになる。
そして、対象となっている法的人格者を契約対象者として指定する（ステップＳ１５０８）。
次に、サービス管理ＤＢ１０２に図８に示す形態で記憶されているサービスを指定する（ステップＳ１５１０）。

そして、そのサービスに対する契約文言を契約文言ＤＢ１０４に図１０に示す形態で記憶されている契約文言から選び、課金条件を課金条件ＤＢ１０３に図９に示す形態で記憶されている課金条件の中から選択する（ステップＳ１５１２）。
次に、契約締結時刻を入力する（ステップＳ１５１４）。
入力した結果（ステップＳ１５０８〜ステップＳ１５１４）に対しては、ユニークな契約ＩＤが付与され、図５に示す形態で契約ＤＢ１０５に記憶され（ステップＳ１５１６）、契約管理モジュール１０６によって管理される。

（ユーザーへのサービス利用権付与）
図１６に示すフローチャートを用いて、契約に基づくユーザーの利用認可と請求先情報の入力処理の例を説明する。ユーザー認可管理モジュール１０７が、本処理を行ってユーザー認可情報テーブル１３００を生成する。
まず、管理者による契約選択の操作に応じて、図１５に示す処理によって登録された契約及び契約情報テーブル５０を用いて認可するサービスを選択する（ステップＳ１６０２）。
次に、ユーザー認可管理モジュール１０７が、ユーザーＤＢ１０８に図１１に示す形態で記憶されているユーザー情報１１００からサービス利用認可対象となるユーザーを検索する（ステップＳ１６０４）。
ユーザーが存在するか否かを判断する（ステップＳ１６０６）。ユーザーが存在する場合（ＹＥＳ）はステップＳ１６１０へ進み、存在しない場合（ＮＯ）にはステップＳ１６０８へ進む。
ステップＳ１６０８では、ユーザー登録を実施する。
そして、利用認可するユーザーを指定する（ステップＳ１６１０）。

次に、この利用認可に関する請求先を請求先ＤＢ１１０に図１２に示す形態で記憶されている請求先情報１２００の中から検索する（ステップＳ１６１２）。
請求先が存在するか否かを判断する（ステップＳ１６１４）。請求先が存在する場合（ＹＥＳ）はステップＳ１６１８へ進み、存在しない場合（ＮＯ）にはステップＳ１６１６へ進む。
ステップＳ１６１６では、請求先を操作者の操作に応じて入力する。
そして、請求先を指定する（ステップＳ１６１８）。
さらに、認可期間（ユーザー認可情報テーブル１３００内の利用認可開始時刻欄１３０５、利用認可終了時刻欄１３０６）を入力し（ステップＳ１６２０）、ユーザー認可の指定結果を利用認可ＤＢ１０９に図１３に示す形態で記憶する（ステップＳ１６２２）。
以上の処理（ステップＳ１６０４〜ステップＳ１６２２）を全ての認可対象ユーザーに対して繰り返す（ステップＳ１６２４）。

（組織情報を利用したサービス利用権付与）
図１７に示すフローチャートを用いて、組織情報を利用したユーザーの利用認可処理の例を説明する。ユーザー認可管理モジュール１０７、組織管理モジュール１１３が、本処理を行ってユーザー認可情報テーブル１３００を生成する。
まず、管理者による契約選択の操作に応じて、図１５に示す処理によって登録された契約及び契約情報テーブル５０を用いて認可するサービスを選択する（ステップＳ１７０２）。
次に、組織管理サーバー１１４の組織管理モジュール１１３が、組織ＤＢ１１２に図１４に示す形態で記憶されている組織情報を検索し、契約対象となる組織を指定する（ステップＳ１７０４）。
次に、請求先ＤＢ１１０から請求先を検索して指定する（ステップＳ１７０６）。そして認可期間（ユーザー認可情報テーブル１３００内の利用認可開始時刻欄１３０５、利用認可終了時刻欄１３０６）を指定する（ステップＳ１７０８）。

管理者による以上の指定が終了すると、組織ＤＢ１１２内の所属ユーザーＩＤを参照し、認可対象となるユーザーＩＤへ展開する（ステップＳ１７１０）。つまり、組織ＩＤからその組織に属しているユーザーＩＤへ変換する。
そして展開された各々のユーザーに対し、ユーザー認可指定、請求先、認可期間等の情報を、図１３に示す形態で利用認可ＤＢ１０９へ記録する（ステップＳ１７１２）。
以上の処理（ステップＳ１７１２）を展開された全てユーザーに対して繰り返す（ステップＳ１７１４）。
この処理においては、組織情報を指定することによって管理者の作業量は減少しているが、利用認可ＤＢ１０９に記憶される情報は、ユーザーごとに指定したものと全く同様になる。

（サービス利用処理）
図１８に示すフローチャートを用いて、サービス利用の処理の例を説明する。ユーザー認可管理モジュール１０７、ユーザー認証モジュール１１６、サービス提供モジュール１１８、履歴収集モジュール１２０が本処理を行ってサービス利用履歴テーブル１９００を生成する。
まず、ユーザーの操作に応じてユーザー端末１１５からユーザー認証サーバー１１７のユーザー認証モジュール１１６へアクセスし、ユーザー認証を実施する（ステップＳ１８０２）。このユーザー認証は、通常のハンドル名／パスワードのチェックでもよいし、ＰＫＩ技術を利用した認証方式や、指紋等の生体認証技術を用いてもかまわない。
ユーザーによるサービス選択の操作に応じて、サービス提供サーバー１１９にあるサービス提供モジュール１１８群によって提供されるサービスを利用対象として指定する。これらのサービスに関する情報は、サービス管理ＤＢ１０２に図８に示す形態で記憶されているので、メニュー等から選択することが可能である（ステップＳ１８０４）。

次に、ユーザー認可管理モジュール１０７が、利用認可ＤＢ１０９に図１３に示す形態で記憶されている利用認可情報をチェックし、現在のユーザーが、選択したサービスに対して、現在時刻において利用が認可されているかどうかをチェックする（ステップＳ１８０６）。認可されている場合（ＯＫ）は、ステップＳ１８０８へ進み、認可されていない場合（ＮＯ）は、ステップＳ１８１２で終了する。
ステップＳ１８０８では、利用が認可されている場合であって、サービス提供モジュール１１８へのアクセスが許可され、具体的なサービス提供モジュール１１８によるサービスが行われる。
サービスの利用結果（履歴）については、履歴収集サーバー１２３の履歴収集モジュール１２０が利用履歴ＤＢ１２２に図１９に示す形態で記憶する（ステップＳ１８１０）。

ここで、図１９を用いて、利用履歴ＤＢ１２２内のサービス利用履歴テーブル１９００を説明する。
この例では、契約ＩＤ欄１９０１には契約ＩＤ、ユーザーＩＤ欄１９０２にはユーザーＩＤ、サービスＩＤ欄１９０３には利用したサービスＩＤ、利用開始時刻欄１９０４には利用開始時刻、利用終了時刻欄１９０５には利用終了時刻、利用量欄１９０６には利用量、利用単位欄１９０７には利用単位の情報が記憶される。

図２０に示すフローチャートを用いて、サービス利用に対する請求処理の例を説明する。つまり、サービス利用履歴テーブル１９００に記憶されている利用履歴に基づいて請求書を発行する処理の例である。課金・請求処理モジュール１２１が本処理を行う。
まず、管理者による契約選択の操作に応じて、請求書を発行する対象となる契約を選択する。実際には、月末等の締め日に一括して処理する（ステップＳ２００２）。
次に、課金・請求処理モジュール１２１が、利用履歴ＤＢ１２２に図１９に示す形態で記憶されている利用履歴から契約ＩＤをもとに関連する利用履歴を抽出する（ステップＳ２００４）。

そして、利用履歴をユーザー単位で集計する（ステップＳ２００６）。さらに、利用認可ＤＢ１０９内のユーザー認可情報テーブル１３００を用いて、ユーザーから請求先を検索し、その請求先単位で集計する（ステップＳ２００８）。
次に、契約管理モジュール１０６を介して契約ＤＢ１０５を参照して課金条件ＩＤを取り出し、その課金条件ＩＤをもとに課金条件ＤＢ１０３を検索して課金条件を取り出す。その上で、集計された利用履歴に対して課金条件を適用して利用料金を計算する（ステップＳ２０１０）。
そして、この計算結果に基づいて、請求先ごとに請求書を発行する（ステップＳ２０１２）。電子的な商取引が利用可能な場合には、請求金額を請求先に対して電送する。

（請求の消し込みと債権回収の開始処理）
図２１に示すフローチャートを用いて、請求消し込み処理と債権回収処理の例を説明する。つまり、請求先からの料金の振り込み結果に基づいて課金情報を消し込み、消し込みができない場合には、債権回収プロセスを開始する処理の例である。課金・請求処理モジュール１２１が本処理を行う。
請求書の振り込み期限等の期間が経過した後、請求先からの入金情報と請求金額を突き合わせ請求消し込み処理を実施する（ステップＳ２１０２）。
ステップＳ２１０２による請求消し込み処理が問題なく行われたか否かを判断する（ステップＳ２１０４）。消し込みが問題なく行われれば（ＯＫ）、この時点で処理を終了する（ステップＳ２１１６）。消し込みができない場合（ＮＯ）には、ステップＳ２１０６へ進む。
ステップＳ２１０６では、契約を検索して管理者へ提示する。

管理者による操作に応じて、入金ミス等であるか否かを判断する（ステップＳ２１０８）。入金ミス等である場合（ＹＥＳ）はステップＳ２１１０へ進み、そうでない場合（ＮＯ）はステップＳ２１１２へ進む。
ステップＳ２１１０では、ユーザー認可管理モジュール１０７を介して請求先ＤＢ１１０に記憶されている請求先を検索し、その請求先に対して連絡し、入金ミスを補正する処理を実施するよう管理者に提示する。実際には、手作業での連絡に基づいて、再入金や返金処理が行われる。
ステップＳ２１１２では、入金ミス等でない場合であり、契約管理モジュール１０６を介して契約ＤＢ１０５をもとに法的人格者ＤＢ１０１を検索して契約対象の法的人格者を管理者へ提示する。
そして、その法的人格者に対する債権回収処理を開始するように管理者に提示する（ステップＳ２１１４）。この後の作業は、参照した情報に基づく手作業となる。実際には、請求先への連絡、請求先への督促状送付、法的人格者への督促状送付、等の段階を踏んだ上で、最終的には裁判所への提訴となる。

なお、本実施の形態としてのプログラムが実行されるコンピュータのハードウェア構成は、図２２に示すように、一般的なコンピュータであり、具体的にはパーソナルコンピュータ、サーバーとなり得るコンピュータ等である。契約管理モジュール１０６、ユーザー認可管理モジュール１０７、組織管理モジュール１１３、履歴収集モジュール１２０、課金・請求処理モジュール１２１、サービス提供モジュール１１８等のプログラムを実行するＣＰＵ（マイクロプロセッサ）２２０１と、そのプログラムやデータを記憶するＲＡＭ（ランダムアクセスメモリ）２２０２と、本コンピュータを起動するためのプログラム等が格納されているＲＯＭ（リードオンリメモリ）２２０３と、補助記憶装置であるＨＤ（ハードディスク）２２０４と、キーボード、マウス等のデータを入力する入力装置２２０６と、ＣＲＴや液晶ディスプレイ等の出力装置２２０５と、例えばネットワークを介して他の装置と通信を行うための通信回線インタフェース２２０７（例えばネットワークインタフェースカードを用いることができる）、そして、それらをつないでデータのやりとりをするためのバス２２０８により構成されている。これらのコンピュータが複数台互いにネットワークによって接続されていてもよい。

なお、図２２に示すハードウェア構成は、１つの構成例を示すものであり、本実施の形態は、図２２に示す構成に限らず、本実施の形態において説明したモジュールを実行可能な構成であればよい。例えば、一部のモジュールを専用のハードウェア（例えば特定用途向け集積回路（Application Specific Integrated Circuit：ＡＳＩＣ）等）で構成してもよく、一部のモジュールは外部のシステム内にあり通信回線で接続しているような形態でもよく、さらに図２２に示すシステムが複数互いに通信回線によって接続されていて互いに協調動作するようにしてもよい。また、特に、パーソナルコンピュータの他、情報家電、複写機、ファックス、スキャナ、プリンタ、複合機（多機能複写機とも呼ばれ、スキャナ、プリンタ、複写機、ファックス等の機能を有している）などに組み込まれていてもよい。

前記実施の形態においては、図２、図４、図５〜図１４、図１９で示したデータ構造は、これらのデータ構造に限らず他のデータ構造であってもよい。例えば、テーブル構造のものはリンク構造等であってもよい。また、データ項目は、これらに図示したものに限られず、他のデータ項目を有していてもよい。

なお、説明したプログラムについては、記録媒体に格納して提供してもよく、また、そのプログラムを通信手段によって提供してもよい。その場合、例えば、前記説明したプログラムについて、「プログラムを記録したコンピュータ読み取り可能な記録媒体」の発明として捉えてもよい。
「プログラムを記録したコンピュータ読み取り可能な記録媒体」とは、プログラムのインストール、実行、プログラムの流通などのために用いられる、プログラムが記録されたコンピュータで読み取り可能な記録媒体をいう。
なお、記録媒体としては、例えば、デジタル・バーサタイル・ディスク（ＤＶＤ）であって、ＤＶＤフォーラムで策定された規格である「ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ等」、ＤＶＤ＋ＲＷで策定された規格である「ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等」、コンパクトディスク（ＣＤ）であって、読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）等、光磁気ディスク（ＭＯ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去及び書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）等が含まれる。
そして、前記のプログラム又はその一部は、前記記録媒体に記録して保存や流通等させてもよい。また、通信によって、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等に用いられる有線ネットワーク、あるいは無線通信ネットワーク、さらにこれらの組み合わせ等の伝送媒体を用いて伝送させてもよく、また、搬送波に乗せて搬送させてもよい。
さらに、前記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。また、複数の記録媒体に分割して
記録されていてもよい。また、圧縮や暗号化など、復元可能であればどのような態様で記録されていてもよい。

本実施の形態の構成例についての概念的なモジュール構成図である。 サービス提供契約における契約合意内容及び関連情報の基本構造の例を示す説明図である。 サービス契約における関連情報のＩＤの例を示す説明図である。 サービス提供契約における契約合意内容及び関連情報の基本構造の例をＩＤで表現した模式図である。 契約ＤＢ内の契約情報テーブルのデータ構造例を示す説明図である。 法的人格者ＤＢ内の法人情報のデータ構造例を示す説明図である。 法的人格者ＤＢ内の自然人情報のデータ構造例を示す説明図である。 サーバー管理ＤＢ内のサービス情報テーブルのデータ構造例を示す説明図である。 課金条件ＤＢ内の課金条件テーブルのデータ構造例を示す説明図である。 契約文言ＤＢ内の契約書文言情報のデータ構造例を示す説明図である。 ユーザーＤＢ内のユーザー情報のデータ構造例を示す説明図である。 請求先ＤＢ内の請求先情報のデータ構造例を示す説明図である。 利用認可ＤＢ内のユーザー認可情報テーブルのデータ構造例を示す説明図である。 組織ＤＢ内の組織情報テーブルのデータ構造例を示す説明図である。 契約の入力処理の例を示すフローチャートである。 契約に基づくユーザーの利用認可と請求先情報の入力処理の例を示すフローチャートである。 組織情報を利用したユーザーの利用認可処理の例を示すフローチャートである。 サービス利用の処理の例を示すフローチャートである。 サービス利用履歴テーブルのデータ構造例を示す説明図である。 サービス利用に対する請求処理の例を示すフローチャートである。 請求消し込み処理と債権回収処理の例を示すフローチャートである。 本実施の形態を実現するコンピュータのハードウェア構成例を示すブロック図である。

符号の説明

１０１…法的人格者ＤＢ
１０２…サービス管理ＤＢ
１０３…課金条件ＤＢ
１０４…契約文言ＤＢ
１０５…契約ＤＢ
１０６…契約管理モジュール
１０７…ユーザー認可管理モジュール
１０８…ユーザーＤＢ
１０９…利用認可ＤＢ
１１０…請求先ＤＢ
１１１…契約管理サーバー
１１２…組織ＤＢ
１１３…組織管理モジュール
１１４…組織管理サーバー
１１５…ユーザー端末
１１６…ユーザー認証モジュール
１１７…ユーザー認証サーバー
１１８…サービス提供モジュール
１１９…サービス提供サーバー
１２０…履歴収集モジュール
１２１…課金・請求処理モジュール
１２２…利用履歴ＤＢ
１２３…履歴収集サーバー
１２４…ネットワーク

Claims (5)

1. 契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
   組織を識別する組織識別子、該組織に所属する利用者を識別する利用者識別子を対応させて記憶する組織情報記憶手段と、
   前記契約識別子、前記利用者識別子、該契約識別子の契約において該利用者識別子の利用者に認可されたサービスを識別するサービス識別子を対応させて記憶する利用者認可情報記憶手段と、
   利用者に対してサービスの認可処理を行う対象となる契約の契約識別子を受け付ける契約受付手段と、
   前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている認可対象サービス識別子を取得する認可対象サービス取得手段と、
   前記認可対象サービス取得手段によって取得された認可対象サービス識別子の認可対象サービスを利用できる組織の組織識別子を受け付ける組織受付手段と、
   前記組織受付手段によって受け付けられた組織識別子に基づいて、前記組織情報記憶手段に記憶されている利用者識別子を取得し、該利用者識別子及び前記認可対象サービス取得手段によって取得された認可対象サービス識別子を前記利用者認可情報記憶手段に記憶させる利用者認可手段
   を具備することを特徴とする情報処理システム。
2. 契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
   前記契約識別子、利用者を特定する利用者識別子、サービスを特定するサービス識別子、該サービスの利用量を表すサービス利用量を対応させて記憶する利用履歴記憶手段と、
   前記課金条件識別子、課金の条件を対応させて記憶する課金条件記憶手段と、
   サービスの利用料金の計算処理の対象となる契約の契約識別子を受け付ける契約受付手段と、
   前記契約受付手段によって受け付けられた契約識別子に基づいて、前記利用履歴記憶手段に記憶されているサービス利用量を取得するサービス利用量取得手段と、
   前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている課金条件識別子を取得し、該課金条件識別子に基づいて、前記課金条件記憶手段に記憶されている課金の条件を取得する課金条件取得手段と、
   前記サービス利用量取得手段によって取得されたサービス利用量及び前記課金条件取得手段によって取得された課金の条件に基づいて、前記契約におけるサービスの利用料金を計算するサービス利用料金計算手段
   を具備することを特徴とする情報処理システム。
3. 前記契約識別子、前記利用者識別子、該契約識別子の契約において該利用者識別子の利用者に認可されたサービスを識別するサービス識別子、該利用者識別子の利用者によるサービスの利用料金を請求する請求先を識別する請求先識別子を対応させて記憶する利用者認可情報記憶手段
   をさらに具備し、
   前記サービス利用料金計算手段は、前記利用者認可情報記憶手段に記憶されている請求先識別子に基づいて、該請求先識別子に対応する前記利用者識別子の利用者によるサービスの利用料金を合算する
   ことを特徴とする請求項２に記載の情報処理システム。
4. コンピュータを、
   契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
   組織を識別する組織識別子、該組織に所属する利用者を識別する利用者識別子を対応させて記憶する組織情報記憶手段と、
   前記契約識別子、前記利用者識別子、該契約識別子の契約において該利用者識別子の利用者に認可されたサービスを識別するサービス識別子を対応させて記憶する利用者認可情報記憶手段と、
   利用者に対してサービスの認可処理を行う対象となる契約の契約識別子を受け付ける契約受付手段と、
   前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている認可対象サービス識別子を取得する認可対象サービス取得手段と、
   前記認可対象サービス取得手段によって取得された認可対象サービス識別子の認可対象サービスを利用できる組織の組織識別子を受け付ける組織受付手段と、
   前記組織受付手段によって受け付けられた組織識別子に基づいて、前記組織情報記憶手段に記憶されている利用者識別子を取得し、該利用者識別子及び前記認可対象サービス取得手段によって取得された認可対象サービス識別子を前記利用者認可情報記憶手段に記憶させる利用者認可手段
   として機能させることを特徴とする情報処理プログラム。
5. コンピュータを、
   契約を識別する契約識別子、該契約において認可対象とされているサービスを識別する認可対象サービス識別子、該サービスにおける課金の条件を識別する課金条件識別子を対応させて記憶する契約情報記憶手段と、
   前記契約識別子、利用者を特定する利用者識別子、サービスを特定するサービス識別子、該サービスの利用量を表すサービス利用量を対応させて記憶する利用履歴記憶手段と、
   前記課金条件識別子、課金の条件を対応させて記憶する課金条件記憶手段と、
   サービスの利用料金の計算処理の対象となる契約の契約識別子を受け付ける契約受付手段と、
   前記契約受付手段によって受け付けられた契約識別子に基づいて、前記利用履歴記憶手段に記憶されているサービス利用量を取得するサービス利用量取得手段と、
   前記契約受付手段によって受け付けられた契約識別子に基づいて、前記契約情報記憶手段に記憶されている課金条件識別子を取得し、該課金条件識別子に基づいて、前記課金条件記憶手段に記憶されている課金の条件を取得する課金条件取得手段と、
   前記サービス利用量取得手段によって取得されたサービス利用量及び前記課金条件取得手段によって取得された課金の条件に基づいて、前記契約におけるサービスの利用料金を計算するサービス利用料金計算手段
   として機能させることを特徴とする情報処理プログラム。

Images