JP2004185521A - 代行サービス提供方法およびその実施システム - Google Patents

Abstract

【課題】本発明は、ネットワーク上でアクセス可能なサービスを複数利用者で効率的に活用する方法に関わるもので、従来はサービスの部分的な利用ができなかったことや、利用に応じて一方的に利用料が一方的に増えるという問題があった。
【解決手段】上記課題を解決するため、代行サービスシステムがサービス利用者とサービス提供者の仲介者となり、サービスの共有方法の条件や利用料の計算に必要な情報を管理するデータベースと、利用者からのサービス要求を管理するデータベース、サービス要求単位とサービスの対応を管理するデータベースのほか、サービス利用者からのサービス要求を個々のサービス要求単位に分解する機能、サービスの共有方法を判断する機能、分解されたサービス要求単位をサービスごとにグループ化する機能、などを備えることで、複数利用者でのサービスの効率的な活用を行う。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、インターネット等のネットワーク上で実行可能なサービスの利用に対する課金処理とサービス実行の代行技術に関する。
【０００２】
【従来の技術】
従来、サービス利用者がインターネット上で公開されているサービスを利用する場合、サービスの利用料金は、サービス提供者あるいは第３者である仲介者が管理する課金情報に従い、利用者がサービスへの対価として提供者に支払う。
サービスの課金装置に関する技術としては、特開２００２−４２００２号や特開平１１−３１６７２９号などに開示されたものがあり、また、サービスの相乗り予約と相乗り人数に応じた料金割引を行うための装置に関しては特開２００２−２２２３５１号に開示されている。
【０００３】
【特許文献１】
特開２００２−４２００２号
【特許文献２】
特開平１１−３１６７２９号
【特許文献３】
特開２００２−２２２３５１号
【０００４】
【発明が解決しようとする課題】
しかしながら、上記の従来例は、サービス提供者への対価の支払いのための課金の一括処理や、プリペイドカードの認証・課金処理を前提とするサービス処理に関するものであり、利用者の希望する利用形態に応じたサービスの共有方法とそれに応じた課金方法を提供するものではなく、また、利用者は、一部しか必要ないサービスであっても、サービスの利用形態はサービス提供者との契約に拘束され、部分的な利用ができない、利用に応じて一方的に増える利用料を支払わなくてはならないという課題があった。
【０００５】
本発明の目的は、複数のサービス要求を集め、利用時間を調整したサービス共用やサービスの一括実行を行い、従来よりもきめ細かい料金体系でサービスの実行を代行することで、利用者はサービスの一部しか必要ない場合など、従来よりも割安に利用することを可能とし、サービスの利用度向上も図ることにある。
【０００６】
【課題を解決するための手段】
上記課題を改善するため、代行サービスシステムに、サービス利用者とサービス提供者とサービスに関する情報をそれぞれ管理するテーブルを含むデータベースと、サービスの共有方法の条件や利用料の計算に必要な情報を管理するデータベース、利用者からのサービス要求を管理するデータベースと、サービス要求単位とサービスの対応を管理するデータベースのほか、登録されたサービスを共用するための条件を決める機能、サービス利用者からのサービス要求を個々のサービス要求単位に分解する機能、サービスの共有方法を判断する機能、分解されたサービス要求単位をサービスごとにグループ化する機能、サービス提供者からの結果を分析分解し個々のサービス利用者へのサービス結果にマッピングする機能、などを備えることで、無駄を省いたサービス実行を実現するものである。
【０００７】
一方、サービス提供者がサービスの共用を許す場合にも対応し、サービス提供者のサービスの共用機能を備えたものである。
【０００８】
【発明の実施の形態】
以下、本発明の実施例を図面に基づいて説明する。
【０００９】
図１はシステム構成図の実施例である。例えば、ネットワークであるインターネットに各種サービスを提供する複数のサービス提供者（サービス提供装置）１とこれらのサービスを使う複数の利用者（利用者端末）２、そして代行サービスシステム３が接続されている。代行サービスシステム３は、データ受付部３０１と、処理振り分け部３０２と、登録部３０３と、要求メッセージ分解部３０４と、サービス共用判断部３０５と、実行部３０６と、結果メッセージ分解部３０７と、課金処理部３０８と、メッセージ出力部３０９と、サービスアクセス監視部３１０と、各種データベースを有している。データ受付部３０１は利用者と提供者からのあらゆる入力データを受け付け、処理振り分け部３０２はデータ受付部３０１から受け取る各種要求メッセージに基づき、適切な処理部にタスクを送るほか、各処理部における処理終了後にタスクの完了通知を各処理部から受け、次の処理部に後続のタスクを送る、というような中央管理的な機能を果たす。
【００１０】
登録部３０３は、利用者端末２を経由した利用者と提供者装置１から処理振り分け部３０２を通じて代行サービスシステム３への登録要求がきた際に、登録ＤＢ３１１に情報を登録する。さらに、登録部３０３は、サービスに関する情報を元に、利用者と代行サービスシステム３で契約を結んだ上で複数の利用者で利用時間を区切って共有可能なサービスかどうか、または複数の要求を１回で処理できるサービスかどうかの判断を行い、サービスがどちらのタイプであるか、そして契約締結あるいはサービス実行のタイミングを決める判断の材料となるような条件と、条件の内容を踏まえた課金率を決めて、条件ＤＢ３１４に登録する。また、利用時間を区切ってサービスを共用するような契約を必要とするタイプのサービスの利用に関する要求メッセージを受けた場合のため、必要とする時間帯別にキューを作成する。
【００１１】
登録ＤＢ３１１の詳細は図６に示す。要求メッセージ分解部３０４は、利用者から、代行サービスシステム３に登録されているサービスを利用する要求メッセージを処理振り分け部３０２を通じて受けると、構文解析してサービス要素に分解し、要求メッセージとそれぞれのサービス要素に識別子をつけて要求メッセージ管理ＤＢ３１２に格納する。さらに、要求メッセージ分解部３０４は、サービス要素の処理に最適なサービスを登録ＤＢ３１１から検索・取得して、サービス要素に対応するサービス及びそのサービス提供者をサービス要素の対応管理ＤＢ３１３に格納する。要求メッセージ分解部３０４の詳細は図２に示す。
【００１２】
サービス共用判断部３０５は要求メッセージ管理ＤＢ３１２とサービス要素の対応管理ＤＢ３１３と条件ＤＢ３１４を参照して、複数の利用者で利用時間を区切ってサービスを共有可能とするための条件を満たすのに必要な要求が集まっているかどうか、または複数の要求を１回で処理するための条件を満たすのに必要な数の要求が集まっているかどうかを判断する。サービス共用判断部３０５は、時間で区切ってサービスを共用可能とする要求が集まっていると判断した場合、利用者に特定の利用形態での利用権を与え、この利用権に関する契約を利用者との間で結ぶ。実行部３０６はサービス共用判断部３０５にて複数の要求を１回のサービス実行で処理可能と判断され、処理振り分け部３０２を通じてその通知を受けると、サービスごとにサービス要素をグルーピングしてサービス実行メッセージを組み立てて実行する。
【００１３】
また、利用時間を区切ってサービスを共用するような契約を必要とするタイプのサービスの利用に関する要求の場合は、サービス実行メッセージを組み立てて、登録部３０３が作成した時間帯別キューに格納しておき、所定の時間にキューに入っているサービス実行メッセージを実行する。実行部３０６の詳細は図３に示す。結果メッセージ分解部３０７は、サービス実行または利用後に処理振り分け部３０２を通じて結果メッセージを受け取り、それを構文解析しサービス要素の対応管理ＤＢ３１３を用いてもとのサービス要素に対応する結果を要求メッセージ管理ＤＢ３１２に格納する。利用時間を区切ってサービスを共用するような契約を必要とするタイプのサービスの利用に関する要求の実行後に受け取る結果メッセージの場合は、構文解析する必要はない。結果メッセージ分解部３０７の詳細は図４に示す。課金処理部３０８は条件ＤＢ３１４と登録ＤＢ３１１を参照して該当利用者への請求金額を計算する。
【００１４】
メッセージ出力部３０９は処理振り分け部３０２を通して結果メッセージ分解部３０７と課金処理部３０８の処理完了の通知を受けると、結果等の情報を含む利用者への返信メッセージを作成し、出力する。メッセージ出力部３０９はあらゆる場合に利用者へのメッセージ送信におけるメッセージの作成と出力を行う。メッセージ出力部３０９の詳細は図５に示す。サービスサービスアクセス監視部３１０は利用時間を区切ってサービスを共用するような、契約を必要とするタイプのサービスに関してのみ、サービスを効率的に共用するためのサービス利用状況の監視・制御を行う。サービス代行システムと利用者の間でサービス契約を行い、契約に基づく規定時間内でのサービス利用を前提とするが、時間を割り当てられている利用者からの処理要求がない場合など、同じサービスの利用権をもつ他の利用者の処理要求を実行するなど、効率的な処理が可能である。
【００１５】
図２は要求メッセージ分解部３０４の詳細を示す。要求メッセージ分解部３０４は利用者からの要求メッセージを受け取る要求メッセージ受付部３０４１と、要求メッセージ分析部３０４２から成る。要求メッセージ分析部３０４２は要求メッセージを構文解析しサービス要素に分解して、要求メッセージとそれぞれのサービス要素に識別子をつけた上で要求メッセージ管理ＤＢ３１２に格納し、サービス要素の処理に最適なサービスを検索・取得してサービス要素に対応するサービス及びそのサービス提供者をサービス要素の対応管理ＤＢ３１３に格納する。
【００１６】
図３は実行部３０６の詳細を示す。サービス実行メッセージ組み立て部３０６１はサービスを共用するサービス要素を、サービスごとにグルーピングし、登録ＤＢ３１１に格納されているインターフェース情報に基づきサービス提供者に送信するサービス実行メッセージを組み立て、サービス実行部３０６２を用いサービス要求の実行処理を行う。利用時間を区切ってサービスを共用するような、契約を必要とするタイプのサービスの利用に関するサービス要素の場合は、サービス利用者と代行サービスの間の契約に基づき定められた時間帯にサービス実行が行えるよう、実行時間帯別時間処理キュー３０６３にサービス実行メッセージを追加する。実際のサービス実行は、時間帯のスタート時刻になると起動される時刻起動サービス実行部３０６４が、登録部３０３が事前に作成した複数の時間処理キュー３０６３のうち該当実行時間帯のキューからメッセージを読み出し、サービス提供者に送信することで実現するが、条件が満たされる場合にはキューに入れずに即時実行も行う。
【００１７】
図４は結果メッセージ分解部３０７の詳細を示す。サービスの実行結果メッセージを受け取る結果メッセージ受付部３０７１とそれを構文解析してサービス要素毎に対応する結果を要求メッセージ管理ＤＢ３１２に格納する結果メッセージ分析部３０７２を含む。
【００１８】
図５はメッセージ出力部３０９の詳細を示す。サービスの実行結果や課金計算による利用料などを含む情報を利用者への返信メッセージとして作成する返信メッセージ作成部３０９１とそれを出力する返信メッセージ出力部３０９２を含む。
図６は登録ＤＢ３１１の構成を示す。登録ＤＢ３１１は利用者管理テーブル３１１１と提供者管理テーブル３１１２とサービス管理テーブル３１１３をもち、それぞれに利用者・提供者・サービスに関する情報を格納する。
【００１９】
図７は提供者により提供者に関する情報とサービスに関する情報が入力された後、登録部３０３が行う処理のフローチャートである。提供者に関する情報は提供者管理テーブル３１１２に登録し（ステップ７００）、サービスに関する情報はサービス管理テーブル３１１３に登録する（ステップ７０１）。提供者管理テーブル３１１２の構成の実施例は図１４、サービス管理テーブル３１１３の構成の実施例は図１５に示す。サービスに関する情報の登録後、利用時間を区切って複数の利用者で共有可能なサービスかどうか、または複数の要求を１回で処理できるサービスかどうかの判断を行い、サービスがどちらのタイプであるか、そして契約締結あるいはサービス実行のタイミングを決める判断の材料となるような条件と、条件の内容を踏まえた課金率を決めて、条件ＤＢ３１４に登録する。条件や課金率は代行サービスシステム管理者が決定すればよい。また、利用時間を区切ってサービス共用する、契約を必要とするタイプのサービスの利用に関する要求メッセージを受けた場合のため、必要とする時間帯別にキューを作成する。
【００２０】
登録ＤＢ３１１に含まれている利用者に関する情報を格納する利用者管理テーブルの構成例は図１３に示す。
ここから、利用時間を区切ってサービスを共用するような、利用者と代行サービスシステムで事前に契約を必要とするサービスをタイプ▲１▼とし、また、複数の要求を１回で処理できるサービスをタイプ▲２▼として、それぞれのタイプの実施例について、図８から図１８を使って説明する。図８から図１０はタイプ▲１▼に関連する処理のフロー図であり、図１１から図１２はタイプ▲２▼に関連する処理のフロー図である。
【００２１】
まず、タイプ▲１▼の実施例について説明する。本実施例では、利用者“Ｕ１”と“Ｕ３”がＩＴレポートの閲覧サービス“Ｓ３”を、“Ｕ１”は午前、“Ｕ２”は午後に利用希望しており、サービス代行システムでは、サービス“Ｓ３”を共用可能とする条件を、午前と午後の利用希望者が１人ずつ集まることとしている。
【００２２】
図８はタイプ１のサービスを利用するために、利用者と代行サービスシステムの間で契約を結ぶ処理のフローチャートである。データ受信部３０１が利用者“Ｕ１”からサービス“Ｓ３”の利用契約を希望する旨書かれている要求メッセージを受け取ると（ステップ８００）、要求メッセージ分解部３０４はこの要求メッセージに識別子“Ｒ１”を付与し、これをサービス要素に分解して（ステップ８０１）、サービス要素“ＩＴレポート閲覧” に識別子“ＳＥ１”を付与し、図１６に示す構成例のように、要求メッセージが何の処理を希望するかを示す要求タイプと、要求メッセージの受け付け時間や利用者の希望利用形態、処理実行の希望期限などと共に要求メッセージ管理ＤＢ３１２に格納し、処理に最適なサービスをサービス管理テーブル３１１３からサービス要素“ＳＥ１”に対応するサービスを検索、“Ｓ３”を取得してさらにそのサービスの識別子“Ｓ３”をもとに提供者管理テーブル３１１２より対応サービス提供者“Ｔ３”を取得してサービス要素の対応管理ＤＢ３１３に格納する。
【００２３】
そして、サービス要素の対応管理ＤＢ３１３に新しいサービス要素が格納される毎にサービス要素の対応管理ＤＢ３１３からサービス毎のサービス要素を取得し、各サービス要素の希望利用形態を基準に、条件ＤＢ３１４を使ってサービス共用判断部３０５にてタイプ２の利用のための利用者と代行サービスシステムの契約成立可否を判断する（ステップ８０２）。サービス要素“ＳＥ１”は同じサービス“Ｓ３”の午前の閲覧、“ＳＥ４”は午後の閲覧を希望しているので、条件“Ｊ１”で契約が成立し、メッセージ出力部３０９は“Ｕ１”と“Ｕ３”にサービス利用権を通知するメッセージを送る（ステップ８０３）。サービス要素の対応管理ＤＢ３１３の構成例は図１７に、条件ＤＢ３１４に格納するデータ構成の例は図１８に示している。
【００２４】
図９はステップ８０３ですでにサービス利用権通知メッセージを受けた利用者が、サービスを使って各種要求処理を行う要求メッセージを蓄積しておくプロセスを示すフローチャートである。利用時間を区切ってサービスを共用するため、本実施例では利用者“Ｕ１”と“Ｕ３”がそれぞれ午前と午後にＩＴレポートを閲覧する権利をもっていることから、ステップ７０３で登録部３０３が作成した時間処理キューは、午前６時に蓄積されているメッセージの処理実行を開始する時間処理キュー１と午後１２時に蓄積されているメッセージの処理実行を開始する時間処理キュー２の２つある。データ受付部３０１が利用者から、どのＩＴレポートを閲覧したいか等の情報を含む要求メッセージを受けると（ステップ９００）、適切な時間処理キューにサービス実行メッセージとして入れておく（ステップ９０１）。利用者“Ｕ１”からの要求であれば、時間処理キュー１に格納し、“Ｕ３”からの要求であれば、時間処理キュー２に格納しておく。キューへの要求メッセージ格納は、契約で規定する時間外でも可能である。
【００２５】
図１０はサービス実行メッセージを時刻起動サービス実行部３０６４が実行し、実行結果を利用者に返信するまでの処理のフローチャートである。例えば、利用者“Ｕ１”からの要求メッセージが、午後１２時から午前６時までの間に時間処理キュー１に２件格納されていた場合、午前６時になると、時刻起動サービス実行部はこの２つのメッセージをキューから取り出し、実行する（ステップ１０００）。そして結果メッセージ受付部３０７１が実行結果を受けると要求メッセージ管理ＤＢ３１２に結果などの情報を格納し、（ステップ１００１）、返信メッセージ出力部３０９２が利用者に実行結果を渡すため、返信メッセージを出力する（ステップ１００２）。
【００２６】
利用者“Ｕ１”と利用者“Ｕ３”が条件“Ｊ１”に基づき契約したサービス“Ｓ３”は、条件ＤＢ３１４にて、課金率が６０％となっているので、利用者“Ｕ１”と“Ｕ３”はそれぞれ、代行サービスシステム３を利用せずに提供者と２４時間サービス利用可能である契約を直接交わした場合と比べると利用可能な時間は二分の一となるが、利用料は４０％引きになる。
次に、タイプ▲２▼の実施例について説明する。利用者“Ｕ２”が仙台から東京へ電車で来てコンサートに行くため、仙台−東京間の往復切符とコンサートチケットを購入するという要求メッセージをサービス代行システム３に送り、また利用者“Ｕ１”が“Ｕ２”と同じコンサートチケットの購入希望要求メッセージを送る場合の実施例について説明する。
【００２７】
図１１は複数の要求メッセージを受け、蓄積しておくプロセスのフローチャートである。利用者“Ｕ２” 、そして利用者“Ｕ１”が送信する要求メッセージを要求メッセージ受付部３０４１が受信すると（ステップ１１００）、要求メッセージ分析部３０４２が解析してサービス要素分解し、さらに、各サービス要素への対応サービスと提供者の情報を検索・取得し、これらの情報は図１６と図１７に示すように要求メッセージ管理ＤＢ３１２とサービス要素の対応管理ＤＢ３１３に格納する（ステップ１１０１）。本実施例では、“Ｕ２”からの要求メッセージに識別子“Ｒ２”、サービス要素にはそれぞれ“電車切符”に識別子“ＳＥ２”、 “コンサートチケット”に識別子“ＳＥ３”を付与する。“Ｕ１”からの要求メッセージ受信時にも同様に要求メッセージへの識別子“Ｒ４”、サービス要素“コンサートチケット”に識別子“ＳＥ５”を付与する。そして、サービス共用判断部３０５は条件ＤＢ３１４とサービス要素の対応管理ＤＢ３１３からサービス毎のサービス要求を取得し、サービス実行に必要な条件を満たしているかどうかを判断する（ステップ１１０２）。条件ＤＢ３１４に格納するデータ構成の例は図１８に示している。条件を満たさない場合はこのプロセスは終了するが、利用者の希望にそって条件を満たしている場合、例えばサービス要素の対応管理ＤＢ３１３を参照すると、サービス要素“ＳＥ３”と“ＳＥ５”は同じサービス“Ｓ２”が対応サービスであることが判明、さらに要求メッセージ管理ＤＢ３１２を参照し“ＳＥ３”と“ＳＥ５”の希望利用形態がともに‘早く’であることから、条件ＤＢ３１４の条件“Ｊ３”の条件を満たし、つまりサービス“Ｓ２”を１回実行することで要求メッセージ“Ｒ２”と“Ｒ４”の両要求を満たすと判断できるので、サービス実行メッセージ組み立て部３０６１が要求要素“ＳＥ３”と“ＳＥ５”のグルーピングを行い、サービス管理テーブル３１１３に格納されているサービス“Ｓ２”のインターフェース情報を利用してサービス実行メッセージを組み立てる（ステップ１１０３）。
【００２８】
図１２はステップ１１０３で作成されたサービス実行メッセージをサービス実行部３０６２が実行し、実行結果を利用者に返信するまでの処理のフローチャートである。ステップ１１０３で作成されたサービス実行メッセージはサービス実行部３０６２が実行し（ステップ１２００）、次に、サービスの実行結果を結果メッセージ受付部３０７１が受け取ると（ステップ１２０１）、結果メッセージ分析部３０７２が結果メッセージを分析しサービス要素の対応管理ＤＢ３１３を用いてもとのサービス要素“ＳＥ３”と“ＳＥ５”に対応する結果を要求メッセージ管理ＤＢ３１２に格納する（ステップ１２０２）。そして課金処理部３０８は条件ＤＢ３１４とサービス管理テーブル３１１３を参照して利用者“Ｕ２”と“Ｕ１”それぞれの利用料金を計算する（ステップ１２０３）。返信メッセージ作成部３０９１がステップ１２０３で算出された利用料金に関する情報や実行結果を含む返信メッセージを作成し、返信メッセージ出力部３０９２がこれを利用者へ送る（ステップ１２０４）。本実施例では、要求メッセージ“Ｒ２”に含まれているサービス要素“ＳＥ２”はまだ実行条件が満たされないため、“Ｒ２”への返信メッセージはまだ返さないが、要求メッセージ“Ｒ４”に含まれているサービス要素は全て実行されているので、“Ｒ４”への返信メッセージは作成する、という方法をとるが、要求“Ｒ２”のように、異なるサービス要素が複数含まれている場合の実行のタイミングや返信メッセージを利用者へ送るタイミングは利用者からの要求受付時に利用者に指定させてもよいし、提供者がルールとして決めておいてもよい。後、利用者“Ｕ２”からの要求“Ｒ２”に含まれているサービス要素“ＳＥ３”の実行が完了したら、サービス要素“ＳＥ２”と“ＳＥ３”のそれぞれに対する結果をもとに、サービス結果メッセージを組み立てて利用者へ返信する。利用料金について、この場合は条件ＤＢ３１４にて課金率が６０％となっているので、利用者“Ｕ２”と“Ｕ１”はそれぞれ、従来例により利用するよりも４０％引きの利用料で利用できたことになる。
【００２９】
以上説明してきたように、代行サービスシステム３によれば、サービス利用者は通常より割安な料金でサービスの部分利用が可能となり、また、複数利用者の要求を一回のサービス実行に集約して利用者一人あたりの利用料を割安にすることが可能となる。また、サービスの活用方法や割引率の決め方は代行サービスシステム管理者が決めればよいので、様々な詳細レベルで設定可能である。更に、サービスについて登録できる情報の種類を増やすなど、代行サービスシステム３が管理し参照する情報の充実化により、サービス内容や利用料をさらにきめ細かく処理し利用者と提供者にとって、より最適な方法でサービスの実行を代行することが可能である。
【００３０】
【発明の効果】
以上説明したように、本発明によれば、サービス利用者は通常より割安な料金でサービスの部分利用が可能となり、また、複数利用者の要求を一回のサービス実行に集約して利用者一人あたりの利用料を割安にすることが可能となる。また、サービスの活用方法や割引率の決め方は代行サービスシステム管理者が決めればよいので、様々な詳細レベルで設定可能である。更に、サービスについて登録できる情報の種類を増やすなど、代行サービスシステムが管理し参照する情報の充実化により、サービス内容や利用料をさらにきめ細かく処理し利用者と提供者にとって、より最適な方法でサービスの実行を代行することが可能である。
【図面の簡単な説明】
【図１】本実施形態の代行サービスシステムのシステム構成を示す図である。
【図２】本実施形態の要求メッセージ分解部３０４の概略構成を示す図である。
【図３】本実施形態の実行部３０６の概略構成を示す図である。
【図４】本実施形態の結果メッセージ分解部３０７の概略構成を示す図である。
【図５】本実施形態のメッセージ出力部３０９の概略構成を示す図である。
【図６】本実施形態の登録ＤＢ３１１の概略構成を示す図である。
【図７】登録部３０３が行う処理のフローチャートである。
【図８】利用時間を区切ってサービスを共用するような、利用者と代行サービスシステムで事前に契約を必要とするサービスの場合の、利用者と代行サービスシステムの間で契約を結ぶ処理のフローチャートである。
【図９】利用時間を区切ってサービスを共用するような、利用者と代行サービスシステムで事前に契約を必要とするサービスの場合の、サービス利用権をもつ利用者が、サービスを使って各種要求処理を行う要求メッセージを蓄積しておくプロセスを示すフローチャートである。
【図１０】利用時間を区切ってサービスを共用するような、利用者と代行サービスシステムで事前に契約を必要とするサービスの場合の、サービス実行メッセージを実行し、実行結果を利用者に返信するまでの処理のフローチャートである。
【図１１】複数の要求を１回で処理できるサービスの場合の、複数の要求メッセージを蓄積しておくプロセスのフローチャートである。
【図１２】複数の要求を１回で処理できるサービスの場合の、サービス実行メッセージを実行し、実行結果を利用者に返信するまでの処理のフローチャートである。
【図１３】本実施形態の利用者管理テーブル３１１１に格納される利用者データの一例を示す図である。
【図１４】本実施形態の提供者管理テーブル３１１２に格納される利用者データの一例を示す図である。
【図１５】本実施形態のサービス管理テーブル３１１３に格納される利用者データの一例を示す図である。
【図１６】本実施形態の要求メッセージ管理ＤＢ３１２に格納される利用者データの一例を示す図である。
【図１７】本実施形態のサービス要素の対応管理ＤＢ３１３に格納される利用者データの一例を示す図である。
【図１８】本実施形態の条件ＤＢ３１４に格納される利用者データの一例を示す図である。
【符号の説明】
１…提供者、２…利用者、３…代行サービスシステム、３０１…データ受付部、３０２…処理振り分け部、３０３…登録部、３０４１…要求メッセージ受付部、３０４２…要求メッセージ分析部、３０５…サービス共用診断部、３０６１…サービス実行メッセージ組み立て部、３０６２…サービス実行部、３０６３…時間処理キュー、３０６４…時刻起動サービス実行部、３０７１…結果メッセージ受付部、３０７２…結果メッセージ分析部、３０８…課金処理部、３０９１…返信メッセージ作成部、３０９２…返信メッセージ出力部、３１０…サービスサービスアクセス監視部、３１１１…利用者管理テーブル、３１１２…提供者管理テーブル、３１１３…サービス管理テーブル

