図面 (/)

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

出願人 キヤノン株式会社
発明者 若井聖範山本直子前田聡美
出願日 2001年12月20日 (18年11ヶ月経過) 出願番号 2001-387856
公開日 2002年9月13日 (18年2ヶ月経過) 公開番号 2002-259772
状態 未査定
技術分野 特定用途計算機 他に分類されない音響(残響,カラオケ等)
主要キーワード 判定条件データ 一括判定 予算枠 禁止期間内 システム終了処理 ウィンドウショッピング 要求機器 他デバイス
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2002年9月13日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

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

解決手段

本発明の一形態では、クライアント端末において承認要求を生成し、生成された承認要求をリクエストサーバの承認要求格納部に格納しておき、一方、サービスサーバに承認判定所により設定された承認サービスを格納しておく。そして、リクエストサーバに格納されている承認要求に適した承認サービスをサービスサーバから検索して、検索された承認サービスを用いて該承認要求の承認判定処理を行う。

概要

背景

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

概要

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

本発明の一形態では、クライアント端末において承認要求を生成し、生成された承認要求をリクエストサーバの承認要求格納部に格納しておき、一方、サービスサーバに承認判定所により設定された承認サービスを格納しておく。そして、リクエストサーバに格納されている承認要求に適した承認サービスをサービスサーバから検索して、検索された承認サービスを用いて該承認要求の承認判定処理を行う。

目的

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

承認要求を生成する承認要求生成手段と、承認サービスプロバイダにより設定される承認サービスを格納する格納手段と、前記格納された承認サービスを用いて、前記生成された承認要求を承認するか否か判定する判定手段と、前記判定手段の判定結果を出力する出力手段とを有することを特徴とする情報処理装置

請求項2

更に前記出力された判定結果が承認であった場合に、該承認要求に対応する処理を実行する実行手段を有することを特徴とする請求項1に記載の情報処理装置。

請求項3

前記承認サービスには、承認要求者と前記承認要求の内容に応じて判定するための判定条件が含まれることを特徴とする請求項1に記載の情報処理装置。

請求項4

前記判定条件には、更に承認要求生成した情報処理装置の情報も含まれることを特徴とする請求項3に記載の情報処理装置。

請求項5

前記判定手段は、前記判定を禁止する期間か否か判断して、禁止期間であると判断した場合は、前記承認要求の承認判定を実行しないことを特徴とする請求項1に記載の情報処理装置。

請求項6

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

請求項7

前記サービスプロバイダは、前記承認サービスの情報が格納されたカードが挿入されるのに応答して、前記サービスサーバに前記承認サービスを登録し、前記カードが取り出されるのに応答して、前記サービスサーバから該当する承認サービスを削除することを特徴とする請求項6に記載の承認システム。

請求項8

更に、前記クライアント端末は、複数の承認要求を格納する承認要求格納手段を有し、前記判定実行手段は、前記承認要求格納手段に格納されている複数の承認要求の承認判定処理を実行するよう制御することを特徴とする請求項6に記載の承認システム。

請求項9

前記取得手段は、前記クライアント端末がネットワークを介して前記サービスサーバに接続されたのを検知すると、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索して取得することを特徴とする請求項8に記載の承認システム。

請求項10

前記クライアント端末は、携帯端末であることを特徴とする請求項9に記載の承認システム。

請求項11

前記取得手段は、前記承認要求が格納されたカードが前記クライアント端末に挿入されるのに応答して、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索して取得することを特徴とする請求項6に記載の承認システム。

請求項12

前記クライアント端末は、更に前記出力された判定結果が承認であった場合に、該承認要求に対応する処理を実行する実行手段を有することを特徴とする請求項6に記載の承認システム。

請求項13

前記承認サービスには、承認要求者と前記承認要求の内容に応じて判定するための判定条件が含まれることを特徴とする請求項6に記載の承認システム。

請求項14

前記取得手段は、更に前記承認サービスプロバイダに格納されている承認サービスも検索することを特徴とする請求項6に記載の承認システム。

請求項15

承認サービスプロバイダから登録するよう指示された承認サービスを複数格納する承認サービス格納手段と、外部装置から検索指示された、承認要求に対応する承認サービスを検索して、該承認サービスを前記外部装置に送信する送信手段とを有することを特徴とするサービスサーバ。

請求項16

前記承認サービスプロバイダにより新たな承認サービスが登録されると、登録通知を前記外部装置に通知する通知手段を有することを特徴とする請求項15に記載のサービスサーバ。

請求項17

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

請求項18

前記取得手段は、前記サービスサーバに該承認要求に対応する承認サービスが検索できなかった場合、該承認要求を前記承認要求格納手段に保留しておき、前記サービスサーバに新たな承認サービスが登録されたことを検知すると、再度、前記保留されていた承認要求に対応する承認サービスを検索して取得することを特徴とする請求項17に記載の承認システム。

請求項19

前記サービスサーバは、前記サービスプロバイダにより新たな承認サービスが登録されると、登録通知を前記リクエストサーバに通知する通知手段を有することを特徴とする請求項18に記載の承認システム。

請求項20

前記サービスプロバイダに承認判定者がログインするのに応答して、該承認判定者に対応する承認サービスが前記サービスサーバに登録され、前記サービスプロバイダから承認判定者がログアウトするのに応答して、該承認判定者に対応する承認サービスが前記サービスサーバから削除されることを特徴とする請求項17に記載の承認システム。

請求項21

承認サービスが格納されたカードが前記サービスプロバイダに挿入されるのに応答して、該カードに格納されている承認サービスが前記サービスサーバに登録され、前記カードが前記サービスプロバイダから取り出されるのに応答して、該カードに格納されている承認サービスに対応する承認サービスが前記サービスサーバから削除されることを特徴とする請求項17に記載の承認システム。

請求項22

前記カードには、前記承認サービスで用いる判定条件データが含まれることを特徴とする請求項21に記載の承認システム。

請求項23

前記サービスプロバイダは、前記挿入されたカードの前記判定条件データに基づいて、前記承認サービスを作成して、前記サービスサーバに登録することを特徴とする請求項22に記載の承認システム。

請求項24

前記クライアント端末は、更に、前記出力手段により出力された判定結果を受信する受信手段を有することを特徴とする請求項17に記載の承認システム。

請求項25

前記クライアント端末は、更に前記受信した判定結果が承認であった場合に、該承認要求に対応する処理を実行する実行手段を有することを特徴とする請求項24に記載の承認システム。

請求項26

