JP2002259772A - 承認システム、承認要求に関する処理を行うための装置、方法、プログラム - Google Patents

Abstract

(57)【要約】 【課題】 本発明は、承認判定者が不在の場合や多忙な
場合であっても、承認要求者が長時間待たされることな
く、承認判定を行うことができるようにするものであ
る。 【解決手段】 本発明の一形態では、クライアント端末
において承認要求を生成し、生成された承認要求をリク
エストサーバの承認要求格納部に格納しておき、一方、
サービスサーバに承認判定所により設定された承認サー
ビスを格納しておく。そして、リクエストサーバに格納
されている承認要求に適した承認サービスをサービスサ
ーバから検索して、検索された承認サービスを用いて該
承認要求の承認判定処理を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、承認要求者からの
承認要求に対して承認判定処理を実行する承認システ
ム、承認要求に関する処理を行うための装置、方法、プ
ログラムに関するものである。

【０００２】

【従来の技術】図１は、従来技術による購買承認処理の
流れを例示した説明図である。本図に示すように、従
来、承認要求者が何らかの承認を得る為には、承認判定
者が理解可能な様式で文書化して承認判定者にその文書
を渡し、承認を得る必要があった。

【０００３】

【発明が解決しようとする課題】この従来の手法では、
承認要求者が承認判定者のところへ出向く必要があるば
かりでなく、出向いたその時に承認判定者が多忙である
場合には、実際に承認を得るまでに多くの待ち時間を要
するという不都合があった。

【０００４】

【課題を解決するための手段】本発明は、承認判定者の
ところへ出向くことなく、承認要求を行えるような承認
システム、装置、方法、プログラムを提供する。

【０００５】上記課題を解決する為に、本発明の一形態
である情報処理装置は、承認要求を生成する承認要求生
成手段と、承認サービスプロバイダにより設定される承
認サービスを格納する格納手段と、前記格納された承認
サービスを用いて、前記生成された承認要求を承認する
か否か判定する判定手段と、前記判定手段の判定結果を
出力する出力手段とを有する。

【０００６】また、本発明の一形態である承認システム
は、承認サービスプロバイダによって登録された複数の
承認サービスを管理するサービスサーバと、承認要求を
生成する承認要求生成手段を有するクライアント端末と
を含む承認システムであって、前記クライアント端末
は、更に、前記サービスサーバに登録されている複数の
承認サービスの中から、前記承認要求に適した承認サー
ビスを検索して取得する取得手段と、該取得した承認サ
ービスを用いて前記承認要求の承認判定を行う判定実行
手段と、前記判定実行手段の判定結果を出力する出力手
段とを有する。

【０００７】また、本発明の一形態であるサービスサー
バは、承認サービスプロバイダから登録するよう指示さ
れた承認サービスを複数格納する承認サービス格納手段
と、外部装置から検索指示された、承認要求に対応する
承認サービスを検索して、該承認サービスを前記外部装
置に送信する送信手段とを有する。

【０００８】また、本発明の一形態である承認システム
は、承認サービスプロバイダによって登録された複数の
承認サービスを管理するサービスサーバと、承認要求を
生成する承認要求生成手段を有するクライアント端末
と、前記クライアント端末で生成された承認要求を格納
する承認要求格納手段を有するリクエストサーバとを含
む承認システムであって、前記リクエストサーバは、前
記クライアント端末で生成された承認要求を格納する承
認要求格納手段と、前記サービスサーバに登録されてい
る複数の承認サービスの中から、前記承認要求格納手段
に格納されている承認要求に適した承認サービスを検索
して取得する取得手段と、該取得した承認サービスを用
いて前記承認要求の承認判定を行う判定実行手段と、前
記判定実行手段の判定結果を出力する出力手段とを有す
る。

【０００９】また、本発明の一形態である承認システム
は、承認サービスプロバイダによって登録された複数の
承認サービスを管理するサービスサーバと、承認要求を
生成する承認要求生成手段を有するクライアント端末と
を含む承認システムであって、前記クライアント端末
は、更に、前記サービスサーバに登録されている複数の
承認サービスの中から、前記承認要求に適した承認サー
ビスを検索する検索手段と、前記検索手段により承認サ
ービスが検索された場合、該承認要求を前記サービスサ
ーバに送信する送信手段と、前記サービスサーバから該
送信した承認要求の承認判定結果を受信する受信手段と
を有し、前記サービスサーバは、前記クライアント端末
から送信されてきた承認要求を、該承認要求に適した承
認サービスを用いて承認判定を行う判定実行手段と、該
承認判定結果を前記クライアント端末に送信する送信手
段とを有する。

【００１０】また、本発明の一形態である承認システム
は、承認サービスプロバイダによって登録された複数の
承認サービスを管理するサービスサーバと、承認要求を
生成する承認要求生成手段を有するクライアント端末
と、前記クライアント端末で生成された承認要求を格納
する承認要求格納手段を有するリクエストサーバとを含
む承認システムであって、前記リクエストサーバは、前
記クライアント端末で生成された承認要求を格納する承
認要求格納手段と、前記サービスサーバに登録されてい
る複数の承認サービスの中から、前記承認要求格納手段
に格納されている承認要求に適した承認サービスを検索
する検索手段と、前記検索手段により承認サービスが検
索された場合、該承認要求を前記サービスサーバに送信
する送信手段と、前記サービスサーバから該承認要求の
承認判定結果を受信する受信手段とを有し、前記サービ
スサーバは、前記リクエストサーバから送信されてきた
承認要求を、該承認要求に適した承認サービスを用いて
承認判定を行う判定実行手段と、該承認判定結果を前記
リクエストサーバに送信する送信手段とを有する。

【００１１】

【発明の実施の形態】以下、図面を参照して、本発明の
各実施の形態を詳細に説明していく。

【００１２】図７は、後に詳述する各実施の形態におい
て用いる情報処理装置（クライアント端末、承認判定者
用端末、サービスサーバ、リクエストサーバなど）のハ
ードウェア構成を示すブロック図である。本図におい
て、１は、情報を入力するための入力部である。２は、
ＣＰＵであり、コンピュータプログラムに従って各種処
理のための演算・論理判断等を行い、バス６に接続され
た各構成要素を制御する。３は、情報を出力する出力部
である。

【００１３】４は、プログラムメモリであり、フローチ
ャートを参照しながら後に詳述する処理手順ならびにＣ
ＰＵ２による他の制御手順をプログラムの形態で格納し
たメモリである。このプログラムメモリ４は、ＲＯＭで
あってもよいし、外部記憶装置などからプログラムがロ
ードされるＲＡＭであってもよい。

【００１４】５は、データメモリであり、各種の処理で
生じたデータを格納するほか、後述する知識ベースの知
識を格納する。このデータメモリ５として、本実施の形
態ではＲＡＭを用いるが、上記知識ベースの知識は、不
揮発な外部記憶媒体から各処理に先立ってロードしてお
くか、あるいは、必要があるたびに参照することも可能
である。

【００１５】６は、ＣＰＵ２の制御の対象となる各構成
要素に指示を与えるためのアドレス信号，各構成要素を
制御するためのコントロール信号，各構成機器相互間で
授受されるデータの転送を行うためのバスである。

【００１６】＜実施の形態１＞本実施形態１では、図２
に示したように、予め、承認要求者が扱うクライアント
装置は、承認のための各種条件が承認判定者によって設
定された承認サービスを受け取って格納部に格納してお
き、該承認サービスを用いて、承認要求判定処理を行
う。

【００１７】図８は、本実施の形態に係るシステム全体
の処理を示すフローチャートである。まず、システムが
起動されると、ステップＳ８０１のシステム起動処理で
システムが持つ各種デバイスやメモリなどが初期化され
る。

【００１８】続いて、ステップＳ８０２でユーザからの
入力操作や、他の装置から情報の受信や、タイマからの
信号などの各種イベントが発生するのを待機する。

【００１９】そこで、何らかのイベントが発生すると、
次のステップＳ８０３で電源ＯＦＦを指示したイベント
か否かが判断される。その結果、電源ＯＦＦを指示して
いると判断された場合、ステップＳ８１０のシステム終
了処理により、システムが持つ各種デバイスやメモリな
どの終了処理を実行後、システムを終了する。

【００２０】ステップＳ８０３で電源ＯＦＦを指示して
いると判断されなかった場合、次のステップＳ８０４で
購買承認要求の生成開始を指示しているか否かが判断さ
れる。その結果、購買承認要求の生成開始を指示してい
ると判断されなかった場合、再びステップＳ８０２に戻
り、処理を繰り返す。

【００２１】ステップＳ８０４で購買承認要求の生成開
始を指示していると判断された場合、次のステップＳ８
０５の購買承認要求生成処理により、購買承認要求が生
成され、次のステップＳ８０６で生成が成功したか否か
が判断される。その結果、生成が成功したと判断されな
かった場合、再びステップＳ８０２に戻り、処理を繰り
返す。

【００２２】一方、ステップＳ８０６で生成が成功した
と判断された場合、次のステップＳ８０７において、該
生成された購買承認要求を承認サービスに通知して、該
購買承認要求を承認するか否かが判定され、次のステッ
プＳ８０８で承認されたか否か判断される。その結果、
承認されたと判断されなかった場合、再びステップＳ８
０２に戻り、処理を繰り返す。

【００２３】ステップＳ８０８で承認されたと判断され
た場合、次のステップＳ８０９の購買実施処理により、
上記購買承認要求に対応した処理を実行し、再びステッ
プＳ８０２に戻り、処理を繰り返す。なお、ステップＳ
８０９で購買承認要求に応じた購買実施処理を行った
際、該実施処理を行ったことを承認判定者に電子メール
等を用いて通知するようにしてもよい。

【００２４】図９は、図８に示したシステム全体の流れ
における、ステップＳ８０５の購買承認要求生成処理の
流れを示す図である。

【００２５】本実施の形態で用いる情報処理装置におけ
る購買承認要求生成処理では、ユーザからの入力操作を
受け付け、購買承認要求を生成する。具体的には、購買
承認要求生成処理が起動されると、ステップＳ９０１で
過去の購買履歴から商品名を取得し、商品名候補として
格納する。図１０は、購買履歴の一例を示す図であり、
購買を行った日時と、商品名と、その分類が格納されて
いる。

【００２６】続くステップＳ９０２では、分類項目一覧
から分類項目を取得し、分類項目候補として格納する。
図１１は、分類項目一覧の一例を示す図である。本情報
処理装置における分類項目一覧には、ＩＤと、このＩＤ
に対応する分類項目名が格納されている。

【００２７】続くステップＳ９０３の購買承認要求入力
処理では、上記商品名候補および上記分類項目候補を用
いて、後述するような購買承認要求入力画面（図１２参
照）を表示し、ユーザの入力を促し、操作を受け付け
る。次のステップＳ９０４で、購買承認要求がされたか
判断する。承認要求があったと判断されなかった場合、
購買承認要求の生成失敗として処理を終了する。

【００２８】ステップＳ９０４において、購買承認要求
があったと判断された場合、続くステップＳ９０５にお
いて、空の購買承認要求を生成してステップＳ９０６〜
Ｓ９０８でパラメータを設定する。更に、次のステップ
Ｓ９０６で、実際に操作をしているユーザを購買承認要
求の要求者として設定する。更に、次のステップＳ９０
７で、実際に操作をしている機器を購買承認要求の要求
元として設定する。更に、次のステップＳ９０８の上記
購買承認要求入力処理で、ユーザが入力した各種値を購
買承認要求として格納し、後述するような購買承認要求
の生成を完了し、購買承認要求の生成成功として処理を
終了する。

【００２９】図１２は、上記購買承認要求生成処理にお
ける、ステップＳ９０３の購買承認要求入力処理で、上
記商品名候補および分類項目候補を受け取り、ユーザの
入力を促し、操作を受け付けるために、表示される購買
承認要求入力画面の一例を示す図である。

【００３０】本情報処理装置における購買承認要求入力
画面では、購買承認要求の対象となる商品の名称１２１
と、その分類１２３、金額１２４、納期１２５、優先度
１２６を入力することができる。また、ステップＳ９０
１及びＳ９０２で格納した商品名候補１２２や分類項目
候補を表示し、その中から商品の名称や分類項目を選択
することもできる。

【００３１】以上、ユーザの入力・選択操作の後、購買
承認要求実行ボタン１２７、あるいはキャンセルボタン
１２８を押すことで、購買承認要求実行、あるいはキャ
ンセルとして終了させることができる。

【００３２】図１３および図１４は、上記購買承認要求
生成処理（ステップＳ８０５）によって、生成される購
買承認要求の一例を示す図である。

【００３３】本情報処理装置における購買承認要求に
は、購買承認要求を行った要求者、操作を行った要求
元、商品の名称、その分類、金額、納期、優先度などが
格納されている。例えば、図１３の例の場合、要求者
「太郎」が、要求元「コンポ」から、商品名称「小さい
秋」（３回再生分）」、分類「音楽」を、金額「￥８
０」で、納期「１９９９年１２月１５日」までに、優先
度「８０」で、生成された購買承認要求を示している。

【００３４】一方、図１４の例の場合、要求者「太郎」
が、要求元「コンポ」から、商品名称「第九（３回再生
分）」、分類「“ＭｕｓｉｃＦｌａｓｈ”」を、金額
「￥８０」で、納期「１９９９年１２月１５日」まで
に、優先度「９０」で、生成された購買承認要求を示し
ている。

【００３５】図１５は、上記システム全体の流れにおけ
る、ステップＳ８０７の購買承認判定処理の流れを示す
図である。

【００３６】本情報処理装置に格納された承認サービス
による購買承認判定処理では、承認判定を行うべきと判
断された場合にのみ、承認判定情報を検索し、適用する
ことで、購買承認要求を承認するか否かを判定する。具
体的には、購買承認判定処理が起動されると、ステップ
Ｓ１５０１の購買承認判定実行判断処理により、承認判
定を行うべきか否か判断される。その結果、次のステッ
プＳ１５０２で承認判定を実行すべきと判断されなかっ
た場合、ステップＳ１５１１に進み、購買却下通知処理
により、購買承認要求が却下されたことを要求者に通知
し、却下として処理を終了する。

【００３７】ステップＳ１５０２で承認判定を実行すべ
きと判断された場合、次のステップＳ１５０３の承認判
定情報検索処理により、入力された購買承認要求に対応
した承認判定情報を検索する。その結果、次のステップ
Ｓ１５０４で検索成功と判断されなかった場合、ステッ
プＳ１５１１に進み、購買却下通知処理により、購買承
認要求が却下されたことを要求者に通知し、却下として
処理を終了する。

【００３８】ステップＳ１５０４で検索成功と判断され
た場合、次のステップＳ１５０５の承認判定情報適用処
理により、購買承認要求を上記承認判定情報に適用す
る。その結果、次のステップＳ１５０６で、適用成功と
判断されなかった場合、ステップＳ１５１１に進み、購
買却下通知処理により、購買承認要求が却下されたこと
を要求者に通知し、却下として処理を終了する。

【００３９】ステップＳ１５０６で適用成功と判断され
た場合、次のステップＳ１５０７で承認判定者に確認す
る必要があるか否かを判断する。その結果、確認する必
要があると判断された場合、ステップＳ１５０８の承認
確認処理により、承認判定者に該承認要求を通知して承
認するか否かを確認する。その結果、次のステップＳ１
５０９で承認されたと判断されなかった場合、ステップ
Ｓ１５１１に進み、購買却下通知処理により、購買承認
要求が却下されたことを要求者に通知し、却下として処
理を終了する。

【００４０】ステップＳ１５０７で承認判定者に確認す
る必要が無いと判断された場合、あるいはステップＳ１
５０９で承認判定者が確認した結果、承認されたと判断
された場合、ステップＳ１５１０の購買承認通知処理に
より、購買承認要求が承認されたことを要求者に通知
し、承認として処理を終了する。