Claims (4)

1. サービス利用者端末とサービス提供者装置とをネットワークを介して接続された、サービス実行に伴う課金計算の処理とサービスプログラムの実行を行う代行サービスシステムにおける代行サービス提供方法において、
   前記サービスの利用にあたり、サービス提供者装置およびサービス利用者端末からの登録を受け付け、サービス利用者端末からのサービスリクエストを複数集め、利用者の希望する利用形態、または利用状況を監視しながら、サービス提供者装置から提供されている１つのサービスを複数利用者に時間を分割し、当該利用の時間帯は各利用者がサービスを独占的に利用出来るようにすることで利用者に代わり提供者への窓口となってサービスを代行することを特徴とする代行サービス提供方法。
2. サービス利用者端末とサービス提供者装置とをネットワークを介して接続された、サービス実行に伴う課金計算の処理とサービスプログラムの実行を行う代行サービスシステムにおける代行サービス提供方法において、
   該サービスの利用にあたり、サービス提供者装置およびサービス利用者端末からの登録を受け付け、サービス利用者端末からのサービスリクエストを複数集め、１つのサービスに対し複数リクエストを集約し、それらをサービス実行プログラムにて１回で処理することで、利用者に代わり提供者への窓口となってサービスを代行することを特徴とする代行サービス提供方法。