前記承認サービスには、承認要求者と前記承認要求の内容に応じて判定するための判定条件が含まれることを特徴とする請求項17に記載の承認システム。

請求項27

前記取得手段は、更に前記承認サービスプロバイダに格納されている承認サービスも検索することを特徴とする請求項17に記載の承認システム。

請求項28

前記出力手段により出力された判定結果は、前記サービスプロバイダにも出力されることを特徴とする請求項17に記載の承認システム。

請求項29

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

請求項30

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

請求項31

承認要求を生成する承認要求生成ステップと、承認サービスプロバイダにより設定される承認サービスを格納する格納ステップと、前記格納された承認サービスを用いて、前記生成された承認要求を承認するか否か判定する判定ステップと、前記判定ステップの判定結果を出力する出力ステップとを有することを特徴とする情報処理方法

請求項32

更に前記出力された判定結果が承認であった場合に、該承認要求に対応する処理を実行する実行ステップを有することを特徴とする請求項31に記載の情報処理方法。

請求項33

前記承認サービスには、承認要求者と前記承認要求の内容に応じて判定するための判定条件が含まれることを特徴とする請求項31に記載の情報処理方法。

請求項34

前記判定条件には、更に承認要求生成した情報処理方法の情報も含まれることを特徴とする請求項33に記載の情報処理方法。

請求項35

前記判定ステップは、前記判定を禁止する期間か否か判断して、禁止期間であると判断した場合は、前記承認要求の承認判定を実行しないことを特徴とする請求項31に記載の情報処理方法。

請求項36

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末とを含む承認システムを制御する制御方法であって、前記クライアント端末においては、承認要求を生成する承認要求生成ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索して取得する取得ステップと、該取得した承認サービスを用いて前記承認要求の承認判定を行う判定実行ステップと、前記判定実行ステップの判定結果を出力する出力ステップとを有することを特徴とする承認システム制御方法。

請求項37

前記サービスプロバイダのおいては、前記承認サービスの情報が格納されたカードが挿入されるのに応答して、前記サービスサーバに前記承認サービスを登録し、前記カードが取り出されるのに応答して、前記サービスサーバから該当する承認サービスを削除することを特徴とする請求項36に記載の承認システム制御方法。

請求項38

更に、前記クライアント端末においては、複数の承認要求をメモリに格納する承認要求格納ステップを有し、前記判定実行ステップは、前記格納されている複数の承認要求の承認判定処理を実行するよう制御することを特徴とする請求項36に記載の承認システム制御方法。

請求項39

前記取得ステップでは、前記クライアント端末がネットワークを介して前記サービスサーバに接続されたのを検知すると、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索して取得することを特徴とする請求項38に記載の承認システム制御方法。

請求項40

前記クライアント端末は、携帯端末であることを特徴とする請求項39に記載の承認システム制御方法。

請求項41

前記取得ステップでは、前記承認要求が格納されたカードが前記クライアント端末に挿入されるのに応答して、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索して取得することを特徴とする請求項36に記載の承認システム制御方法。

請求項42

前記クライアント端末においては、更に前記出力された判定結果が承認であった場合に、該承認要求に対応する処理を実行する実行ステップを有することを特徴とする請求項36に記載の承認システム制御方法。

請求項43

前記承認サービスには、承認要求者と前記承認要求の内容に応じて判定するための判定条件が含まれることを特徴とする請求項36に記載の承認システム制御方法。

請求項44

前記取得ステップでは、更に前記承認サービスプロバイダに格納されている承認サービスも検索することを特徴とする請求項36に記載の承認システム制御方法。

請求項45

承認サービスプロバイダから登録するよう指示された承認サービスをメモリに複数格納する承認サービス格納ステップと、外部装置から検索指示された、承認要求に対応する承認サービスを検索して、該承認サービスを前記外部装置に送信する送信ステップとを有することを特徴とするサービスサーバ制御方法。

請求項46

前記承認サービスプロバイダにより新たな承認サービスが登録されると、登録通知を前記外部装置に通知する通知ステップを有することを特徴とする請求項45に記載のサービスサーバ制御方法。

請求項47

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末と、前記クライアント端末で生成された承認要求を格納するメモリを有するリクエストサーバとを含む承認システムの制御方法であって、前記リクエストサーバにおいては、前記クライアント端末で生成された承認要求を前記メモリに格納する承認要求格納ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記格納されている承認要求に適した承認サービスを検索して取得する取得ステップと、該取得した承認サービスを用いて前記承認要求の承認判定を行う判定実行ステップと、前記判定実行ステップの判定結果を出力する出力ステップとを有することを特徴とする承認システム制御方法。

請求項48

前記取得ステップでは、前記サービスサーバに該承認要求に対応する承認サービスが検索できなかった場合、該承認要求を前記メモリに保留しておき、前記サービスサーバに新たな承認サービスが登録されたことを検知すると、再度、前記保留されていた承認要求に対応する承認サービスを検索して取得することを特徴とする請求項47に記載の承認システム制御方法。

請求項49

前記サービスサーバにおいては、前記サービスプロバイダにより新たな承認サービスが登録されると、登録通知を前記リクエストサーバに通知する通知ステップを有することを特徴とする請求項48に記載の承認システム制御方法。

請求項50

前記サービスプロバイダに承認判定者がログインするのに応答して、該承認判定者に対応する承認サービスが前記サービスサーバに登録され、前記サービスプロバイダから承認判定者がログアウトするのに応答して、該承認判定者に対応する承認サービスが前記サービスサーバから削除されることを特徴とする請求項47に記載の承認システム制御方法。

請求項51

承認サービスが格納されたカードが前記サービスプロバイダに挿入されるのに応答して、該カードに格納されている承認サービスが前記サービスサーバに登録され、前記カードが前記サービスプロバイダから取り出されるのに応答して、該カードに格納されている承認サービスに対応する承認サービスが前記サービスサーバから削除されることを特徴とする請求項47に記載の承認システム制御方法。

請求項52

前記カードには、前記承認サービスで用いる判定条件データが含まれることを特徴とする請求項51に記載の承認システム制御方法。

請求項53

前記サービスプロバイダにおいては、前記挿入されたカードの前記判定条件データに基づいて、前記承認サービスを作成して、前記サービスサーバに登録することを特徴とする請求項52に記載の承認システム制御方法。

請求項54

前記クライアント端末においては、更に、前記出力ステップにより出力された判定結果を受信する受信ステップを有することを特徴とする請求項47に記載の承認システム制御方法。

請求項55