【００４１】図１６は、上記購買承認判定処理の流れに
おける、ステップＳ１５０１の購買承認判定実行判断処
理の流れを示す図である。

【００４２】本実施形態における購買承認判定実行判断
処理では、後述する購買承認判定実行フラグおよび、購
買承認判定禁止スケジュールを参照することで、承認判
定を行うべきか否か判断する。具体的には、購買承認判
定実行判断処理が起動されると、ステップＳ１６０１で
後述する購買承認判定実行フラグを参照し、判断を切り
替える。すなわち、購買承認判定実行フラグが「ＯＫ」
の場合には、購買承認判定実行として処理を終了する。
他方、購買承認判定実行フラグが「ＮＧ」の場合には、
購買承認判定禁止として処理を終了する。

【００４３】購買承認判定実行フラグが上記以外の場合
には、次のステップＳ１６０２の購買承認判定禁止スケ
ジュール検索処理により、現在の時刻を、後述する購買
承認判定禁止スケジュールの承認判定禁止期間から検索
する。その結果、次のステップＳ１６０３で禁止期間内
であると判断された場合には購買承認判定禁止とし、禁
止期間内でないと判断された場合には購買承認判定実行
として処理を終了する。

【００４４】上記ステップにより、まず購買承認判定実
行フラグでの指定を優先して判断し、指定されていない
場合にのみ、購買承認判定禁止スケジュールを参照する
こととしている。

【００４５】図１７は、上記購買承認判定実行判断処理
における、ステップＳ１６０１で参照される、購買承認
判定実行フラグの定義の一例を示す図である。本情報処
理装置における購買承認判定実行フラグでは、「ＯＫ」
を購買承認判定実行可能、「ＮＧ」を購買承認判定実行
禁止、上記以外を未設定として定義している。

【００４６】図１８は、上記購買承認判定実行判断処理
における、ステップＳ１６０２の購買承認判定禁止スケ
ジュール検索処理で参照される、購買承認判定禁止スケ
ジュールの一例を示す図である。

【００４７】本情報処理装置における購買承認判定禁止
スケジュールには、購買承認判定を行ってはいけない時
間帯を、リストとして記述してある。よって、上記購買
承認判定禁止スケジュール検索処理では、このリスト中
に現在の時刻が適合するか否かをチェックすることで、
検索している。

【００４８】図１９は、図１５に示したステップＳ１５
０５の承認判定情報適用処理で用いられる予算情報の一
例を示す図である。

【００４９】本情報処理装置における予算情報には、各
機器および分類毎に、それぞれの個人予算枠と、機器自
身の予算枠と、上記承認確認（ステップＳ１５０７参
照）が必要か否かを示すデータが格納されている。

【００５０】例えば、機器「コンポ」の分類「“Ｍｕｓ
ｉｃＦｌａｓｈ”」には、「太郎」の予算枠￥２，００
０のみが確保されており、承認確認が不要である。ま
た、機器「コンポ」の分類「音楽」には、「花子」の予
算枠￥２，０００、「拓哉」の予算枠￥５００が確保さ
れており、承認確認は必要である。

【００５１】ここで、前述の図を用いて、１つの装置内
（もしくは単一システム内）で、ユーザの購買承認要求
を生成し、購買の承認を判断し、購買を実施する場合に
ついて、具体的に説明する。

【００５２】図２に示したように、本実施の形態で説明
した装置に購買承認要求生成開始を指示すると、図８の
ステップＳ８０４で購買承認要求の生成開始を指示した
と判断され、次のステップＳ８０５の購買承認要求生成
処理により、購買承認要求が生成される。例えば、操作
ユーザ「太郎」が、操作機器「コンポ」で、図１２に示
したように名称「小さい秋（３回再生分）」、分類「音
楽」、金額「￥８０」、納期「１９９９年１２月１５
日」、優先度「８０」を入力し、購買承認要求１２７を
選択すると、図１３に示したような購買承認要求が作成
される。

【００５３】その結果、次のステップＳ８０６で購買承
認要求の生成が成功したと判断され、続くステップＳ８
０７の購買承認判定処理により、承認するか否かが判定
される。

【００５４】購買承認判定処理では、ステップＳ１５０
３の承認判定情報検索処理により、図１９の予算情報を
参照した結果、要求機器「コンポ」で、分類「音楽」が
検索される。

【００５５】その結果、次のステップＳ１５０４で検索
成功と判断され、続くステップＳ１５０５の承認判定情
報適用処理により、要求者「太郎」の予算枠￥０に、要
求金額￥８０を適用しようと試みるが、予算が足りない
ので失敗し、ステップＳ１５１１で購買が却下されたこ
とを通知して、処理を終了する。

【００５６】一方、図１４に示したような購買承認要求
の場合、要求者「太郎」、機器「コンポ」で、分類
「“ＭｕｓｉｃＦｌａｓｈ”」が検索され、要求者「太
郎」の予算枠￥２，０００に、要求金額￥８０を適用し
ようと試みた結果、予算に収まるので成功する。更に、
ステップＳ１５０７で承認確認の必要性を判断した結
果、「要」と指定されていないので不要と判断し、ステ
ップＳ１５１０で購買が承認されたことを通知して、処
理を終了する。

【００５７】なお、これまで説明した例では、図２に示
すように１つの装置内において購買承認要求の生成，承
認判定を行う場合であったが、１つの装置内に限らず、
閉じた１つの単一システム、あるいは閉じた１つの処理
系統において同様の処理を行い得ることは勿論である。

【００５８】以上説明した通り本実施の形態１では、承
認要求者が使用するクライアント装置（又はクライアン
トシステム）において、あらかじめ設定しておいた「購
買承認判断に必要な情報」を参照して承認の判定を実行
することとしているので、承認判定者が多忙であるとき
には承認を得るまでに多くに時間を要するという従来の
欠点を除去することができる。

【００５９】更に、ステップＳ１５０１において購買承
認判定実行判断処理を先行して実行することにより、夜
間などの承認判定禁止期間に、自動的に承認判定が行わ
れてしまうという不都合を回避することができる。

【００６０】＜実施の形態２＞実施の形態１では、図２
に示したように、承認サービスを行うための条件が予め
クライアント端末に設定されていた。

【００６１】本実施形態２では、購買承認判断の為の情
報をあらかじめ全て用意しておくこと無く、新規分野の
購買承認要求が現れるたびにそれに対応する承認サービ
スを登録して対応することで、システムの複雑化・肥大
化を避けるようにする。

【００６２】そこで、実施の形態２では、図３に示すよ
うにサービスサーバに承認サービスを登録・削除・更新
の機能を持たせて、クライアント装置において承認サー
ビスが必要となった場合そのサービスサーバが所有する
承認サービスを検索して取得し、承認サービス判定を行
うようにすることで実現する。以下に、図２０〜図３６
を用いて具体的に説明する。

【００６３】図２０は、図３で示した、購買承認要求者
が利用するクライアント端末、購買承認判定者が利用す
る承認者用端末、および購買承認サービスを登録管理す
るサービスサーバ間の関係を、より詳細に示した例であ
る。サービスサーバ２００１には、様々な承認サービス
（２００２〜２０１１）が登録される。

【００６４】具体的には、下記のような流れで処理が行
われる。

【００６５】１．サービスプロバイダが「音楽承認サー
ビス」を、サービスサーバ２００１に登録する。これに
より、サービスサーバ２００１に音楽承認サービス２０
０３が追加される。

【００６６】２．クライアント端末において、ユーザか
らの指示により購買承認要求が生成される。

【００６７】３．承認判定を行うために、該承認要求に
対応する承認サービスを、サービスサーバ２００１から
検索する。

【００６８】４．上記検索の結果、クライアント端末
は、検索された承認サービスを取得する。

【００６９】５．クライアント端末は、取得した承認サ
ービスを用いて、実施形態１と同様にして承認要求の判
別を行う。

【００７０】ただし、この図２０からは、承認サービス
そのものがサービスサーバ２００１に直接格納されてい
るように見えるが、他のデバイスに存在する実体にアク
セスする為だけの情報が格納されるよう構成することも
可能である。

【００７１】図２１は、購買承認者が利用する端末（購
買承認サービスプロバイダ）で実行される処理を示す図
である。具体的には、まず購買承認サービスプロバイダ
が起動されると、ステップＳ２１０１のシステム起動処
理でシステムが持つ各種デバイスやメモリなどが初期化
される。続いて、ステップＳ２１０２でユーザからの入
力操作や、他の装置から情報の受信や、タイマからの信
号などの各種イベントが発生するのを待機する。

【００７２】そこで、何らかのイベントが発生すると、
次のステップＳ２１０３で電源ＯＦＦを指示したイベン
トか否か判断される。その結果、電源ＯＦＦを指示して
いると判断された場合、ステップＳ２１０７のシステム
終了処理により、システムが持つ各種デバイスやメモリ
などの終了処理を実行後、本システムの処理を終了す
る。

【００７３】ステップＳ２１０３で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ２１０
４で承認サービスに対する指示か否か判断される。その
結果、承認サービスに対する指示と判断されなかった場
合、再びステップＳ２１０２に戻る。

【００７４】ステップＳ２１０４で承認サービスの開始
が指示されたと判断した場合、ステップＳ２１０５の承
認サービス登録処理により、承認サービスをサービスサ
ーバ２００１に登録し、再びステップＳ２１０２に戻
る。

【００７５】ステップＳ２１０４で承認サービスの終了
が指示されたと判断した場合、ステップＳ２１０６の承
認サービス削除処理により、承認サービスをサービスサ
ーバ２００１から削除し、再びステップＳ２１０２に戻
る。

【００７６】図２２は、購買承認サービスを登録管理す
る購買承認サービスサーバの全体の処理を示す図であ
る。具体的には、まず購買承認サービスサーバが起動さ
れると、ステップＳ２２０１のシステム起動処理でシス
テムが持つ各種デバイスやメモリなどが初期化される。
続いて、ステップＳ２２０２でユーザからの入力操作
や、他の装置から情報の受信や、タイマからの信号など
の各種イベントが発生するのを待機する。

【００７７】そこで、何らかのイベントが発生すると、
次のステップＳ２２０３で電源ＯＦＦを指示したイベン
トか否か判断される。その結果、電源ＯＦＦを指示して
いると判断された場合、ステップＳ２２０９のシステム
終了処理により、システムが持つ各種デバイスやメモリ
などの終了処理を実行後、本システムの処理を終了す
る。

【００７８】ステップＳ２２０３で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ２２０
４でイベントの種類が何かについて判断がなされる。そ
の結果、承認サービスに対する指示と判断されなかった
場合、再びステップＳ２２０２に戻る。

【００７９】ステップＳ２２０４で承認サービスの登録
が指示されたと判断した場合、ステップＳ２２０５の承
認サービス登録処理において、サービスプロバイダから
送信されてきた承認サービスを承認サービス登録情報
（図２３参照）として登録し、再びステップＳ２２０２
に戻る。

【００８０】ステップＳ２２０４で承認サービスの削除
が指示されたと判断した場合、ステップＳ２２０６の承
認サービス削除処理において、指示された承認サービス
を承認サービス登録情報から削除し、再びステップＳ２
２０２に戻る。

【００８１】ステップＳ２２０４で承認サービスの更新
が指示されたと判断した場合、ステップＳ２２０７の承
認サービス更新処理により、承認サービス登録情報とし
て格納されている承認サービスを指示に応じて更新し、
再びステップＳ２２０２に戻る。

【００８２】ステップＳ２２０４で承認サービスの検索
が指示されたと判断した場合、ステップＳ２２０８の承
認サービス検索処理により、対応する承認サービスを承
認サービス登録情報から検索して、検索要求元に渡し、
再びステップＳ２２０２に戻る。

【００８３】図２３は、購買承認サービスサーバ２００
１に登録・参照される購買承認サービス登録情報の一例
を示す図である。

【００８４】本情報処理装置における購買承認サービス
登録情報には、それぞれの購買承認サービスを表すＩＤ
と、その分類、およびオブジェクトが格納されている。

【００８５】ここで、オブジェクトとは、購買承認サー
ビスそのものでもかまわないし、購買承認サービスで必
要となる情報だけでもかまわないし、他デバイスなどに
存在する購買情報サービスにアクセスする為の情報であ
ってもかまわない。

【００８６】図２４は、上記購買承認サービス登録情報
に格納されている、購買承認サービスのオブジェクトの
一例を示す図であり、音楽承認サービスの例を詳細に表
している。具体的には、購買承認サービスのオブジェク
トには、サービスを実現する為のメソッドと、承認判定
のための条件データを有しており、これらを組み合わせ
ることでサービスを提供している。

【００８７】図２５は、図２２に示したステップＳ２２
０８の購買承認サービス検索処理の流れを示す図であ
る。

【００８８】承認サービスサーバにおける購買承認サー
ビス検索処理では、対応する承認サービスを前述の承認
サービス登録情報から検索し、要求元のクライアント端
末に渡す。具体的には、まず購買承認サービス検索処理
が起動されると、ステップＳ２５０１で処理対象を前述
の購買承認サービス登録情報の先頭で初期化し、続くス
テップＳ２５０２において処理対象が終了か否か判断す
る。その結果、前述の購買承認サービス登録情報すべて
に対する処理が終了したと判断された場合、検索失敗と
して処理を終了する。

【００８９】ステップＳ２５０２で終了と判断されなか
った場合、次のステップＳ２５０３で検索条件として与
えられた上記購買承認要求の分類と、購買承認サービス
登録情報の分類が、一致するか否か判断する。分類が一
致すると判断された場合、ステップＳ２５０５で該分類
が一致した承認サービスオブジェクトを取得して、要求
元のクライアント端末に渡し、検索成功として処理を終
了する。

【００９０】ステップＳ２５０３で分類が一致すると判
断されなかった場合、次のステップＳ２５０４で処理対
象を承認サービス登録情報に登録されている次の承認サ
ービスに進めて、再びステップＳ２５０２に戻る。

【００９１】クライアント端末は、実施形態１と同様に
図１５の処理を行うが、本実施形態２では、ステップＳ
１５０１の実行判断処理として、図２６に示す処理を行
うことになる。

【００９２】本実施形態２では、前述の購買承認サービ
スサーバから、購買承認要求に対応した購買承認サービ
スを検索した結果から、承認判定を行うべきか否かを判
断する。

【００９３】具体的には、まず購買承認判定実行判断処
理が起動されると、ステップＳ２６０１の購買承認サー
ビス検索処理により、サービスサーバに対して、購買承
認要求に対応した購買承認サービスを検索要求して、該
サービスサーバから検索結果を得る。その結果、次のス
テップＳ２６０２で検索成功と判断された場合、購買承
認判定実行として処理を終了する。

【００９４】他方、ステップＳ２６０２で検索成功と判
断されなかった場合、購買承認判定禁止として処理を終
了する。

【００９５】上記のステップにより、購買承認判定を行
うか否かの切り替えを、購買承認サービスが購買承認サ
ービスサーバに登録されているか否かで行うことができ
る。

【００９６】図２７から図３６は、図２６に示したステ
ップＳ２６０１の購買承認サービス検索処理で検索さ
れ、図１５に示したステップＳ１５０５の承認判定情報
適用処理で適用される、予算情報（すなわち、承認判定
情報の１つ）の一例を示す図である。

【００９７】具体的には、図２４で示したように、各予
算情報はそれぞれの承認サービスの一部となっている。
例えば、図２７に示した「ＭｕｓｉｃＦｌａｓｈ予算情
報」は「ＭｕｓｉｃＦｌａｓｈ承認サービス」の一部で
あり、その他図２８〜図３６に示した各予算情報も同様
である。また、本情報処理装置における各予算情報（図
２７〜図３６参照）には、要求機器毎に、それぞれの個
人予算枠と、機器自身の予算枠と、承認確認（図１５の
ステップＳ１５０８参照）が必要か否かを示すデータが
格納されている。