3. サービス利用者端末とサービス提供者装置とをネットワークを介して接続された、サービス実行に伴う課金計算の処理とサービスプログラムの実行を行う代行サービスシステムにおける代行サービスシステムにおいて、
   前記サービスの利用にあたり、サービス提供者装置およびサービス利用者端末からの登録を受け付ける手段と、サービス利用者端末からのサービスリクエストを複数集め、利用者の希望する利用形態、または利用状況を監視しながら、サービス提供者装置から提供されている１つのサービスを複数利用者に時間を分割し、当該利用の時間帯は各利用者がサービスを独占的に利用出来るようにすることで利用者に代わり提供者への窓口となってサービスを代行する手段とを備えたことを特徴とする代行サービスシステム。
4. サービス利用者端末とサービス提供者装置とをネットワークを介して接続された、サービス実行に伴う課金計算の処理とサービスプログラムの実行を行う代行サービスシステムにおける代行サービスシステムにおいて、
   該サービスの利用にあたり、サービス提供者装置およびサービス利用者端末からの登録を受け付ける手段と、サービス利用者端末からのサービスリクエストを複数集め、１つのサービスに対し複数リクエストを集約し、それらをサービス実行プログラムにて１回で処理することで、利用者に代わり提供者への窓口となってサービスを代行する手段とを備えたことを特徴とする代行サービス提供方法。

Images