前記クライアント端末においては、更に前記受信した判定結果が承認であった場合に、該承認要求に対応する処理を実行する実行ステップを有することを特徴とする請求項54に記載の承認システム制御方法。

請求項56

前記承認サービスには、承認要求者と前記承認要求の内容に応じて判定するための判定条件が含まれることを特徴とする請求項47に記載の承認システム制御方法。

請求項57

前記取得ステップでは、更に前記承認サービスプロバイダに格納されている承認サービスも検索することを特徴とする請求項47に記載の承認システム制御方法。

請求項58

前記出力ステップにより出力された判定結果は、前記サービスプロバイダにも出力されることを特徴とする請求項47に記載の承認システム制御方法。

請求項59

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末とを含む承認システムの制御方法であって、前記クライアント端末においては、承認要求を生成する承認要求生成ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索する検索ステップと、前記検索ステップにより承認サービスが検索された場合、該承認要求を前記サービスサーバに送信する送信ステップと、前記サービスサーバから該送信した承認要求の承認判定結果を受信する受信ステップとを有し、前記サービスサーバにおいては、前記クライアント端末から送信されてきた承認要求を、該承認要求に適した承認サービスを用いて承認判定を行う判定実行ステップと、該承認判定結果を前記クライアント端末に送信する送信ステップとを有することを特徴とする承認システム制御方法。

請求項60

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末と、前記クライアント端末で生成された承認要求を格納するメモリを有するリクエストサーバとを含む承認システムであって、前記リクエストサーバにおいては、前記クライアント端末で生成された承認要求を前記メモリに格納する承認要求格納ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求格納ステップに格納されている承認要求に適した承認サービスを検索する検索ステップと、前記検索ステップにより承認サービスが検索された場合、該承認要求を前記サービスサーバに送信する送信ステップと、前記サービスサーバから該承認要求の承認判定結果を受信する受信ステップとを有し、前記サービスサーバにおいては、前記リクエストサーバから送信されてきた承認要求を、該承認要求に適した承認サービスを用いて承認判定を行う判定実行ステップと、該承認判定結果を前記リクエストサーバに送信する送信ステップとを有することを特徴とする承認システム制御方法。

請求項61

承認要求を生成する承認要求生成ステップと、承認サービスプロバイダにより設定される承認サービスを格納する格納ステップと、前記格納された承認サービスを用いて、前記生成された承認要求を承認するか否か判定する判定ステップと、前記判定ステップの判定結果を出力する出力ステップとを有することを特徴とするコンピュータ実行可能なコードから構成されるコンピュータプログラム

請求項62

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末とを含む承認システムを制御するコンピュータ実行可能な制御プログラムであって、前記クライアント端末においては、承認要求を生成する承認要求生成ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索して取得する取得ステップと、該取得した承認サービスを用いて前記承認要求の承認判定を行う判定実行ステップと、前記判定実行ステップの判定結果を出力する出力ステップとを有することを特徴とするコンピュータ実行可能な承認システム制御プログラム。

請求項63

承認サービスプロバイダから登録するよう指示された承認サービスをメモリに複数格納する承認サービス格納ステップと、外部装置から検索指示された、承認要求に対応する承認サービスを検索して、該承認サービスを前記外部装置に送信する送信ステップとを有することを特徴とするコンピュータ実行可能なサービスサーバ制御プログラム。

請求項64

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末と、前記クライアント端末で生成された承認要求を格納するメモリを有するリクエストサーバとを含む承認システムを制御するコンピュータ実行可能な制御プログラムであって、前記リクエストサーバにおいては、前記クライアント端末で生成された承認要求を前記メモリに格納する承認要求格納ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記格納されている承認要求に適した承認サービスを検索して取得する取得ステップと、該取得した承認サービスを用いて前記承認要求の承認判定を行う判定実行ステップと、前記判定実行ステップの判定結果を出力する出力ステップとを有することを特徴とするコンピュータ実行可能な承認システム制御プログラム。

請求項65

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末とを含む承認システムを制御するコンピュータ実行可能な制御プログラムであって、前記クライアント端末においては、承認要求を生成する承認要求生成ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求に適した承認サービスを検索する検索ステップと、前記検索ステップにより承認サービスが検索された場合、該承認要求を前記サービスサーバに送信する送信ステップと、前記サービスサーバから該送信した承認要求の承認判定結果を受信する受信ステップとを有し、前記サービスサーバにおいては、前記クライアント端末から送信されてきた承認要求を、該承認要求に適した承認サービスを用いて承認判定を行う判定実行ステップと、該承認判定結果を前記クライアント端末に送信する送信ステップとを有することを特徴とするコンピュータ実行可能な承認システム制御プログラム。

請求項66

承認サービスプロバイダによって登録された複数の承認サービスを管理するサービスサーバと、承認要求を生成するクライアント端末と、前記クライアント端末で生成された承認要求を格納するメモリを有するリクエストサーバとを含む承認システムを制御するコンピュータ実行可能な制御プログラムであって、前記リクエストサーバにおいては、前記クライアント端末で生成された承認要求を前記メモリに格納する承認要求格納ステップと、前記サービスサーバに登録されている複数の承認サービスの中から、前記承認要求格納ステップに格納されている承認要求に適した承認サービスを検索する検索ステップと、前記検索ステップにより承認サービスが検索された場合、該承認要求を前記サービスサーバに送信する送信ステップと、前記サービスサーバから該承認要求の承認判定結果を受信する受信ステップとを有し、前記サービスサーバにおいては、前記リクエストサーバから送信されてきた承認要求を、該承認要求に適した承認サービスを用いて承認判定を行う判定実行ステップと、該承認判定結果を前記リクエストサーバに送信する送信ステップとを有することを特徴とするコンピュータ実行可能な承認システム制御プログラム。

技術分野

0001

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

背景技術

0002

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

発明が解決しようとする課題

0003

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

課題を解決するための手段

0004

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

0005

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

0006

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

0007

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

0008

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

0009

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

0010

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

発明を実施するための最良の形態

0011

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

0012

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

0013

4は、プログラムメモリであり、フローチャートを参照しながら後に詳述する処理手順ならびにCPU2による他の制御手順をプログラムの形態で格納したメモリである。このプログラムメモリ4は、ROMであってもよいし、外部記憶装置などからプログラムがロードされるRAMであってもよい。

0014

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

0015

6は、CPU2の制御の対象となる各構成要素に指示を与えるためのアドレス信号,各構成要素を制御するためのコントロール信号各構成機器相互間で授受されるデータの転送を行うためのバスである。