【００９８】ここで、前述の各図を用いて、サービスサ
ーバを利用した環境下で、ユーザの購買承認要求を生成
し、購買の承認を判断し、購買を実施する場合につい
て、具体的に説明する。

【００９９】既に図２０に示したように、購買承認者が
利用する購買承認サービスプロバイダで「音楽購買承認
サービス」の開始が指示されると図２１のステップＳ２
１０５の購買承認サービス登録処理により、図２０の２
００３のように「音楽購買承認サービス」が、サービス
サーバ２００１に登録される。

【０１００】図２０に示したように、購買承認要求者に
よりクライアント端末で購買承認要求生成開始が指示さ
れると、図８のステップＳ８０５の購買承認要求生成処
理により、購買承認要求が生成される。

【０１０１】例えば、操作ユーザ「太郎」が、操作機器
「コンポ」で、図１２に示したように名称「小さい秋
（３回再生分）」、分類「音楽」、金額「￥８０」、納
期「１９９９年１２月１５日」、優先度「８０」を入力
し、購買承認要求１２７を選択すると、図１３に示した
ような購買承認要求が作成される。

【０１０２】その結果、次のステップＳ８０６で購買承
認要求の生成が成功したと判断され、続くステップＳ８
０７の購買承認判定処理により、承認か否か判定され
る。図１５に示した購買承認判定処理におけるステップ
Ｓ１５０１の購買承認判定実行判断処理では、上記購買
承認要求に対応する購買承認サービスを、図２３で示し
たサービスサーバに登録されている購買承認サービス登
録情報から検索する。

【０１０３】前述の購買承認要求の場合、クライアント
端末は、分類「音楽」に対応して検索された「音楽承認
サービス」を取得する。次に、ステップＳ１５０３（図
１５参照）の承認判定情報検索処理により、図２８に示
した予算情報を参照した結果、要求機器「コンポ」が検
索される。その結果、次のステップＳ１５０４で検索成
功と判断され、続くステップＳ１５０５の承認判定情報
適用処理により、要求者「太郎」の予算枠￥０に、要求
金額￥８０を適用しようと試みるが、予算が足りないの
で失敗し、ステップＳ１５１１で購買が却下されたこと
を通知して、処理を終了する。

【０１０４】一方、図１４に示したような購買承認要求
の場合、クライアント端末は、分類「“ＭｕｓｉｃＦｌ
ａｓｈ”」に対応して検索された「ＭｕｓｉｃＦｌａｓ
ｈ承認サービス」を取得する。次に、ステップＳ１５０
３（図１５参照）の承認判定情報検索処理により、図２
７の予算情報を参照した結果、要求機器「コンポ」が検
索され、要求者「太郎」の予算枠￥２，０００に、要求
金額￥８０を適用しようと試みた結果、予算に収まるの
で成功する。更に、ステップＳ１５０７で承認確認の必
要性を判断した結果、図２７に「要」と指定されていな
いので不要と判断し、ステップＳ１５１０で購買が承認
されたことを通知して、処理を終了する。

【０１０５】なお、承認判定情報が変化したことを通知
する手段を設けることも可能である。

【０１０６】以上説明した通り本実施の形態２によれ
ば、サービスサーバに登録されている承認サービスを取
得して実行することで、承認判定者が多忙であるときに
は承認を得るまでに多くの時間を要するという従来の欠
点を解決することができ、クライアント端末に多くの承
認サービスを登録しておく必要もなくなる。

【０１０７】更に、サービスサーバへの登録・削除・更
新および検索処理を利用することで、より自由度の高い
操作が可能になる。例えば、承認者が在席中には承認サ
ービスを登録し、帰宅時には承認サービスを削除するこ
となどにより、重要な承認件が知らない間に自動承認さ
れることによるトラブルを避けることができる。

【０１０８】また、承認者が利用する端末としてカード
リーダを用いることも可能である。例えば、あらかじめ
承認対象の分類と予算枠を定めた承認サービスの情報を
格納したカードをカードリーダに差し込むと、そのイベ
ントを検知して承認サービスをサービスサーバに登録
し、上記カードをカードリーダから抜いた場合には承認
サービスをサービスサーバから削除するようなカードリ
ーダとカードを用いるようにしてもよい。また、この場
合、上記カード内には対応する承認サービスを直接格納
することなく、対応する承認サービスを特定する為の情
報だけを格納することも可能である。

【０１０９】更に加えて、上記それぞれの場合に、認証
に必要な情報を付与することも可能である。

【０１１０】＜実施の形態３＞図４に示すように、本実
施形態３では、購買承認要求の生成と、承認判定処理を
分離することで、より柔軟な運用を可能とする。

【０１１１】本実施形態３では、クライアント端末で生
成された承認要求を、リクエストサーバに登録し、リク
エストサーバにおいて承認判定処理を行うようにする。
また、リクエストサーバには、承認要求を登録・削除・
更新・検索する機能を持たせることで、かかる柔軟な運
用を実現する。また、リクエストサーバに承認要求を登
録しておけるので、複数の承認要求をまとめて処理する
ことができるようになる。

【０１１２】図３７は、図４で示した、購買承認要求者
が利用するクライアント端末、購買承認者が利用する承
認判定者用端末、および購買承認要求を登録管理するリ
クエストサーバ、承認サービスを登録管理するサービス
サーバ間の関係について、特にリクエストサーバに格納
される購買承認要求の例を、より詳細に示したものであ
る。

【０１１３】具体的には、下記のような流れで処理され
る。

【０１１４】１．実施形態２と同様に、サービスプロバ
イダが「承認サービス」をサービスサーバに登録する。

【０１１５】２．クライアント端末で生成された承認要
求を、リクエストサーバ３７０１に登録する。

【０１１６】３．リクエストサーバ３７０１は、登録さ
れた購買承認要求の承認判断を得る為、適切なタイミン
グで、該承認要求に対応する承認サービスをサービスサ
ーバから検索を行う。

【０１１７】４．上記検索の結果、リクエストサーバ３
７０１は検索された承認サービスを取得する。

【０１１８】５．リクエストサーバ３７０１は、取得し
た承認サービスを用いて、格納されている承認要求の判
断を行い、承認判断結果を、購買承認要求の要求元のク
ライアント端末に送る。

【０１１９】なお、この図３７だけでは、承認要求その
ものがリクエストサーバに直接格納されているように見
えるが、他のデバイスに存在する実体にアクセスする為
だけの情報が格納されていてもかまわない。

【０１２０】また、承認判断結果を承認要求者のほかに
承認判定者にも送るようにしても良い。

【０１２１】図３８は、購買承認要求を生成するクライ
アント端末での処理を示す流れ図である。具体的には、
まずシステムが起動されると、ステップＳ３８０１のシ
ステム起動処理でシステムが持つ各種デバイスやメモリ
などが初期化される。

【０１２２】続いて、ステップＳ３８０２でユーザから
の入力操作や、他の装置から情報の受信や、タイマから
の信号などの各種イベントが発生するのを待機する。

【０１２３】そこで、何らかのイベントが発生すると、
次のステップＳ３８０３で電源ＯＦＦを指示したイベン
トか否か判断される。その結果、電源ＯＦＦを指示して
いると判断された場合、ステップＳ３８１０のシステム
終了処理により、システムが持つ各種デバイスやメモリ
などの終了処理を実行後、本システムの処理を終了す
る。

【０１２４】ステップＳ３８０３で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ３８０
４で購買承認要求の生成開始を指示しているか否か判断
される。

【０１２５】ステップＳ３８０４で購買承認要求の生成
開始を指示していると判断された場合、次のステップＳ
３８０５の購買承認要求生成処理により、購買承認要求
が生成され、次のステップＳ３８０６で生成が成功した
か否かが判断される。その結果、生成が成功したと判断
されなかった場合は、再びステップＳ３８０２に戻る。

【０１２６】ステップＳ３８０６で生成が成功したと判
断された場合、次のステップＳ３８０７の購買承認要求
登録処理により、該生成された購買承認要求をリクエス
トサーバ３７０１に登録し、再びステップＳ３８０２に
戻る。

【０１２７】ステップＳ３８０４で購買承認要求の生成
開始を指示していると判断されなかった場合、次のステ
ップＳ３８０８で、リクエストサーバ３７０１から送ら
れた購買承認イベントか否かが判断される。その結果、
承認されたと判断されなかった場合は、再びステップＳ
３８０２に戻る。

【０１２８】ステップＳ３８０８で承認されたと判断さ
れた場合、次のステップＳ３８０９の購買実施処理によ
り、上記購買承認要求に対応した処理を実行し、再びス
テップＳ３８０２に戻る。

【０１２９】図３９は、購買承認要求を管理する、購買
承認リクエストサーバでの処理を示す図である。具体的
には、まず購買承認リクエストサーバが起動されると、
ステップＳ３９０１のシステム起動処理においてシステ
ムが持つ各種デバイスやメモリなどが初期化される。続
いて、ステップＳ３９０２の購買承認一括判定処理によ
り、後述する購買承認要求登録情報として格納された、
すべての購買承認要求に対して承認判定を行い、その結
果を要求元の要求者に通知する。

【０１３０】続いて、次のステップＳ３９０３でユーザ
からの入力操作や、他の装置から情報の受信や、タイマ
からの信号などの各種イベントが発生するのを待機す
る。そこで、何らかのイベントが発生すると、次のステ
ップＳ３９０４で電源ＯＦＦを指示したイベントか否か
判断される。その結果、電源ＯＦＦを指示していると判
断された場合、ステップＳ３９１０のシステム終了処理
により、システムが持つ各種デバイスやメモリなどの終
了処理を実行後、本システムの処理を終了する。

【０１３１】ステップＳ３９０４で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ３９０
５でイベントの種類が何か判断される。その結果、承認
要求に対する指示と判断されなかった場合、再びステッ
プＳ３９０２に戻る。

【０１３２】ステップＳ３９０５で承認要求の登録が指
示されたと判断した場合、ステップＳ３９０６の承認要
求登録処理により、クライアントから送信されてきた承
認要求を承認要求登録情報（図４０参照）に登録し、再
びステップＳ３９０２に戻る。

【０１３３】ステップＳ３９０５で承認要求の削除が指
示されたと判断した場合、ステップＳ３９０７の承認要
求削除処理により、対応する承認要求を承認要求登録情
報から削除し、再びステップＳ３９０２に戻る。

【０１３４】ステップＳ３９０５で承認要求の更新が指
示されたと判断した場合、ステップＳ３９０８の承認要
求更新処理により、承認要求登録情報として格納された
対応する承認要求を更新し、再びステップＳ３９０２に
戻る。

【０１３５】ステップＳ３９０５で承認要求の検索が指
示されたと判断した場合、ステップＳ３９０９の承認要
求検索処理により、対応する承認要求を承認要求登録情
報から検索し、要求元に渡し、再びステップＳ３９０２
に戻る。

【０１３６】図４０は、図３９に示したステップＳ３９
０２の購買承認一括判定処理において参照される、購買
承認要求登録情報の一例を示す図である。

【０１３７】本情報処理装置における購買承認要求登録
情報には、それぞれの購買承認要求を表すＩＤと、その
要求者、要求元、およびオブジェクトが格納されてい
る。ここで、オブジェクトとは、購買承認要求そのもの
でもかまわないし、他デバイスなどに存在する購買情報
要求にアクセスする為の情報であってもかまわない。

【０１３８】図４１は、図４０に示した購買承認要求登
録情報に格納されている、購買承認要求のオブジェクト
の一例を示す図であり、「小さい秋」購買承認要求の例
を詳細に表している。具体的には、購買承認要求のオブ
ジェクトには、名称、分類、金額など、購買承認要求の
データが格納されている。

【０１３９】図４２は、図３９に示したステップＳ３９
０２の購買承認一括判定処理のフローチャートである。

【０１４０】本実施形態では、所定の時刻になったり、
承認要求が所定数登録されたりすると、購買承認一括判
定処理が起動されるものとする。購買承認一括判定処理
が起動されると、購買承認要求登録情報に格納された、
すべての購買承認要求に対して承認判定を行い、その結
果を要求元の要求者に通知する。

【０１４１】具体的には、まず購買承認一括判定処理が
起動されると、ステップＳ４２０１で処理対象を上記購
買承認要求登録情報の先頭で初期化し、続くステップＳ
４２０２で処理対象が終了か否かを判断する。その結
果、すべての購買承認要求登録情報に対する処理を終了
したと判断すると、処理を終了する。

【０１４２】ステップＳ４２０２で処理対象が終了と判
断されなかった場合、ステップＳ４２０３の購買承認判
定処理により、処理対象の購買承認要求を承認するか否
かが判定される。そして、次のステップＳ４２０４で承
認されたか否か判断する。その結果、承認でも却下でも
なかった場合、ステップＳ４２０８で処理対象を進め、
再びステップＳ４２０２に戻り、処理を繰り返す。

【０１４３】ステップＳ４２０４で却下されたと判断し
た場合、ステップＳ４２０５で購買却下イベントを要求
元の要求者に通知し、ステップＳ４２０７で該処理対象
の承認要求を購買承認要求登録情報から削除した上で、
ステップＳ４２０８で処理対象を次の承認要求に進め、
再びステップＳ４２０２に戻る。

【０１４４】ステップＳ４２０４で承認されたと判断し
た場合、ステップＳ４２０６で購買承認イベントを要求
元の要求者に通知し、ステップＳ４２０７で該処理対象
の承認要求を購買承認要求登録情報から削除した上で、
ステップＳ４２０８で処理対象を次の承認要求に進め、
再びステップＳ４２０２に戻る。

【０１４５】図４３は、図４２に示したステップＳ４２
０３の購買承認判定処理のフローチャートである。

【０１４６】本情報処理装置における購買承認判定処理
では、承認判定を行うべきと判断された場合にのみ、承
認判定情報を検索し、適用することで、購買承認要求を
承認するか否かを判定する。具体的には、まず購買承認
判定処理が起動されると、ステップＳ４３０１の購買承
認判定実行判断処理により、処理対象の承認要求に対応
する承認サービスをサービスサーバから検索して取得
し、取得できたかどうかに基づいて承認判定処理を行う
べきか否か判断する。その結果、次のステップＳ４３０
２で承認判定を実行すべきと判断されなかった場合、承
認判定結果不明として処理を終了する。

【０１４７】ステップＳ４３０２で承認判定を実行すべ
きと判断された場合、次のステップＳ４３０３の承認判
定情報検索処理により、処理対象の購買承認要求に対応
した承認判定情報を検索する。その結果、次のステップ
Ｓ４３０４で検索成功と判断されなかった場合、ステッ
プＳ４３１１に進み、購買却下通知処理により、購買承
認要求が却下されたことをクライアント端末に通知し、
却下として処理を終了する。

【０１４８】ステップＳ４３０４で検索成功と判断され
た場合、次のステップＳ４３０５の承認判定情報適用処
理により、購買承認要求を上記承認判定情報に適用す
る。その結果、次のステップＳ４３０６で、適用成功と
判断されなかった場合、ステップＳ４３１１に進み、購
買却下通知処理により、購買承認要求が却下されたこと
をクライアント端末に通知し、却下として処理を終了す
る。

【０１４９】ステップＳ４３０６で適用成功と判断され
た場合、次のステップＳ４３０７で承認者に確認する必
要があるか否かを判断する。その結果、確認する必要が
あると判断された場合、ステップＳ４３０８の承認確認
処理により承認を確認する。その確認結果、次のステッ
プＳ４３０９で承認されたと判断されなかった場合、ス
テップＳ４３１１に進み、購買却下通知処理により、購
買承認要求が却下されたことをクライアント端末に通知
し、却下として処理を終了する。

