認証ワークフローシステム、認証サーバ装置、決裁に関する認証方法、記録媒体
【課題】 発注を実際に行うまでの決裁処理を簡素化し、一連の電子商取引をよりスムーズに行えるようにする。
【解決手段】 認証ルートおよび各人が持つ商品購入限度額などを登録する認証情報登録部１７と、ユーザ端末内の注文入力部３１により入力された商品の購入金額とその商品の注文を行った者の商品購入限度額とを比較し、商品の購入金額が商品購入限度額を超えている場合に、認証ルートとして設定された承認者に対して承認を要求する通知を行う状態遷移制御部２１および承認依頼通知部２６と、通知された承認要求に対して承認を行う承認入力部３２とを備え、決裁処理を電子的に行うことにより簡素化し、一連の電子商取引をよりスムーズに行うことができるようにする。
【解決手段】 認証ルートおよび各人が持つ商品購入限度額などを登録する認証情報登録部１７と、ユーザ端末内の注文入力部３１により入力された商品の購入金額とその商品の注文を行った者の商品購入限度額とを比較し、商品の購入金額が商品購入限度額を超えている場合に、認証ルートとして設定された承認者に対して承認を要求する通知を行う状態遷移制御部２１および承認依頼通知部２６と、通知された承認要求に対して承認を行う承認入力部３２とを備え、決裁処理を電子的に行うことにより簡素化し、一連の電子商取引をよりスムーズに行うことができるようにする。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、認証ワークフローシステム、認証サーバ装置、決裁に関する認証方法、記録媒体に関し、特に、イントラネットやインターネットなどのネットワーク上での商取引を行う際に必要な決裁、管理などのワークフローを支援するシステムに用いて好適なものである。
【０００２】
【従来の技術】一般に、商取引を大きく分けると、企業が消費者に商品やサービスを提供するいわゆるＢ to Ｃ（Business to Consumer）の取引と、企業間の取引を意味するいわゆるＢ to Ｂ（Business to Business）の取引とがある。
【０００３】ここで、Ｂ to Ｃの取引において個々の消費者が商品を購入する場合は、その消費者個人の決断で購入するものを自由に決定し、実際に購入することが可能である。しかし、Ｂ to Ｂの取引において企業が商品を購入する場合は、その企業内の個々の担当者が購入するものを一人で決定することはできず、所定のルートに従って上司の決裁（承認）を受けなければいけないのが一般的である。
【０００４】近年、コンピュータの広範な普及、インターネット等のネットワーク技術の進展などを背景として、インターネットのウェブページ上に公開された商品をネット上で売買するオンラインショッピングが盛んに行われている。このオンラインショッピングシステムに関しても、Ｂ to Ｃをターゲットにしたシステムと、Ｂto Ｂをターゲットにしたシステムとが提案されている。
【０００５】
【発明が解決しようとする課題】従来、Ｂ to Ｂの取引において、例えばある企業が商品を購入する際の決裁は、紙ベースで行われていた。すなわち、ある企業内の担当者が商品を購入しようとする場合は、購入希望の商品やその金額などを記述した書類を作成し、それを上司に提出することによって承認を得るようにしていた。
【０００６】しかしこれでは、購入希望を出してから承認を得るまでの段階で紙ベースによる煩雑な事務処理を行う必要があり、商品の注文をスムーズに行うことができない問題があった。特に、オンラインショッピングのシステムを利用して商品を購入する場合、商品の選択や発注自体はオンライン上で簡単に行えるにもかかわらず、その発注に至るまでの処理に多大の労力と時間がかかり、ネット販売による便利さの利益を完全に享受することができないという問題があった。
【０００７】また、販売側の企業等にとっても、購入側の担当者によって行われた注文がきちんと承認を得ているものかどうかが分からない限り、注文を安易に受けることができないという問題がある。すなわち、担当者からの注文が正式に承認されたものでないと、取引が後に取り止めになってしまったり、商品を納入しても代金が支払われないなどのトラブルを引き起こす可能性がある。そのため、注文が購入側で正式に承認を得たものであるかどうかを確認し、承認済みの注文のみを受けるようにする仕組みが望まれていた。
【０００８】本発明は、このような実情に鑑みて成されたものであり、最終的な承認を得るまでの決裁処理を簡素化し、一連の商取引をよりスムーズに行えるようにすることを目的としている。また、本発明は、商品の販売側において、購入側から発注された注文が正式に承認を得ているかどうかを確実に確認できるようにし、商取引上のトラブル発生を少なくできるようにすることをも目的としている。
【０００９】
【課題を解決するための手段】本発明の認証ワークフローシステムは、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を登録する認証情報登録手段と、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力手段と、上記購入商品情報入力手段により入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証情報登録手段により登録された承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に対応して、承認に関する情報を入力する承認手段とを備えたことを特徴とする。
【００１０】本発明の他の態様では、上記承認要求通知手段は、上記購入商品情報入力手段により入力された商品の購入金額と、ある承認者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合に、更に上の承認者に対して承認を要求する通知を行うことを特徴とする。
【００１１】本発明のその他の態様では、上記承認手段によって必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする。本発明のその他の態様では、上記確認通知手段は、上記承認手段によって必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする。
【００１２】本発明のその他の態様では、上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認手段による承認に関する情報入力をウェブブラウザによる入力画面で行うようにしたことを特徴とする。
【００１３】本発明のその他の態様では、上記電子メールに埋め込まれたアドレスに従って上記ウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うログイン手段を備えたことを特徴とする。
【００１４】本発明のその他の態様では、上記ウェブブラウザによる入力画面には、上記商品の購入金額に応じて必要となる全ての承認者および承認の有無を表示することを特徴とする。
【００１５】本発明のその他の態様では、上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を参照する状態参照手段とを備えたことを特徴とする。
【００１６】本発明のその他の態様では、上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする。
【００１７】本発明のその他の態様では、上記商取引はネットワーク上で行われる電子商取引であることを特徴とする。
【００１８】本発明のその他の態様では、上記承認手段によって必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする。
【００１９】本発明のその他の態様では、必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする。
【００２０】本発明のその他の態様では、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートを登録する認証情報登録手段と、上記認証情報登録手段により登録された認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする。
【００２１】本発明のその他の態様では、上記認証情報登録手段は、上記認証ワークフローに関する処理を行う認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって上記認証情報の登録を行うことを特徴とする。
【００２２】また、本発明の認証サーバ装置は、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を記憶する認証情報記憶手段と、入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報記憶手段により記憶されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に応じて上記承認者により入力された承認に関する情報を受け付ける承認受付手段とを備えたことを特徴とする。
【００２３】本発明のその他の態様では、必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする。本発明のその他の態様では、上記確認通知手段は、必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする。
【００２４】本発明のその他の態様では、上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認要求通知の電子メールに埋め込まれたアドレスが指定されたときに、所定のログイン処理を経て上記承認を促すためのウェブブラウザによる入力画面に遷移させるようにしたことを特徴とする。
【００２５】本発明のその他の態様では、上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を要求に応じて提供する状態情報提供手段とを備えたことを特徴とする。
【００２６】本発明のその他の態様では、上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする。
【００２７】本発明のその他の態様では、必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする。本発明のその他の態様では、上記必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする。
【００２８】本発明のその他の態様では、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートを記憶する認証情報記憶手段と、上記認証情報記憶手段により記憶されている認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする。
【００２９】本発明のその他の態様では、上記認証情報記憶手段に記憶される認証情報は、上記認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって登録されることを特徴とする。
【００３０】また、本発明の決裁に関する認証方法は、商取引において必要となる決裁の認証を行う決裁に関する認証方法であって、認証ルートおよび各承認者が持つ商品購入限度額などの認証情報を登録する認証情報登録ステップと、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力ステップと、上記入力された商品の購入金額と、その入力を行った者に関して登録されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知ステップと、上記通知された承認要求に対応して、承認に関する情報を入力する承認ステップとを有することを特徴とする。
【００３１】また、本発明のコンピュータ読み取り可能な記録媒体は、請求項１〜２５の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラム、あるいは、請求項２６〜３４の何れか１項に記載された決裁の認証方法の処理手順をコンピュータに実行させるためのプログラム記録したことを特徴とする。
【００３２】本発明は上記技術手段より成るので、商取引において必要となる決裁の一連の認証が電子的なワークフロー処理によって行われ、紙ベースによる煩雑な事務処理は全く行う必要がなくなる。また、認証ルートがあらかじめ登録され、これに従って認証の処理が半自動的に行われることとなるので、希望する商品を購入するのに承認が必要かどうかや、誰の承認を得なければならないか等について何ら意識する必要がない。また、商品の購入金額に応じて必要となる全ての承認者および承認の有無を承認入力画面に表示することにより、承認が必要な者と認証ワークフローの進捗状況が一目瞭然となる。
【００３３】本発明の他の特徴によれば、必要な承認が全て得られたときには注文受付の確認メッセージを注文者に対して通知し、必要な承認が却下されたときには注文却下の確認メッセージを注文者に対して通知するようにしたので、スピーディかつ正確な注文の確認を行うことが可能となる。
【００３４】本発明のその他の特徴によれば、承認要求の通知や確認メッセージの通知を電子メールで行うとともに、承認をウェブブラウザによる入力画面で行うようにしたので、各人が使用する端末においては電子メールの機能とウェブブラウザの機能とがあれば良く、特別なクライアントソフトウェアなどを備える必要はない。
【００３５】本発明のその他の特徴によれば、電子メールに埋め込まれたアドレスに従ってウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うようにしたので、承認を行う権限を有する承認者だけが実際に承認を行えるようになり、認証に関する不正や間違いを防止することが可能となる。
【００３６】本発明のその他の特徴によれば、認証ワークフローの現在の状態を参照できるようにしたので、例えば、注文を出してから最終的な認証が下りるまでに時間がかかっているような場合に、認証ワークフローがどこで停滞しているかなどの確認を行うことが可能となる。
【００３７】また、本発明のその他の特徴によれば、承認要求が通知された承認者の代わりに、更に上の承認者が承認に関する情報を入力することを認めるようにしたので、認証ワークフローの状態がある承認者のところで停滞していても、代理の承認者によって承認を行うことができ、一連の認証処理を速やかに行うことが可能となる。
【００３８】本発明のその他の特徴によれば、商取引がネットワーク上で行われる電子商取引であり、必要な承認が全て得られた注文については次工程の処理を実行するようにしたので、注文を最終的に承認するまでの決裁処理と、オンライン上で発注や配送指示などを行う次工程の処理とを有機的に結び付けて一連の電子商取引をよりスムーズに行うことが可能となる。また、商品販売側の企業にとっても、発注された注文が正式に承認を得ているかどうかを容易に把握することが可能となる。
【００３９】本発明のその他の特徴によれば、必要な承認の全てが得られていない注文については次工程の処理の実行を禁止するようにしたので、最終的な決裁が下りていない注文が誤って発注されてしまうなどの不都合を防ぐことが可能となる。
【００４０】本発明のその他の特徴によれば、認証サーバ装置とは別の端末から認証サーバ装置へのウェブによるアクセスによって認証情報を登録するようにしたので、認証情報の登録を、認証サーバを管理する場所とは別の場所から行うことが可能となる。例えば、この認証情報の登録をそれぞれの購入側企業において分散して行うことにより、認証サーバの管理側の負担を軽減することが可能となる。
【００４１】
【発明の実施の形態】以下、本発明の一実施形態を図面に基づいて説明する。
【００４２】（第１の実施形態）図１は、第１の実施形態による認証ワークフローシステムの一構成例を示す図である。この図１に示すシステムは、例えば企業内の担当者２がインターネット７上で商品を購入する際に、その商取引に伴う決裁のワークフローを認証サーバ１で処理し、一連の認証処理を電子的に行うようにした例について示すものである。
【００４３】図１において、認証サーバ１は、例えばオンラインショッピングの電子店舗を持つ企業、あるいは当該企業の委託を受けたデータセンタ等に置かれる。また、ユーザ端末２，３，４は、例えば商品を購入する側の企業等に置かれる。そして、上記認証サーバ１とユーザ端末２，３，４とがインターネット７を介して接続される。
【００４４】上記ユーザ端末２，３，４のうち、２は担当者端末であり、希望商品の注文を行う担当者が使用するものである。３，４は承認者端末であり、担当者により行われた注文を承認する上司などが使用するものである。ここでは、一方の承認者端末３は担当者の直属の上司が使用する端末であり、もう一方の承認者端末４は更にその上司が使用する端末であるものとして説明する。
【００４５】なお、ここで言う担当者端末２および承認者端末３，４は、物理的な端末ではなく、論理的な端末を意味する。つまり、物理的に同じ端末でも、それを使用する者が担当者であれば担当者端末２となり、承認者であれば承認者端末３，４となる。また、ここでは説明の便宜上、上司は、担当者によりなされた注文の承認を行うものとしたが、上司自身が商品の注文を行うことができることは言うまでもない。
【００４６】本実施形態の認証ワークフローシステムでは、例えば担当者端末２から商品の注文が入力されると、当該担当者端末２および承認者端末３，４を含むユーザ端末と認証サーバ１との間のインタラクティブ処理により、その入力された注文に関する一連の電子決裁（上司による承認）の処理が行われる。そして、最終的に決裁が下りた時点で、入力された注文の受注が完了することとなる。
【００４７】図２は、上記認証サーバ１およびユーザ端末２，３，４の機能的な構成例を示すブロック図である。図２において、１１はウェブサーバであり、ユーザ端末２，３，４に対してＨＴＭＬ（Hyper Text Markup Language）などの情報を提供する。具体的には、ユーザ端末２，３，４からの要求に応じて、商品の注文を行うための注文入力画面、注文の承認を行うための注文承認画面、当該注文承認画面に遷移するためのログイン画面などをＨＴＭＬ形式で提供する。
【００４８】１２はメールサーバであり、本実施形態では特に、認証サーバ１内で作成された電子メールをユーザ端末２，３，４に送信する処理を行う。具体的には、一定の場合に認証サーバ１内で作成される注文承認依頼に関する電子メールを承認者端末３，４に送信したり、注文受付や注文却下の確認メッセージに関する電子メールを注文者の担当者端末２に送信したりする。
【００４９】１３は商品登録部であり、電子店舗において販売している商品に関する種々の情報を登録する。ここで登録する商品情報には、例えば商品名、商品の仕様、標準単価、仕切率、販売単価、備考事項などが含まれる。この商品情報の登録は、例えば認証サーバ１が備える表示装置に表示された入力画面において、キーボードやマウスなどの入力デバイスを用いて商品情報を入力することによって行う。また、認証サーバ１以外の端末で作成された商品情報を、フロッピー（登録商標）ディスクなどのリムーバル記憶媒体あるいはインターネット７を介して入力することによって登録しても良い。登録された商品情報は、商品情報記憶部１４に蓄積保存される。
【００５０】１５は取引先登録部であり、商品の取引先に関する種々の情報を登録する。ここで登録する取引先情報には、例えば購入側企業の企業名、電子メールアドレス、備考事項などが含まれる。この取引先情報の登録は、例えば認証サーバ１が備える表示装置に表示された入力画面において、キーボードやマウスなどの入力デバイスを用いて取引先情報を入力することによって行う。また、認証サーバ１以外の端末で作成された取引先情報をフロッピーディスクなどのリムーバル記憶媒体あるいはインターネット７を介して入力することによって登録しても良い。登録された取引先情報は、取引先情報記憶部１６に蓄積保存される。
【００５１】３１は注文入力部であり、ユーザ端末２，３，４が備えるウェブブラウザ機能を用いて、所望の商品を購入するための注文を入力する。具体的には、ユーザ端末２，３，４が備えるキーボードやマウスなどの入力デバイスを用いて所定のＵＲＬ（Uniform Resource Locator）を指定することにより、商品を選択して注文を行うための画面を表示装置に表示させ、ここで注文の入力を行う。この注文入力画面は、認証サーバ１内の商品情報記憶部１４に記憶されている商品情報等に基づいてウェブサーバ１１によって提供される。本発明の購入商品情報入力手段はこの注文入力部３１を含んで構成される。
【００５２】１７は認証情報登録部であり、商品購入側で注文の承認を行う際における一連の認証ルートおよび各人が持つ商品購入限度額（決裁権限）などの認証情報を登録する。ここで登録する認証ルートは、１つの企業内で完結する認証ルートだけでなく、複数の企業にまたがったグループ企業内の認証ルートであっても良い。また、企業に関する認証ルートに限らず、一連の承認処理が必要なその他の団体等についても認証ルートを任意に設定することが可能である。
【００５３】以下では一例として、１つの企業内で完結する認証ルートを登録する場合について説明する。この場合における認証ルートの登録は、例えば、企業内の組織および各組織部門における担当者（購入者）および承認者などの組織情報を登録することによって行うことが可能である。
【００５４】このような認証情報の登録は、例えば認証サーバ１が備える表示装置に表示された入力画面において、キーボードやマウスなどの入力デバイスを用いて認証情報を入力することによって行う。また、認証サーバ１以外の端末で作成された認証情報をフロッピーディスクなどのリムーバル記憶媒体あるいはインターネット７を介して入力することによって登録しても良い。登録された認証情報は、認証情報記憶部１８に蓄積保存される。
【００５５】図４は、認証サーバ１の表示装置に表示される認証情報の登録画面の一例を示す図である。図４に示す認証情報登録画面（ワークフロー設定画面）には、認証ルート（例えば企業内の組織情報）を登録するためのフィールド４１と、企業内の各人に関して認証を行うのに必要な種々の情報を登録するためのフィールド４２とが含まれる。
【００５６】企業内の組織情報は、図４のフィールド４１に示すようにツリー構造で表す。そして、ツリー構造で表したそれぞれの組織部門に少なくとも一人の承認者（上司）を設定する。図４の例では、社長、事業部長、部長、課長が承認者に設定され、これらは承認者であることを表すマークで表示されている。また、開発２課の中には課長の他に担当者Ａ，Ｂ，Ｃが含まれていることが示されており、これらは承認者と異なるマークで表示されている。
【００５７】また、各人に関する認証のための情報としては、図４のフィールド４２に示すように、ログインＩＤ、パスワード、氏名、部署名、電子メールアドレス、購入限度額（決裁権限）などを登録する。購入限度額は通常、担当者＜課長＜部長＜事業部長＜社長の順で高く設定される。担当者の購入限度額を０円に設定することもある。
【００５８】図２に戻り、１９は注文管理部であり、ユーザ端末２，３，４の注文入力部３１から送られてくる注文情報を入力し、管理する処理を行う。具体的には、注文管理部１９は、注文入力部３１からウェブサーバ１１を介して入力される注文ごとにユニークな番号を付し、注文情報記憶部２０に蓄積保存して管理する。ここでの注文情報には、購入する商品名、購入数、購入金額などの情報が含まれる。
【００５９】２１は状態遷移制御部であり、注文情報記憶部２０に記憶されている注文情報および認証情報記憶部１８に記憶されている認証情報に基づいて、認証ワークフローの状態を適宜遷移させる処理を行う。すなわち、注文管理部１９で最初に注文の入力が行われたときには、当該注文管理部１９からの通知を受けて、その注文に関するワークフローの状態を初期状態（未承認の状態）に設定する。その後は、承認者によって注文の承認が行われる毎に、ワークフローの状態を逐次遷移させる処理を行う。
【００６０】この状態遷移制御部２１によるワークフローの状態遷移は、対象とする注文に関してワークフローの遷移状態を表した情報をワークフロー情報記憶部２２の中から読み出し、後述する承認受付部２５から与えられる承認情報に従って、承認を行った者の状態を未承認から承認済に変更することによって行われる。
【００６１】本実施形態の状態遷移制御部２１は、上述のように認証ワークフローの状態を遷移させる処理を行う過程で、必要に応じて、後述する承認依頼通知部２６に指示を出して承認依頼の通知メールを承認者端末３，４に送信したり、後述する確認メッセージ通知部２７に指示を出して注文受付や注文却下の確認メッセージの通知メールを注文者の担当者端末２に送信したりする処理も行う。
【００６２】すなわち、状態遷移制御部２１は、注文情報記憶部２０に注文情報の一部として記憶されている商品の購入金額（複数の商品を購入した場合にはトータルの金額）と、認証情報記憶部１８に認証情報の一部として記憶されている、注文を行った者の購入限度額とを比較する。そして、商品の購入金額が注文者の購入限度額を超えている場合に、承認依頼通知部２６に対して承認依頼の通知メールを承認者端末３，４に送信することを指示する。
【００６３】また、ある承認者が上記承認依頼の通知メールに基づき注文の承認を行った場合には、状態遷移制御部２１は、注文情報記憶部２０に注文情報の一部として記憶されている商品の購入金額と、認証情報記憶部１８に認証情報の一部として記憶されている上記承認者の購入限度額とを比較する。そして、商品の購入金額がその承認者の購入限度額を超えている場合に、承認依頼通知部２６に対して承認依頼の通知メールを承認者端末３，４に送信することを指示する。
【００６４】つまり、例えば担当者Ａからある商品の注文が行われた場合に、その商品の購入金額が担当者Ａの購入限度額を超えているときには、承認依頼通知部２６に対して、承認依頼の通知メールを直属の上司（課長）の承認者端末３に送信することを指示する。また、当該課長によって承認が行われたときにも、上記商品の購入金額と課長の購入限度額とを比較する。そして、商品の購入金額が課長の購入限度額を超えている場合には、承認依頼通知部２６に対して、承認依頼の通知メールを更に上司（部長）の承認者端末４に送信することを指示する。このときどの承認者端末３，４に通知を行うかは、認証情報記憶部１８に記憶されている認証ルート情報に基づいて判断する。
【００６５】また、状態遷移制御部２１は、注文情報記憶部２０に注文情報の一部として記憶されている商品の購入金額と、認証情報記憶部１８に認証情報の一部として記憶されている購入限度額とを比較し、商品の購入金額が購入限度額内に収まっている場合（商品の購入金額が注文を行った者の購入限度額以下の場合、必要な承認が全て得られた場合の双方を含む）に、確認メッセージ通知部２７に対して注文受付の確認メールを担当者端末２に送信することを指示する。
【００６６】さらに、状態遷移制御部２１は、ある承認者によって注文が却下された場合には、確認メッセージ通知部２７に対して注文却下の確認メールを担当者端末２に送信することを指示する。
【００６７】上記承認依頼通知部２６は、上記状態遷移制御部２１からの指示に応じて、メールサーバ１２を用いて承認者端末３，４に対して承認依頼の通知を電子メールで行う。承認依頼通知部２６がこの承認依頼の通知を行うときは、注文を行った者の端末（担当者端末２、承認者端末３，４の何れか）に対して、承認が必要であることを知らせる確認通知も電子メールで行う。本発明の承認要求通知手段は、上記状態遷移制御部２１および承認依頼通知部２６を含んで構成される。
【００６８】また、確認メッセージ通知部２７は、上記状態遷移制御部２１からの指示に応じて、承認が不要であるか全ての承認が済んだことを知らせる注文受付の確認メッセージ、または何れかの承認者で承認が行われずに注文が却下されたことを表す注文却下の確認メッセージをメールサーバ１２を用いて電子メールで通知する。本発明の確認通知手段は、上記状態遷移制御部２１および確認メッセージ通知部２７を含んで構成される。
【００６９】３４は通知受信部であり、認証サーバ１のメールサーバ１２から電子メールの形で送られてくる種々の通知を受信する。すなわち、この通知受信部３４は、上述の承認依頼通知部２６により行われる注文承認の依頼通知および承認依頼の確認通知に関する電子メールを受信する。また、上述の確認メッセージ通知部２７により行われる注文受付および注文却下の確認通知に関する電子メールも受信する。
【００７０】図５は、承認依頼通知部２６からメールサーバ１２により承認者端末３，４に送られてくる注文承認依頼メッセージの電子メールの表示例を示す図である。図５に示すように、注文承認依頼メールの中には、注文承認画面のＵＲＬ５１が埋めこまれている。この注文承認依頼メールを受け取った承認者は、その中のＵＲＬ５１をマウスでクリックすることにより、ウェブブラウザによる注文承認画面を承認者端末３，４の表示装置に表示させることができる。
【００７１】本実施形態では、この注文承認依頼メールに埋め込まれたＵＲＬ５１に従って注文承認画面に遷移する際に、所定のログイン処理を行う。すなわち、上記ＵＲＬ５１をクリックすると、まずはウェブサーバ１１によってログイン画面が提供され、ログインＩＤとパスワードの入力が促される。ここで、承認者がログイン情報入力部３３を用いてログインＩＤやパスワードを入力すると、それが認証サーバ１の認証部２３に送られて認証処理が行われる。
【００７２】認証部２３では、認証情報記憶部１８に記憶されている認証情報に基づいて、入力されたログインＩＤとパスワードとを検証し、ログインしてきた者が承認者として登録されているかどうか、注文を行った者に対して承認を行う権限を有する正当な承認者かどうかなどを調べる。そして、認証が得られたときにのみ注文承認画面に遷移させる処理を行う。このようにすることにより、承認を行う権限を有する承認者だけが実際に承認を行えるようになり、認証に関する不正や間違いを防止することが可能となる。本発明のログイン手段は、認証部２３およびログイン情報入力部３３を含んで構成される。
【００７３】２４は承認画面作成部であり、上記認証部２３により承認者の認証が得られたときに、商品情報記憶部１４に記憶されている商品情報、認証情報記憶部１８に記憶されている認証情報、注文情報記憶部２０に記憶されている注文情報、ワークフロー情報記憶部２２記憶されているワークフロー情報などに基づいて、ＨＴＭＬ形式による注文承認画面を作成する。ここで作成された注文承認画面は、ウェブサーバ１１により承認者端末３，４に提供される。
【００７４】図６は、承認者端末３，４の表示装置に表示される注文承認画面の例を示す図である。図６に示すように、注文承認画面には、注文明細情報６１の他に、認証ワークフローの状態を表す状態一覧６２が表示されている。状態一覧６２には、注文を行った者が承認を得るべき全ての承認者およびその部署、承認の状態（未承認、承認済、代理承認済など）、承認日の情報が表示される。
【００７５】ここで、注文を行った者が承認を得るべき全ての承認者およびその部署は、注文情報に含まれる商品の購入金額と、認証情報に含まれる認証ルートおよび各人の購入限度額（決裁権限）とを比較することによって判断される。図６の例では、開発部開発２課に所属する担当者Ａが販売単価３０７，４４０円の時計付き横型ラジオを１個注文した場合に、購入金額の３０７，４４０円の決裁権限を持つのは開発部長であるため、開発２課の承認者（課長）と開発部の承認者（部長）の承認を得るべきことが表示されている。
【００７６】また、承認の状態は、ワークフロー情報記憶部２２に記憶されている現在の状態に基づいて判断される。図６の例では、課長および部長ともに未承認であることが示されている。つまり、この図６に示す注文承認画面は、課長が使用する承認者端末３に表示されるものであり、まだ課長の承認も済んでいないことを示している。
【００７７】この注文承認画面で課長は、注文を承認する場合は承認ボタン６３をクリックし、承認しない場合は却下ボタン６４をクリックする。図２の承認入力部３２は、図６に示す注文承認画面中の承認ボタン６３および却下ボタン６４を含み、本発明の承認手段はこの承認入力部３２を含んで構成される。
【００７８】このように、本実施形態では、商品の購入金額に応じて必要となる全ての承認者および承認の状態を注文承認画面に一覧として表示するようにしている。これにより、承認が必要な者と認証ワークフローの進捗状況とを一目で理解することが可能となる。
【００７９】上記承認入力部３２により注文の承認あるいは却下が行われると、そのことがウェブサーバ１１を介して承認受付部２５に入力される。そして、注文の承認あるいは却下が行われたことが状態遷移制御部２１に伝えられ、認証ワークフローの状態が遷移させられる。そして、注文が却下された場合は、そのことが確認メッセージ通知部２７によって注文者に対して電子メールで伝えられ、その注文に関する認証ワークフローの処理は終了する。
【００８０】一方、注文が承認された場合は、状態遷移制御部２１によって認証ワークフローの状態が遷移させられ、更に上の承認者から承認を得る必要があるかどうかが判断される。そして、必要な全ての承認が得られた場合には、確認メッセージ通知部２７を介して注文者に注文受付の確認メッセージが電子メールで通知される。また、更に上の承認が必要な場合には、承認依頼通知部２６を介して更に上の承認者に承認依頼通知メールが送信される。
【００８１】図６に示した例の場合、開発２課の課長だけでなく、開発部の部長の承認も必要なので、部長が使用する承認者端末４に対して承認依頼通知メールが送信される。これに対応して、部長がログインを行って図６の注文承認画面を開いたときには、状態一覧６２における開発２課の状態は「承認済」となり、承認者および承認日の情報も表示された状態となっている。
【００８２】ここで部長も注文の承認をすると、確認メッセージ通知部２７によって、全ての承認が済んだことを知らせる注文受付の確認メッセージが注文者の担当者端末２に送信される。図７に、この注文受付確認メッセージの電子メールの表示例を示す。注文却下確認メッセージの電子メールもこの図７とほぼ同様である。このような注文受付の確認メッセージあるいは注文却下の確認メッセージを担当者端末２に送ることにより、スピーディかつ正確な注文の確認を行うことが可能となる。
【００８３】また、３５は状態参照部であり、ワークフロー情報記憶部２２に記憶されている注文の認証ワークフローに関する現在の状態を参照するためのものである。状態参照部３５を用いて、例えば所望の注文番号などを指定すると、指定された注文に関する現在の認証ワークフローの状態が、ウェブサーバ１１によってＨＴＭＬ形式で表示される。このとき表示される画面には、例えば図６の状態一覧６２と同様の情報が含まれる。
【００８４】このような状態参照部３５を設けることにより、注文に関する認証ワークフローの状態を任意の時点で確認することができる。例えば、注文を出してから最終的な決定（注文受付または注文却下）がなかなか来ない場合に、この状態参照部３５を用いることで、認証ワークフローがどこで停滞しているかを確認することができる。
【００８５】本実施形態の認証ワークフローシステムではさらに、代理認証の機能を設けている。代理認証とは、ある承認者の代わりに、それより上の承認者によって注文の承認を行えるようにしたものである。例えば、ある承認者が長期出張などで承認を行えないような状態にあるとき、その承認者に代わって更に上の上司によって承認を行うことが可能である。
【００８６】例えば、注文者が上記状態参照部３５を用いて認証ワークフローの状態を参照したところ、開発２課での承認は済んでいるが、開発部のところで認証ワークフローが停滞していることが確認できたとする。この場合には、注文者は、開発部の部長より更に上の上司（図４の例によれば事業部長）に対して、代理認証を依頼することができる。
【００８７】代理認証の依頼を受けた事業部長は、自分が使用する端末あるいは担当者の端末などから、あらかじめ決められた固定のＵＲＬを指定して所定のログイン画面にアクセスする。そして、事業部長は自己のログインＩＤとパスワードとを入力してログインを行う。このとき入力された事業部長のログインＩＤやパスワードは、認証サーバ１の認証部２３に送られて認証処理が行われる。
【００８８】認証部２３では、認証情報記憶部１８に記憶されている認証情報に基づいて、入力されたログインＩＤとパスワードとを検証し、ログインしてきた者が代理認証を行う権限を有する者かどうかなどを調べる。そして、認証が得られたときには、認証情報記憶部１８に記憶されている認証情報、注文情報記憶部２０に記憶されている注文情報、ワークフロー情報記憶部２２に記憶されているワークフロー情報などに基づいて、その事業部長の配下にある組織内で未承認の注文を全て検索し、一覧として表示する。
【００８９】この未承認注文一覧の表示を見て事業部長は、担当者から聞いた注文番号などを頼りに代理認証の依頼を受けた注文を探し、マウスクリック等によってそれを指定する。注文の指定が行われると、承認画面作成部２４によって注文承認画面が作成され、表示される。このとき表示される注文承認画面は、図６に示した承認ボタン６３が代理承認ボタンに変わることを除けば、部長に対する注文承認画面と同じである。
【００９０】ここで、事業部長が注文の代理承認をすると、状態遷移制御部２１によって認証ワークフローの状態が「代理承認済」に遷移させられる。そして、これによって必要な承認が全て得られた場合には、確認メッセージ通知部２７を介して注文者に注文受付の確認メッセージが電子メールで通知される。
【００９１】このように、本実施形態では、状態参照部３５と代理認証の機能とを設けることにより、認証ワークフローの状態が停滞して先に進まなくなってしまう不都合を防止でき、一連の認証処理を速やかに行うことができるようになる。
【００９２】なお、以上に示したユーザ端末２，３，４の構成において、注文入力部３１、承認入力部３２、ログイン情報入力部３３および状態参照部３５の機能は、ウェブサーバ１１によって提供された所定の入力画面にキーボードやマウスなどの入力デバイスを用いて情報を入力することによって実現される。また、通知受信部３４は、電子メールの送受信機能の一部によって実現される。
【００９３】また、認証サーバ１およびユーザ端末２，３，４の各機能ブロックは、実際にはコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭ、あるいはこれ以外のハードディスク等に記憶されたプログラムが動作することによって実現できる。
【００９４】図３は、上記認証サーバ１による認証ワークフロー動作の例を示すフローチャートである。このフローチャートの動作を実行する前提として、商品情報、取引先情報、認証情報の登録は既に済んでいるものとする。なお、ここでは担当者Ａが担当者端末２から商品の注文を行い、その上司である課長および部長が承認者端末３，４から承認を行う場合を例にとって処理の流れを説明する。
【００９５】図３において、ステップＳ１では、認証サーバ１に入力されたイベントがユーザ端末２，３，４からの注文かどうかを判断する。そして、例えば担当者端末２から注文が入力された場合は、ステップＳ２に進み、注文管理部１９によってその注文に対してユニークな番号を付けるとともに、状態遷移制御部２１によって認証ワークフローの初期状態を設定する。
【００９６】次に、ステップＳ３で状態遷移制御部２１は、その注文を行った担当者Ａおよびその上司について設定されている購入限度額を認証情報記憶部１８の中から読み取る。そして、ステップＳ４で、注文された商品の購入金額が、上記読み取った担当者Ａの購入限度額を超えているかどうかを判断する。ここで、商品の購入金額がその担当者Ａの購入限度額を超えていない場合は、ステップＳ１６に進み、確認メッセージ通知部２７によって注文受付メッセージの電子メールを担当者端末２に送信する。
【００９７】一方、商品の購入金額がその担当者Ａの購入限度額を超えている場合は、ステップＳ５に進む。ここで状態遷移制御部２１は、その購入金額と、認証情報記憶部１８に記憶されている認証情報とを照らし合わせて、その注文に関して承認を得ることが必要な全ての承認者（今の例では課長および部長）を探索する。そして、ステップＳ６で、承認依頼通知部２６は、探索された全ての承認者のうち、最初の承認者（課長）に対する承認依頼の電子メールを作成して送信する。このとき、担当者Ａに対して承認が必要であることを知らせるメールも送信する。その後、ステップＳ１に戻る。
【００９８】上記ステップＳ１で注文の入力がないと判断したときは、ステップＳ７に進む。ステップＳ７では、認証サーバ１に入力されたイベントが、注文承認依頼メールに埋めこまれたＵＲＬ５１に対するアクセスであるかどうかをウェブサーバ１１において判断する。そして、このＵＲＬ５１に対してアクセスがあった場合は、ステップＳ８に進む。
【００９９】ステップＳ８では、ログインを行ってきた何れかの承認者端末３，４の表示装置にログイン画面を表示させる。最初は、課長の承認者端末３からログインが行われるので、当該課長の承認者端末３にログイン画面を表示させる。これに応じてログインが行われると、認証部２３は、ステップＳ９で認証処理を行い、ログインが正しく行われたかどうかを判定する。
【０１００】ここで、ログインが正しく行われていない場合は、ステップＳ１０でエラーメッセージを承認者端末３に通知した後、ステップＳ１に戻る。ログインが正しく行われた場合は、ステップＳ１１に進み、承認画面作成部２４によってＨＴＭＬによる注文承認画面を作成し、ウェブサーバ１１によってその注文承認画面を承認者端末３の表示装置に表示させる。このとき、注文承認画面には、上記ステップＳ５で探索した全ての承認者を状態一覧６２に表示する。そして、注文の承認あるいは却下の入力を待つ。
【０１０１】また、上記ステップＳ７で、認証サーバ１に入力されたイベントが、注文承認依頼メールに埋めこまれたＵＲＬ５１に対するアクセスでもないと判断した場合は、そのとき入力されたイベントは、代理認証を行うための固定のＵＲＬに対するアクセスということになる。よって、この場合は、ステップＳ１７に進む。ステップＳ１７では、入力された固定のＵＲＬに従って、ログインを行ってきた端末の表示装置に所定のログイン画面を表示する。
【０１０２】これに応じてログインが行われると、認証部２３は、ステップＳ１８で認証処理を行い、代理認証を行う権限を有する者によってログインが正しく行われたかどうかを判定する。ここで、ログインが正しく行われていない場合は、ステップＳ１０でエラーメッセージを通知した後、ステップＳ１に戻る。一方、ログインが正しく行われた場合は、ステップＳ１９に進み、事業部長の配下にある組織内で未承認の注文を全て検索し、一覧として表示する。
【０１０３】次のステップＳ２０では、この未承認注文の一覧の中から、代理認証を行いたい注文が指定されたかどうかを判断する。そして、注文の指定が行われると、ステップＳ１１に進み、承認画面作成部２４によってＨＴＭＬによる注文承認画面を作成し、ウェブサーバ１１によってその注文承認画面を表示させる。このとき表示される注文承認画面は、上述したように、図６に示した承認ボタン６３が代理承認ボタンに変わるだけで、その他は通常の注文承認画面と同じである。
【０１０４】次に、ステップＳ１２で、承認受付部２５は、承認者端末３において注文の承認があったか却下があったかを判断する。ここで、注文が却下された場合は、ステップＳ１３で注文却下のメッセージを担当者Ａの担当者端末２に送信し、ステップＳ１に戻る。一方、注文が承認された場合は、ステップＳ１４に進み、状態遷移制御部２１によって認証ワークフローの状態を遷移させる。このとき、正規の承認者によって承認が行われた場合には「承認済」、代理の承認者によって承認が行われた場合には「代理承認済」の状態にそれぞれ遷移する。
【０１０５】そして、ステップＳ１５で、全ての承認者による承認が済んだかどうかを判断し、済んでいない場合にはステップＳ６に戻り、済んだ場合にはステップＳ１６に進む。今の例の場合、課長による承認は済んだが、部長による承認はまだ済んでいないので、ステップＳ６に戻る。この場合、ステップＳ６では、部長に対する承認依頼の電子メールを作成して送信する。
【０１０６】以下同様にしてステップＳ７〜Ｓ１５の処理が行われ、部長の承認も行われた場合には、ステップＳ１６に進み、確認メッセージ通知部２７によって注文受付メッセージの電子メールを担当者端末２に送信する。そして、ステップＳ１に戻り、当該ステップＳ１とステップＳ７で、別の注文やメール内に埋めこまれたＵＲＬ５１へのアクセスがないかどうかを監視し続ける。
【０１０７】なお、必要な全ての承認が得られ、注文受付の確認メッセージが注文者に通知された時点で、その注文は正式に受注されたことになる。
【０１０８】以上詳しく説明したように、本実施形態によれば、商取引において必要となる決裁の一連の認証を電子的なワークフロー処理によって行うことができ、紙ベースによる煩雑な事務処理は全く行う必要がなくなる。また、認証ルートがあらかじめ登録され、これに従って認証の処理が半自動的に行われることとなるので、希望する商品を購入するのに承認が必要かどうかや、誰の承認を得なければならないか等について特に意識する必要もなくなる。これにより、認証処理を簡素化し、一連の電子商取引をよりスムーズに行うことができるようになる。
【０１０９】また、注文を行った商品購入者に対して注文受付あるいは注文却下の確認メッセージを送ることにより、スピーディかつ正確な注文の確認を行うことができる。また、電子店舗を運営する商品販売側においても、認証サーバ１内のワークフロー情報を参照することができ、注文について必要な承認が全て得られているかどうかを確認することができる。したがって、商品販売側の企業等にとっても、発注された注文が正式に承認を得ているかどうかを確認して、承認済みの注文のみを受けることができるので、電子商取引上のトラブル発生を少なくすることもできる。
【０１１０】また、本実施形態では、承認者端末３，４に対する承認依頼の通知を電子メールで行うとともに、承認をウェブブラウザによる注文承認画面で行うようにしたので、企業内の各人が使用するユーザ端末２，３，４においては電子メールの機能とウェブブラウザの機能とがあれば良く、特別なクライアントソフトウェアなどを備える必要がないというメリットも有する。
【０１１１】また、本実施形態では、注文に関する認証ワークフローの状態を任意の時点で確認することができるので、例えば認証ワークフローの処理が停滞している場合に、その原因箇所を容易に確認することができる。さらに本実施形態では、代理認証の機能を設けているので、認証ワークフローの状態が停滞して先に進まなくなってしまう不都合を防止でき、一連の認証処理を速やかに行うことができるようになる。
【０１１２】（第２の実施形態）次に、本発明の第２の実施形態について説明する。上記第１の実施形態では、認証サーバ１とユーザ端末２，３，４とをインターネット７で接続したが、第２の実施形態ではこれらをイントラネット（インターネットを介して行われる企業内（組織間）通信であるエクストラネットを含む）で接続する。イントラネットで接続した場合、認証サーバ１は、例えば企業内の資材調達部門などに置かれ、ユーザ端末２，３，４はその他の購買部門等に置かれる。
【０１１３】図８は、第２の実施形態による認証ワークフローシステムの一構成例を示す図である。この図８に示すシステムは、例えば企業内のある部門に属する担当者２がインターネット７上で商品の注文を行う際に、その商取引に伴う決裁のワークフローを認証サーバ１で処理し、全ての承認を得た時点で注文を仕入先８-1，８-2に対して発注したり、配送センタ９に対して配送指示を出したりするものである。なお、この図８において、図１R>１に示したものと同様の機能を有するものには同一の符号を付している。
【０１１４】図８において、認証サーバ１とユーザ端末２，３，４はイントラネット５を介して接続されている。本実施形態において、これらの認証サーバ１およびユーザ端末２，３，４は、例えば商品購入側の企業内に置かれる。そして、上述したように認証サーバ１は、その企業内の資材調達部門などに置かれ、ユーザ端末２，３，４はその他の購買部門等に置かれる。
【０１１５】なお、第１の実施形態でも述べたように、認証サーバ１とユーザ端末２，３，４は、必ずしも１つの企業内に置く必要はない。例えば、複数の企業にまたがったグループ企業や、企業以外の団体など、一連の承認処理が必要な組織であれば何れにも適用することが可能であり、その組織内の任意の場所に認証サーバ１およびユーザ端末２，３，４を設置することが可能である。
【０１１６】上記イントラネット５は、ファイアフォール６を介してインターネット７に接続されている。ファイアウォール６は、インターネット７を介して第三者がイントラネット５内に不正に侵入するのを防ぐために設けられる。インターネット７には、様々な仕入先企業の端末８-1，８-2や、例えば商品購入側の企業等が商品を在庫として持つ配送センタ９の端末など接続されている。本実施形態において、この仕入先端末８-1，８-2や配送センタ端末９は、商品購入側企業からの発注情報あるいは配送指示情報を受信する電子メール機能、ウェブブラウザ機能、あるいはファクシミリ機能などを有している。
【０１１７】本実施形態の認証ワークフローシステムでは、例えば担当者端末２から商品の注文が入力されると、当該担当者端末２および承認者端末３，４を含むユーザ端末と認証サーバ１との間のインタラクティブ処理により、その入力された注文に関する一連の電子決裁（上司による承認）の処理が行われる。そして、最終的に決裁が下りた時点で、インターネット７を介して仕入先端末８-1，８-2に対して発注が行われたり、配送センタ端末９に配送指示が行われたりする。
【０１１８】図９は、上記認証サーバ１およびユーザ端末２，３，４の機能的な構成例を示すブロック図である。この図９において、上記図２に示した機能ブロックと同じものには同一の符号を付し、重複する説明は省略する。
【０１１９】本実施形態において、商品登録部１３では、仕入先において販売している商品や、配送センタに在庫として存在する商品などに関する種々の情報を登録する。また、取引先登録部１５では、商品の取引先として、購入側企業、仕入先、配送センタなどに関する種々の情報を登録する。
【０１２０】また、状態遷移制御部２１は、第１の実施形態で説明した機能に加え、認証ワークフローの状態を遷移させて最終的に全ての承認が得られた時点で、承認済注文処理部２８に指示を出して、承認済の注文を用いて商品を手配するなどの次工程の処理をも行う。次工程の処理の例としては、仕入先端末８-1，８-2に発注の電子メールを送信したり、配送センタ端末９に配送指示の電子メールを送信する処理が考えられる。
【０１２１】すなわち、状態遷移制御部２１は、商品の購入金額が購入限度額内に収まっている場合（注文を行った者の購入限度額より商品の購入金額が低い場合、必要な承認が全て得られた場合の双方を含む）に、仕入先端末８-1，８-2に発注メールを送信したり、配送センタ端末９に配送指示メールを送信したりする処理を承認済注文処理部２８に対して指示する。
【０１２２】承認済注文処理部２８は、上記状態遷移制御部２１からの指示に応じて、仕入先端末８-1，８-2に対して発注の通知を電子メールで行う。または、配送センタ端末９に対して配送指示の通知を電子メールで行う。このとき、注文情報記憶部２０に記憶されている注文情報に基づいて発注先または配送指示先が判断される。この発注情報や配送指示情報には、注文情報記憶部２０に記憶されている注文情報の他に、必要な承認が全て得られたことを表す情報が含まれる。なお、ここでは発注および配送指示を電子メールで行うこととしているが、電話やファクシミリ通信などにより行うようにしても良い。本発明の承認済注文処理手段は、上記状態遷移制御部２１および承認済注文処理部２８を含んで構成される。
【０１２３】上記のように構成した認証サーバ１による認証ワークフロー動作は、図３に示したフローチャートとほぼ同様である。ただし、本実施形態の場合は、ステップＳ１６の処理の後でステップＳ１に戻る前に、仕入先端末８-1，８-2に対する発注メールの送信、あるいは配送センタ端末９に対する配送指示メールの送信を行う。
【０１２４】以上詳しく説明したように、第２の実施形態によれば、必要な承認が全て得られた注文に関する発注情報や配送指示情報等を、承認済みであることを表す情報と共に仕入先端末８-1，８-2、配送センタ端末９に送信するようにしたので、上述した第１の実施形態による効果に加え、注文を承認するまでの決裁処理と、オンライン上で発注や配送指示を行う処理とを有機的に結び付けて一連の電子商取引をよりスムーズに行うことができる。
【０１２５】（第３の実施形態）次に、本発明の第３の実施形態について説明する。上記第１および第２の実施形態では、商品情報、取引先情報、認証情報の登録を認証サーバ１において行うようにしたが、第３の実施形態ではこれらの情報の登録を、認証サーバ１以外の端末から認証サーバ１内のウェブサーバ１１にアクセスすることによって行えるようにする。
【０１２６】図１０は、第３の実施形態による認証ワークフローシステムの一構成例を示す図である。この図１０R>０に示すシステムでは、店舗側には、認証サーバ１の他に店舗管理端末７１が備えられ、これらが相互に接続される。また、購入企業側には、担当者端末２、承認者端末３，４の他に購入企業管理端末７２が備えられ、これらが相互に接続される。店舗管理端末７１から認証サーバ１に対して商品情報や取引先情報の登録を行うことができ、購入企業管理端末７２から認証サーバ１に対して認証情報の登録を行うことができる。
【０１２７】図１１は、上記図１０に示した認証サーバ１、ユーザ端末２，３，４、店舗管理端末７１および購入企業管理端末７２の機能的な構成例を示すブロック図である。この図１１において、上記図２に示した機能ブロックと同じものには同一の符号を付し、重複する説明は省略する。
【０１２８】本実施形態において、認証サーバ１は、図２R>２に示した商品登録部１３、取引先登録部１５、認証情報登録部１７の代わりに、情報記録部８１を備えている。また、店舗管理端末７１は、商品登録部８２および取引先登録部８３を備え、購入企業管理端末７２は、認証情報登録部８４を備えている。
【０１２９】上記商品登録部８２、取引先登録部８３および認証情報登録部８４により登録する商品情報、取引先情報、認証情報の内容は、図２の商品登録部１３、取引先登録部１５、認証情報登録部１７により登録する各情報と同じである。ただし、本実施形態では、店舗管理端末７１や購入企業管理端末７２から認証サーバ１内のウェブサーバ１１にアクセスすることにより、ウェブブラウザを通じて各情報の登録を行う。ウェブサーバ１１を通じて登録された各情報は、情報記録部８１によって商品情報記憶部１４、取引先情報記憶部１６、認証情報記憶部１８にそれぞれ記憶される。
【０１３０】このように、本実施形態では、商品情報、取引先情報、認証情報の登録を、認証サーバ１以外の店舗管理端末７１および購入企業管理端末７２からウェブへのアクセスによって行えるようにしたので、これらの情報登録を機能分散した運用を行うことが可能となる。
【０１３１】これにより、店舗側では、自己が扱う商品や取引先についてのみ情報登録を行えば良く、購入企業側の認証情報の登録については購入企業自身に任せることができる。特に、購入企業が数多くなってきたときには、それぞれの企業が個別に自己の認証情報を登録すれば良く、店舗側の情報登録の負担を大幅に軽減することができる。また、購入企業側にとっても、機密性のある組織情報を店舗側に開示しなくても済むというメリットを有する。
【０１３２】なお、上記第１〜第３の実施形態では、インターネット７を通じて行う電子商取引を例に挙げて説明したが、通常の商取引を行う際の決裁に関する認証ワークフローにも適用することが可能である。この場合には、図８に示したある企業のイントラネット５はインターネット７に接続されている必要は必ずしもなく、企業内の閉じたネットワークで認証ワークフローの処理が実行されるようにしても良い。
【０１３３】また、上記第２の実施形態では、商品の購入金額が注文者の購入限度額以内の場合、および全ての承認が得られた場合には、仕入先端末８-1，８-2に対する発注や配送センタ端末９に対する配送指示を自動的に送信するようにしたが、まずは注文者が確認をした後、注文者の指示に応じてこれらの情報を送信するようにしても良い。この場合は、必要な承認の全てが得られていない状態で指示が出されたときには、発注情報や配送指示情報の送信を禁止するように制御する。このようにすることで、最終的な決裁が下りていない注文が誤って発注あるいは配送指示されてしまうことを防ぐことが可能となる。
【０１３４】また、上記第３の実施形態では、企業間の取引に対して情報登録の分散機能を実現した例を示したが、図８に示したような企業の購買システムに対して情報登録の分散機能を実現することも可能である。この場合、図１０および図１１に示した店舗管理端末７１および購入企業管理端末７２に相当する端末は、企業内の資材調達部門に置かれる。
【０１３５】なお、以上に説明した各実施形態の認証ワークフローシステムおよび認証サーバ装置は、上述したようにコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記機能を果たすように動作させるプログラムを、例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。上記プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、フロッピーディスク、ハードディスク、磁気テープ、光磁気ディスク、不揮発性メモリカード等を用いることができる。
【０１３６】また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。
【０１３７】また、本発明はネットワーク環境で利用されるものであり、認証サーバ１やユーザ端末２，３，４の全部あるいは一部のプログラムが他のコンピュータで実行されるようになっていても良い。
【０１３８】上記説明した実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【０１３９】
【発明の効果】以上説明したように本発明によれば、注文について最終的な承認を得るまでの決裁処理を電子的に行うことにより簡素化し、一連の商取引をよりスムーズに行うことができるようになる。また、本発明のその他の特徴によれば、必要な承認が全て得られた場合には、その注文に関する次工程の処理まで実行するので、注文を承認するまでの決裁処理と、オンライン上で発注や配送指示などを行う処理とを有機的に結び付けて一連の電子商取引をよりスムーズに行うことができるようになる。また、商品の販売側企業においても、購入側企業から発注された注文が正式に承認を得ているものかどうかを容易に確認でき、電子商取引上のトラブル発生を少なくすることができる。
【図面の簡単な説明】
【図１】第１の実施形態による認証ワークフローシステムの一構成例を示す図である。
【図２】第１の実施形態による認証サーバおよびユーザ端末の機能的な構成例を示すブロック図である。
【図３】第１の実施形態の認証サーバによる認証ワークフロー動作の例を示すフローチャートである。
【図４】本実施形態による認証サーバの表示装置に表示される認証情報の登録画面の例を示す図である。
【図５】承認者端末の表示装置に表示される注文承認依頼メールの例を示す図である。
【図６】承認者端末の表示装置に表示される注文承認画面の例を示す図である。
【図７】注文者端末の表示装置に表示される注文受付確認通知メールの例を示す図である。
【図８】第２の実施形態による認証ワークフローシステムの一構成例を示す図である。
【図９】第２の実施形態による認証サーバおよびユーザ端末の機能的な構成例を示すブロック図である。
【図１０】第３の実施形態による認証ワークフローシステムの一構成例を示す図である。
【図１１】第３の実施形態による認証サーバおよびユーザ端末の機能的な構成例を示すブロック図である。
【符号の説明】
１ 認証サーバ
２ 担当者端末
３，４ 承認者端末
５ イントラネット
６ ファイアウォール
７ インターネット
８-1，８-2 仕入先端末
９ 配送センタ端末
１１ ウェブサーバ
１２ メールサーバ
１３ 商品登録部
１４ 商品情報記憶部
１５ 取引先登録部
１６ 取引先情報記憶部
１７ 認証情報登録部
１８ 認証情報記憶部
１９ 注文管理部
２０ 注文情報記憶部
２１ 状態遷移制御部
２２ ワークフロー情報記憶部
２３ 認証部
２４ 承認画面作成部
２５ 承認受付部
２６ 承認依頼通知部
２７ 確認メッセージ通知部
２８ 承認済注文処理部
３１ 注文入力部
３２ 承認入力部
３３ ログイン情報入力部
３４ 通知受信部
３５ 状態参照部
７１ 店舗管理端末
７２ 購入企業管理端末
８１ 商品登録部
８２ 取引先登録部
８３ 認証情報登録部
【０００１】
【発明の属する技術分野】本発明は、認証ワークフローシステム、認証サーバ装置、決裁に関する認証方法、記録媒体に関し、特に、イントラネットやインターネットなどのネットワーク上での商取引を行う際に必要な決裁、管理などのワークフローを支援するシステムに用いて好適なものである。
【０００２】
【従来の技術】一般に、商取引を大きく分けると、企業が消費者に商品やサービスを提供するいわゆるＢ to Ｃ（Business to Consumer）の取引と、企業間の取引を意味するいわゆるＢ to Ｂ（Business to Business）の取引とがある。
【０００３】ここで、Ｂ to Ｃの取引において個々の消費者が商品を購入する場合は、その消費者個人の決断で購入するものを自由に決定し、実際に購入することが可能である。しかし、Ｂ to Ｂの取引において企業が商品を購入する場合は、その企業内の個々の担当者が購入するものを一人で決定することはできず、所定のルートに従って上司の決裁（承認）を受けなければいけないのが一般的である。
【０００４】近年、コンピュータの広範な普及、インターネット等のネットワーク技術の進展などを背景として、インターネットのウェブページ上に公開された商品をネット上で売買するオンラインショッピングが盛んに行われている。このオンラインショッピングシステムに関しても、Ｂ to Ｃをターゲットにしたシステムと、Ｂto Ｂをターゲットにしたシステムとが提案されている。
【０００５】
【発明が解決しようとする課題】従来、Ｂ to Ｂの取引において、例えばある企業が商品を購入する際の決裁は、紙ベースで行われていた。すなわち、ある企業内の担当者が商品を購入しようとする場合は、購入希望の商品やその金額などを記述した書類を作成し、それを上司に提出することによって承認を得るようにしていた。
【０００６】しかしこれでは、購入希望を出してから承認を得るまでの段階で紙ベースによる煩雑な事務処理を行う必要があり、商品の注文をスムーズに行うことができない問題があった。特に、オンラインショッピングのシステムを利用して商品を購入する場合、商品の選択や発注自体はオンライン上で簡単に行えるにもかかわらず、その発注に至るまでの処理に多大の労力と時間がかかり、ネット販売による便利さの利益を完全に享受することができないという問題があった。
【０００７】また、販売側の企業等にとっても、購入側の担当者によって行われた注文がきちんと承認を得ているものかどうかが分からない限り、注文を安易に受けることができないという問題がある。すなわち、担当者からの注文が正式に承認されたものでないと、取引が後に取り止めになってしまったり、商品を納入しても代金が支払われないなどのトラブルを引き起こす可能性がある。そのため、注文が購入側で正式に承認を得たものであるかどうかを確認し、承認済みの注文のみを受けるようにする仕組みが望まれていた。
【０００８】本発明は、このような実情に鑑みて成されたものであり、最終的な承認を得るまでの決裁処理を簡素化し、一連の商取引をよりスムーズに行えるようにすることを目的としている。また、本発明は、商品の販売側において、購入側から発注された注文が正式に承認を得ているかどうかを確実に確認できるようにし、商取引上のトラブル発生を少なくできるようにすることをも目的としている。
【０００９】
【課題を解決するための手段】本発明の認証ワークフローシステムは、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を登録する認証情報登録手段と、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力手段と、上記購入商品情報入力手段により入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証情報登録手段により登録された承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に対応して、承認に関する情報を入力する承認手段とを備えたことを特徴とする。
【００１０】本発明の他の態様では、上記承認要求通知手段は、上記購入商品情報入力手段により入力された商品の購入金額と、ある承認者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合に、更に上の承認者に対して承認を要求する通知を行うことを特徴とする。
【００１１】本発明のその他の態様では、上記承認手段によって必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする。本発明のその他の態様では、上記確認通知手段は、上記承認手段によって必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする。
【００１２】本発明のその他の態様では、上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認手段による承認に関する情報入力をウェブブラウザによる入力画面で行うようにしたことを特徴とする。
【００１３】本発明のその他の態様では、上記電子メールに埋め込まれたアドレスに従って上記ウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うログイン手段を備えたことを特徴とする。
【００１４】本発明のその他の態様では、上記ウェブブラウザによる入力画面には、上記商品の購入金額に応じて必要となる全ての承認者および承認の有無を表示することを特徴とする。
【００１５】本発明のその他の態様では、上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を参照する状態参照手段とを備えたことを特徴とする。
【００１６】本発明のその他の態様では、上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする。
【００１７】本発明のその他の態様では、上記商取引はネットワーク上で行われる電子商取引であることを特徴とする。
【００１８】本発明のその他の態様では、上記承認手段によって必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする。
【００１９】本発明のその他の態様では、必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする。
【００２０】本発明のその他の態様では、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートを登録する認証情報登録手段と、上記認証情報登録手段により登録された認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする。
【００２１】本発明のその他の態様では、上記認証情報登録手段は、上記認証ワークフローに関する処理を行う認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって上記認証情報の登録を行うことを特徴とする。
【００２２】また、本発明の認証サーバ装置は、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を記憶する認証情報記憶手段と、入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報記憶手段により記憶されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に応じて上記承認者により入力された承認に関する情報を受け付ける承認受付手段とを備えたことを特徴とする。
【００２３】本発明のその他の態様では、必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする。本発明のその他の態様では、上記確認通知手段は、必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする。
【００２４】本発明のその他の態様では、上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認要求通知の電子メールに埋め込まれたアドレスが指定されたときに、所定のログイン処理を経て上記承認を促すためのウェブブラウザによる入力画面に遷移させるようにしたことを特徴とする。
【００２５】本発明のその他の態様では、上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を要求に応じて提供する状態情報提供手段とを備えたことを特徴とする。
【００２６】本発明のその他の態様では、上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする。
【００２７】本発明のその他の態様では、必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする。本発明のその他の態様では、上記必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする。
【００２８】本発明のその他の態様では、商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートを記憶する認証情報記憶手段と、上記認証情報記憶手段により記憶されている認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする。
【００２９】本発明のその他の態様では、上記認証情報記憶手段に記憶される認証情報は、上記認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって登録されることを特徴とする。
【００３０】また、本発明の決裁に関する認証方法は、商取引において必要となる決裁の認証を行う決裁に関する認証方法であって、認証ルートおよび各承認者が持つ商品購入限度額などの認証情報を登録する認証情報登録ステップと、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力ステップと、上記入力された商品の購入金額と、その入力を行った者に関して登録されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知ステップと、上記通知された承認要求に対応して、承認に関する情報を入力する承認ステップとを有することを特徴とする。
【００３１】また、本発明のコンピュータ読み取り可能な記録媒体は、請求項１〜２５の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラム、あるいは、請求項２６〜３４の何れか１項に記載された決裁の認証方法の処理手順をコンピュータに実行させるためのプログラム記録したことを特徴とする。
【００３２】本発明は上記技術手段より成るので、商取引において必要となる決裁の一連の認証が電子的なワークフロー処理によって行われ、紙ベースによる煩雑な事務処理は全く行う必要がなくなる。また、認証ルートがあらかじめ登録され、これに従って認証の処理が半自動的に行われることとなるので、希望する商品を購入するのに承認が必要かどうかや、誰の承認を得なければならないか等について何ら意識する必要がない。また、商品の購入金額に応じて必要となる全ての承認者および承認の有無を承認入力画面に表示することにより、承認が必要な者と認証ワークフローの進捗状況が一目瞭然となる。
【００３３】本発明の他の特徴によれば、必要な承認が全て得られたときには注文受付の確認メッセージを注文者に対して通知し、必要な承認が却下されたときには注文却下の確認メッセージを注文者に対して通知するようにしたので、スピーディかつ正確な注文の確認を行うことが可能となる。
【００３４】本発明のその他の特徴によれば、承認要求の通知や確認メッセージの通知を電子メールで行うとともに、承認をウェブブラウザによる入力画面で行うようにしたので、各人が使用する端末においては電子メールの機能とウェブブラウザの機能とがあれば良く、特別なクライアントソフトウェアなどを備える必要はない。
【００３５】本発明のその他の特徴によれば、電子メールに埋め込まれたアドレスに従ってウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うようにしたので、承認を行う権限を有する承認者だけが実際に承認を行えるようになり、認証に関する不正や間違いを防止することが可能となる。
【００３６】本発明のその他の特徴によれば、認証ワークフローの現在の状態を参照できるようにしたので、例えば、注文を出してから最終的な認証が下りるまでに時間がかかっているような場合に、認証ワークフローがどこで停滞しているかなどの確認を行うことが可能となる。
【００３７】また、本発明のその他の特徴によれば、承認要求が通知された承認者の代わりに、更に上の承認者が承認に関する情報を入力することを認めるようにしたので、認証ワークフローの状態がある承認者のところで停滞していても、代理の承認者によって承認を行うことができ、一連の認証処理を速やかに行うことが可能となる。
【００３８】本発明のその他の特徴によれば、商取引がネットワーク上で行われる電子商取引であり、必要な承認が全て得られた注文については次工程の処理を実行するようにしたので、注文を最終的に承認するまでの決裁処理と、オンライン上で発注や配送指示などを行う次工程の処理とを有機的に結び付けて一連の電子商取引をよりスムーズに行うことが可能となる。また、商品販売側の企業にとっても、発注された注文が正式に承認を得ているかどうかを容易に把握することが可能となる。
【００３９】本発明のその他の特徴によれば、必要な承認の全てが得られていない注文については次工程の処理の実行を禁止するようにしたので、最終的な決裁が下りていない注文が誤って発注されてしまうなどの不都合を防ぐことが可能となる。
【００４０】本発明のその他の特徴によれば、認証サーバ装置とは別の端末から認証サーバ装置へのウェブによるアクセスによって認証情報を登録するようにしたので、認証情報の登録を、認証サーバを管理する場所とは別の場所から行うことが可能となる。例えば、この認証情報の登録をそれぞれの購入側企業において分散して行うことにより、認証サーバの管理側の負担を軽減することが可能となる。
【００４１】
【発明の実施の形態】以下、本発明の一実施形態を図面に基づいて説明する。
【００４２】（第１の実施形態）図１は、第１の実施形態による認証ワークフローシステムの一構成例を示す図である。この図１に示すシステムは、例えば企業内の担当者２がインターネット７上で商品を購入する際に、その商取引に伴う決裁のワークフローを認証サーバ１で処理し、一連の認証処理を電子的に行うようにした例について示すものである。
【００４３】図１において、認証サーバ１は、例えばオンラインショッピングの電子店舗を持つ企業、あるいは当該企業の委託を受けたデータセンタ等に置かれる。また、ユーザ端末２，３，４は、例えば商品を購入する側の企業等に置かれる。そして、上記認証サーバ１とユーザ端末２，３，４とがインターネット７を介して接続される。
【００４４】上記ユーザ端末２，３，４のうち、２は担当者端末であり、希望商品の注文を行う担当者が使用するものである。３，４は承認者端末であり、担当者により行われた注文を承認する上司などが使用するものである。ここでは、一方の承認者端末３は担当者の直属の上司が使用する端末であり、もう一方の承認者端末４は更にその上司が使用する端末であるものとして説明する。
【００４５】なお、ここで言う担当者端末２および承認者端末３，４は、物理的な端末ではなく、論理的な端末を意味する。つまり、物理的に同じ端末でも、それを使用する者が担当者であれば担当者端末２となり、承認者であれば承認者端末３，４となる。また、ここでは説明の便宜上、上司は、担当者によりなされた注文の承認を行うものとしたが、上司自身が商品の注文を行うことができることは言うまでもない。
【００４６】本実施形態の認証ワークフローシステムでは、例えば担当者端末２から商品の注文が入力されると、当該担当者端末２および承認者端末３，４を含むユーザ端末と認証サーバ１との間のインタラクティブ処理により、その入力された注文に関する一連の電子決裁（上司による承認）の処理が行われる。そして、最終的に決裁が下りた時点で、入力された注文の受注が完了することとなる。
【００４７】図２は、上記認証サーバ１およびユーザ端末２，３，４の機能的な構成例を示すブロック図である。図２において、１１はウェブサーバであり、ユーザ端末２，３，４に対してＨＴＭＬ（Hyper Text Markup Language）などの情報を提供する。具体的には、ユーザ端末２，３，４からの要求に応じて、商品の注文を行うための注文入力画面、注文の承認を行うための注文承認画面、当該注文承認画面に遷移するためのログイン画面などをＨＴＭＬ形式で提供する。
【００４８】１２はメールサーバであり、本実施形態では特に、認証サーバ１内で作成された電子メールをユーザ端末２，３，４に送信する処理を行う。具体的には、一定の場合に認証サーバ１内で作成される注文承認依頼に関する電子メールを承認者端末３，４に送信したり、注文受付や注文却下の確認メッセージに関する電子メールを注文者の担当者端末２に送信したりする。
【００４９】１３は商品登録部であり、電子店舗において販売している商品に関する種々の情報を登録する。ここで登録する商品情報には、例えば商品名、商品の仕様、標準単価、仕切率、販売単価、備考事項などが含まれる。この商品情報の登録は、例えば認証サーバ１が備える表示装置に表示された入力画面において、キーボードやマウスなどの入力デバイスを用いて商品情報を入力することによって行う。また、認証サーバ１以外の端末で作成された商品情報を、フロッピー（登録商標）ディスクなどのリムーバル記憶媒体あるいはインターネット７を介して入力することによって登録しても良い。登録された商品情報は、商品情報記憶部１４に蓄積保存される。
【００５０】１５は取引先登録部であり、商品の取引先に関する種々の情報を登録する。ここで登録する取引先情報には、例えば購入側企業の企業名、電子メールアドレス、備考事項などが含まれる。この取引先情報の登録は、例えば認証サーバ１が備える表示装置に表示された入力画面において、キーボードやマウスなどの入力デバイスを用いて取引先情報を入力することによって行う。また、認証サーバ１以外の端末で作成された取引先情報をフロッピーディスクなどのリムーバル記憶媒体あるいはインターネット７を介して入力することによって登録しても良い。登録された取引先情報は、取引先情報記憶部１６に蓄積保存される。
【００５１】３１は注文入力部であり、ユーザ端末２，３，４が備えるウェブブラウザ機能を用いて、所望の商品を購入するための注文を入力する。具体的には、ユーザ端末２，３，４が備えるキーボードやマウスなどの入力デバイスを用いて所定のＵＲＬ（Uniform Resource Locator）を指定することにより、商品を選択して注文を行うための画面を表示装置に表示させ、ここで注文の入力を行う。この注文入力画面は、認証サーバ１内の商品情報記憶部１４に記憶されている商品情報等に基づいてウェブサーバ１１によって提供される。本発明の購入商品情報入力手段はこの注文入力部３１を含んで構成される。
【００５２】１７は認証情報登録部であり、商品購入側で注文の承認を行う際における一連の認証ルートおよび各人が持つ商品購入限度額（決裁権限）などの認証情報を登録する。ここで登録する認証ルートは、１つの企業内で完結する認証ルートだけでなく、複数の企業にまたがったグループ企業内の認証ルートであっても良い。また、企業に関する認証ルートに限らず、一連の承認処理が必要なその他の団体等についても認証ルートを任意に設定することが可能である。
【００５３】以下では一例として、１つの企業内で完結する認証ルートを登録する場合について説明する。この場合における認証ルートの登録は、例えば、企業内の組織および各組織部門における担当者（購入者）および承認者などの組織情報を登録することによって行うことが可能である。
【００５４】このような認証情報の登録は、例えば認証サーバ１が備える表示装置に表示された入力画面において、キーボードやマウスなどの入力デバイスを用いて認証情報を入力することによって行う。また、認証サーバ１以外の端末で作成された認証情報をフロッピーディスクなどのリムーバル記憶媒体あるいはインターネット７を介して入力することによって登録しても良い。登録された認証情報は、認証情報記憶部１８に蓄積保存される。
【００５５】図４は、認証サーバ１の表示装置に表示される認証情報の登録画面の一例を示す図である。図４に示す認証情報登録画面（ワークフロー設定画面）には、認証ルート（例えば企業内の組織情報）を登録するためのフィールド４１と、企業内の各人に関して認証を行うのに必要な種々の情報を登録するためのフィールド４２とが含まれる。
【００５６】企業内の組織情報は、図４のフィールド４１に示すようにツリー構造で表す。そして、ツリー構造で表したそれぞれの組織部門に少なくとも一人の承認者（上司）を設定する。図４の例では、社長、事業部長、部長、課長が承認者に設定され、これらは承認者であることを表すマークで表示されている。また、開発２課の中には課長の他に担当者Ａ，Ｂ，Ｃが含まれていることが示されており、これらは承認者と異なるマークで表示されている。
【００５７】また、各人に関する認証のための情報としては、図４のフィールド４２に示すように、ログインＩＤ、パスワード、氏名、部署名、電子メールアドレス、購入限度額（決裁権限）などを登録する。購入限度額は通常、担当者＜課長＜部長＜事業部長＜社長の順で高く設定される。担当者の購入限度額を０円に設定することもある。
【００５８】図２に戻り、１９は注文管理部であり、ユーザ端末２，３，４の注文入力部３１から送られてくる注文情報を入力し、管理する処理を行う。具体的には、注文管理部１９は、注文入力部３１からウェブサーバ１１を介して入力される注文ごとにユニークな番号を付し、注文情報記憶部２０に蓄積保存して管理する。ここでの注文情報には、購入する商品名、購入数、購入金額などの情報が含まれる。
【００５９】２１は状態遷移制御部であり、注文情報記憶部２０に記憶されている注文情報および認証情報記憶部１８に記憶されている認証情報に基づいて、認証ワークフローの状態を適宜遷移させる処理を行う。すなわち、注文管理部１９で最初に注文の入力が行われたときには、当該注文管理部１９からの通知を受けて、その注文に関するワークフローの状態を初期状態（未承認の状態）に設定する。その後は、承認者によって注文の承認が行われる毎に、ワークフローの状態を逐次遷移させる処理を行う。
【００６０】この状態遷移制御部２１によるワークフローの状態遷移は、対象とする注文に関してワークフローの遷移状態を表した情報をワークフロー情報記憶部２２の中から読み出し、後述する承認受付部２５から与えられる承認情報に従って、承認を行った者の状態を未承認から承認済に変更することによって行われる。
【００６１】本実施形態の状態遷移制御部２１は、上述のように認証ワークフローの状態を遷移させる処理を行う過程で、必要に応じて、後述する承認依頼通知部２６に指示を出して承認依頼の通知メールを承認者端末３，４に送信したり、後述する確認メッセージ通知部２７に指示を出して注文受付や注文却下の確認メッセージの通知メールを注文者の担当者端末２に送信したりする処理も行う。
【００６２】すなわち、状態遷移制御部２１は、注文情報記憶部２０に注文情報の一部として記憶されている商品の購入金額（複数の商品を購入した場合にはトータルの金額）と、認証情報記憶部１８に認証情報の一部として記憶されている、注文を行った者の購入限度額とを比較する。そして、商品の購入金額が注文者の購入限度額を超えている場合に、承認依頼通知部２６に対して承認依頼の通知メールを承認者端末３，４に送信することを指示する。
【００６３】また、ある承認者が上記承認依頼の通知メールに基づき注文の承認を行った場合には、状態遷移制御部２１は、注文情報記憶部２０に注文情報の一部として記憶されている商品の購入金額と、認証情報記憶部１８に認証情報の一部として記憶されている上記承認者の購入限度額とを比較する。そして、商品の購入金額がその承認者の購入限度額を超えている場合に、承認依頼通知部２６に対して承認依頼の通知メールを承認者端末３，４に送信することを指示する。
【００６４】つまり、例えば担当者Ａからある商品の注文が行われた場合に、その商品の購入金額が担当者Ａの購入限度額を超えているときには、承認依頼通知部２６に対して、承認依頼の通知メールを直属の上司（課長）の承認者端末３に送信することを指示する。また、当該課長によって承認が行われたときにも、上記商品の購入金額と課長の購入限度額とを比較する。そして、商品の購入金額が課長の購入限度額を超えている場合には、承認依頼通知部２６に対して、承認依頼の通知メールを更に上司（部長）の承認者端末４に送信することを指示する。このときどの承認者端末３，４に通知を行うかは、認証情報記憶部１８に記憶されている認証ルート情報に基づいて判断する。
【００６５】また、状態遷移制御部２１は、注文情報記憶部２０に注文情報の一部として記憶されている商品の購入金額と、認証情報記憶部１８に認証情報の一部として記憶されている購入限度額とを比較し、商品の購入金額が購入限度額内に収まっている場合（商品の購入金額が注文を行った者の購入限度額以下の場合、必要な承認が全て得られた場合の双方を含む）に、確認メッセージ通知部２７に対して注文受付の確認メールを担当者端末２に送信することを指示する。
【００６６】さらに、状態遷移制御部２１は、ある承認者によって注文が却下された場合には、確認メッセージ通知部２７に対して注文却下の確認メールを担当者端末２に送信することを指示する。
【００６７】上記承認依頼通知部２６は、上記状態遷移制御部２１からの指示に応じて、メールサーバ１２を用いて承認者端末３，４に対して承認依頼の通知を電子メールで行う。承認依頼通知部２６がこの承認依頼の通知を行うときは、注文を行った者の端末（担当者端末２、承認者端末３，４の何れか）に対して、承認が必要であることを知らせる確認通知も電子メールで行う。本発明の承認要求通知手段は、上記状態遷移制御部２１および承認依頼通知部２６を含んで構成される。
【００６８】また、確認メッセージ通知部２７は、上記状態遷移制御部２１からの指示に応じて、承認が不要であるか全ての承認が済んだことを知らせる注文受付の確認メッセージ、または何れかの承認者で承認が行われずに注文が却下されたことを表す注文却下の確認メッセージをメールサーバ１２を用いて電子メールで通知する。本発明の確認通知手段は、上記状態遷移制御部２１および確認メッセージ通知部２７を含んで構成される。
【００６９】３４は通知受信部であり、認証サーバ１のメールサーバ１２から電子メールの形で送られてくる種々の通知を受信する。すなわち、この通知受信部３４は、上述の承認依頼通知部２６により行われる注文承認の依頼通知および承認依頼の確認通知に関する電子メールを受信する。また、上述の確認メッセージ通知部２７により行われる注文受付および注文却下の確認通知に関する電子メールも受信する。
【００７０】図５は、承認依頼通知部２６からメールサーバ１２により承認者端末３，４に送られてくる注文承認依頼メッセージの電子メールの表示例を示す図である。図５に示すように、注文承認依頼メールの中には、注文承認画面のＵＲＬ５１が埋めこまれている。この注文承認依頼メールを受け取った承認者は、その中のＵＲＬ５１をマウスでクリックすることにより、ウェブブラウザによる注文承認画面を承認者端末３，４の表示装置に表示させることができる。
【００７１】本実施形態では、この注文承認依頼メールに埋め込まれたＵＲＬ５１に従って注文承認画面に遷移する際に、所定のログイン処理を行う。すなわち、上記ＵＲＬ５１をクリックすると、まずはウェブサーバ１１によってログイン画面が提供され、ログインＩＤとパスワードの入力が促される。ここで、承認者がログイン情報入力部３３を用いてログインＩＤやパスワードを入力すると、それが認証サーバ１の認証部２３に送られて認証処理が行われる。
【００７２】認証部２３では、認証情報記憶部１８に記憶されている認証情報に基づいて、入力されたログインＩＤとパスワードとを検証し、ログインしてきた者が承認者として登録されているかどうか、注文を行った者に対して承認を行う権限を有する正当な承認者かどうかなどを調べる。そして、認証が得られたときにのみ注文承認画面に遷移させる処理を行う。このようにすることにより、承認を行う権限を有する承認者だけが実際に承認を行えるようになり、認証に関する不正や間違いを防止することが可能となる。本発明のログイン手段は、認証部２３およびログイン情報入力部３３を含んで構成される。
【００７３】２４は承認画面作成部であり、上記認証部２３により承認者の認証が得られたときに、商品情報記憶部１４に記憶されている商品情報、認証情報記憶部１８に記憶されている認証情報、注文情報記憶部２０に記憶されている注文情報、ワークフロー情報記憶部２２記憶されているワークフロー情報などに基づいて、ＨＴＭＬ形式による注文承認画面を作成する。ここで作成された注文承認画面は、ウェブサーバ１１により承認者端末３，４に提供される。
【００７４】図６は、承認者端末３，４の表示装置に表示される注文承認画面の例を示す図である。図６に示すように、注文承認画面には、注文明細情報６１の他に、認証ワークフローの状態を表す状態一覧６２が表示されている。状態一覧６２には、注文を行った者が承認を得るべき全ての承認者およびその部署、承認の状態（未承認、承認済、代理承認済など）、承認日の情報が表示される。
【００７５】ここで、注文を行った者が承認を得るべき全ての承認者およびその部署は、注文情報に含まれる商品の購入金額と、認証情報に含まれる認証ルートおよび各人の購入限度額（決裁権限）とを比較することによって判断される。図６の例では、開発部開発２課に所属する担当者Ａが販売単価３０７，４４０円の時計付き横型ラジオを１個注文した場合に、購入金額の３０７，４４０円の決裁権限を持つのは開発部長であるため、開発２課の承認者（課長）と開発部の承認者（部長）の承認を得るべきことが表示されている。
【００７６】また、承認の状態は、ワークフロー情報記憶部２２に記憶されている現在の状態に基づいて判断される。図６の例では、課長および部長ともに未承認であることが示されている。つまり、この図６に示す注文承認画面は、課長が使用する承認者端末３に表示されるものであり、まだ課長の承認も済んでいないことを示している。
【００７７】この注文承認画面で課長は、注文を承認する場合は承認ボタン６３をクリックし、承認しない場合は却下ボタン６４をクリックする。図２の承認入力部３２は、図６に示す注文承認画面中の承認ボタン６３および却下ボタン６４を含み、本発明の承認手段はこの承認入力部３２を含んで構成される。
【００７８】このように、本実施形態では、商品の購入金額に応じて必要となる全ての承認者および承認の状態を注文承認画面に一覧として表示するようにしている。これにより、承認が必要な者と認証ワークフローの進捗状況とを一目で理解することが可能となる。
【００７９】上記承認入力部３２により注文の承認あるいは却下が行われると、そのことがウェブサーバ１１を介して承認受付部２５に入力される。そして、注文の承認あるいは却下が行われたことが状態遷移制御部２１に伝えられ、認証ワークフローの状態が遷移させられる。そして、注文が却下された場合は、そのことが確認メッセージ通知部２７によって注文者に対して電子メールで伝えられ、その注文に関する認証ワークフローの処理は終了する。
【００８０】一方、注文が承認された場合は、状態遷移制御部２１によって認証ワークフローの状態が遷移させられ、更に上の承認者から承認を得る必要があるかどうかが判断される。そして、必要な全ての承認が得られた場合には、確認メッセージ通知部２７を介して注文者に注文受付の確認メッセージが電子メールで通知される。また、更に上の承認が必要な場合には、承認依頼通知部２６を介して更に上の承認者に承認依頼通知メールが送信される。
【００８１】図６に示した例の場合、開発２課の課長だけでなく、開発部の部長の承認も必要なので、部長が使用する承認者端末４に対して承認依頼通知メールが送信される。これに対応して、部長がログインを行って図６の注文承認画面を開いたときには、状態一覧６２における開発２課の状態は「承認済」となり、承認者および承認日の情報も表示された状態となっている。
【００８２】ここで部長も注文の承認をすると、確認メッセージ通知部２７によって、全ての承認が済んだことを知らせる注文受付の確認メッセージが注文者の担当者端末２に送信される。図７に、この注文受付確認メッセージの電子メールの表示例を示す。注文却下確認メッセージの電子メールもこの図７とほぼ同様である。このような注文受付の確認メッセージあるいは注文却下の確認メッセージを担当者端末２に送ることにより、スピーディかつ正確な注文の確認を行うことが可能となる。
【００８３】また、３５は状態参照部であり、ワークフロー情報記憶部２２に記憶されている注文の認証ワークフローに関する現在の状態を参照するためのものである。状態参照部３５を用いて、例えば所望の注文番号などを指定すると、指定された注文に関する現在の認証ワークフローの状態が、ウェブサーバ１１によってＨＴＭＬ形式で表示される。このとき表示される画面には、例えば図６の状態一覧６２と同様の情報が含まれる。
【００８４】このような状態参照部３５を設けることにより、注文に関する認証ワークフローの状態を任意の時点で確認することができる。例えば、注文を出してから最終的な決定（注文受付または注文却下）がなかなか来ない場合に、この状態参照部３５を用いることで、認証ワークフローがどこで停滞しているかを確認することができる。
【００８５】本実施形態の認証ワークフローシステムではさらに、代理認証の機能を設けている。代理認証とは、ある承認者の代わりに、それより上の承認者によって注文の承認を行えるようにしたものである。例えば、ある承認者が長期出張などで承認を行えないような状態にあるとき、その承認者に代わって更に上の上司によって承認を行うことが可能である。
【００８６】例えば、注文者が上記状態参照部３５を用いて認証ワークフローの状態を参照したところ、開発２課での承認は済んでいるが、開発部のところで認証ワークフローが停滞していることが確認できたとする。この場合には、注文者は、開発部の部長より更に上の上司（図４の例によれば事業部長）に対して、代理認証を依頼することができる。
【００８７】代理認証の依頼を受けた事業部長は、自分が使用する端末あるいは担当者の端末などから、あらかじめ決められた固定のＵＲＬを指定して所定のログイン画面にアクセスする。そして、事業部長は自己のログインＩＤとパスワードとを入力してログインを行う。このとき入力された事業部長のログインＩＤやパスワードは、認証サーバ１の認証部２３に送られて認証処理が行われる。
【００８８】認証部２３では、認証情報記憶部１８に記憶されている認証情報に基づいて、入力されたログインＩＤとパスワードとを検証し、ログインしてきた者が代理認証を行う権限を有する者かどうかなどを調べる。そして、認証が得られたときには、認証情報記憶部１８に記憶されている認証情報、注文情報記憶部２０に記憶されている注文情報、ワークフロー情報記憶部２２に記憶されているワークフロー情報などに基づいて、その事業部長の配下にある組織内で未承認の注文を全て検索し、一覧として表示する。
【００８９】この未承認注文一覧の表示を見て事業部長は、担当者から聞いた注文番号などを頼りに代理認証の依頼を受けた注文を探し、マウスクリック等によってそれを指定する。注文の指定が行われると、承認画面作成部２４によって注文承認画面が作成され、表示される。このとき表示される注文承認画面は、図６に示した承認ボタン６３が代理承認ボタンに変わることを除けば、部長に対する注文承認画面と同じである。
【００９０】ここで、事業部長が注文の代理承認をすると、状態遷移制御部２１によって認証ワークフローの状態が「代理承認済」に遷移させられる。そして、これによって必要な承認が全て得られた場合には、確認メッセージ通知部２７を介して注文者に注文受付の確認メッセージが電子メールで通知される。
【００９１】このように、本実施形態では、状態参照部３５と代理認証の機能とを設けることにより、認証ワークフローの状態が停滞して先に進まなくなってしまう不都合を防止でき、一連の認証処理を速やかに行うことができるようになる。
【００９２】なお、以上に示したユーザ端末２，３，４の構成において、注文入力部３１、承認入力部３２、ログイン情報入力部３３および状態参照部３５の機能は、ウェブサーバ１１によって提供された所定の入力画面にキーボードやマウスなどの入力デバイスを用いて情報を入力することによって実現される。また、通知受信部３４は、電子メールの送受信機能の一部によって実現される。
【００９３】また、認証サーバ１およびユーザ端末２，３，４の各機能ブロックは、実際にはコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭ、あるいはこれ以外のハードディスク等に記憶されたプログラムが動作することによって実現できる。
【００９４】図３は、上記認証サーバ１による認証ワークフロー動作の例を示すフローチャートである。このフローチャートの動作を実行する前提として、商品情報、取引先情報、認証情報の登録は既に済んでいるものとする。なお、ここでは担当者Ａが担当者端末２から商品の注文を行い、その上司である課長および部長が承認者端末３，４から承認を行う場合を例にとって処理の流れを説明する。
【００９５】図３において、ステップＳ１では、認証サーバ１に入力されたイベントがユーザ端末２，３，４からの注文かどうかを判断する。そして、例えば担当者端末２から注文が入力された場合は、ステップＳ２に進み、注文管理部１９によってその注文に対してユニークな番号を付けるとともに、状態遷移制御部２１によって認証ワークフローの初期状態を設定する。
【００９６】次に、ステップＳ３で状態遷移制御部２１は、その注文を行った担当者Ａおよびその上司について設定されている購入限度額を認証情報記憶部１８の中から読み取る。そして、ステップＳ４で、注文された商品の購入金額が、上記読み取った担当者Ａの購入限度額を超えているかどうかを判断する。ここで、商品の購入金額がその担当者Ａの購入限度額を超えていない場合は、ステップＳ１６に進み、確認メッセージ通知部２７によって注文受付メッセージの電子メールを担当者端末２に送信する。
【００９７】一方、商品の購入金額がその担当者Ａの購入限度額を超えている場合は、ステップＳ５に進む。ここで状態遷移制御部２１は、その購入金額と、認証情報記憶部１８に記憶されている認証情報とを照らし合わせて、その注文に関して承認を得ることが必要な全ての承認者（今の例では課長および部長）を探索する。そして、ステップＳ６で、承認依頼通知部２６は、探索された全ての承認者のうち、最初の承認者（課長）に対する承認依頼の電子メールを作成して送信する。このとき、担当者Ａに対して承認が必要であることを知らせるメールも送信する。その後、ステップＳ１に戻る。
【００９８】上記ステップＳ１で注文の入力がないと判断したときは、ステップＳ７に進む。ステップＳ７では、認証サーバ１に入力されたイベントが、注文承認依頼メールに埋めこまれたＵＲＬ５１に対するアクセスであるかどうかをウェブサーバ１１において判断する。そして、このＵＲＬ５１に対してアクセスがあった場合は、ステップＳ８に進む。
【００９９】ステップＳ８では、ログインを行ってきた何れかの承認者端末３，４の表示装置にログイン画面を表示させる。最初は、課長の承認者端末３からログインが行われるので、当該課長の承認者端末３にログイン画面を表示させる。これに応じてログインが行われると、認証部２３は、ステップＳ９で認証処理を行い、ログインが正しく行われたかどうかを判定する。
【０１００】ここで、ログインが正しく行われていない場合は、ステップＳ１０でエラーメッセージを承認者端末３に通知した後、ステップＳ１に戻る。ログインが正しく行われた場合は、ステップＳ１１に進み、承認画面作成部２４によってＨＴＭＬによる注文承認画面を作成し、ウェブサーバ１１によってその注文承認画面を承認者端末３の表示装置に表示させる。このとき、注文承認画面には、上記ステップＳ５で探索した全ての承認者を状態一覧６２に表示する。そして、注文の承認あるいは却下の入力を待つ。
【０１０１】また、上記ステップＳ７で、認証サーバ１に入力されたイベントが、注文承認依頼メールに埋めこまれたＵＲＬ５１に対するアクセスでもないと判断した場合は、そのとき入力されたイベントは、代理認証を行うための固定のＵＲＬに対するアクセスということになる。よって、この場合は、ステップＳ１７に進む。ステップＳ１７では、入力された固定のＵＲＬに従って、ログインを行ってきた端末の表示装置に所定のログイン画面を表示する。
【０１０２】これに応じてログインが行われると、認証部２３は、ステップＳ１８で認証処理を行い、代理認証を行う権限を有する者によってログインが正しく行われたかどうかを判定する。ここで、ログインが正しく行われていない場合は、ステップＳ１０でエラーメッセージを通知した後、ステップＳ１に戻る。一方、ログインが正しく行われた場合は、ステップＳ１９に進み、事業部長の配下にある組織内で未承認の注文を全て検索し、一覧として表示する。
【０１０３】次のステップＳ２０では、この未承認注文の一覧の中から、代理認証を行いたい注文が指定されたかどうかを判断する。そして、注文の指定が行われると、ステップＳ１１に進み、承認画面作成部２４によってＨＴＭＬによる注文承認画面を作成し、ウェブサーバ１１によってその注文承認画面を表示させる。このとき表示される注文承認画面は、上述したように、図６に示した承認ボタン６３が代理承認ボタンに変わるだけで、その他は通常の注文承認画面と同じである。
【０１０４】次に、ステップＳ１２で、承認受付部２５は、承認者端末３において注文の承認があったか却下があったかを判断する。ここで、注文が却下された場合は、ステップＳ１３で注文却下のメッセージを担当者Ａの担当者端末２に送信し、ステップＳ１に戻る。一方、注文が承認された場合は、ステップＳ１４に進み、状態遷移制御部２１によって認証ワークフローの状態を遷移させる。このとき、正規の承認者によって承認が行われた場合には「承認済」、代理の承認者によって承認が行われた場合には「代理承認済」の状態にそれぞれ遷移する。
【０１０５】そして、ステップＳ１５で、全ての承認者による承認が済んだかどうかを判断し、済んでいない場合にはステップＳ６に戻り、済んだ場合にはステップＳ１６に進む。今の例の場合、課長による承認は済んだが、部長による承認はまだ済んでいないので、ステップＳ６に戻る。この場合、ステップＳ６では、部長に対する承認依頼の電子メールを作成して送信する。
【０１０６】以下同様にしてステップＳ７〜Ｓ１５の処理が行われ、部長の承認も行われた場合には、ステップＳ１６に進み、確認メッセージ通知部２７によって注文受付メッセージの電子メールを担当者端末２に送信する。そして、ステップＳ１に戻り、当該ステップＳ１とステップＳ７で、別の注文やメール内に埋めこまれたＵＲＬ５１へのアクセスがないかどうかを監視し続ける。
【０１０７】なお、必要な全ての承認が得られ、注文受付の確認メッセージが注文者に通知された時点で、その注文は正式に受注されたことになる。
【０１０８】以上詳しく説明したように、本実施形態によれば、商取引において必要となる決裁の一連の認証を電子的なワークフロー処理によって行うことができ、紙ベースによる煩雑な事務処理は全く行う必要がなくなる。また、認証ルートがあらかじめ登録され、これに従って認証の処理が半自動的に行われることとなるので、希望する商品を購入するのに承認が必要かどうかや、誰の承認を得なければならないか等について特に意識する必要もなくなる。これにより、認証処理を簡素化し、一連の電子商取引をよりスムーズに行うことができるようになる。
【０１０９】また、注文を行った商品購入者に対して注文受付あるいは注文却下の確認メッセージを送ることにより、スピーディかつ正確な注文の確認を行うことができる。また、電子店舗を運営する商品販売側においても、認証サーバ１内のワークフロー情報を参照することができ、注文について必要な承認が全て得られているかどうかを確認することができる。したがって、商品販売側の企業等にとっても、発注された注文が正式に承認を得ているかどうかを確認して、承認済みの注文のみを受けることができるので、電子商取引上のトラブル発生を少なくすることもできる。
【０１１０】また、本実施形態では、承認者端末３，４に対する承認依頼の通知を電子メールで行うとともに、承認をウェブブラウザによる注文承認画面で行うようにしたので、企業内の各人が使用するユーザ端末２，３，４においては電子メールの機能とウェブブラウザの機能とがあれば良く、特別なクライアントソフトウェアなどを備える必要がないというメリットも有する。
【０１１１】また、本実施形態では、注文に関する認証ワークフローの状態を任意の時点で確認することができるので、例えば認証ワークフローの処理が停滞している場合に、その原因箇所を容易に確認することができる。さらに本実施形態では、代理認証の機能を設けているので、認証ワークフローの状態が停滞して先に進まなくなってしまう不都合を防止でき、一連の認証処理を速やかに行うことができるようになる。
【０１１２】（第２の実施形態）次に、本発明の第２の実施形態について説明する。上記第１の実施形態では、認証サーバ１とユーザ端末２，３，４とをインターネット７で接続したが、第２の実施形態ではこれらをイントラネット（インターネットを介して行われる企業内（組織間）通信であるエクストラネットを含む）で接続する。イントラネットで接続した場合、認証サーバ１は、例えば企業内の資材調達部門などに置かれ、ユーザ端末２，３，４はその他の購買部門等に置かれる。
【０１１３】図８は、第２の実施形態による認証ワークフローシステムの一構成例を示す図である。この図８に示すシステムは、例えば企業内のある部門に属する担当者２がインターネット７上で商品の注文を行う際に、その商取引に伴う決裁のワークフローを認証サーバ１で処理し、全ての承認を得た時点で注文を仕入先８-1，８-2に対して発注したり、配送センタ９に対して配送指示を出したりするものである。なお、この図８において、図１R>１に示したものと同様の機能を有するものには同一の符号を付している。
【０１１４】図８において、認証サーバ１とユーザ端末２，３，４はイントラネット５を介して接続されている。本実施形態において、これらの認証サーバ１およびユーザ端末２，３，４は、例えば商品購入側の企業内に置かれる。そして、上述したように認証サーバ１は、その企業内の資材調達部門などに置かれ、ユーザ端末２，３，４はその他の購買部門等に置かれる。
【０１１５】なお、第１の実施形態でも述べたように、認証サーバ１とユーザ端末２，３，４は、必ずしも１つの企業内に置く必要はない。例えば、複数の企業にまたがったグループ企業や、企業以外の団体など、一連の承認処理が必要な組織であれば何れにも適用することが可能であり、その組織内の任意の場所に認証サーバ１およびユーザ端末２，３，４を設置することが可能である。
【０１１６】上記イントラネット５は、ファイアフォール６を介してインターネット７に接続されている。ファイアウォール６は、インターネット７を介して第三者がイントラネット５内に不正に侵入するのを防ぐために設けられる。インターネット７には、様々な仕入先企業の端末８-1，８-2や、例えば商品購入側の企業等が商品を在庫として持つ配送センタ９の端末など接続されている。本実施形態において、この仕入先端末８-1，８-2や配送センタ端末９は、商品購入側企業からの発注情報あるいは配送指示情報を受信する電子メール機能、ウェブブラウザ機能、あるいはファクシミリ機能などを有している。
【０１１７】本実施形態の認証ワークフローシステムでは、例えば担当者端末２から商品の注文が入力されると、当該担当者端末２および承認者端末３，４を含むユーザ端末と認証サーバ１との間のインタラクティブ処理により、その入力された注文に関する一連の電子決裁（上司による承認）の処理が行われる。そして、最終的に決裁が下りた時点で、インターネット７を介して仕入先端末８-1，８-2に対して発注が行われたり、配送センタ端末９に配送指示が行われたりする。
【０１１８】図９は、上記認証サーバ１およびユーザ端末２，３，４の機能的な構成例を示すブロック図である。この図９において、上記図２に示した機能ブロックと同じものには同一の符号を付し、重複する説明は省略する。
【０１１９】本実施形態において、商品登録部１３では、仕入先において販売している商品や、配送センタに在庫として存在する商品などに関する種々の情報を登録する。また、取引先登録部１５では、商品の取引先として、購入側企業、仕入先、配送センタなどに関する種々の情報を登録する。
【０１２０】また、状態遷移制御部２１は、第１の実施形態で説明した機能に加え、認証ワークフローの状態を遷移させて最終的に全ての承認が得られた時点で、承認済注文処理部２８に指示を出して、承認済の注文を用いて商品を手配するなどの次工程の処理をも行う。次工程の処理の例としては、仕入先端末８-1，８-2に発注の電子メールを送信したり、配送センタ端末９に配送指示の電子メールを送信する処理が考えられる。
【０１２１】すなわち、状態遷移制御部２１は、商品の購入金額が購入限度額内に収まっている場合（注文を行った者の購入限度額より商品の購入金額が低い場合、必要な承認が全て得られた場合の双方を含む）に、仕入先端末８-1，８-2に発注メールを送信したり、配送センタ端末９に配送指示メールを送信したりする処理を承認済注文処理部２８に対して指示する。
【０１２２】承認済注文処理部２８は、上記状態遷移制御部２１からの指示に応じて、仕入先端末８-1，８-2に対して発注の通知を電子メールで行う。または、配送センタ端末９に対して配送指示の通知を電子メールで行う。このとき、注文情報記憶部２０に記憶されている注文情報に基づいて発注先または配送指示先が判断される。この発注情報や配送指示情報には、注文情報記憶部２０に記憶されている注文情報の他に、必要な承認が全て得られたことを表す情報が含まれる。なお、ここでは発注および配送指示を電子メールで行うこととしているが、電話やファクシミリ通信などにより行うようにしても良い。本発明の承認済注文処理手段は、上記状態遷移制御部２１および承認済注文処理部２８を含んで構成される。
【０１２３】上記のように構成した認証サーバ１による認証ワークフロー動作は、図３に示したフローチャートとほぼ同様である。ただし、本実施形態の場合は、ステップＳ１６の処理の後でステップＳ１に戻る前に、仕入先端末８-1，８-2に対する発注メールの送信、あるいは配送センタ端末９に対する配送指示メールの送信を行う。
【０１２４】以上詳しく説明したように、第２の実施形態によれば、必要な承認が全て得られた注文に関する発注情報や配送指示情報等を、承認済みであることを表す情報と共に仕入先端末８-1，８-2、配送センタ端末９に送信するようにしたので、上述した第１の実施形態による効果に加え、注文を承認するまでの決裁処理と、オンライン上で発注や配送指示を行う処理とを有機的に結び付けて一連の電子商取引をよりスムーズに行うことができる。
【０１２５】（第３の実施形態）次に、本発明の第３の実施形態について説明する。上記第１および第２の実施形態では、商品情報、取引先情報、認証情報の登録を認証サーバ１において行うようにしたが、第３の実施形態ではこれらの情報の登録を、認証サーバ１以外の端末から認証サーバ１内のウェブサーバ１１にアクセスすることによって行えるようにする。
【０１２６】図１０は、第３の実施形態による認証ワークフローシステムの一構成例を示す図である。この図１０R>０に示すシステムでは、店舗側には、認証サーバ１の他に店舗管理端末７１が備えられ、これらが相互に接続される。また、購入企業側には、担当者端末２、承認者端末３，４の他に購入企業管理端末７２が備えられ、これらが相互に接続される。店舗管理端末７１から認証サーバ１に対して商品情報や取引先情報の登録を行うことができ、購入企業管理端末７２から認証サーバ１に対して認証情報の登録を行うことができる。
【０１２７】図１１は、上記図１０に示した認証サーバ１、ユーザ端末２，３，４、店舗管理端末７１および購入企業管理端末７２の機能的な構成例を示すブロック図である。この図１１において、上記図２に示した機能ブロックと同じものには同一の符号を付し、重複する説明は省略する。
【０１２８】本実施形態において、認証サーバ１は、図２R>２に示した商品登録部１３、取引先登録部１５、認証情報登録部１７の代わりに、情報記録部８１を備えている。また、店舗管理端末７１は、商品登録部８２および取引先登録部８３を備え、購入企業管理端末７２は、認証情報登録部８４を備えている。
【０１２９】上記商品登録部８２、取引先登録部８３および認証情報登録部８４により登録する商品情報、取引先情報、認証情報の内容は、図２の商品登録部１３、取引先登録部１５、認証情報登録部１７により登録する各情報と同じである。ただし、本実施形態では、店舗管理端末７１や購入企業管理端末７２から認証サーバ１内のウェブサーバ１１にアクセスすることにより、ウェブブラウザを通じて各情報の登録を行う。ウェブサーバ１１を通じて登録された各情報は、情報記録部８１によって商品情報記憶部１４、取引先情報記憶部１６、認証情報記憶部１８にそれぞれ記憶される。
【０１３０】このように、本実施形態では、商品情報、取引先情報、認証情報の登録を、認証サーバ１以外の店舗管理端末７１および購入企業管理端末７２からウェブへのアクセスによって行えるようにしたので、これらの情報登録を機能分散した運用を行うことが可能となる。
【０１３１】これにより、店舗側では、自己が扱う商品や取引先についてのみ情報登録を行えば良く、購入企業側の認証情報の登録については購入企業自身に任せることができる。特に、購入企業が数多くなってきたときには、それぞれの企業が個別に自己の認証情報を登録すれば良く、店舗側の情報登録の負担を大幅に軽減することができる。また、購入企業側にとっても、機密性のある組織情報を店舗側に開示しなくても済むというメリットを有する。
【０１３２】なお、上記第１〜第３の実施形態では、インターネット７を通じて行う電子商取引を例に挙げて説明したが、通常の商取引を行う際の決裁に関する認証ワークフローにも適用することが可能である。この場合には、図８に示したある企業のイントラネット５はインターネット７に接続されている必要は必ずしもなく、企業内の閉じたネットワークで認証ワークフローの処理が実行されるようにしても良い。
【０１３３】また、上記第２の実施形態では、商品の購入金額が注文者の購入限度額以内の場合、および全ての承認が得られた場合には、仕入先端末８-1，８-2に対する発注や配送センタ端末９に対する配送指示を自動的に送信するようにしたが、まずは注文者が確認をした後、注文者の指示に応じてこれらの情報を送信するようにしても良い。この場合は、必要な承認の全てが得られていない状態で指示が出されたときには、発注情報や配送指示情報の送信を禁止するように制御する。このようにすることで、最終的な決裁が下りていない注文が誤って発注あるいは配送指示されてしまうことを防ぐことが可能となる。
【０１３４】また、上記第３の実施形態では、企業間の取引に対して情報登録の分散機能を実現した例を示したが、図８に示したような企業の購買システムに対して情報登録の分散機能を実現することも可能である。この場合、図１０および図１１に示した店舗管理端末７１および購入企業管理端末７２に相当する端末は、企業内の資材調達部門に置かれる。
【０１３５】なお、以上に説明した各実施形態の認証ワークフローシステムおよび認証サーバ装置は、上述したようにコンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記機能を果たすように動作させるプログラムを、例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。上記プログラムを記録する記録媒体としては、ＣＤ−ＲＯＭ以外に、フロッピーディスク、ハードディスク、磁気テープ、光磁気ディスク、不揮発性メモリカード等を用いることができる。
【０１３６】また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。
【０１３７】また、本発明はネットワーク環境で利用されるものであり、認証サーバ１やユーザ端末２，３，４の全部あるいは一部のプログラムが他のコンピュータで実行されるようになっていても良い。
【０１３８】上記説明した実施形態は、何れも本発明を実施するにあたっての具体化の一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。
【０１３９】
【発明の効果】以上説明したように本発明によれば、注文について最終的な承認を得るまでの決裁処理を電子的に行うことにより簡素化し、一連の商取引をよりスムーズに行うことができるようになる。また、本発明のその他の特徴によれば、必要な承認が全て得られた場合には、その注文に関する次工程の処理まで実行するので、注文を承認するまでの決裁処理と、オンライン上で発注や配送指示などを行う処理とを有機的に結び付けて一連の電子商取引をよりスムーズに行うことができるようになる。また、商品の販売側企業においても、購入側企業から発注された注文が正式に承認を得ているものかどうかを容易に確認でき、電子商取引上のトラブル発生を少なくすることができる。
【図面の簡単な説明】
【図１】第１の実施形態による認証ワークフローシステムの一構成例を示す図である。
【図２】第１の実施形態による認証サーバおよびユーザ端末の機能的な構成例を示すブロック図である。
【図３】第１の実施形態の認証サーバによる認証ワークフロー動作の例を示すフローチャートである。
【図４】本実施形態による認証サーバの表示装置に表示される認証情報の登録画面の例を示す図である。
【図５】承認者端末の表示装置に表示される注文承認依頼メールの例を示す図である。
【図６】承認者端末の表示装置に表示される注文承認画面の例を示す図である。
【図７】注文者端末の表示装置に表示される注文受付確認通知メールの例を示す図である。
【図８】第２の実施形態による認証ワークフローシステムの一構成例を示す図である。
【図９】第２の実施形態による認証サーバおよびユーザ端末の機能的な構成例を示すブロック図である。
【図１０】第３の実施形態による認証ワークフローシステムの一構成例を示す図である。
【図１１】第３の実施形態による認証サーバおよびユーザ端末の機能的な構成例を示すブロック図である。
【符号の説明】
１ 認証サーバ
２ 担当者端末
３，４ 承認者端末
５ イントラネット
６ ファイアウォール
７ インターネット
８-1，８-2 仕入先端末
９ 配送センタ端末
１１ ウェブサーバ
１２ メールサーバ
１３ 商品登録部
１４ 商品情報記憶部
１５ 取引先登録部
１６ 取引先情報記憶部
１７ 認証情報登録部
１８ 認証情報記憶部
１９ 注文管理部
２０ 注文情報記憶部
２１ 状態遷移制御部
２２ ワークフロー情報記憶部
２３ 認証部
２４ 承認画面作成部
２５ 承認受付部
２６ 承認依頼通知部
２７ 確認メッセージ通知部
２８ 承認済注文処理部
３１ 注文入力部
３２ 承認入力部
３３ ログイン情報入力部
３４ 通知受信部
３５ 状態参照部
７１ 店舗管理端末
７２ 購入企業管理端末
８１ 商品登録部
８２ 取引先登録部
８３ 認証情報登録部
【特許請求の範囲】
【請求項１】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を登録する認証情報登録手段と、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力手段と、上記購入商品情報入力手段により入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証情報登録手段により登録された承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に対応して、承認に関する情報を入力する承認手段とを備えたことを特徴とする認証ワークフローシステム。
【請求項２】 上記承認要求通知手段は、上記購入商品情報入力手段により入力された商品の購入金額と、ある承認者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合に、更に上の承認者に対して承認を要求する通知を行うことを特徴とする請求項１に記載の認証ワークフローシステム。
【請求項３】 上記承認手段によって必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする請求項１または２に記載の認証ワークフローシステム。
【請求項４】 上記確認通知手段は、上記承認手段によって必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする請求項３に記載の認証ワークフローシステム。
【請求項５】 上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認手段による承認に関する情報入力をウェブブラウザによる入力画面で行うようにしたことを特徴とする請求項１〜４の何れか１項に記載の認証ワークフローシステム。
【請求項６】 上記電子メールに埋め込まれたアドレスに従って上記ウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うログイン手段を備えたことを特徴とする請求項５に記載の認証ワークフローシステム。
【請求項７】 上記ウェブブラウザによる入力画面には、上記商品の購入金額に応じて必要となる全ての承認者および承認の有無を表示することを特徴とする請求項５または６に記載の認証ワークフローシステム。
【請求項８】 上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を参照する状態参照手段とを備えたことを特徴とする請求項１〜７の何れか１項に記載の認証ワークフローシステム。
【請求項９】 上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする請求項８に記載の認証ワークフローシステム。
【請求項１０】 上記商取引はネットワーク上で行われる電子商取引であることを特徴とする請求項１〜９の何れか１項に記載の認証ワークフローシステム。
【請求項１１】 上記承認手段によって必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする請求項１０に記載の認証ワークフローシステム。
【請求項１２】 必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする請求項１１に記載の認証ワークフローシステム。
【請求項１３】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートを登録する認証情報登録手段と、上記認証情報登録手段により登録された認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする認証ワークフローシステム。
【請求項１４】 上記認証情報登録手段は、上記認証ワークフローに関する処理を行う認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって上記認証情報の登録を行うことを特徴とする請求項１〜１３の何れか１項に記載の認証ワークフローシステム。
【請求項１５】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を記憶する認証情報記憶手段と、入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報記憶手段により記憶されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に応じて上記承認者により入力された承認に関する情報を受け付ける承認受付手段とを備えたことを特徴とする認証サーバ装置。
【請求項１６】 上記承認要求通知手段は、上記入力された商品の購入金額と、ある承認者に関して上記認証情報記憶手段により記憶されている商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合に、更に上の承認者に対して承認を要求する通知を行うことを特徴とする請求項１５に記載の認証サーバ装置。
【請求項１７】 必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする請求項１５または１６に記載の認証サーバ装置。
【請求項１８】 上記確認通知手段は、必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする請求項１７に記載の認証サーバ装置。
【請求項１９】 上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認要求通知の電子メールに埋め込まれたアドレスが指定されたときに、所定のログイン処理を経て上記承認を促すためのウェブブラウザによる入力画面に遷移させるようにしたことを特徴とする請求項１５〜１８の何れか１項に記載の認証サーバ装置。
【請求項２０】 上記ウェブブラウザによる入力画面には、上記商品の購入金額に応じて必要となる全ての承認者および承認の有無を表示することを特徴とする請求項１９に記載の認証サーバ装置。
【請求項２１】 上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を要求に応じて提供する状態情報提供手段とを備えたことを特徴とする請求項１５〜２０の何れか１項に記載の認証サーバ装置。
【請求項２２】 上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする請求項２１に記載の認証サーバ装置。
【請求項２３】 上記商取引はネットワーク上で行われる電子商取引であることを特徴とする請求項１５〜２２の何れか１項に記載の認証サーバ装置。
【請求項２４】 必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする請求項２３に記載の認証サーバ装置。
【請求項２５】 上記必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする請求項２４に記載の認証サーバ装置。
【請求項２６】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートを記憶する認証情報記憶手段と、上記認証情報記憶手段により記憶されている認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする認証サーバ装置。
【請求項２７】 上記認証情報記憶手段に記憶される認証情報は、上記認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって登録されることを特徴とする請求項１５〜２６の何れか１項に記載の認証サーバ装置。
【請求項２８】 商取引において必要となる決裁の認証を行う決裁に関する認証方法であって、認証ルートおよび各承認者が持つ商品購入限度額などの認証情報を登録する認証情報登録ステップと、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力ステップと、上記入力された商品の購入金額と、その入力を行った者に関して登録されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知ステップと、上記通知された承認要求に対応して、承認に関する情報を入力する承認ステップとを有することを特徴とする決裁に関する認証方法。
【請求項２９】 上記入力された商品の購入金額と、ある承認者に関して登録されている商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合には、上記承認要求通知ステップで更に上の承認者に対して承認を要求し、上記承認要求通知ステップと上記承認ステップとを繰り返し行うようにしたことを特徴とする請求項２８に記載の決裁に関する認証方法。
【請求項３０】 上記承認ステップで必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知ステップを更に有することを特徴とする請求項２８または２９に記載の決裁に関する認証方法。
【請求項３１】 上記確認通知ステップでは、上記承認ステップによって必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする請求項３０に記載の決裁に関する認証方法。
【請求項３２】 上記承認要求通知ステップでの承認要求の通知、上記確認通知ステップでの確認メッセージの通知を電子メールで行うとともに、上記承認ステップでの承認に関する情報入力をウェブブラウザによる入力画面で行うようにしたことを特徴とする請求項２８〜３１の何れか１項に記載の決裁に関する認証方法。
【請求項３３】 上記電子メールに埋め込まれたアドレスに従って上記ウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うようにしたことを特徴とする請求項３２に記載の決裁に関する認証方法。
【請求項３４】 上記認証ワークフローの現在の状態を参照できるようにするとともに、上記承認要求通知ステップで上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認めるようにしたことを特徴とする請求項２８〜３３の何れか１項に記載の決裁に関する認証方法。
【請求項３５】 上記商取引はネットワーク上で行われる電子商取引であり、上記承認ステップで必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理ステップを更に有することを特徴とする請求項２８〜３４の何れか１項に記載の決裁に関する認証方法。
【請求項３６】 必要な承認の全てが得られていない注文については上記次工程の処理の実行を禁止するようにしたことを特徴とする請求項３５に記載の決裁に関する認証方法。
【請求項３７】 請求項１〜２７の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項３８】 請求項２８〜３６の何れか１項に記載された決裁の認証方法の処理手順をコンピュータに実行させるためのプログラム記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を登録する認証情報登録手段と、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力手段と、上記購入商品情報入力手段により入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証情報登録手段により登録された承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に対応して、承認に関する情報を入力する承認手段とを備えたことを特徴とする認証ワークフローシステム。
【請求項２】 上記承認要求通知手段は、上記購入商品情報入力手段により入力された商品の購入金額と、ある承認者に関して上記認証情報登録手段により登録された商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合に、更に上の承認者に対して承認を要求する通知を行うことを特徴とする請求項１に記載の認証ワークフローシステム。
【請求項３】 上記承認手段によって必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする請求項１または２に記載の認証ワークフローシステム。
【請求項４】 上記確認通知手段は、上記承認手段によって必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする請求項３に記載の認証ワークフローシステム。
【請求項５】 上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認手段による承認に関する情報入力をウェブブラウザによる入力画面で行うようにしたことを特徴とする請求項１〜４の何れか１項に記載の認証ワークフローシステム。
【請求項６】 上記電子メールに埋め込まれたアドレスに従って上記ウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うログイン手段を備えたことを特徴とする請求項５に記載の認証ワークフローシステム。
【請求項７】 上記ウェブブラウザによる入力画面には、上記商品の購入金額に応じて必要となる全ての承認者および承認の有無を表示することを特徴とする請求項５または６に記載の認証ワークフローシステム。
【請求項８】 上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を参照する状態参照手段とを備えたことを特徴とする請求項１〜７の何れか１項に記載の認証ワークフローシステム。
【請求項９】 上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする請求項８に記載の認証ワークフローシステム。
【請求項１０】 上記商取引はネットワーク上で行われる電子商取引であることを特徴とする請求項１〜９の何れか１項に記載の認証ワークフローシステム。
【請求項１１】 上記承認手段によって必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする請求項１０に記載の認証ワークフローシステム。
【請求項１２】 必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする請求項１１に記載の認証ワークフローシステム。
【請求項１３】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証ワークフローシステムであって、認証ルートを登録する認証情報登録手段と、上記認証情報登録手段により登録された認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする認証ワークフローシステム。
【請求項１４】 上記認証情報登録手段は、上記認証ワークフローに関する処理を行う認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって上記認証情報の登録を行うことを特徴とする請求項１〜１３の何れか１項に記載の認証ワークフローシステム。
【請求項１５】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートおよび各人が持つ商品購入限度額などの認証情報を記憶する認証情報記憶手段と、入力された注文商品の購入金額と、その注文の入力を行った者に関して上記認証情報記憶手段により記憶されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知手段と、上記承認要求通知手段により通知された承認要求に応じて上記承認者により入力された承認に関する情報を受け付ける承認受付手段とを備えたことを特徴とする認証サーバ装置。
【請求項１６】 上記承認要求通知手段は、上記入力された商品の購入金額と、ある承認者に関して上記認証情報記憶手段により記憶されている商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合に、更に上の承認者に対して承認を要求する通知を行うことを特徴とする請求項１５に記載の認証サーバ装置。
【請求項１７】 必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知手段を備えたことを特徴とする請求項１５または１６に記載の認証サーバ装置。
【請求項１８】 上記確認通知手段は、必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする請求項１７に記載の認証サーバ装置。
【請求項１９】 上記承認要求通知手段による承認要求の通知、上記確認通知手段による確認メッセージの通知を電子メールで行うとともに、上記承認要求通知の電子メールに埋め込まれたアドレスが指定されたときに、所定のログイン処理を経て上記承認を促すためのウェブブラウザによる入力画面に遷移させるようにしたことを特徴とする請求項１５〜１８の何れか１項に記載の認証サーバ装置。
【請求項２０】 上記ウェブブラウザによる入力画面には、上記商品の購入金額に応じて必要となる全ての承認者および承認の有無を表示することを特徴とする請求項１９に記載の認証サーバ装置。
【請求項２１】 上記認証ワークフローの遷移の状態を注文毎に記憶するワークフロー情報記憶手段と、上記ワークフロー情報記憶手段に記憶されている認証ワークフローの現在の状態を要求に応じて提供する状態情報提供手段とを備えたことを特徴とする請求項１５〜２０の何れか１項に記載の認証サーバ装置。
【請求項２２】 上記承認要求通知手段により上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認める代理認証手段を備えたことを特徴とする請求項２１に記載の認証サーバ装置。
【請求項２３】 上記商取引はネットワーク上で行われる電子商取引であることを特徴とする請求項１５〜２２の何れか１項に記載の認証サーバ装置。
【請求項２４】 必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理手段を備えたことを特徴とする請求項２３に記載の認証サーバ装置。
【請求項２５】 上記必要な承認の全てが得られていない注文について、上記次工程の処理の実行を禁止する禁止手段を備えたことを特徴とする請求項２４に記載の認証サーバ装置。
【請求項２６】 商取引において必要となる決裁の認証ワークフローに関する処理を行う認証サーバ装置であって、認証ルートを記憶する認証情報記憶手段と、上記認証情報記憶手段により記憶されている認証ルートに従って、電子メールおよびウェブブラウザの機能を用いて商品注文に関する一連の決裁の認証処理を行う認証ワークフロー処理手段とを備えたことを特徴とする認証サーバ装置。
【請求項２７】 上記認証情報記憶手段に記憶される認証情報は、上記認証サーバ装置とは別の端末から上記認証サーバ装置へのウェブによるアクセスによって登録されることを特徴とする請求項１５〜２６の何れか１項に記載の認証サーバ装置。
【請求項２８】 商取引において必要となる決裁の認証を行う決裁に関する認証方法であって、認証ルートおよび各承認者が持つ商品購入限度額などの認証情報を登録する認証情報登録ステップと、購入希望の商品およびその購入金額に関する情報を入力する購入商品情報入力ステップと、上記入力された商品の購入金額と、その入力を行った者に関して登録されている商品購入限度額とを比較し、上記商品の購入金額が上記商品購入限度額を超えている場合に、上記認証ルートにより示される承認者に対して承認を要求する通知を行う承認要求通知ステップと、上記通知された承認要求に対応して、承認に関する情報を入力する承認ステップとを有することを特徴とする決裁に関する認証方法。
【請求項２９】 上記入力された商品の購入金額と、ある承認者に関して登録されている商品購入限度額とを比較し、上記商品の購入金額が上記承認者の商品購入限度額を超えている場合には、上記承認要求通知ステップで更に上の承認者に対して承認を要求し、上記承認要求通知ステップと上記承認ステップとを繰り返し行うようにしたことを特徴とする請求項２８に記載の決裁に関する認証方法。
【請求項３０】 上記承認ステップで必要な承認が全て得られたときに、注文受付の確認メッセージを注文者に対して通知する確認通知ステップを更に有することを特徴とする請求項２８または２９に記載の決裁に関する認証方法。
【請求項３１】 上記確認通知ステップでは、上記承認ステップによって必要な承認が却下されたときに、注文却下の確認メッセージを注文者に対して通知することを特徴とする請求項３０に記載の決裁に関する認証方法。
【請求項３２】 上記承認要求通知ステップでの承認要求の通知、上記確認通知ステップでの確認メッセージの通知を電子メールで行うとともに、上記承認ステップでの承認に関する情報入力をウェブブラウザによる入力画面で行うようにしたことを特徴とする請求項２８〜３１の何れか１項に記載の決裁に関する認証方法。
【請求項３３】 上記電子メールに埋め込まれたアドレスに従って上記ウェブブラウザによる入力画面に遷移する際に、所定のログイン処理を行うようにしたことを特徴とする請求項３２に記載の決裁に関する認証方法。
【請求項３４】 上記認証ワークフローの現在の状態を参照できるようにするとともに、上記承認要求通知ステップで上記承認要求が通知された承認者の代わりに、更に上の承認者が上記承認に関する情報を入力することを認めるようにしたことを特徴とする請求項２８〜３３の何れか１項に記載の決裁に関する認証方法。
【請求項３５】 上記商取引はネットワーク上で行われる電子商取引であり、上記承認ステップで必要な承認が全て得られた注文に関する次工程の処理を実行する承認済注文処理ステップを更に有することを特徴とする請求項２８〜３４の何れか１項に記載の決裁に関する認証方法。
【請求項３６】 必要な承認の全てが得られていない注文については上記次工程の処理の実行を禁止するようにしたことを特徴とする請求項３５に記載の決裁に関する認証方法。
【請求項３７】 請求項１〜２７の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項３８】 請求項２８〜３６の何れか１項に記載された決裁の認証方法の処理手順をコンピュータに実行させるためのプログラム記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図４】
【図５】
【図３】
【図６】
【図７】
【図１０】
【図８】
【図９】
【図１１】
【図２】
【図４】
【図５】
【図３】
【図６】
【図７】
【図１０】
【図８】
【図９】
【図１１】
【公開番号】特開２００１−３３１７５８（Ｐ２００１−３３１７５８Ａ）
【公開日】平成１３年１１月３０日（２００１．１１．３０）
【国際特許分類】
【出願番号】特願２０００−１５０５１５（Ｐ２０００−１５０５１５）
【出願日】平成１２年５月２２日（２０００．５．２２）
【出願人】（３９９１０４８４４）住商情報システム株式会社 (7)
【Ｆターム（参考）】
【公開日】平成１３年１１月３０日（２００１．１１．３０）
【国際特許分類】
【出願日】平成１２年５月２２日（２０００．５．２２）
【出願人】（３９９１０４８４４）住商情報システム株式会社 (7)
【Ｆターム（参考）】
[ Back to top ]