0016

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

0017

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

0018

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

0019

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

0020

ステップS803で電源OFFを指示していると判断されなかった場合、次のステップS804で購買承認要求の生成開始を指示しているか否かが判断される。その結果、購買承認要求の生成開始を指示していると判断されなかった場合、再びステップS802に戻り、処理を繰り返す。

0021

ステップS804で購買承認要求の生成開始を指示していると判断された場合、次のステップS805の購買承認要求生成処理により、購買承認要求が生成され、次のステップS806で生成が成功したか否かが判断される。その結果、生成が成功したと判断されなかった場合、再びステップS802に戻り、処理を繰り返す。

0022

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

0023

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

0024

図9は、図8に示したシステム全体の流れにおける、ステップS805の購買承認要求生成処理の流れを示す図である。

0025

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

0026

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

0027

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

0028

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

0029

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

0030

本情報処理装置における購買承認要求入力画面では、購買承認要求の対象となる商品の名称121と、その分類123、金額124、納期125、優先度126を入力することができる。また、ステップS901及びS902で格納した商品名候補122や分類項目候補を表示し、その中から商品の名称や分類項目を選択することもできる。

0031

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

0032

図13および図14は、上記購買承認要求生成処理(ステップS805)によって、生成される購買承認要求の一例を示す図である。

0033

本情報処理装置における購買承認要求には、購買承認要求を行った要求者、操作を行った要求元、商品の名称、その分類、金額、納期、優先度などが格納されている。例えば、図13の例の場合、要求者「太郎」が、要求元「コンポ」から、商品名称「小さい」(3回再生分)」、分類「音楽」を、金額「¥80」で、納期「1999年12月15日」までに、優先度「80」で、生成された購買承認要求を示している。

0034

一方、図14の例の場合、要求者「太郎」が、要求元「コンポ」から、商品名称「第九(3回再生分)」、分類「“MusicFlash”」を、金額「¥80」で、納期「1999年12月15日」までに、優先度「90」で、生成された購買承認要求を示している。

0035

図15は、上記システム全体の流れにおける、ステップS807の購買承認判定処理の流れを示す図である。

0036

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

0037

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

0038

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

0039

ステップS1506で適用成功と判断された場合、次のステップS1507で承認判定者に確認する必要があるか否かを判断する。その結果、確認する必要があると判断された場合、ステップS1508の承認確認処理により、承認判定者に該承認要求を通知して承認するか否かを確認する。その結果、次のステップS1509で承認されたと判断されなかった場合、ステップS1511に進み、購買却下通知処理により、購買承認要求が却下されたことを要求者に通知し、却下として処理を終了する。

0040

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

0041

図16は、上記購買承認判定処理の流れにおける、ステップS1501の購買承認判定実行判断処理の流れを示す図である。

0042

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

0043

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

0044

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

0045

図17は、上記購買承認判定実行判断処理における、ステップS1601で参照される、購買承認判定実行フラグの定義の一例を示す図である。本情報処理装置における購買承認判定実行フラグでは、「OK」を購買承認判定実行可能、「NG」を購買承認判定実行禁止、上記以外を未設定として定義している。

0046

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

0047

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

0048

図19は、図15に示したステップS1505の承認判定情報適用処理で用いられる予算情報の一例を示す図である。

0049

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

0050

例えば、機器「コンポ」の分類「“MusicFlash”」には、「太郎」の予算枠¥2,000のみが確保されており、承認確認が不要である。また、機器「コンポ」の分類「音楽」には、「花子」の予算枠¥2,000、「拓哉」の予算枠¥500が確保されており、承認確認は必要である。

0051

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

0052

図2に示したように、本実施の形態で説明した装置に購買承認要求生成開始を指示すると、図8のステップS804で購買承認要求の生成開始を指示したと判断され、次のステップS805の購買承認要求生成処理により、購買承認要求が生成される。例えば、操作ユーザ「太郎」が、操作機器「コンポ」で、図12に示したように名称「小さい秋(3回再生分)」、分類「音楽」、金額「¥80」、納期「1999年12月15日」、優先度「80」を入力し、購買承認要求127を選択すると、図13に示したような購買承認要求が作成される。

0053

その結果、次のステップS806で購買承認要求の生成が成功したと判断され、続くステップS807の購買承認判定処理により、承認するか否かが判定される。

0054

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

0055

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

0056

一方、図14に示したような購買承認要求の場合、要求者「太郎」、機器「コンポ」で、分類「“MusicFlash”」が検索され、要求者「太郎」の予算枠¥2,000に、要求金額¥80を適用しようと試みた結果、予算に収まるので成功する。更に、ステップS1507で承認確認の必要性を判断した結果、「要」と指定されていないので不要と判断し、ステップS1510で購買が承認されたことを通知して、処理を終了する。

0057

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

0058

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

0059

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

0060

<実施の形態2>実施の形態1では、図2に示したように、承認サービスを行うための条件が予めクライアント端末に設定されていた。

0061

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

0062

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

0063

図20は、図3で示した、購買承認要求者が利用するクライアント端末、購買承認判定者が利用する承認者用端末、および購買承認サービスを登録管理するサービスサーバ間の関係を、より詳細に示した例である。サービスサーバ2001には、様々な承認サービス(2002〜2011)が登録される。

0064

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

0065

1.サービスプロバイダが「音楽承認サービス」を、サービスサーバ2001に登録する。これにより、サービスサーバ2001に音楽承認サービス2003が追加される。

0066

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

0067

3.承認判定を行うために、該承認要求に対応する承認サービスを、サービスサーバ2001から検索する。

0068

4.上記検索の結果、クライアント端末は、検索された承認サービスを取得する。

0069

5.クライアント端末は、取得した承認サービスを用いて、実施形態1と同様にして承認要求の判別を行う。

0070

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

0071

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

0072

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

0073

ステップS2103で電源OFFを指示していると判断されなかった場合、次のステップS2104で承認サービスに対する指示か否か判断される。その結果、承認サービスに対する指示と判断されなかった場合、再びステップS2102に戻る。

0074

ステップS2104で承認サービスの開始が指示されたと判断した場合、ステップS2105の承認サービス登録処理により、承認サービスをサービスサーバ2001に登録し、再びステップS2102に戻る。

0075

ステップS2104で承認サービスの終了が指示されたと判断した場合、ステップS2106の承認サービス削除処理により、承認サービスをサービスサーバ2001から削除し、再びステップS2102に戻る。