【０１５０】ステップＳ４３０７で承認者に確認する必
要が無いと判断された場合、あるいはステップＳ４３０
９で承認者が確認した結果、承認されたと判断された場
合、ステップＳ４３１０の購買承認通知処理により、購
買承認要求が承認されたことをクライアント端末に通知
し、承認として処理を終了する。

【０１５１】ここで、前述の各図を用いて、リクエスト
サーバを利用した環境下で、ユーザの購買承認要求を生
成し、購買の承認を判断し、購買を実施する場合につい
て、具体的に説明する。

【０１５２】先に述べた図３７のように、クライアント
端末で購買承認要求生成開始が指示されると、図３８の
ステップＳ３８０５の購買承認要求生成処理により、購
買承認要求が生成される。

【０１５３】例えば、操作ユーザ「太郎」が、操作機器
「コンポ」で、図１２に示したように名称「小さい秋
（３回再生分）」、分類「音楽」、金額「￥８０」、納
期「１９９９年１２月１５日」、優先度「８０」を入力
し、購買承認要求１２７を選択すると、図１３に示した
ような購買承認要求が作成される。

【０１５４】その結果、次のステップＳ３８０６で購買
承認要求の生成が成功したと判断され、続くステップＳ
３８０７の購買承認要求登録処理により、図３７の３７
０２のように「「小さい秋」購買承認要求」が、リクエ
ストサーバ３７０１に登録される。

【０１５５】これに対して、購買承認リクエストサーバ
３７０１では、クライアント端末から購買承認要求の登
録が指示されたと判断し、図４０および図４１のように
上記購買承認要求を購買承認要求登録情報に登録する
（Ｓ３９０６）。その後、ステップＳ３９０２の購買承
認一括判定処理により、上記購買承認要求登録情報に格
納された、それぞれの購買承認要求について、承認か否
か判定される。

【０１５６】具体的には、個々の購買承認要求につい
て、ステップＳ４２０３の購買承認判定処理により、承
認か否か判定される。

【０１５７】その際、図４３に示した購買承認判定処理
におけるステップＳ４３０１の購買承認判定実行判断処
理では、上記購買承認要求に対応する購買承認サービス
を、図２３で示したサービスサーバが持つ購買承認サー
ビス登録情報から検索する。

【０１５８】図１３の購買承認要求の場合、分類「音
楽」に対応して検索された「音楽承認サービス」が提供
するメソッドである。ステップＳ４３０３の承認判定情
報検索処理により、図２８の予算情報を参照した結果、
要求機器「コンポ」が検索される。その結果、次のステ
ップＳ４３０４で検索成功と判断され、続くステップＳ
４３０５の承認判定情報適用処理により、要求者「太
郎」の予算枠￥０に、要求金額￥８０を適用しようと試
みるが、予算が足りないので失敗し、ステップＳ４３１
１で購買が却下されたことを通知して、処理を終了す
る。

【０１５９】一方、図１４に示したような購買承認要求
の場合、分類「“ＭｕｓｉｃＦｌａｓｈ”」に対応して
検索された「ＭｕｓｉｃＦｌａｓｈ承認サービス」が提
供するメソッドである。ステップＳ４３０３の承認判定
情報検索処理により、図２７の予算情報を参照した結
果、要求機器「コンポ」が検索され、ステップＳ４３０
５ｎｏ承認判定情報適用処理により、要求者「太郎」の
予算枠￥２，０００に、要求金額￥８０を適用しようと
試みた結果、予算に収まるので成功する。更に、ステッ
プＳ４３０７で承認確認の必要性を判断した結果、
「要」と指定されていないので不要と判断し、ステップ
Ｓ４３１０で購買が承認されたことを通知して、処理を
終了する。

【０１６０】以上説明した通り本実施の形態によれば、
複数の承認要求を格納するリクエストサーバを設けるこ
とにより、承認要求生成処理と承認要求判定処理とを、
異なる機器に分散することができ、より柔軟な運用が可
能となる。これにより、個々のクライアント端末が、承
認要求が発生するたびに、承認判定処理を行わずに済む
ようになる。

【０１６１】また、リクエストサーバに対する登録・削
除・更新・検索を利用することで、より自由度の高い操
作が可能となる。例えば、複数のクライアント端末から
の購買承認要求をまとめて、承認判定することもできる
ようになる。

【０１６２】また、所定の時刻毎や日毎に、承認判定を
行うようにすることもでき、承認判定処理が行われる前
であれば変更やキャンセルをすることも可能である。

【０１６３】また、承認者が不在中には、承認判定処理
を行わずに購買承認要求をストックしておき、承認判定
者が戻ってくると、承認判定処理を実行するように構成
することも可能である。

【０１６４】＜実施の形態４＞本実施の形態４では、最
初の承認サービスの検索時には必要とされる承認サービ
スがサービスサーバに存在せずに、後からサービスサー
バに承認サービスが追加された場合、該追加された承認
サービスを用いて承認要求判定処理を実行できる実施形
態を示す。

【０１６５】図５は、購買承認要求者が利用するクライ
アント端末、購買承認者が利用する承認判定者用端末
（サービスプロバイダ）、購買承認サービスを登録管理
するサービスサーバ、および購買承認要求を登録管理す
るリクエストサーバ間の関係を示したものである。

【０１６６】本実施の形態４では、具体的に下記のよう
な流れで処理がなされる。

【０１６７】１．クライアント端末で生成された購買承
認要求を購買承認リクエストサーバに登録する。そし
て、リクエストサーバは、承認サービスの検索を行う
が、この最初の検索では所望の承認サービスが見つから
なかったとして、該承認要求を承認要求格納部に格納し
ておくこととする。

【０１６８】２．購買承認判定者がサービスプロバイダ
を用いて、購買承認サービスを購買承認サービスサーバ
に登録する。

【０１６９】３．購買承認サービスサーバは、購買承認
サービスが登録されると、購買承認サービス登録イベン
トを購買承認リクエストサーバに通知する。

【０１７０】４．購買承認リクエストサーバは、承認サ
ービス登録イベントの通知を受けると、承認要求格納部
に登録されている各購買承認要求に対応する購買承認サ
ービスを、購買承認サービスサーバから検索する。

【０１７１】５．承認サービスの検索に成功した場合、
該承認サービスを取得して、承認要求の判定を行う。

【０１７２】６．取得された購買承認サービスを用いて
承認判定を行った結果を、該購買承認要求の要求元のク
ライアント端末に通知する。

【０１７３】なお、上記の処理では購買承認リクエスト
サーバが購買承認サービスサーバから、購買承認サービ
スそのものを取得してから処理を行っているように説明
してあるが、処理に必要な情報のみを取得しても良い。

【０１７４】図４４は、図５で説明した購買承認判定者
が利用するサービスプロバイダから購買承認サービスを
購買承認サービスサーバに登録する例として、購買承認
判定者がサービスプロバイダシステムへログイン・ログ
アウトする操作に連動させた様子を示している。

【０１７５】具体的には、まず購買承認判定者が購買承
認サービスプロバイダ４４１６を操作すると、ログイン
画面４４１８が表示される。そこで、購買承認判定者が
ユーザ名４４１２およびパスワード４４１３を入力し、
ログインボタン４４１５を押すと、購買承認サービスプ
ロバイダ４４１６にログインすると共に、自動的に承認
サービス登録処理が起動され、ログインした購買承認判
定者に対応した購買承認サービス４４０３が、購買承認
サービスサーバ４４１７に登録される。また、購買承認
判定者がログアウトボタン４４１４を押すと、購買承認
サービスプロバイダ４４１６の承認サービス削除処理が
自動的に起動され、購買承認判定者に対応した購買承認
サービス４４０３が、購買承認サービスサーバ４４１７
から削除される。

【０１７６】図４５は、購買承認判定者のログイン・ロ
グアウトの操作に連動して、購買承認サービスの開始と
終了を制御する購買承認サービスプロバイダ４４１６で
の処理を示す図である。具体的には、まず購買承認サー
ビスプロバイダ４４１６が起動されると、ステップＳ４
５０１のシステム起動処理でシステムが持つ各種デバイ
スやメモリなどが初期化される。続いて、ステップＳ４
５０２でユーザからの入力操作や、他の装置から情報の
受信や、タイマからの信号などの各種イベントが発生す
るのを待機する。

【０１７７】そこで、何らかのイベントが発生すると、
次のステップＳ４５０３で電源ＯＦＦを指示したイベン
トか否かが判断される。その結果、電源ＯＦＦを指示し
ていると判断された場合、ステップＳ４５０９のシステ
ム終了処理により、システムが持つ各種デバイスやメモ
リなどの終了処理を実行後、本システムの処理を終了す
る。

【０１７８】ステップＳ４５０３で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ４５０
４でログイン・ログアウトに対する指示か否か判断され
る。その結果、ログイン・ログアウトに対する指示と判
断されなかった場合、再びステップＳ４５０２に戻る。

【０１７９】ステップＳ４５０４でログインが指示され
たと判断した場合、ステップＳ４５０５の承認サービス
取得処理により、後述する購買承認者対応情報を参照
し、ログインした購買承認判定者に対応した購買承認サ
ービス情報を全て取得する。続くステップＳ４５０６の
承認サービス登録処理により、該取得した承認サービス
をサービスサーバ４４１７（図４４参照）に登録し、再
びステップＳ４５０２に戻る。

【０１８０】ステップＳ４５０４でログアウトが指示さ
れたと判断した場合、ステップＳ４５０７の承認サービ
ス取得処理により、後述する購買承認者対応情報を参照
し、ログアウトした購買承認判定者に対応した購買承認
サービス情報を全て取得する。続くステップＳ４５０８
の承認サービス削除処理により、取得した購買承認サー
ビス情報に対応する承認サービスをサービスサーバ４４
１７から削除し、再びステップＳ４５０２に戻る。

【０１８１】図４６は、図４５に示したステップＳ４５
０５およびステップＳ４５０７の承認サービス取得処理
で参照される、購買承認者対応情報の一例を示す図であ
る。

【０１８２】本情報処理装置における購買承認者対応情
報には、購買承認判定者と、それぞれの購買承認判定者
に対応する購買承認サービスが定義されている。例え
ば、購買承認判定者「Ｔａｋａｈａｓｈｉ」には購買承
認サービス「ＭｕｓｉｃＦｌａｓｈ承認サービス」が対
応づけられており、購買承認判定者「Ｓｕｚｕｋｉ」に
は購買承認サービス「ニュース承認サービス」および
「ドラマ承認サービス」が対応づけられている。

【０１８３】図４７は、購買承認サービス登録イベント
を購買承認リクエストサーバに通知することができる、
購買承認サービスサーバ４４１７（図４４参照）での処
理を示す図である。具体的には、購買承認サービスサー
バが起動されると、ステップＳ４７０１のシステム起動
処理でシステムが持つ各種デバイスやメモリなどが初期
される。続いて、ステップＳ４７０２でユーザからの入
力操作や、他の装置から情報の受信や、タイマからの信
号などの各種イベントが発生するのを待機する。

【０１８４】そこで、何からのイベントが発生すると、
次のステップＳ４７０３で電源ＯＦＦを指示したイベン
トか否かが判断される。その結果、電源ＯＦＦを指示し
ていると判断された場合、ステップＳ４７１０のシステ
ム終了処理により、システムが持つ各種デバイスやメモ
リなどの終了処理を実行後、本システムの処理を終了す
る。

【０１８５】ステップＳ４７０３で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ４７０
４でイベントの種類が何か判断される。その結果、承認
サービスに対する指示と判断されなかった場合、再びス
テップＳ４７０２に戻る。

【０１８６】ステップＳ４７０４で承認サービスの登録
が指示されたと判断した場合、ステップＳ４７０５の承
認サービス登録処理により、サービスプロバイダから送
信された承認サービスを承認サービス登録情報に登録
し、次のステップＳ４７０６で購買承認サービス登録イ
ベントを購買承認リクエストサーバに通知し、再びステ
ップＳ４７０２に戻る。

【０１８７】ステップＳ４７０４で承認サービスの削除
が指示されたと判断した場合、ステップＳ４７０７の承
認サービス削除処理により、対応する承認サービスを承
認サービス登録情報から削除し、再びステップＳ４７０
２に戻る。

【０１８８】ステップＳ４７０４で承認サービスの更新
が指示されたと判断した場合、ステップＳ４７０８の承
認サービス更新処理により、承認サービス登録情報に格
納された対応する承認サービスを更新し、再びステップ
Ｓ４７０２に戻る。

【０１８９】ステップＳ４７０４で承認サービスの検索
が指示されたと判断した場合、ステップＳ４７０９の承
認サービス検索処理により、対応する承認サービスを承
認サービス登録情報から検索して、要求元に渡し、再び
ステップＳ４７０２に戻る。

【０１９０】ここで、図５および図４４に示したよう
に、最初は対応する購買承認サービスが存在しない状態
で購買承認要求がリクエストサーバに登録された後、購
買承認判定者がログインしたことで、対応する購買承認
サービスがサービスサーバに登録された場合について、
具体的に説明する。

【０１９１】図５で示したように、クライアント端末で
購買承認要求生成開始が指示されると、図３８のステッ
プＳ３８０５の購買承認要求生成処理により、購買承認
要求が生成される。

【０１９２】例えば、操作ユーザ「太郎」が、操作機器
「コンポ」で、図１２に示したように名称「小さい秋
（３回再生分）」、分類「音楽」、金額「￥８０」、納
期「１９９９年１２月１５日」、優先度「８０」を入力
し、購買承認要求１２７を選択すると、図１３に示した
ような購買承認要求が作成される。

【０１９３】その結果、次のステップＳ３８０６で購買
承認要求の生成が成功したと判断され、続くステップＳ
３８０７の購買承認要求登録処理により、「「小さい
秋」購買要求」が、リクエストサーバに登録される。

【０１９４】これに対して、購買承認リクエストサーバ
では、クライアント端末の、購買承認要求登録処理に対
応したイベントをステップＳ３９０３で受け取り、ステ
ップＳ３９０５で登録を指示するイベントと判断し、図
４０および図４１のように上記購買承認要求を購買承認
要求登録情報に登録する。その後、ステップＳ３９０２
の購買承認一括判定処理により、上記購買承認要求登録
情報に格納された、それぞれの購買承認要求について、
承認か否かが判定される。具体的には、個々の購買承認
要求について、ステップＳ４２０３の購買承認判定処理
により、承認か否か判定される。

【０１９５】前述の購買承認要求の場合、購買承認判定
処理のステップＳ４３０１の購買承認判定実行判断処理
で、上記購買承認要求に対応する購買承認サービスをサ
ービスサーバが持つ購買承認サービス登録情報から検索
した結果、上記購買承認要求の分類「音楽」に対応する
購買承認サービスが見つからないので、ステップＳ４２
０４で処理をスキップし、承認判定を保留しておく。

【０１９６】その後、図５および図４４のように、購買
承認サービスプロバイダで購買承認判定者「Ｙａｍａｄ
ａ」がシステムにログインすると、図４５のステップＳ
４５０４でログインが指示されたと判断して、次のステ
ップＳ４５０５の購買承認サービス取得処理により、購
買承認者対応情報を参照した結果、「音楽承認サービ
ス」が取得される。続く、ステップＳ４５０６の購買承
認サービス登録処理により、図４４の４４０３のように
「音楽承認サービス」が、購買承認サービスサーバ４４
１７に登録される。