0076

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

0077

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

0078

ステップS2203で電源OFFを指示していると判断されなかった場合、次のステップS2204でイベントの種類が何かについて判断がなされる。その結果、承認サービスに対する指示と判断されなかった場合、再びステップS2202に戻る。

0079

ステップS2204で承認サービスの登録が指示されたと判断した場合、ステップS2205の承認サービス登録処理において、サービスプロバイダから送信されてきた承認サービスを承認サービス登録情報図23参照)として登録し、再びステップS2202に戻る。

0080

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

0081

ステップS2204で承認サービスの更新が指示されたと判断した場合、ステップS2207の承認サービス更新処理により、承認サービス登録情報として格納されている承認サービスを指示に応じて更新し、再びステップS2202に戻る。

0082

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

0083

図23は、購買承認サービスサーバ2001に登録・参照される購買承認サービス登録情報の一例を示す図である。

0084

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

0085

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

0086

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

0087

図25は、図22に示したステップS2208の購買承認サービス検索処理の流れを示す図である。

0088

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

0089

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

0090

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

0091

クライアント端末は、実施形態1と同様に図15の処理を行うが、本実施形態2では、ステップS1501の実行判断処理として、図26に示す処理を行うことになる。

0092

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

0093

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

0094

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

0095

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

0096

図27から図36は、図26に示したステップS2601の購買承認サービス検索処理で検索され、図15に示したステップS1505の承認判定情報適用処理で適用される、予算情報(すなわち、承認判定情報の1つ)の一例を示す図である。

0097

具体的には、図24で示したように、各予算情報はそれぞれの承認サービスの一部となっている。例えば、図27に示した「MusicFlash予算情報」は「MusicFlash承認サービス」の一部であり、その他図28図36に示した各予算情報も同様である。また、本情報処理装置における各予算情報(図27図36参照)には、要求機器毎に、それぞれの個人予算枠と、機器自身の予算枠と、承認確認(図15のステップS1508参照)が必要か否かを示すデータが格納されている。

0098

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

0099

既に図20に示したように、購買承認者が利用する購買承認サービスプロバイダで「音楽購買承認サービス」の開始が指示されると図21のステップS2105の購買承認サービス登録処理により、図20の2003のように「音楽購買承認サービス」が、サービスサーバ2001に登録される。

0100

図20に示したように、購買承認要求者によりクライアント端末で購買承認要求生成開始が指示されると、図8のステップS805の購買承認要求生成処理により、購買承認要求が生成される。

0101

例えば、操作ユーザ「太郎」が、操作機器「コンポ」で、図12に示したように名称「小さい秋(3回再生分)」、分類「音楽」、金額「¥80」、納期「1999年12月15日」、優先度「80」を入力し、購買承認要求127を選択すると、図13に示したような購買承認要求が作成される。

0102

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

0103

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

0104

一方、図14に示したような購買承認要求の場合、クライアント端末は、分類「“MusicFlash”」に対応して検索された「MusicFlash承認サービス」を取得する。次に、ステップS1503(図15参照)の承認判定情報検索処理により、図27の予算情報を参照した結果、要求機器「コンポ」が検索され、要求者「太郎」の予算枠¥2,000に、要求金額¥80を適用しようと試みた結果、予算に収まるので成功する。更に、ステップS1507で承認確認の必要性を判断した結果、図27に「要」と指定されていないので不要と判断し、ステップS1510で購買が承認されたことを通知して、処理を終了する。

0105

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

0106

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

0107

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

0108

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

0109

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

0110

<実施の形態3>図4に示すように、本実施形態3では、購買承認要求の生成と、承認判定処理を分離することで、より柔軟な運用を可能とする。

0111

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

0112

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

0113

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

0114

1.実施形態2と同様に、サービスプロバイダが「承認サービス」をサービスサーバに登録する。

0115

2.クライアント端末で生成された承認要求を、リクエストサーバ3701に登録する。

0116

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

0117

4.上記検索の結果、リクエストサーバ3701は検索された承認サービスを取得する。

0118

5.リクエストサーバ3701は、取得した承認サービスを用いて、格納されている承認要求の判断を行い、承認判断結果を、購買承認要求の要求元のクライアント端末に送る。

0119

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

0120

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

0121

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

0122

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

0123

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

0124

ステップS3803で電源OFFを指示していると判断されなかった場合、次のステップS3804で購買承認要求の生成開始を指示しているか否か判断される。

0125

ステップS3804で購買承認要求の生成開始を指示していると判断された場合、次のステップS3805の購買承認要求生成処理により、購買承認要求が生成され、次のステップS3806で生成が成功したか否かが判断される。その結果、生成が成功したと判断されなかった場合は、再びステップS3802に戻る。

0126

ステップS3806で生成が成功したと判断された場合、次のステップS3807の購買承認要求登録処理により、該生成された購買承認要求をリクエストサーバ3701に登録し、再びステップS3802に戻る。

0127

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

0128

ステップS3808で承認されたと判断された場合、次のステップS3809の購買実施処理により、上記購買承認要求に対応した処理を実行し、再びステップS3802に戻る。

0129

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

0130

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

0131

ステップS3904で電源OFFを指示していると判断されなかった場合、次のステップS3905でイベントの種類が何か判断される。その結果、承認要求に対する指示と判断されなかった場合、再びステップS3902に戻る。

0132

ステップS3905で承認要求の登録が指示されたと判断した場合、ステップS3906の承認要求登録処理により、クライアントから送信されてきた承認要求を承認要求登録情報(図40参照)に登録し、再びステップS3902に戻る。

0133

ステップS3905で承認要求の削除が指示されたと判断した場合、ステップS3907の承認要求削除処理により、対応する承認要求を承認要求登録情報から削除し、再びステップS3902に戻る。

0134

ステップS3905で承認要求の更新が指示されたと判断した場合、ステップS3908の承認要求更新処理により、承認要求登録情報として格納された対応する承認要求を更新し、再びステップS3902に戻る。

0135

ステップS3905で承認要求の検索が指示されたと判断した場合、ステップS3909の承認要求検索処理により、対応する承認要求を承認要求登録情報から検索し、要求元に渡し、再びステップS3902に戻る。

0136

図40は、図39に示したステップS3902の購買承認一括判定処理において参照される、購買承認要求登録情報の一例を示す図である。

0137

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

0138

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

0139

図42は、図39に示したステップS3902の購買承認一括判定処理のフローチャートである。

0140

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

0141

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

0142

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

0143