【０１９７】これにより、購買承認サービスサーバのス
テップＳ４７０４で購買承認サービスの登録が指示され
たと判断し、ステップＳ４７０５でサービスプロバイダ
から送信されてきた承認サービスを登録した後、続くス
テップＳ４７０６で購買承認サービス登録イベントを、
購買承認リクエストサーバに通知する。

【０１９８】上記購買承認サービス登録イベントを受信
した購買承認リクエストサーバでは、再び、ステップＳ
３９０２の購買承認一括判定処理により、上記購買承認
要求登録情報に格納された、それぞれの購買承認要求に
ついて、承認か否か判定される。まず、承認サービス検
索処理により、上記購買承認要求の分類「音楽」に対応
する購買承認サービスを検索し、分類「音楽」に対応し
て検索された「音楽承認サービス」を取得する。ステッ
プＳ４３０３の承認判定情報検索処理により、音楽承認
サービスの判定条件である図２８の予算情報を参照した
結果、要求機器「コンポ」が検索される。

【０１９９】その結果、次のステップＳ４３０４で検索
成功と判断され、続くステップＳ４３０５の承認判定情
報適用処理により、分類「音楽」、要求者「太郎」、要
求機器「コンポ」の予算枠￥０に、要求金額￥８０を適
用しようと試みるが、予算が足りないので失敗し、ステ
ップＳ４３１１で購買が却下されたことを通知する。

【０２００】一方、図１４に示したような購買承認要求
の場合、分類「“ＭｕｓｉｃＦｌａｓｈ”」に対応して
検索された「ＭｕｓｉｃＦｌａｓｈ承認サービス」を取
得する。ステップＳ４３０３の承認判定情報検索処理に
より、図２７の予算情報を参照した結果、要求機器「コ
ンポ」、要求者「太郎」の予算枠￥２，０００に、要求
金額￥８０を適用しようと試みた結果、予算に収まるの
で成功する。更に、ステップＳ４３０７で承認確認の必
要性を判断した結果、「要」と指定されていないので不
要と判断し、ステップＳ４３１０で購買が承認されたこ
とを通知して、処理を終了する。

【０２０１】以上説明した通り本実施の形態によれば、
購買承認リクエストサーバに購買承認要求を登録した時
に、対応する購買承認サービスが存在せずに、承認判定
が行えなかったとしても、その後、購買承認サービスが
購買承認サービスサーバに登録されたことに対応して、
承認判定を行うことが可能となる。

【０２０２】これにより、承認要求者は、承認サービス
が登録されるのを待つことなく、承認要求を出すことが
できる。

【０２０３】例えば、複数の承認要求者の購買承認要求
をまとめて、承認判定者に承認してもらうこともでき
る。また、承認者が不在中には、承認判定処理を行わず
に購買承認要求をストックしておき、承認判定者が戻っ
てきてログインすると、承認判定処理を実行するように
構成することも可能である。

【０２０４】＜実施の形態５＞上述した実施の形態４で
は、購買承認者のログイン・ログアウトの操作に連動し
て、購買承認サービスを登録・削除する例について説明
したが、本実施形態５では購買承認サービスを内包した
購買承認カードを用いたシステムについて、具体的に説
明する。

【０２０５】図４８は、図５で説明した購買承認判定者
が購買承認サービスを購買承認サービスサーバに登録・
削除する例として、購買承認サービスを内包した購買承
認カードの挿入・取り出しの操作に連動させた様子を示
している。

【０２０６】具体的には、購買承認判定者が購買承認サ
ービスプロバイダ４８１６に購買承認カード４８１２を
挿入すると、購買承認サービスプロバイダ４８１６の承
認サービス登録処理により、購買承認カード４８１２に
格納された購買承認サービス４８１３が、購買承認サー
ビスサーバ４８１７に登録される。また、購買承認判定
者が購買承認カード４８１２を取り出すと、購買承認サ
ービスプロバイダ４８１６の承認サービス削除処理によ
り、対応する購買承認サービス４８１３が、購買承認サ
ービスサーバ４８１７から削除される。

【０２０７】なお、上記の例では、購買承認カード４８
１２には、１つの購買承認サービスしか格納されていな
いように記述されているが、複数の購買承認サービスを
格納し、購買承認カード４８１２の挿入および取り出し
により、複数の購買承認サービスの登録・削除を行わせ
ることも可能である。

【０２０８】図４９は、購買承認サービスプロバイダで
の処理を示す図である。

【０２０９】具体的には、まず購買承認サービスプロバ
イダが起動されると、ステップＳ４９０１のシステム起
動処理でシステムが持つ各種デバイスやメモリなどが初
期化される。続いて、ステップＳ４９０２でユーザから
の入力操作や、他の装置から情報の受信や、タイマから
の信号などの各種イベントが発生するのを待機する。

【０２１０】そこで、何らかのイベントが発生すると、
次のステップＳ４９０３で電源ＯＦＦを指示したイベン
トか否かが判断される。その結果、電源ＯＦＦが指示さ
れたと判断した場合、ステップＳ４９０９のシステム終
了処理により、システムが持つ各種デバイスやメモリな
どの終了処理を実行後、本システムの処理を終了する。

【０２１１】ステップＳ４９０３で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ４９０
４で購買承認カードの挿入・取り出しの操作か否かが判
断される。その結果、購買承認カードの挿入・取り出し
の操作と判断されなかった場合、再びステップＳ４９０
２に戻る。

【０２１２】ステップＳ４９０４で購買承認カードの挿
入操作と判断された場合、ステップＳ４９０５の承認サ
ービス読み込み処理により、購買承認カードに格納され
ている承認サービスが読み込まれる。続くステップＳ４
９０６の承認サービス登録処理により、読み込まれた承
認サービスをサービスサーバ４８１７に登録し、再びス
テップＳ４９０２に戻る。

【０２１３】ステップＳ４９０４で購買承認カードの取
り出し操作と判断された場合、ステップＳ４９０７の承
認サービス読み込み処理により、購買承認カードに格納
されている承認サービスが読み込まれる。続くステップ
Ｓ４９０８の承認サービス削除処理により、対応する承
認サービスをサービスサーバ４８１７から削除し、再び
ステップＳ４９０２に戻る。

【０２１４】ここで、図５及び図４８に示したように、
最初は対応する購買承認サービスが存在しない状態で購
買承認要求がリクエストサーバに登録された後、購買承
認カードが挿入されることで、対応する購買承認サービ
スがサービスサーバに登録された場合について、具体的
に説明する。

【０２１５】図５のように、クライアント端末で購買承
認要求生成開始が指示されると、図３８のステップＳ３
８０５の購買承認要求生成処理により、購買承認要求が
生成される。

【０２１６】例えば、操作ユーザ「太郎」が、操作機器
「コンポ」で、図１２に示したように名称「小さい秋
（３回再生分）」、分類「音楽」、金額「￥８０」、納
期「１９９９年１２月１５日」、優先度「８０」を入力
し、購買承認要求１２７を選択すると、図１３に示した
ような購買承認要求が作成される。

【０２１７】その結果、次のステップＳ３８０６で購買
承認要求の生成が成功したと判断され、続くステップＳ
３８０７の購買承認要求登録処理により、「「小さい
秋」購買要求」が、リクエストサーバに登録される。

【０２１８】これに対して、購買承認リクエストサーバ
では、クライアント端末の、購買承認要求登録処理に対
応したイベントをステップＳ３９０３で受け取り、ステ
ップＳ３９０５で登録を指示するイベントと判断し、図
４０および図４１のように上記購買承認要求を購買承認
要求登録情報に登録する。その後、ステップＳ３９０２
の購買承認一括判定処理により、上記購買承認要求登録
情報に格納された、それぞれの購買承認要求について、
承認か否かが判定される。具体的には、個々の購買承認
要求について、ステップＳ４２０３の購買承認判定処理
により、承認か否か判定される。

【０２１９】前述の購買承認要求の場合、購買承認判定
処理のステップＳ４３０１の購買承認判定実行判断処理
で、上記購買承認要求に対応する購買承認サービスをサ
ービスサーバが持つ購買承認サービス登録情報から検索
した結果、上記購買承認要求の分類「音楽」に対応する
購買承認サービスが見つからないので、ステップＳ４２
０４で処理をスキップし、承認判定を保留しておく。

【０２２０】その後、図５および図４８のように、購買
承認サービスプロバイダ４８１６に、購買承認カード４
８１２が挿入されると、図４９のステップＳ４９０４で
購買承認カードが挿入されたと判断して、次のステップ
Ｓ４９０５の購買承認サービス読み込み処理により、購
買承認カードに格納されている承認サービスが読み込ま
れる。そして、ステップＳ４９０６の購買承認サービス
登録処理により、図４８の４８０３のように「音楽承認
サービス」が、購買承認サービスサーバ４８１７に登録
される。

【０２２１】これにより、購買承認サービスサーバのス
テップＳ４７０４で購買承認サービスの登録が指示され
たと判断し、ステップＳ４７０５でサービスプロバイダ
から送信されてきた承認サービスを登録した後、続くス
テップＳ４７０６で購買承認サービス登録イベントを、
購買承認リクエストサーバに通知する。

【０２２２】上記購買承認サービス登録イベントを受信
した購買承認リクエストサーバでは、再び、ステップＳ
３９０２の購買承認一括判定処理により、上記購買承認
要求登録情報に格納された、それぞれの購買承認要求に
ついて、承認か否かが判定される。まず、承認サービス
検索処理により、上記購買承認要求の分類「音楽」に対
応する購買承認サービスを検索し、分類「音楽」に対応
して検索された「音楽承認サービス」を取得する。ステ
ップＳ４３０３の承認判定情報検索処理により、音楽承
認サービスの判定条件である図５０の予算情報５０１３
を参照した結果、要求機器「コンポ」が検索される。

【０２２３】その結果、次のステップＳ４３０４で検索
成功と判断され、続くステップＳ４３０５の承認判定情
報適用処理により、分類「音楽」、要求者「太郎」、要
求機器「コンポ」の予算枠￥０に、要求金額￥８０を適
用しようと試みるが、予算が足りないので失敗し、ステ
ップＳ４３１１で購買が却下されたことを通知する。

【０２２４】一方、図１４に示したような購買承認要求
の場合、分類「“ＭｕｓｉｃＦｌａｓｈ”」に対応して
検索された「ＭｕｓｉｃＦｌａｓｈ承認サービス」を取
得する。ステップＳ４３０３の承認判定情報検索処理に
より、図２７の予算情報を参照した結果、要求機器「コ
ンポ」、要求者「太郎」の予算枠￥２，０００に、要求
金額￥８０を適用しようと試みた結果、予算に収まるの
で成功する。更に、ステップＳ４３０７で承認確認の必
要性を判断した結果、「要」と指定されていないので不
要と判断し、ステップＳ４３１０で購買が承認されたこ
とを通知して、処理を終了する。

【０２２５】以上説明した通り本実施の形態５によれ
ば、購買承認リクエストサーバに購買承認要求を登録し
た時に、対応する購買承認サービスが存在せずに、承認
判定が行えなかったとしても、その後、購買承認カード
が挿入されるのに連動してサービスサーバに追加された
購買承認サービスを用いて、承認判定を行うことが可能
となる。このように、購買承認サービスの登録・削除の
制御を、購買承認カードで容易に行うことができる。

【０２２６】＜実施の形態６＞上述した実施の形態５で
は、購買承認カードに購買承認サービスのメソッドと判
定に用いる条件データとを格納していたが、本実施形態
６では、購買承認カードには購買承認サービスの条件デ
ータだけが格納されているものとする。

【０２２７】図５０は、図５で説明した購買承認判定者
が購買承認サービスを購買承認サービスサーバに登録・
削除する例として、購買承認サービスに必要な情報を内
包した購買承認カードの挿入・取り出しの操作に連動さ
せた様子を示している。具体的には、まず購買承認判定
者が購買承認サービスプロバイダ５０１６に購買承認カ
ード５０１２を挿入すると、購買承認サービスプロバイ
ダ５０１６の承認サービス登録処理により、購買承認カ
ード５０１２に格納された購買承認サービスに必要な情
報５０１３から、購買承認サービスを生成し、購買承認
サービスサーバ５０１７に登録される。また、購買承認
判定者が購買承認カード５０１２を取り出すと、購買承
認サービスプロバイダ５０１６の承認サービス削除処理
により、対応する購買承認サービスが、購買承認サービ
スサーバ５０１７から削除される。

【０２２８】なお、上記の例では、購買承認カード５０
１２には、１つの購買承認サービスに必要な情報しか格
納されていないように記述されているが、複数の購買承
認サービスに必要な情報を格納し、購買承認カード５０
１２の挿入および取り出しにより、複数の購買承認サー
ビスを生成し、登録・削除を行わせることも可能であ
る。

【０２２９】図５１は購買承認サービスプロバイダ５０
１６での処理を示す図である。具体的には、まず購買承
認サービスプロバイダが起動されると、ステップＳ５１
０１のシステム起動処理でシステムが持つ各種デバイス
やメモリなどが初期化される。続いて、ステップＳ５１
０２でユーザからの入力操作や、他の装置から情報の受
信や、タイマからの信号などの各種イベントが発生する
のを待機する。

【０２３０】そこで、何らかのイベントが発生すると、
次のステップＳ５１０３で電源ＯＦＦを指示したイベン
トか否か判断される。その結果、電源ＯＦＦが指示され
たと判断した場合、ステップＳ５１１０のシステム終了
処理により、システムが持つ各種デバイスやメモリなど
の終了処理を実行後、本システムの処理を終了する。

【０２３１】ステップＳ５１０３で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ５１０
４で購買承認カードの挿入・取り出しの操作か否か判断
される。その結果、購買承認カードの挿入・取り出しの
操作と判断されなかった場合、再びステップＳ５１０２
に戻る。

【０２３２】ステップＳ５１０４で購買承認カードの挿
入操作と判断された場合、ステップＳ５１０５の承認サ
ービス情報読み込み処理により、購買承認カードに格納
されている購買承認サービスに必要な情報が読み込ま
れ、次のステップＳ５１０６の承認サービス生成処理に
より、上記購買承認サービスに必要な情報を持った購買
承認サービスオブジェクトを生成し、後述する生成済み
購買承認サービス情報として格納する。更に、続くステ
ップＳ５１０７の承認サービス登録処理により、生成さ
れた承認サービスをサービスサーバ５０１７に登録し、
再びステップＳ５１０２に戻る。

【０２３３】ステップＳ５１０４で購買承認カードの取
り出し操作と判断された場合、ステップＳ５１０８の生
成済み承認サービス取得処理により、上記生成された購
買承認サービスを、後述する生成済み購買承認サービス
情報を参照することで、取得する。続くステップＳ５１
０９の承認サービス削除処理により、上記取得された承
認サービスをサービスサーバ５０１７から削除し、再び
ステップＳ５１０２に戻る。

【０２３４】図５２は、図５１に示したステップＳ５１
０６の購買承認サービス生成処理を示す図である。

【０２３５】購買承認サービス生成処理では、購買承認
サービスに必要な情報を持った購買承認サービスオブジ
ェクトを生成し、後述する生成済み購買承認サービス情
報として格納する。

【０２３６】具体的には、まず購買承認サービス生成処
理が起動されると、ステップＳ５２０１で、読み込まれ
た購買承認サービスに必要な情報中に格納された、分類
に対応したメソッドを有する空の購買承認サービスオブ
ジェクトを生成する。

【０２３７】次のステップＳ５２０２では、購買承認カ
ードから読み込まれた購買承認サービスに必要な情報
を、上記購買承認サービスオブジェクトに格納する。

【０２３８】次のステップＳ５２０３では、上記生成さ
れた購買承認サービスオブジェクトを後述する生成済み
購買承認サービス情報に格納し、処理を終了する。

【０２３９】図５３は、図５２のステップＳ５２０３で
生成された購買承認サービスオブジェクトが格納された
生成済み購買承認サービス情報の一例を示す図である。