ステップS4204で却下されたと判断した場合、ステップS4205で購買却下イベントを要求元の要求者に通知し、ステップS4207で該処理対象の承認要求を購買承認要求登録情報から削除した上で、ステップS4208で処理対象を次の承認要求に進め、再びステップS4202に戻る。

0144

ステップS4204で承認されたと判断した場合、ステップS4206で購買承認イベントを要求元の要求者に通知し、ステップS4207で該処理対象の承認要求を購買承認要求登録情報から削除した上で、ステップS4208で処理対象を次の承認要求に進め、再びステップS4202に戻る。

0145

図43は、図42に示したステップS4203の購買承認判定処理のフローチャートである。

0146

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

0147

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

0148

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

0149

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

0150

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

0151

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

0152

先に述べた図37のように、クライアント端末で購買承認要求生成開始が指示されると、図38のステップS3805の購買承認要求生成処理により、購買承認要求が生成される。

0153

例えば、操作ユーザ「太郎」が、操作機器「コンポ」で、図12に示したように名称「小さい秋(3回再生分)」、分類「音楽」、金額「¥80」、納期「1999年12月15日」、優先度「80」を入力し、購買承認要求127を選択すると、図13に示したような購買承認要求が作成される。

0154

その結果、次のステップS3806で購買承認要求の生成が成功したと判断され、続くステップS3807の購買承認要求登録処理により、図37の3702のように「「小さい秋」購買承認要求」が、リクエストサーバ3701に登録される。

0155

これに対して、購買承認リクエストサーバ3701では、クライアント端末から購買承認要求の登録が指示されたと判断し、図40および図41のように上記購買承認要求を購買承認要求登録情報に登録する(S3906)。その後、ステップS3902の購買承認一括判定処理により、上記購買承認要求登録情報に格納された、それぞれの購買承認要求について、承認か否か判定される。

0156

具体的には、個々の購買承認要求について、ステップS4203の購買承認判定処理により、承認か否か判定される。

0157

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

0158

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

0159

一方、図14に示したような購買承認要求の場合、分類「“MusicFlash”」に対応して検索された「MusicFlash承認サービス」が提供するメソッドである。ステップS4303の承認判定情報検索処理により、図27の予算情報を参照した結果、要求機器「コンポ」が検索され、ステップS4305no承認判定情報適用処理により、要求者「太郎」の予算枠¥2,000に、要求金額¥80を適用しようと試みた結果、予算に収まるので成功する。更に、ステップS4307で承認確認の必要性を判断した結果、「要」と指定されていないので不要と判断し、ステップS4310で購買が承認されたことを通知して、処理を終了する。

0160

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

0161

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

0162

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

0163

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

0164

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

0165

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

0166

本実施の形態4では、具体的に下記のような流れで処理がなされる。

0167

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

0168

2.購買承認判定者がサービスプロバイダを用いて、購買承認サービスを購買承認サービスサーバに登録する。

0169

3.購買承認サービスサーバは、購買承認サービスが登録されると、購買承認サービス登録イベントを購買承認リクエストサーバに通知する。

0170

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

0171

5.承認サービスの検索に成功した場合、該承認サービスを取得して、承認要求の判定を行う。

0172

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

0173

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

0174

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

0175

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

0176

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

0177

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

0178

ステップS4503で電源OFFを指示していると判断されなかった場合、次のステップS4504でログイン・ログアウトに対する指示か否か判断される。その結果、ログイン・ログアウトに対する指示と判断されなかった場合、再びステップS4502に戻る。

0179

ステップS4504でログインが指示されたと判断した場合、ステップS4505の承認サービス取得処理により、後述する購買承認者対応情報を参照し、ログインした購買承認判定者に対応した購買承認サービス情報を全て取得する。続くステップS4506の承認サービス登録処理により、該取得した承認サービスをサービスサーバ4417(図44参照)に登録し、再びステップS4502に戻る。

0180

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

0181

図46は、図45に示したステップS4505およびステップS4507の承認サービス取得処理で参照される、購買承認者対応情報の一例を示す図である。

0182

本情報処理装置における購買承認者対応情報には、購買承認判定者と、それぞれの購買承認判定者に対応する購買承認サービスが定義されている。例えば、購買承認判定者「Takahashi」には購買承認サービス「MusicFlash承認サービス」が対応づけられており、購買承認判定者「Suzuki」には購買承認サービス「ニュース承認サービス」および「ドラマ承認サービス」が対応づけられている。

0183

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

0184

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

0185

ステップS4703で電源OFFを指示していると判断されなかった場合、次のステップS4704でイベントの種類が何か判断される。その結果、承認サービスに対する指示と判断されなかった場合、再びステップS4702に戻る。

0186

ステップS4704で承認サービスの登録が指示されたと判断した場合、ステップS4705の承認サービス登録処理により、サービスプロバイダから送信された承認サービスを承認サービス登録情報に登録し、次のステップS4706で購買承認サービス登録イベントを購買承認リクエストサーバに通知し、再びステップS4702に戻る。

0187

ステップS4704で承認サービスの削除が指示されたと判断した場合、ステップS4707の承認サービス削除処理により、対応する承認サービスを承認サービス登録情報から削除し、再びステップS4702に戻る。

0188

ステップS4704で承認サービスの更新が指示されたと判断した場合、ステップS4708の承認サービス更新処理により、承認サービス登録情報に格納された対応する承認サービスを更新し、再びステップS4702に戻る。

0189

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

0190

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

0191

図5で示したように、クライアント端末で購買承認要求生成開始が指示されると、図38のステップS3805の購買承認要求生成処理により、購買承認要求が生成される。

0192

例えば、操作ユーザ「太郎」が、操作機器「コンポ」で、図12に示したように名称「小さい秋(3回再生分)」、分類「音楽」、金額「¥80」、納期「1999年12月15日」、優先度「80」を入力し、購買承認要求127を選択すると、図13に示したような購買承認要求が作成される。

0193

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

0194

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

0195

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

0196

その後、図5および図44のように、購買承認サービスプロバイダで購買承認判定者「Yamada」がシステムにログインすると、図45のステップS4504でログインが指示されたと判断して、次のステップS4505の購買承認サービス取得処理により、購買承認者対応情報を参照した結果、「音楽承認サービス」が取得される。続く、ステップS4506の購買承認サービス登録処理により、図44の4403のように「音楽承認サービス」が、購買承認サービスサーバ4417に登録される。

0197

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

0198

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

0199

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

0200

一方、図14に示したような購買承認要求の場合、分類「“MusicFlash”」に対応して検索された「MusicFlash承認サービス」を取得する。ステップS4303の承認判定情報検索処理により、図27の予算情報を参照した結果、要求機器「コンポ」、要求者「太郎」の予算枠¥2,000に、要求金額¥80を適用しようと試みた結果、予算に収まるので成功する。更に、ステップS4307で承認確認の必要性を判断した結果、「要」と指定されていないので不要と判断し、ステップS4310で購買が承認されたことを通知して、処理を終了する。

0201

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

0202

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

0203

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

0204

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

0205

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

0206

具体的には、購買承認判定者が購買承認サービスプロバイダ4816に購買承認カード4812を挿入すると、購買承認サービスプロバイダ4816の承認サービス登録処理により、購買承認カード4812に格納された購買承認サービス4813が、購買承認サービスサーバ4817に登録される。また、購買承認判定者が購買承認カード4812を取り出すと、購買承認サービスプロバイダ4816の承認サービス削除処理により、対応する購買承認サービス4813が、購買承認サービスサーバ4817から削除される。

0207

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

0208

図49は、購買承認サービスプロバイダでの処理を示す図である。

0209

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

0210

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

0211

ステップS4903で電源OFFを指示していると判断されなかった場合、次のステップS4904で購買承認カードの挿入・取り出しの操作か否かが判断される。その結果、購買承認カードの挿入・取り出しの操作と判断されなかった場合、再びステップS4902に戻る。

0212

ステップS4904で購買承認カードの挿入操作と判断された場合、ステップS4905の承認サービス読み込み処理により、購買承認カードに格納されている承認サービスが読み込まれる。続くステップS4906の承認サービス登録処理により、読み込まれた承認サービスをサービスサーバ4817に登録し、再びステップS4902に戻る。

0213

ステップS4904で購買承認カードの取り出し操作と判断された場合、ステップS4907の承認サービス読み込み処理により、購買承認カードに格納されている承認サービスが読み込まれる。続くステップS4908の承認サービス削除処理により、対応する承認サービスをサービスサーバ4817から削除し、再びステップS4902に戻る。

0214

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

0215

図5のように、クライアント端末で購買承認要求生成開始が指示されると、図38のステップS3805の購買承認要求生成処理により、購買承認要求が生成される。

0216

例えば、操作ユーザ「太郎」が、操作機器「コンポ」で、図12に示したように名称「小さい秋(3回再生分)」、分類「音楽」、金額「¥80」、納期「1999年12月15日」、優先度「80」を入力し、購買承認要求127を選択すると、図13に示したような購買承認要求が作成される。

0217

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

0218

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

0219

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

0220

その後、図5および図48のように、購買承認サービスプロバイダ4816に、購買承認カード4812が挿入されると、図49のステップS4904で購買承認カードが挿入されたと判断して、次のステップS4905の購買承認サービス読み込み処理により、購買承認カードに格納されている承認サービスが読み込まれる。そして、ステップS4906の購買承認サービス登録処理により、図48の4803のように「音楽承認サービス」が、購買承認サービスサーバ4817に登録される。

0221

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

0222

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

0223

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

0224

一方、図14に示したような購買承認要求の場合、分類「“MusicFlash”」に対応して検索された「MusicFlash承認サービス」を取得する。ステップS4303の承認判定情報検索処理により、図27の予算情報を参照した結果、要求機器「コンポ」、要求者「太郎」の予算枠¥2,000に、要求金額¥80を適用しようと試みた結果、予算に収まるので成功する。更に、ステップS4307で承認確認の必要性を判断した結果、「要」と指定されていないので不要と判断し、ステップS4310で購買が承認されたことを通知して、処理を終了する。

0225

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

0226

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

0227

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

0228

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

0229

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

0230

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

0231

ステップS5103で電源OFFを指示していると判断されなかった場合、次のステップS5104で購買承認カードの挿入・取り出しの操作か否か判断される。その結果、購買承認カードの挿入・取り出しの操作と判断されなかった場合、再びステップS5102に戻る。

0232

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

0233

ステップS5104で購買承認カードの取り出し操作と判断された場合、ステップS5108の生成済み承認サービス取得処理により、上記生成された購買承認サービスを、後述する生成済み購買承認サービス情報を参照することで、取得する。続くステップS5109の承認サービス削除処理により、上記取得された承認サービスをサービスサーバ5017から削除し、再びステップS5102に戻る。

0234

図52は、図51に示したステップS5106の購買承認サービス生成処理を示す図である。

0235

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

0236

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

0237

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

0238

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

0239

図53は、図52のステップS5203で生成された購買承認サービスオブジェクトが格納された生成済み購買承認サービス情報の一例を示す図である。

0240

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

0241

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

0242

図5のように、クライアント端末で購買承認要求生成開始が指示されると、図38のステップS3805の購買承認要求生成処理により、購買承認要求が生成される。例えば、操作ユーザ「太郎」が、操作機器「コンポ」で、図12に示したように名称「小さい秋(3回再生分)」、分類「音楽」、金額「¥80」、納期「1999年12月15日」、優先度「80」を入力し、購買承認要求127を選択すると、図13に示したような購買承認要求が作成される。

0243

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

0244

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

0245

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

0246

その後、図5および図50のように、購買承認サービスプロバイダ5016に、購買承認カード5012が挿入されると、図51のステップS5104で購買承認カードが挿入されたと判断して、次のステップS5105の購買承認サービス情報読み込み処理により、購買承認カードに格納されている承認サービスに必要な情報が読み込まれ、続くステップS5106の承認サービス生成処理により、対応する購買承認サービスが生成される。そして、続くステップS5107の購買承認サービス登録処理により、図50の5003のように「音楽承認サービス」が、購買承認サービスサーバ5017に登録される。

0247

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

0248

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

0249

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

0250

一方、図14に示したような購買承認要求の場合、分類「“MusicFlash”」に対応して検索された「MusicFlash承認サービス」を取得する。ステップS4303の承認判定情報検索処理により、図27の予算情報を参照した結果、要求機器「コンポ」、要求者「太郎」の予算枠¥2,000に、要求金額¥80を適用しようと試みた結果、予算に収まるので成功する。更に、ステップS4307で承認確認の必要性を判断した結果、「要」と指定されていないので不要と判断し、ステップS4310で購買が承認されたことを通知して、処理を終了する。

0251

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

0252