【０２４０】本情報処理装置における生成済み購買承認
サービス情報には、ＩＤおよびその分類と対応する購買
承認サービスオブジェクトが、対応づけられて格納され
ている。

【０２４１】ここで、図５及び図５０に示したように、
最初は対応する購買承認サービスが存在しない状態で購
買承認要求がリクエストサーバに登録された後、購買承
認カードが挿入されることで、対応する購買承認サービ
スがサービスサーバに登録された場合について、具体的
に説明する。

【０２４２】図５のように、クライアント端末で購買承
認要求生成開始が指示されると、図３８のステップＳ３
８０５の購買承認要求生成処理により、購買承認要求が
生成される。例えば、操作ユーザ「太郎」が、操作機器
「コンポ」で、図１２に示したように名称「小さい秋
（３回再生分）」、分類「音楽」、金額「￥８０」、納
期「１９９９年１２月１５日」、優先度「８０」を入力
し、購買承認要求１２７を選択すると、図１３に示した
ような購買承認要求が作成される。

【０２４３】その結果、次のステップＳ３８０６で購買
承認要求の生成が成功したと判断され、続くステップＳ
３８０７の購買承認要求登録処理により、「「小さい
秋」購買要求」が、リクエストサーバに登録される。

【０２４４】これに対して、購買承認リクエストサーバ
では、クライアント端末の、購買承認要求登録処理に対
応したイベントをステップＳ３９０３で受け取り、ステ
ップＳ３９０５で登録を指示するイベントと判断し、図
４０および図４１のように上記購買承認要求を購買承認
要求登録情報として登録する。その後、ステップＳ３９
０２の購買承認一括判定処理により、上記購買承認要求
登録情報に格納された、それぞれの購買承認要求につい
て、承認か否か判定される。具体的には、個々の購買承
認要求について、ステップＳ４２０３の購買承認判定処
理により、承認か否か判定される。

【０２４５】前述の購買承認要求の場合、購買承認判定
処理のステップＳ４３０１の購買承認判定実行判断処理
で、上記購買承認要求に対応する購買承認サービスをサ
ービスサーバが持つ購買承認サービス登録情報から検索
した結果、上記購買承認要汲フ分類「音楽」に対応する
購買承認サービスが見つからないので、ステップＳ４２
０４で処理をスキップし、承認判定を保留しておく。

【０２４６】その後、図５および図５０のように、購買
承認サービスプロバイダ５０１６に、購買承認カード５
０１２が挿入されると、図５１のステップＳ５１０４で
購買承認カードが挿入されたと判断して、次のステップ
Ｓ５１０５の購買承認サービス情報読み込み処理によ
り、購買承認カードに格納されている承認サービスに必
要な情報が読み込まれ、続くステップＳ５１０６の承認
サービス生成処理により、対応する購買承認サービスが
生成される。そして、続くステップＳ５１０７の購買承
認サービス登録処理により、図５０の５００３のように
「音楽承認サービス」が、購買承認サービスサーバ５０
１７に登録される。

【０２４７】これにより、購買承認サービスサーバのス
テップＳ４７０４で購買承認サービスの登録が指示され
たと判断し、ステップＳ４７０５でサービスプロバイダ
から送信されてきた承認サービスを登録した後、続くス
テップＳ４７０６で購買承認サービス登録イベントを、
購買承認リクエストサーバに通知する。

【０２４８】上記購買承認サービス登録イベントを受信
した購買承認リクエストサーバでは、再び、ステップＳ
３９０２の購買承認一括判定処理により、上記購買承認
要求登録情報に格納された、それぞれの購買承認要求に
ついて、承認か否か判定される。まず、承認サービス検
索処理により、上記購買承認要求の分類「音楽」に対応
する購買承認サービスを検索し、分類「音楽」に対応し
て検索された「音楽承認サービス」を取得する。ステッ
プＳ４３０３の承認判定情報検索処理により、図５３の
予算情報５３０１を参照した結果、要求機器「コンポ」
が検索される。

【０２４９】その結果、次のステップＳ４３０４で検索
成功と判断され、続くステップＳ４３０５の承認判定情
報適用処理により、分類「音楽」、要求者「太郎」、要
求機器「コンポ」の予算枠￥０に、要求金額￥８０を適
用しようと試みるが、予算が足りないので失敗し、ステ
ップＳ４３１１で購買が却下されたことを通知する。

【０２５０】一方、図１４に示したような購買承認要求
の場合、分類「“ＭｕｓｉｃＦｌａｓｈ”」に対応して
検索された「ＭｕｓｉｃＦｌａｓｈ承認サービス」を取
得する。ステップＳ４３０３の承認判定情報検索処理に
より、図２７の予算情報を参照した結果、要求機器「コ
ンポ」、要求者「太郎」の予算枠￥２，０００に、要求
金額￥８０を適用しようと試みた結果、予算に収まるの
で成功する。更に、ステップＳ４３０７で承認確認の必
要性を判断した結果、「要」と指定されていないので不
要と判断し、ステップＳ４３１０で購買が承認されたこ
とを通知して、処理を終了する。

【０２５１】以上説明した通り本実施の形態６によれ
ば、購買承認リクエストサーバに購買承認要求を登録し
た時に、対応する購買承認サービスが存在せずに、承認
判定が行えなかったとしても、その後、購買承認カード
が挿入されるのに連動して生成・追加された購買承認サ
ービスを用いて、承認判定を行うことが可能となる。ま
た、購買承認カードには購買承認サービスに必要な情報
（条件データ）だけが格納されていればよいので、購買
承認カードのメモリ容量も少なくて済む。

【０２５２】＜実施の形態７＞本実施形態７では、図６
のように、クライアント端末には、持ち運び可能な携帯
情報端末（ＰＤＡ）を用い、さらに、リクエストサーバ
機能を持たせて承認要求を格納することができるように
する。更に、クライアント端末がネットワークに接続さ
れた時点でサービスサーバを検索して承認要求の判定処
理を行うようにする。

【０２５３】本実施形態７では、下記のような処理が行
われる。

【０２５４】１．購買承認判定者が購買承認サービスを
購買承認サービスサーバに登録する。

【０２５５】２．購買承認要求者が複数の購買承認要求
を、購買承認要求者自身が携帯しているＰＤＡ（個人用
携帯情報端末：ＰｅｒｓｏｎａｌＤｉｇｉｔａｌＡｓｓ
ｉｓｔａｎｔ）の購買承認リクエストサーバに登録する
が、承認サービスを利用可能なネットワークに接続され
ていない場合には、その購買承認リクエストサーバが対
応する承認サービスを検索できないことになるので、ネ
ットワークへの接続イベントを検知するまで承認要求を
格納しておく。

【０２５６】３．クライアント端末がネットワークに接
続されると、ネットワークへの接続イベントがリクエス
トサーバに通知される。

【０２５７】４．購買承認リクエストサーバが、ネット
ワークへの接続イベントを検知し、承認要求格納部に登
録されているそれぞれの購買承認要求に対応する購買承
認サービスを、購買承認サービスサーバから検索する。

【０２５８】５．購買承認サービスが検索されれば、該
承認サービスを取得し、該承認要求の判定を行う。

【０２５９】６．取得された購買承認サービスを用いて
承認判定を行った結果を通知する。

【０２６０】なお、上記の場合では、購買承認リクエス
トサーバが、購買承認サービスサーバから購買承認サー
ビスそのものを取得してから処理を行っているように説
明してあるが、処理に必要な情報のみを取得しても良
い。

【０２６１】図５４は、図６で説明した購買承認要求者
自身が携帯しているＰＤＡ５４１６が持つ購買承認リク
エストサーバ５４０１に登録しておいた購買承認要求を
処理する例として、ＰＤＡ５４１６を承認サービスが利
用可能なネットワークに接続した様子を示している。

【０２６２】具体的には、例えば購買承認要求者が、外
出先等でウィンドウショッピングをしている時などに何
か商品を欲しくなった場合、ＰＤＡ５４１６が持つ購買
承認リクエストサーバ５４０１にその商品に対する購買
承認要求５４０２を追加しておく。ところが、その時点
ではＰＤＡ５４１６はネットワークに接続されておら
ず、購買承認サービスを取得可能な環境に無い為、上記
購買承認要求を保留としてストックしておく。このよう
にして格納された購買承認要求の例が５４０２〜５４１
１に示されている。

【０２６３】その後、購買承認要求者がネットワークに
ＰＤＡ５４１６を接続することで、ＰＤＡに格納されて
いる購買承認要求に対する処理が実行される。

【０２６４】図３９のステップＳ３９０３で、発生した
ネットワーク接続イベントを検知し、ステップＳ３９０
２の購買承認一括判定処理により、購買承認要求５４０
２〜５４１１に対する購買承認サービスを取得し、承認
判定を実行する。

【０２６５】以上説明した通り、本実施の形態７によれ
ば、クライアント端末が、購買承認サービスを利用不可
能な環境にあっても、あるいは敢えて購買承認サービス
を利用したくない場合であっても、いったんＰＤＡが持
つ購買承認リクエストサーバに登録しておき、任意のタ
イミングで購買承認サービスを利用可能な環境に接続す
ることで、まとめて承認判定を求めることが可能とな
り、より自由度の高い操作が可能となる。

【０２６６】＜実施の形態８＞本実施形態８では、購買
承認要求を格納した購買承認要求カードを用いた場合を
説明する。

【０２６７】図５５は、図６で説明した購買承認要求者
自身が携帯しているＰＤＡを直接ネットワークに接続す
る代わりに、購買承認要求５５０２〜５５１１を格納し
た購買承認要求カード５５１２を、購買承認リクエスト
サーバを有するネットワークに接続されたカードリーダ
５５１６に、挿入した様子を示している。

【０２６８】具体的には、例えば購買承認要求者が、外
出先等でウィンドウショッピングをしている時などに何
か商品を欲しくなった場合、その商品の前に置いてある
購買承認要求カードをもらっておく。あるいは、ＰＤＡ
やその商品の前に設置してある購買承認要求カードライ
タを用いて、その商品に対する購買承認要求５５０２を
自分の購買承認要求カードに追加しておく。

【０２６９】その後、購買承認要求者が帰宅して、購買
承認要求カード５５１２をホームネットワークに接続さ
れているカードリーダ５５１６に挿入することで、前述
の購買承認要求に対する処理が実行される。

【０２７０】図５６は、本実施の形態８に係るシステム
において、カードリーダが有する購買承認リクエストサ
ーバでの処理を示す図である。

【０２７１】具体的には、まずカードリーダの購買承認
リクエストサーバが起動されると、ステップＳ５６０１
のシステム起動処理でシステムが持つ各種デバイスやメ
モリなどが初期化される。続いて、ステップＳ５６０２
の購買承認一括判定処理により、購買承認要求登録情報
に格納された、すべての購買承認要求に対して承認判定
を行い、その結果を要求元の要求者に通知する。

【０２７２】ステップＳ５６０３でユーザからの入力操
作や、他の装置から情報の受信や、タイマからの信号な
どの各種イベントが発生するのを待機する。そこで、何
らかのイベントが発生すると、次のステップＳ５６０４
で電源ＯＦＦを指示したイベントか否か判断される。そ
の結果、電源ＯＦＦを指示していると判断された場合、
ステップＳ５６１５のシステム終了処理により、システ
ムが持つ各種デバイスやメモリなどの終了処理を実行
後、本システムの処理を終了する。

【０２７３】ステップＳ５６０４で電源ＯＦＦを指示し
ていると判断されなかった場合、次のステップＳ５６０
５でカード操作か否かが判断される。その結果、カード
操作と判断されなかった場合、ステップＳ５６１０に進
む。

【０２７４】ステップＳ５６０５で購買承認要求カード
が挿入されたと判断した場合、ステップＳ５６０６の購
買承認要求読込処理により、購買承認要求カードに格納
された購買承認要求が読み込まれ、続くステップＳ５６
０７でイベントの種類を上記読み込まれた購買承認要求
の登録指示に変更する。

【０２７５】ステップＳ５６０５で購買承認要求カード
を取り出したと判断された場合、ステップＳ５６０８の
購買承認要求読込処理により、購買承認要求カードに格
納された購買承認要求が読み込まれ、続くステップＳ５
６０９でイベントの種類を上記読み込まれた購買承認要
求の削除指示に変更する。

【０２７６】次のステップＳ５６１０でイベントの種類
が何か判断される。その結果、承認要求に対する指示と
判断されなかった場合、再びステップＳ５６０２に戻
る。

【０２７７】ステップＳ５６１０で承認要求の登録を指
示していると判断された場合、ステップＳ５６１１の承
認要求登録処理により、カードから読み込んだ承認要求
を承認要求登録情報に登録し、再びステップＳ５６０２
に戻る。

【０２７８】ステップＳ５６１０で承認要求の削除を指
示していると判断された場合、ステップＳ５６１２の承
認要求削除処理により、対応する承認要求を承認要求登
録情報から削除し、再びステップＳ５６０２に戻る。

【０２７９】ステップＳ５６１０で承認要求の更新を指
示していると判断された場合、ステップＳ５６１３の承
認要求更新処理により、承認要求登録情報に格納された
対応する承認要求を更新し、再びステップＳ５６０２に
戻る。

【０２８０】ステップＳ５６１０で承認要求の検索を指
示していると判断された場合、ステップＳ５６１４の承
認要求検索処理により、対応する承認要求を承認要求登
録情報から検索し、要求元に渡し、再びステップＳ５６
０２に戻る。

【０２８１】以上説明した通り本実施の形態８によれ
ば、購買承認要求が格納されたカードをカードリーダに
挿入するだけで承認判定処理を行うことができる。

【０２８２】また、上記購買承認要求カードへの登録
を、ＰＤＡまたは商品の近くにあるカードライタによっ
て行うことで、より自由度の高い操作が可能となる。

【０２８３】更に、上記購買承認要求カードそのものを
入手することで、購買承認要求者が承認要求をあらため
て購買承認要求カードに登録する手間を軽減し、より自
由度の高い操作が可能となる。

【０２８４】＜その他の実施の形態＞実施形態２のクラ
イアント端末（又は実施形態３乃至８のリクエストサー
バ）は、サービスサーバに格納された承認サービスを検
索して、検索された承認サービスを取得して、実施形態
２のクライアント端末（又は実施形態３乃至８のリクエ
ストサーバ）で承認判定処理を行うようにしたが、承認
判定処理をサービスサーバに行わせるようにしてもよ
い。具体的には、実施形態２のクライアント端末（又は
実施形態３乃至８のリクエストサーバ）は承認サービス
を検索して、承認サービスが検索された場合に、該承認
要求をサービスサーバに送信して、サービスサーバに承
認判定処理を行わせ、その後、承認判定結果をサービス
サーバから受け取って、承認要求者に提示するようにし
てもよい。

【０２８５】また、実施形態２のクライアント端末（又
は実施形態３乃至８のリクエストサーバ）は、サービス
サーバに格納された承認サービスを検索するようにした
が、サービスサーバ以外にサービスプロバイダも検索す
るようにしてもよい。例えば、直接サービスプロバイダ
を検索してもよいし、サービスサーバを検索した際に承
認要求に適した承認サービスがなかった場合にサービス
プロバイダを検索するようにしてもよい。

【０２８６】また、本発明は、単一の機器からなる装置
に適用しても、複数の機器から構成されるシステムに適
用してもよい。

【０２８７】また本発明は、前述した各実施の形態の機
能を実現するソフトウェアのプログラムコードを記憶し
た記憶媒体を、システムあるいは装置に供給し、そのシ
ステムあるいは装置のコンピュータ（またはＣＰＵやＭ
ＰＵ）が記憶媒体に格納されたプログラムコードを読み
出し実行することによっても、達成されることは言うま
でもない。

【０２８８】この場合、記憶媒体から読み出されたプロ
グラムコード自体が本発明の新規な機能を実現すること
になり、そのプログラムコードを記憶した記憶媒体は本
発明を構成することになる。

【０２８９】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピーディスク、ハードディ
スク、光磁気ディスク、光ディスク、ＣＤ−ＲＯＭ、Ｃ
Ｄ−Ｒ、磁気テープ不揮発性のメモリカード、ＲＯＭな
どを用いることができる。

【０２９０】また、コンピュータが読み出したプログラ
ムコードを実行することによって、前述した実施の形態
の機能が実現される他、そのプログラムコードの指示に
基づき、コンピュータ上で稼動しているＯＳなどが実際
の処理の一部または全部を行い、その処理によっても前
述した実施の形態の機能が実現され得る。

【０２９１】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張ボー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書き込まれた後、そのプログラムコードの指
示に基づき、その機能拡張ボードや機能拡張ユニットに
備わるＣＰＵなどが実際の処理の一部または全部を行
い、その処理によっても前述した実施の形態の機能が実
現され得る。

【０２９２】本発明は、前述した実施の形態の機能を実
現するソフトウェアのプログラムコードを記録した記憶
媒体からそのプログラムをパソコン通信など通信ライン
を介して要求者にそのプログラムを配信する場合にも適
用できることは言うまでもない。

【０２９３】

【発明の効果】以上述べたように、本発明によれば、承
認判定者が不在の場合や多忙な場合であっても、承認要
求者が長時間待たされることなく、承認判定を行うこと
ができる。

【図面の簡単な説明】

【図１】従来技術による購買承認処理の流れを示す説明
図である。

【図２】実施の形態１における、１つの装置内あるいは
単一システム内で行われる購買承認の処理を示す説明図
である。

【図３】実施の形態２における、サービスサーバを利用
した購買承認の処理を示す説明図である。

【図４】実施の形態３における、リクエストサーバを利
用した購買承認の処理を示す説明図である。

【図５】実施の形態４，５，６における、後から承認サ
ービスが登録された場合の購買承認の処理を示す説明図
である。

【図６】実施の形態７，８における、後からリクエスト
サーバが接続された場合の購買承認の処理を示す説明図
である。

【図７】本発明を適用した各実施の形態で用いる情報処
理装置のハードウェア構成を示すブロック図である。

【図８】本発明を適用した実施の形態における、購買承
認要求側システム全体の処理の流れを示すフローチャー
トである。

【図９】本発明を適用した実施の形態における、購買承
認要求生成処理の流れを示すフローチャートである。

【図１０】本発明を適用した実施の形態における、購買
履歴の一例を示す図である。

【図１１】本発明を適用した実施の形態における、分類
項目一覧の一例を示す図である。

【図１２】本発明を適用した実施の形態における、購買
承認要求入力画面の一例を示す図である。

【図１３】本発明を適用した実施の形態における、生成
された購買承認要求の一例を示す図である。

【図１４】本発明を適用した実施の形態における、生成
された購買承認要求の一例を示す図である。

【図１５】本発明を適用した実施の形態における、購買
承認判定処理の流れを示すフローチャートである。

【図１６】本発明を適用した実施の形態における、購買
承認判定実行判断処理の流れを示すフローチャートであ
る。

【図１７】本発明を適用した実施の形態における、購買
承認判定実行判断フラグの定義を示す図である。

【図１８】本発明を適用した実施の形態における、購買
承認判定実行禁止スケジュールの一例を示す図である。

【図１９】本発明を適用した実施の形態における、予算
情報の一例を示す図である。

【図２０】本発明を適用した実施の形態における、サー
ビスサーバに登録された情報の一例を明示すると共に、
サービスサーバを利用した購買承認の流れを示す図であ
る。

【図２１】本発明を適用した実施の形態における、購買
承認サービスプロバイダシステム全体の処理の流れを示
すフローチャートである。

【図２２】本発明を適用した実施の形態における、購買
承認サービスサーバシステム全体の処理の流れを示すフ
ローチャートである。

【図２３】本発明を適用した実施の形態における、購買
承認サービス登録情報の一例を示す図である。

【図２４】本発明を適用した実施の形態における、サー
ビスサーバに登録された情報、および購買承認サービス
の一例を示す図である。

【図２５】本発明を適用した実施の形態における、購買
承認サービス検索処理の流れを示すフローチャートであ
る。

【図２６】本発明を適用した実施の形態における、購買
承認判定実行判断処理の流れを示すフローチャートであ
る。

【図２７】本発明を適用した実施の形態における、Ｍｕ
ｓｉｃＦｌａｓｈ予算情報の一例を示す図である。

【図２８】本発明を適用した実施の形態における、音楽
予算情報の一例を示す図である。

【図２９】本発明を適用した実施の形態における、ニュ
ース予算情報の一例を示す図である。

【図３０】本発明を適用した実施の形態における、ドラ
マ予算情報の一例を示す図である。

【図３１】本発明を適用した実施の形態における、アニ
メ予算情報の一例を示す図である。

【図３２】本発明を適用した実施の形態における、食料
品予算情報の一例を示す図である。

【図３３】本発明を適用した実施の形態における、嗜好
品予算情報の一例を示す図である。

【図３４】本発明を適用した実施の形態における、衣料
品予算情報の一例を示す図である。

【図３５】本発明を適用した実施の形態における、娯楽
品予算情報の一例を示す図である。

【図３６】本発明を適用した実施の形態における、その
他予算情報の一例を示す図である。

【図３７】本発明を適用した実施の形態における、リク
エストサーバに登録された情報の一例を明示すると共
に、リクエストサーバを利用した購買承認の流れを示す
図である。

【図３８】本発明を適用した実施の形態における、購買
承認要求側システム全体の処理の流れを示すフローチャ
ートである。

【図３９】本発明を適用した実施の形態における、購買
承認リクエストサーバシステム全体の処理の流れを示す
フローチャートである。

【図４０】本発明を適用した実施の形態における、購買
承認要求登録情報の一例を示す図である。

【図４１】本発明を適用した実施の形態における、リク
エストサーバに登録された情報、および購買承認要求の
一例を示す図である。

【図４２】本発明を適用した実施の形態における、購買
承認一括判定処理の流れを示すフローチャートである。

【図４３】本発明を適用した実施の形態における、購買
承認判定処理の流れを示すフローチャートである。

【図４４】本発明を適用した実施の形態における、ユー
ザのログイン操作に連動して、後から承認サービスが登
録された場合の購買承認の処理を示す説明図である。

【図４５】本発明を適用した実施の形態における、購買
承認サービスプロバイダシステム全体の処理の流れを示
すフローチャートである。

【図４６】本発明を適用した実施の形態における、購買
承認者対応情報の一例を示す図である。

【図４７】本発明を適用した実施の形態における、購買
承認サービスサーバシステム全体の処理の流れを示すフ
ローチャートである。

【図４８】本発明を適用した実施の形態における、購買
承認サービスを内包した購買承認カードの挿入操作に連
動して、後から承認サービスが登録された場合の購買承
認の処理を示す説明図である。

【図４９】本発明を適用した実施の形態における、購買
承認サービスプロバイダシステム全体の処理の流れを示
すフローチャートである。

【図５０】本発明を適用した実施の形態における、購買
承認サービスに必要な情報を内包した購買承認カードの
挿入操作に連動して、後から承認サービスが登録された
場合の購買承認の処理を示す説明図である。

【図５１】本発明を適用した実施の形態における、購買
承認サービスプロバイダシステム全体の処理の流れを示
すフローチャートである。

【図５２】本発明を適用した実施の形態における、購買
承認サービス生成処理の流れを示すフローチャートであ
る。

【図５３】本発明を適用した実施の形態における、生成
済み購買承認サービス情報の一例を示す図である。

【図５４】本発明を適用した実施の形態における、ＰＤ
Ａのネットワーク接続操作に連動して、後からリクエス
トサーバが接続された場合の購買承認の処理を示す説明
図である。

【図５５】本発明を適用した実施の形態における、購買
承認要求カードの挿入操作に連動して、後からリクエス
トサーバに一括登録された場合の購買承認の処理を示す
説明図である。

【図５６】本発明を適用した実施の形態における、購買
承認リクエストサーバシステム全体の処理の流れを示す
フローチャートである。

Claims (66)

【特許請求の範囲】
1. 【請求項１】 承認要求を生成する承認要求生成手段
   と、 承認サービスプロバイダにより設定される承認サービス
   を格納する格納手段と、 前記格納された承認サービスを用いて、前記生成された
   承認要求を承認するか否か判定する判定手段と、 前記判定手段の判定結果を出力する出力手段とを有する
   ことを特徴とする情報処理装置。
2. 【請求項２】 更に前記出力された判定結果が承認であ
   った場合に、該承認要求に対応する処理を実行する実行
   手段を有することを特徴とする請求項１に記載の情報処
   理装置。
3. 【請求項３】 前記承認サービスには、承認要求者と前
   記承認要求の内容に応じて判定するための判定条件が含
   まれることを特徴とする請求項１に記載の情報処理装
   置。
4. 【請求項４】 前記判定条件には、更に承認要求生成し
   た情報処理装置の情報も含まれることを特徴とする請求
   項３に記載の情報処理装置。
5. 【請求項５】 前記判定手段は、前記判定を禁止する期
   間か否か判断して、禁止期間であると判断した場合は、
   前記承認要求の承認判定を実行しないことを特徴とする
   請求項１に記載の情報処理装置。
6. 【請求項６】 承認サービスプロバイダによって登録さ
   れた複数の承認サービスを管理するサービスサーバと、
   承認要求を生成する承認要求生成手段を有するクライア
   ント端末とを含む承認システムであって、 前記クライアント端末は、更に、前記サービスサーバに
   登録されている複数の承認サービスの中から、前記承認
   要求に適した承認サービスを検索して取得する取得手段
   と、 該取得した承認サービスを用いて前記承認要求の承認判
   定を行う判定実行手段と、 前記判定実行手段の判定結果を出力する出力手段とを有
   することを特徴とする承認システム。
7. 【請求項７】 前記サービスプロバイダは、前記承認サ
   ービスの情報が格納されたカードが挿入されるのに応答
   して、前記サービスサーバに前記承認サービスを登録
   し、前記カードが取り出されるのに応答して、前記サー
   ビスサーバから該当する承認サービスを削除することを
   特徴とする請求項６に記載の承認システム。
8. 【請求項８】 更に、前記クライアント端末は、複数の
   承認要求を格納する承認要求格納手段を有し、 前記判定実行手段は、前記承認要求格納手段に格納され
   ている複数の承認要求の承認判定処理を実行するよう制
   御することを特徴とする請求項６に記載の承認システ
   ム。
9. 【請求項９】 前記取得手段は、前記クライアント端末
   がネットワークを介して前記サービスサーバに接続され
   たのを検知すると、前記サービスサーバに登録されてい
   る複数の承認サービスの中から、前記承認要求に適した
   承認サービスを検索して取得することを特徴とする請求
   項８に記載の承認システム。
10. 【請求項１０】 前記クライアント端末は、携帯端末で
    あることを特徴とする請求項９に記載の承認システム。
11. 【請求項１１】 前記取得手段は、前記承認要求が格納
    されたカードが前記クライアント端末に挿入されるのに
    応答して、前記サービスサーバに登録されている複数の
    承認サービスの中から、前記承認要求に適した承認サー
    ビスを検索して取得することを特徴とする請求項６に記
    載の承認システム。
12. 【請求項１２】 前記クライアント端末は、更に前記出
    力された判定結果が承認であった場合に、該承認要求に
    対応する処理を実行する実行手段を有することを特徴と
    する請求項６に記載の承認システム。
13. 【請求項１３】 前記承認サービスには、承認要求者と
    前記承認要求の内容に応じて判定するための判定条件が
    含まれることを特徴とする請求項６に記載の承認システ
    ム。
14. 【請求項１４】 前記取得手段は、更に前記承認サービ
    スプロバイダに格納されている承認サービスも検索する
    ことを特徴とする請求項６に記載の承認システム。
15. 【請求項１５】 承認サービスプロバイダから登録する
    よう指示された承認サービスを複数格納する承認サービ
    ス格納手段と、 外部装置から検索指示された、承認要求に対応する承認
    サービスを検索して、該承認サービスを前記外部装置に
    送信する送信手段とを有することを特徴とするサービス
    サーバ。
16. 【請求項１６】 前記承認サービスプロバイダにより新
    たな承認サービスが登録されると、登録通知を前記外部
    装置に通知する通知手段を有することを特徴とする請求
    項１５に記載のサービスサーバ。
17. 【請求項１７】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成する承認要求生成手段を有するクラ
    イアント端末と、前記クライアント端末で生成された承
    認要求を格納する承認要求格納手段を有するリクエスト
    サーバとを含む承認システムであって、前記リクエスト
    サーバは、前記クライアント端末で生成された承認要求
    を格納する承認要求格納手段と、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求格納手段に格納されている承
    認要求に適した承認サービスを検索して取得する取得手
    段と、 該取得した承認サービスを用いて前記承認要求の承認判
    定を行う判定実行手段と、 前記判定実行手段の判定結果を出力する出力手段とを有
    することを特徴とする承認システム。
18. 【請求項１８】 前記取得手段は、前記サービスサーバ
    に該承認要求に対応する承認サービスが検索できなかっ
    た場合、該承認要求を前記承認要求格納手段に保留して
    おき、 前記サービスサーバに新たな承認サービスが登録された
    ことを検知すると、再度、前記保留されていた承認要求
    に対応する承認サービスを検索して取得することを特徴
    とする請求項１７に記載の承認システム。
19. 【請求項１９】 前記サービスサーバは、前記サービス
    プロバイダにより新たな承認サービスが登録されると、
    登録通知を前記リクエストサーバに通知する通知手段を
    有することを特徴とする請求項１８に記載の承認システ
    ム。
20. 【請求項２０】 前記サービスプロバイダに承認判定者
    がログインするのに応答して、該承認判定者に対応する
    承認サービスが前記サービスサーバに登録され、前記サ
    ービスプロバイダから承認判定者がログアウトするのに
    応答して、該承認判定者に対応する承認サービスが前記
    サービスサーバから削除されることを特徴とする請求項
    １７に記載の承認システム。
21. 【請求項２１】 承認サービスが格納されたカードが前
    記サービスプロバイダに挿入されるのに応答して、該カ
    ードに格納されている承認サービスが前記サービスサー
    バに登録され、前記カードが前記サービスプロバイダか
    ら取り出されるのに応答して、該カードに格納されてい
    る承認サービスに対応する承認サービスが前記サービス
    サーバから削除されることを特徴とする請求項１７に記
    載の承認システム。
22. 【請求項２２】 前記カードには、前記承認サービスで
    用いる判定条件データが含まれることを特徴とする請求
    項２１に記載の承認システム。
23. 【請求項２３】 前記サービスプロバイダは、前記挿入
    されたカードの前記判定条件データに基づいて、前記承
    認サービスを作成して、前記サービスサーバに登録する
    ことを特徴とする請求項２２に記載の承認システム。
24. 【請求項２４】 前記クライアント端末は、更に、前記
    出力手段により出力された判定結果を受信する受信手段
    を有することを特徴とする請求項１７に記載の承認シス
    テム。
25. 【請求項２５】 前記クライアント端末は、更に前記受
    信した判定結果が承認であった場合に、該承認要求に対
    応する処理を実行する実行手段を有することを特徴とす
    る請求項２４に記載の承認システム。
26. 【請求項２６】 前記承認サービスには、承認要求者と
    前記承認要求の内容に応じて判定するための判定条件が
    含まれることを特徴とする請求項１７に記載の承認シス
    テム。