<実施の形態7>本実施形態7では、図6のように、クライアント端末には、持ち運び可能な携帯情報端末(PDA)を用い、さらに、リクエストサーバ機能を持たせて承認要求を格納することができるようにする。更に、クライアント端末がネットワークに接続された時点でサービスサーバを検索して承認要求の判定処理を行うようにする。

0253

本実施形態7では、下記のような処理が行われる。

0254

1.購買承認判定者が購買承認サービスを購買承認サービスサーバに登録する。

0255

2.購買承認要求者が複数の購買承認要求を、購買承認要求者自身が携帯しているPDA(個人用携帯情報端末:PersonalDigitalAssistant)の購買承認リクエストサーバに登録するが、承認サービスを利用可能なネットワークに接続されていない場合には、その購買承認リクエストサーバが対応する承認サービスを検索できないことになるので、ネットワークへの接続イベントを検知するまで承認要求を格納しておく。

0256

3.クライアント端末がネットワークに接続されると、ネットワークへの接続イベントがリクエストサーバに通知される。

0257

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

0258

5.購買承認サービスが検索されれば、該承認サービスを取得し、該承認要求の判定を行う。

0259

6.取得された購買承認サービスを用いて承認判定を行った結果を通知する。

0260

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

0261

図54は、図6で説明した購買承認要求者自身が携帯しているPDA5416が持つ購買承認リクエストサーバ5401に登録しておいた購買承認要求を処理する例として、PDA5416を承認サービスが利用可能なネットワークに接続した様子を示している。

0262

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

0263

その後、購買承認要求者がネットワークにPDA5416を接続することで、PDAに格納されている購買承認要求に対する処理が実行される。

0264

図39のステップS3903で、発生したネットワーク接続イベントを検知し、ステップS3902の購買承認一括判定処理により、購買承認要求5402〜5411に対する購買承認サービスを取得し、承認判定を実行する。

0265

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

0266

<実施の形態8>本実施形態8では、購買承認要求を格納した購買承認要求カードを用いた場合を説明する。

0267

図55は、図6で説明した購買承認要求者自身が携帯しているPDAを直接ネットワークに接続する代わりに、購買承認要求5502〜5511を格納した購買承認要求カード5512を、購買承認リクエストサーバを有するネットワークに接続されたカードリーダ5516に、挿入した様子を示している。

0268

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

0269

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

0270

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

0271

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

0272

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

0273

ステップS5604で電源OFFを指示していると判断されなかった場合、次のステップS5605でカード操作か否かが判断される。その結果、カード操作と判断されなかった場合、ステップS5610に進む。

0274

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

0275

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

0276

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

0277

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

0278

ステップS5610で承認要求の削除を指示していると判断された場合、ステップS5612の承認要求削除処理により、対応する承認要求を承認要求登録情報から削除し、再びステップS5602に戻る。

0279

ステップS5610で承認要求の更新を指示していると判断された場合、ステップS5613の承認要求更新処理により、承認要求登録情報に格納された対応する承認要求を更新し、再びステップS5602に戻る。

0280

ステップS5610で承認要求の検索を指示していると判断された場合、ステップS5614の承認要求検索処理により、対応する承認要求を承認要求登録情報から検索し、要求元に渡し、再びステップS5602に戻る。

0281

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

0282

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

0283

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

0284

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

0285

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

0286

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

0287

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

0288

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

0289

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

0290

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

0291

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

0292

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

発明の効果

0293

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

図面の簡単な説明

0294

図1従来技術による購買承認処理の流れを示す説明図である。
図2実施の形態1における、1つの装置内あるいは単一システム内で行われる購買承認の処理を示す説明図である。
図3実施の形態2における、サービスサーバを利用した購買承認の処理を示す説明図である。
図4実施の形態3における、リクエストサーバを利用した購買承認の処理を示す説明図である。
図5実施の形態4,5,6における、後から承認サービスが登録された場合の購買承認の処理を示す説明図である。
図6実施の形態7,8における、後からリクエストサーバが接続された場合の購買承認の処理を示す説明図である。
図7本発明を適用した各実施の形態で用いる情報処理装置のハードウェア構成を示すブロック図である。
図8本発明を適用した実施の形態における、購買承認要求側システム全体の処理の流れを示すフローチャートである。
図9本発明を適用した実施の形態における、購買承認要求生成処理の流れを示すフローチャートである。
図10本発明を適用した実施の形態における、購買履歴の一例を示す図である。
図11本発明を適用した実施の形態における、分類項目一覧の一例を示す図である。
図12本発明を適用した実施の形態における、購買承認要求入力画面の一例を示す図である。
図13本発明を適用した実施の形態における、生成された購買承認要求の一例を示す図である。
図14本発明を適用した実施の形態における、生成された購買承認要求の一例を示す図である。
図15本発明を適用した実施の形態における、購買承認判定処理の流れを示すフローチャートである。
図16本発明を適用した実施の形態における、購買承認判定実行判断処理の流れを示すフローチャートである。
図17本発明を適用した実施の形態における、購買承認判定実行判断フラグの定義を示す図である。
図18本発明を適用した実施の形態における、購買承認判定実行禁止スケジュールの一例を示す図である。
図19本発明を適用した実施の形態における、予算情報の一例を示す図である。
図20本発明を適用した実施の形態における、サービスサーバに登録された情報の一例を明示すると共に、サービスサーバを利用した購買承認の流れを示す図である。
図21本発明を適用した実施の形態における、購買承認サービスプロバイダシステム全体の処理の流れを示すフローチャートである。
図22本発明を適用した実施の形態における、購買承認サービスサーバシステム全体の処理の流れを示すフローチャートである。
図23本発明を適用した実施の形態における、購買承認サービス登録情報の一例を示す図である。
図24本発明を適用した実施の形態における、サービスサーバに登録された情報、および購買承認サービスの一例を示す図である。
図25本発明を適用した実施の形態における、購買承認サービス検索処理の流れを示すフローチャートである。
図26本発明を適用した実施の形態における、購買承認判定実行判断処理の流れを示すフローチャートである。
図27本発明を適用した実施の形態における、MusicFlash予算情報の一例を示す図である。
図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本発明を適用した実施の形態における、PDAのネットワーク接続操作に連動して、後からリクエストサーバが接続された場合の購買承認の処理を示す説明図である。
図55本発明を適用した実施の形態における、購買承認要求カードの挿入操作に連動して、後からリクエストサーバに一括登録された場合の購買承認の処理を示す説明図である。
図56本発明を適用した実施の形態における、購買承認リクエストサーバシステム全体の処理の流れを示すフローチャートである。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