27. 【請求項２７】 前記取得手段は、更に前記承認サービ
    スプロバイダに格納されている承認サービスも検索する
    ことを特徴とする請求項１７に記載の承認システム。
28. 【請求項２８】 前記出力手段により出力された判定結
    果は、前記サービスプロバイダにも出力されることを特
    徴とする請求項１７に記載の承認システム。
29. 【請求項２９】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成する承認要求生成手段を有するクラ
    イアント端末とを含む承認システムであって、 前記クライアント端末は、更に、前記サービスサーバに
    登録されている複数の承認サービスの中から、前記承認
    要求に適した承認サービスを検索する検索手段と、 前記検索手段により承認サービスが検索された場合、該
    承認要求を前記サービスサーバに送信する送信手段と、 前記サービスサーバから該送信した承認要求の承認判定
    結果を受信する受信手段とを有し、 前記サービスサーバは、前記クライアント端末から送信
    されてきた承認要求を、該承認要求に適した承認サービ
    スを用いて承認判定を行う判定実行手段と、 該承認判定結果を前記クライアント端末に送信する送信
    手段とを有することを特徴とする承認システム。
30. 【請求項３０】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成する承認要求生成手段を有するクラ
    イアント端末と、前記クライアント端末で生成された承
    認要求を格納する承認要求格納手段を有するリクエスト
    サーバとを含む承認システムであって、 前記リクエストサーバは、前記クライアント端末で生成
    された承認要求を格納する承認要求格納手段と、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求格納手段に格納されている承
    認要求に適した承認サービスを検索する検索手段と、 前記検索手段により承認サービスが検索された場合、該
    承認要求を前記サービスサーバに送信する送信手段と、 前記サービスサーバから該承認要求の承認判定結果を受
    信する受信手段とを有し、 前記サービスサーバは、前記リクエストサーバから送信
    されてきた承認要求を、該承認要求に適した承認サービ
    スを用いて承認判定を行う判定実行手段と、 該承認判定結果を前記リクエストサーバに送信する送信
    手段とを有することを特徴とする承認システム。
31. 【請求項３１】 承認要求を生成する承認要求生成ステ
    ップと、 承認サービスプロバイダにより設定される承認サービス
    を格納する格納ステップと、 前記格納された承認サービスを用いて、前記生成された
    承認要求を承認するか否か判定する判定ステップと、 前記判定ステップの判定結果を出力する出力ステップと
    を有することを特徴とする情報処理方法。
32. 【請求項３２】 更に前記出力された判定結果が承認で
    あった場合に、該承認要求に対応する処理を実行する実
    行ステップを有することを特徴とする請求項３１に記載
    の情報処理方法。
33. 【請求項３３】 前記承認サービスには、承認要求者と
    前記承認要求の内容に応じて判定するための判定条件が
    含まれることを特徴とする請求項３１に記載の情報処理
    方法。
34. 【請求項３４】 前記判定条件には、更に承認要求生成
    した情報処理方法の情報も含まれることを特徴とする請
    求項３３に記載の情報処理方法。
35. 【請求項３５】 前記判定ステップは、前記判定を禁止
    する期間か否か判断して、禁止期間であると判断した場
    合は、前記承認要求の承認判定を実行しないことを特徴
    とする請求項３１に記載の情報処理方法。
36. 【請求項３６】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末とを含む承認
    システムを制御する制御方法であって、 前記クライアント端末においては、承認要求を生成する
    承認要求生成ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求に適した承認サービスを検索
    して取得する取得ステップと、 該取得した承認サービスを用いて前記承認要求の承認判
    定を行う判定実行ステップと、 前記判定実行ステップの判定結果を出力する出力ステッ
    プとを有することを特徴とする承認システム制御方法。
37. 【請求項３７】 前記サービスプロバイダのおいては、
    前記承認サービスの情報が格納されたカードが挿入され
    るのに応答して、前記サービスサーバに前記承認サービ
    スを登録し、前記カードが取り出されるのに応答して、
    前記サービスサーバから該当する承認サービスを削除す
    ることを特徴とする請求項３６に記載の承認システム制
    御方法。
38. 【請求項３８】 更に、前記クライアント端末において
    は、複数の承認要求をメモリに格納する承認要求格納ス
    テップを有し、 前記判定実行ステップは、前記格納されている複数の承
    認要求の承認判定処理を実行するよう制御することを特
    徴とする請求項３６に記載の承認システム制御方法。
39. 【請求項３９】 前記取得ステップでは、前記クライア
    ント端末がネットワークを介して前記サービスサーバに
    接続されたのを検知すると、前記サービスサーバに登録
    されている複数の承認サービスの中から、前記承認要求
    に適した承認サービスを検索して取得することを特徴と
    する請求項３８に記載の承認システム制御方法。
40. 【請求項４０】 前記クライアント端末は、携帯端末で
    あることを特徴とする請求項３９に記載の承認システム
    制御方法。
41. 【請求項４１】 前記取得ステップでは、前記承認要求
    が格納されたカードが前記クライアント端末に挿入され
    るのに応答して、前記サービスサーバに登録されている
    複数の承認サービスの中から、前記承認要求に適した承
    認サービスを検索して取得することを特徴とする請求項
    ３６に記載の承認システム制御方法。
42. 【請求項４２】 前記クライアント端末においては、更
    に前記出力された判定結果が承認であった場合に、該承
    認要求に対応する処理を実行する実行ステップを有する
    ことを特徴とする請求項３６に記載の承認システム制御
    方法。
43. 【請求項４３】 前記承認サービスには、承認要求者と
    前記承認要求の内容に応じて判定するための判定条件が
    含まれることを特徴とする請求項３６に記載の承認シス
    テム制御方法。
44. 【請求項４４】 前記取得ステップでは、更に前記承認
    サービスプロバイダに格納されている承認サービスも検
    索することを特徴とする請求項３６に記載の承認システ
    ム制御方法。
45. 【請求項４５】 承認サービスプロバイダから登録する
    よう指示された承認サービスをメモリに複数格納する承
    認サービス格納ステップと、 外部装置から検索指示された、承認要求に対応する承認
    サービスを検索して、該承認サービスを前記外部装置に
    送信する送信ステップとを有することを特徴とするサー
    ビスサーバ制御方法。
46. 【請求項４６】 前記承認サービスプロバイダにより新
    たな承認サービスが登録されると、登録通知を前記外部
    装置に通知する通知ステップを有することを特徴とする
    請求項４５に記載のサービスサーバ制御方法。
47. 【請求項４７】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末と、前記クラ
    イアント端末で生成された承認要求を格納するメモリを
    有するリクエストサーバとを含む承認システムの制御方
    法であって、 前記リクエストサーバにおいては、前記クライアント端
    末で生成された承認要求を前記メモリに格納する承認要
    求格納ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記格納されている承認要求に適した承認
    サービスを検索して取得する取得ステップと、 該取得した承認サービスを用いて前記承認要求の承認判
    定を行う判定実行ステップと、 前記判定実行ステップの判定結果を出力する出力ステッ
    プとを有することを特徴とする承認システム制御方法。
48. 【請求項４８】 前記取得ステップでは、前記サービス
    サーバに該承認要求に対応する承認サービスが検索でき
    なかった場合、該承認要求を前記メモリに保留してお
    き、 前記サービスサーバに新たな承認サービスが登録された
    ことを検知すると、再度、前記保留されていた承認要求
    に対応する承認サービスを検索して取得することを特徴
    とする請求項４７に記載の承認システム制御方法。
49. 【請求項４９】 前記サービスサーバにおいては、前記
    サービスプロバイダにより新たな承認サービスが登録さ
    れると、登録通知を前記リクエストサーバに通知する通
    知ステップを有することを特徴とする請求項４８に記載
    の承認システム制御方法。
50. 【請求項５０】 前記サービスプロバイダに承認判定者
    がログインするのに応答して、該承認判定者に対応する
    承認サービスが前記サービスサーバに登録され、前記サ
    ービスプロバイダから承認判定者がログアウトするのに
    応答して、該承認判定者に対応する承認サービスが前記
    サービスサーバから削除されることを特徴とする請求項
    ４７に記載の承認システム制御方法。
51. 【請求項５１】 承認サービスが格納されたカードが前
    記サービスプロバイダに挿入されるのに応答して、該カ
    ードに格納されている承認サービスが前記サービスサー
    バに登録され、前記カードが前記サービスプロバイダか
    ら取り出されるのに応答して、該カードに格納されてい
    る承認サービスに対応する承認サービスが前記サービス
    サーバから削除されることを特徴とする請求項４７に記
    載の承認システム制御方法。
52. 【請求項５２】 前記カードには、前記承認サービスで
    用いる判定条件データが含まれることを特徴とする請求
    項５１に記載の承認システム制御方法。
53. 【請求項５３】 前記サービスプロバイダにおいては、
    前記挿入されたカードの前記判定条件データに基づい
    て、前記承認サービスを作成して、前記サービスサーバ
    に登録することを特徴とする請求項５２に記載の承認シ
    ステム制御方法。
54. 【請求項５４】 前記クライアント端末においては、更
    に、前記出力ステップにより出力された判定結果を受信
    する受信ステップを有することを特徴とする請求項４７
    に記載の承認システム制御方法。
55. 【請求項５５】 前記クライアント端末においては、更
    に前記受信した判定結果が承認であった場合に、該承認
    要求に対応する処理を実行する実行ステップを有するこ
    とを特徴とする請求項５４に記載の承認システム制御方
    法。
56. 【請求項５６】 前記承認サービスには、承認要求者と
    前記承認要求の内容に応じて判定するための判定条件が
    含まれることを特徴とする請求項４７に記載の承認シス
    テム制御方法。
57. 【請求項５７】 前記取得ステップでは、更に前記承認
    サービスプロバイダに格納されている承認サービスも検
    索することを特徴とする請求項４７に記載の承認システ
    ム制御方法。
58. 【請求項５８】 前記出力ステップにより出力された判
    定結果は、前記サービスプロバイダにも出力されること
    を特徴とする請求項４７に記載の承認システム制御方
    法。
59. 【請求項５９】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末とを含む承認
    システムの制御方法であって、 前記クライアント端末においては、承認要求を生成する
    承認要求生成ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求に適した承認サービスを検索
    する検索ステップと、 前記検索ステップにより承認サービスが検索された場
    合、該承認要求を前記サービスサーバに送信する送信ス
    テップと、 前記サービスサーバから該送信した承認要求の承認判定
    結果を受信する受信ステップとを有し、 前記サービスサーバにおいては、前記クライアント端末
    から送信されてきた承認要求を、該承認要求に適した承
    認サービスを用いて承認判定を行う判定実行ステップ
    と、 該承認判定結果を前記クライアント端末に送信する送信
    ステップとを有することを特徴とする承認システム制御
    方法。
60. 【請求項６０】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末と、前記クラ
    イアント端末で生成された承認要求を格納するメモリを
    有するリクエストサーバとを含む承認システムであっ
    て、 前記リクエストサーバにおいては、前記クライアント端
    末で生成された承認要求を前記メモリに格納する承認要
    求格納ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求格納ステップに格納されてい
    る承認要求に適した承認サービスを検索する検索ステッ
    プと、 前記検索ステップにより承認サービスが検索された場
    合、該承認要求を前記サービスサーバに送信する送信ス
    テップと、 前記サービスサーバから該承認要求の承認判定結果を受
    信する受信ステップとを有し、 前記サービスサーバにおいては、前記リクエストサーバ
    から送信されてきた承認要求を、該承認要求に適した承
    認サービスを用いて承認判定を行う判定実行ステップ
    と、 該承認判定結果を前記リクエストサーバに送信する送信
    ステップとを有することを特徴とする承認システム制御
    方法。
61. 【請求項６１】 承認要求を生成する承認要求生成ステ
    ップと、 承認サービスプロバイダにより設定される承認サービス
    を格納する格納ステップと、 前記格納された承認サービスを用いて、前記生成された
    承認要求を承認するか否か判定する判定ステップと、 前記判定ステップの判定結果を出力する出力ステップと
    を有することを特徴とするコンピュータ実行可能なコー
    ドから構成されるコンピュータプログラム。
62. 【請求項６２】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末とを含む承認
    システムを制御するコンピュータ実行可能な制御プログ
    ラムであって、 前記クライアント端末においては、承認要求を生成する
    承認要求生成ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求に適した承認サービスを検索
    して取得する取得ステップと、 該取得した承認サービスを用いて前記承認要求の承認判
    定を行う判定実行ステップと、 前記判定実行ステップの判定結果を出力する出力ステッ
    プとを有することを特徴とするコンピュータ実行可能な
    承認システム制御プログラム。
63. 【請求項６３】 承認サービスプロバイダから登録する
    よう指示された承認サービスをメモリに複数格納する承
    認サービス格納ステップと、 外部装置から検索指示された、承認要求に対応する承認
    サービスを検索して、該承認サービスを前記外部装置に
    送信する送信ステップとを有することを特徴とするコン
    ピュータ実行可能なサービスサーバ制御プログラム。
64. 【請求項６４】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末と、前記クラ
    イアント端末で生成された承認要求を格納するメモリを
    有するリクエストサーバとを含む承認システムを制御す
    るコンピュータ実行可能な制御プログラムであって、 前記リクエストサーバにおいては、前記クライアント端
    末で生成された承認要求を前記メモリに格納する承認要
    求格納ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記格納されている承認要求に適した承認
    サービスを検索して取得する取得ステップと、該取得し
    た承認サービスを用いて前記承認要求の承認判定を行う
    判定実行ステップと、 前記判定実行ステップの判定結果を出力する出力ステッ
    プとを有することを特徴とするコンピュータ実行可能な
    承認システム制御プログラム。
65. 【請求項６５】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末とを含む承認
    システムを制御するコンピュータ実行可能な制御プログ
    ラムであって、前記クライアント端末においては、承認
    要求を生成する承認要求生成ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求に適した承認サービスを検索
    する検索ステップと、 前記検索ステップにより承認サービスが検索された場
    合、該承認要求を前記サービスサーバに送信する送信ス
    テップと、 前記サービスサーバから該送信した承認要求の承認判定
    結果を受信する受信ステップとを有し、 前記サービスサーバにおいては、前記クライアント端末
    から送信されてきた承認要求を、該承認要求に適した承
    認サービスを用いて承認判定を行う判定実行ステップ
    と、 該承認判定結果を前記クライアント端末に送信する送信
    ステップとを有することを特徴とするコンピュータ実行
    可能な承認システム制御プログラム。
66. 【請求項６６】 承認サービスプロバイダによって登録
    された複数の承認サービスを管理するサービスサーバ
    と、承認要求を生成するクライアント端末と、前記クラ
    イアント端末で生成された承認要求を格納するメモリを
    有するリクエストサーバとを含む承認システムを制御す
    るコンピュータ実行可能な制御プログラムであって、 前記リクエストサーバにおいては、前記クライアント端
    末で生成された承認要求を前記メモリに格納する承認要
    求格納ステップと、 前記サービスサーバに登録されている複数の承認サービ
    スの中から、前記承認要求格納ステップに格納されてい
    る承認要求に適した承認サービスを検索する検索ステッ
    プと、 前記検索ステップにより承認サービスが検索された場
    合、該承認要求を前記サービスサーバに送信する送信ス
    テップと、 前記サービスサーバから該承認要求の承認判定結果を受
    信する受信ステップとを有し、 前記サービスサーバにおいては、前記リクエストサーバ
    から送信されてきた承認要求を、該承認要求に適した承
    認サービスを用いて承認判定を行う判定実行ステップ
    と、 該承認判定結果を前記リクエストサーバに送信する送信
    ステップとを有することを特徴とするコンピュータ実行
    可能な承認システム制御プログラム。