(57)【要約】【課題】電子商取引における効率的な証跡管理を実現する。【解決手段】電子商取引装置１００は、顧客から取引注文を受け付けると、その取引注文について顧客が実行資格を有しているかを確認すべきか判定する。この判定は顧客属性に基づいて実行される。確認の必要があれば、確認画面を顧客端末２００に表示させ、顧客が確認画面に対して確認した旨を示したことを条件として取引注文を実行し、顧客により確認がなされた旨を取引注文と対応づけて取引履歴情報に記録する。【選択図】図２
2009080688.tif 000002
【特許請求の範囲】
【請求項１】
電子商取引サービスの顧客の属性として、顧客属性情報を保持する顧客属性保持部と、
取引注文の実行資格を有するか確認する必要がある顧客の属性を確認属性として、取引注文の種類と確認属性を対応づけて保持する確認属性保持部と、
顧客から、取引注文の発注指示を受信する注文受信部と、
前記発注指示が受信されたとき、前記顧客属性情報を参照し、前記発注指示元の顧客の属性が前記発注指示された取引注文についての確認属性に該当するかを判定する確認属性判定部と、
前記確認属性に該当するとき、前記取引注文の実行資格を有している旨を明示するための確認入力を前記顧客に促すための確認画面を前記顧客のクライアント端末に表示させる確認表示部と、
前記確認入力を検出する確認検出部と、
前記発注指示された取引注文を実行し、所定の取引履歴情報に記録する注文実行部と、を備え、
前記注文実行部は、前記顧客の属性が前記確認属性に該当するときには前記確認入力が検出されたことを条件として前記取引注文を実行し、前記確認入力が検出された旨を示す確認情報を前記取引注文と対応づけて前記取引履歴情報に記録することを特徴とする電子商取引装置。
【請求項２】
前記確認属性保持部は、所定の株式銘柄の取引についてインサイダー取引に該当する可能性がある顧客の属性を前記株式銘柄の取引注文に対する確認属性として保持し、
前記確認表示部は、前記顧客による前記株式銘柄の取引注文がインサイダー取引に該当しない旨を明示させるための画面として前記確認画面を表示させることを特徴とする請求項１に記載の電子商取引装置。
【請求項３】
前記確認検出部は、前記確認画面に対する前記確認入力として、前記顧客の声による音声データの入力を検出することを特徴とする請求項１に記載の電子商取引装置。
【請求項４】
顧客の声による音声データを保持する音声保持部と、
前記確認入力として入力された前記顧客の音声データと前記顧客についてあらかじめ保持されている音声データとを比較して、前記顧客の本人認証を実行する音声認証部と、を更に備え、
前記注文実行部は、前記顧客の属性が前記確認属性に該当するときには、前記本人認証に成功したことを条件として前記取引注文を実行することを特徴とする請求項３に記載の電子商取引装置。
【請求項５】
前記注文実行部は、前記確認情報として、前記確認入力として入力された音声データを前記取引履歴情報に記録することを特徴とする請求項３に記載の電子商取引装置。
【請求項６】
電子商取引サービスの顧客の属性として、顧客属性情報を保持する機能と、
取引注文の実行資格を有するか確認する必要がある顧客の属性を確認属性として、取引注文の種類と確認属性を対応づけて保持する機能と、
顧客から、取引注文の発注指示を受信する機能と、
前記発注指示が受信されたとき、前記顧客属性情報を参照し、前記発注指示元の顧客の属性が前記発注指示された取引注文についての確認属性に該当するかを判定する機能と、
前記確認属性に該当するとき、前記取引注文の実行資格を有している旨を明示するための確認入力を前記顧客に促すための確認画面を前記顧客のクライアント端末に表示させる機能と、
前記確認入力を検出する機能と、
前記発注指示された取引注文を実行し、所定の取引履歴情報に記録する機能と、をコンピュータに発揮させ、
前記顧客の属性が前記確認属性に該当するときには前記確認入力が検出されたことを条件として前記取引注文を実行し、前記確認入力が検出された旨を示す確認情報を前記取引注文と対応づけて前記取引履歴情報に記録することを特徴とする電子商取引プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、電子商取引に関し、特に、電子商取引において顧客の意思を確認するための技術、に関する。
【背景技術】
【０００２】
近年、コンピュータの普及とネットワーク技術の進展にともない、ネットワークを介した電子情報の交換が盛んになっている。商取引の多くも、ネットワークを介したいわゆる電子商取引に移行しつつあり、最近ではインターネット上にさまざまな電子商取引サイトが開設されている。
【０００３】
電子商取引においては、顧客の明示的な意思確認を必要とする場面も多い。たとえば、インターネットを介した証券取引（以下、「インターネット証券取引」とよぶ）であれば、顧客により指定される株式銘柄の取引がインサイダー取引にあたらないことを顧客に確認する必要がある。また、信用取引口座の開設に際しても、投資経験や保有資産に関して一定の制約条件を設けることも多い。顧客自らこのような制約条件を満たしていることを明示しなければ、信用取引口座の開設は許可されない。
【特許文献１】特開２００１−７７９２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
このように、一部の取引については、顧客の明示的な意思確認の上で取引が実行される必要がある。また、明示的な意思確認がなされた上で取引が実行されたことが客観的に証明できることも重要である。しかし、このような手続きの正しさを証明するために、書面による意思確認を行うとすれば、顧客・事業者双方にとって事務負担が大きく、電子商取引の利便性が減殺されてしまう。
【０００５】
本発明は、上記課題に基づいて完成された発明であり、その主たる目的は、電子商取引における効率的な証跡管理技術、を提供することにある。
【課題を解決するための手段】
【０００６】
本発明のある態様は、電子商取引装置に関する。
この装置は、顧客から取引注文を受け付けると、その取引注文について顧客が実行資格を有しているかを確認すべきか判定する。この判定は顧客属性に基づいて実行される。確認の必要があれば、確認画面を顧客のクライアント端末に表示させ、顧客が確認画面に対して確認した旨を示したことを条件として取引注文を実行し、顧客により確認がなされた旨を取引注文と対応づけて取引履歴情報に記録する。
【０００７】
なお、以上の構成要素の任意の組合せ、本発明を方法、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。
【発明の効果】
【０００８】
本発明によれば、電子商取引における証跡管理を効率化させることができる。
【発明を実施するための最良の形態】
【０００９】
図１は、電子商取引システム２０６のハードウェア構成図である。
本実施例に示す電子商取引システム２０６は、インターネット証券取引を実現するためのシステムであるとして説明する。電子商取引システム２０６においては、電子商取引装置１００が複数の顧客端末２００ａ、２００ｂ、・・・、２００ｃ（以下、単に「顧客端末２００」とよぶ）とインターネット２０２を介して接続される。また、電子商取引装置１００は、ＬＡＮ（Local Area Network）を介して、業務システム２０４と接続される。業務システム２０４は、株式等の発注や決済を処理するためのシステムである。
【００１０】
電子商取引装置１００は、ウェブサーバとしての機能を有し、顧客端末２００にウェブページを送信する。このウェブページにより、顧客が業務システム２０４にアクセスするためのユーザインタフェースが提供される。顧客端末２００は、ウェブブラウザを搭載した一般的なウェブ端末であればよい。ただし、本実施例における顧客端末２００は、顧客が声を入力するための音声入力手段を備える。ここでいう音声入力手段は、マイクや音声処理ソフトウェアなど既知技術の応用により実現されればよい。音声入力手段の使用場面については後述する。
【００１１】
顧客は、顧客端末２００を操作して、電子商取引装置１００により提供される取引画面を介して各種取引注文を入力する。電子商取引装置１００は、顧客端末２００から取引注文を受信し、業務システム２０４にその取引注文の実行を指示することにより、インターネット証券取引業務が実現される。
【００１２】
図２は、電子商取引装置１００の機能ブロック図である。
ここに示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
ここでは、各部の機能を中心として説明し、それらの連携、データ構造、作用については、図３以降に関連して詳述する。
【００１３】
電子商取引装置１００は、ユーザインタフェース処理部１１０、データ処理部１３０およびデータ保持部１４０を含む。
ユーザインタフェース処理部１１０は、顧客とのユーザインタフェース処理を担当する。ユーザインタフェース処理部１１０は、顧客端末２００に取引画面を表示させる。より具体的には、ユーザインタフェース処理部１１０の表示部１１４は、所定のウェブページを顧客端末２００に送信し、顧客端末２００は受信したウェブページをウェブブラウザにより画面表示させる。データ処理部１３０は、ユーザインタフェース処理部１１０やデータ保持部１４０から取得されたデータを元にして各種のデータ処理を実行する。データ処理部１３０は、ユーザインタフェース処理部１１０とデータ保持部１４０との間のインタフェースの役割も果たす。データ保持部１４０は、各種データを保持するための記憶領域である。
【００１４】
ユーザインタフェース処理部１１０：
ユーザインタフェース処理部１１０は、入力部１１２と表示部１１４を含む。表示部１１４は、各顧客端末２００に対してウェブページを送信することにより、顧客端末２００に取引画面を表示させる。表示部１１４は、確認表示部１２０を含む。確認表示部１２０は顧客端末２００に「確認画面」を表示させる。確認画面は、顧客の要求する取引注文について、顧客が確かに取引資格を有しているかを顧客に確認させるために表示される画面であるが、詳しくは後述する。
【００１５】
入力部１１２は、取引画面に対して顧客が入力した各種データを受信する。入力部１１２は、注文受付部１１６と確認受付部１１８を含む。注文受付部１１６は、顧客端末２００から各種取引注文を受信する。確認受付部１１８は、顧客端末２００から「確認情報」を受信する。顧客は、確認画面において、自らが要求する取引注文について取引資格を有していることを言明するために、後述する方法にて確認入力を行う。このとき、確認入力がなされた旨を示す確認情報が顧客端末２００から電子商取引装置１００に送信される。電子商取引装置１００は、確認情報の受信により、顧客自ら取引資格があることを確認したと知ることができる。入力部１１２は、このほかにも、取引画面に対する顧客のさまざまな入力に対応した各種コマンドを受信する。
【００１６】
データ保持部１４０：
データ保持部１４０は、顧客属性保持部１４２、確認属性保持部１４４、取引履歴保持部１４６および音声保持部１４８を含む。顧客属性保持部１４２は、顧客の属性を示す「顧客属性情報」を保持する。顧客属性とは、たとえば、年齢や性別などの身体に関する属性、世帯構成や居住地、趣味などの生活に関する属性、年収や職種などの社会的地位に関する属性等、顧客に特有の情報であればよい。また、顧客の保有株式や預金残高等の資産情報を顧客属性として利用してもよい。
【００１７】
確認属性保持部１４４は、取引注文の種類と「確認属性」を対応づけて保持する。取引注文の中には、その取引注文を実行する資格を顧客が有しているかを顧客に確認した上でなければ許可されないものもある。たとえば、Ａ社株式の売却を注文する顧客がＡ社社員である場合、この注文がインサイダー取引にあたらないか確認する必要がある。この場合、「Ａ社株式の売却注文」という取引注文の確認属性として「Ａ社社員」という顧客属性が設定される。すなわち、Ａ社社員である顧客からＡ社株式の売却が注文される場合、その取引注文を実行する資格を顧客が有しているかを顧客に確認した上でなければ、取引注文は実行してはならない。
【００１８】
別例として、信用取引口座を開設する条件の一つとして「投資経験１年以上」という条件が設定されているとする。ある程度の投資経験のある顧客でなければ、現物取引よりも複雑な信用取引を許可しないというルールにより、投資に不慣れな顧客を不慮の損害から保護するためである。この場合、「信用取引口座開設」という取引注文の確認属性として、「総合証券口座開設から１年未満」という顧客属性が設定される。すなわち、電子商取引装置１００を運用する証券会社に総合証券口座を開設してから１年未満の顧客により、信用取引口座の開設を要求される場合、その顧客が実際に１年以上の投資経験を有しているかを確認した上でなければ、信用取引口座を開設してはならないことになる。
【００１９】
取引履歴保持部１４６は、業務システム２０４に発注された取引内容を示す「取引履歴情報」を保持する。音声保持部１４８は、顧客ごとの音声データを保持する。総合口座開設時に、顧客に所定文章を復唱させ、その音声データを顧客ごとに保持すればよい。
【００２０】
データ処理部１３０：
データ処理部１３０は、確認属性判定部１３２、音声認証部１３４および注文実行部１３６を含む。確認属性判定部１３２は、注文受付部１１６からなんらかの取引注文が受け付けられたとき、その取引注文についての確認属性を確認属性保持部１４４を参照して特定する。そして、顧客属性情報を参照し、取引注文元の顧客の属性が確認属性に該当するかを判定する。たとえば、Ａ社株式の売却注文が受け付けられた場合、顧客がＡ社社員であるか否かを判定する。Ａ社社員でなければ、すなわち、確認属性に該当しなければ、注文実行部１３６は、業務システム２０４に取引注文の実行を指示する。また、注文実行部１３６は、取引履歴保持部１４６に取引内容を記録する。
【００２１】
Ａ社社員であるとき、すなわち、確認属性に該当するときには、確認表示部１２０は確認画面を表示させる。本実施例における確認の方法は２種類であり、一つは「簡易確認」、もう一つは「重要確認」である。確認属性判定部１３２は、確認属性該当時において、簡易確認で済ませるか、重要確認であるかを判定する。たとえば、Ａ社株式の売却を指示する顧客の属性がＡ社の一般社員であれば「簡易確認」、Ａ社部長以上であれば「重要確認」として判定する。簡易確認とするか重要確認とするかは、設計要件に応じて任意に設定されればよい。
【００２２】
簡易確認の場合、確認表示部１２０は、確認画面として、次の図３に示す簡易確認画面１５０を表示させる。重要確認の場合、確認表示部１２０は、確認画面として、その次の図４に示す重要確認画面１６０を表示させる。後述する方法にて、確認受付部１１８は、確認画面に対する顧客の意思表示を示す確認情報を受信する。確認情報が受信されたとき、注文実行部１３６は、業務システム２０４に取引注文の実行を指示する。また、注文実行部１３６は、取引履歴保持部１４６に取引内容を記録する。また、その確認情報を、取引注文が顧客の確認を得た上で実行された証拠として取引履歴情報に記録する。音声認証部１３４は、重要確認に際して、音声に基づく顧客の本人認証を実行するが、詳しくは後述する。
【００２３】
図３は、簡易確認画面１５０の画面図である。
ここでは、総合口座を開設してから１年を経過していない顧客から信用取引口座の開設を要求されたという状況にて説明する。確認属性判定部１３２は、注文主である顧客の属性が確認属性に該当すると判定し、かつ、簡易確認が必要であると判定する。このとき、確認表示部１２０は、顧客端末２００に簡易確認画面１５０を表示させる。説明領域１５２には、顧客に確認を求める事項として「弊社にて信用取引口座を開設するには、１年以上の投資経験が必要です。お客様は上記条件に該当致しますでしょうか？」という文章が表示される。顧客は、１年以上の投資経験があるときにはＹＥＳボタン１５４、ないときにはＮＯボタン１５６をクリックする。ＹＥＳボタン１５４がクリックされたときだけ、顧客端末２００は確認情報を電子商取引装置１００に送信する。確認受付部１１８がこの確認情報を受信すると、注文実行部１３６は取引注文を業務システム２０４に発行する。また、注文実行部１３６は、取引履歴情報に取引注文と確認情報が受信された旨を記録する。顧客端末２００は、顧客の秘密鍵により確認情報を暗号化して送信してもよい。電子商取引装置１００は顧客の公開鍵により確認情報を復号できれば、確認情報が真性に当の顧客から送信されたものであると証明できる。
【００２４】
図４は、重要確認画面１６０の画面図である。
ここでは、「名村證券」という会社の役員である顧客から、名村證券株の購入を要求されたという状況を想定する。確認属性判定部１３２は、注文主である顧客の属性が確認属性に該当すると判定し、かつ、重要確認が必要であると判定する。このとき、確認表示部１２０は、顧客端末２００に重要確認画面１６０を表示させる。説明領域１６２には、顧客に確認を求める事項として「お客様は、「名村證券株式会社の社員としての立場ゆえに、投資判断に影響を及ぼすような未公開の重要な情報を知るに至った上で、上記取引を行う者」に該当しませんでしょうか？」という文章が表示される。顧客は、該当しないとき、すなわち、インサイダー取引にあたらないときには、復唱領域１６４に示される「私は当該名村證券株取引が、いわゆるインサイダー取引に該当しないことを言明いたします。」という文章を口頭にて読み上げる。このときの音声データは、先述した音声入力手段により取得される。読み上げが完了すると、顧客は読上完了ボタン１６８をクリックする。読上完了ボタン１６８がクリックされると、確認情報として取得された音声データが電子商取引装置１００に送信される。確認受付部１１８がこの確認情報を受信すると、音声認証部１３４は、確認情報に含まれる音声データが顧客の音声データであるかを音声保持部１４８の音声データとの比較により判定する。このような音声による本人認証は、既知の音声認証技術を応用すればよい。注文実行部１３６は、音声認証が成功したことを条件として、取引注文を業務システム２０４に実行指示する。なお、キャンセルボタン１７０がクリックされるときには、確認情報が送信されることなく重要確認画面１６０は閉じられる。また、再試行ボタン１６６をクリックすることにより、復唱をやり直すことができる。
【００２５】
図５は、取引注文の発注処理過程を示すフローチャートである。
同図のフローチャートは、以上に示した発注処理の流れをまとめたものである。まず、注文受付部１１６が顧客端末２００から取引注文を受信すると（Ｓ１０）、確認属性判定部１３２は、その取引注文に関して顧客の属性が確認属性に該当するかを判定する（Ｓ１２）。確認属性に該当しなければ（Ｓ１２のＮ）、注文実行部１３６は業務システム２０４に取引注文の実行を指示する（Ｓ２８）。このとき、注文実行部１３６は取引履歴情報に実行された取引注文を後日の履歴管理のために記録する。
【００２６】
確認属性に該当するときには（Ｓ１２のＹ）、確認属性判定部１３２は、更に、重要確認が必要か判定する（Ｓ１４）。簡易確認で充分であれば（Ｓ１４のＮ）、確認表示部１２０は簡易確認画面１５０を表示させる（Ｓ１６）。ＹＥＳボタン１５４のクリックにより確認入力がなされたなら（Ｓ２０のＹ）、注文実行部１３６は業務システム２０４に取引注文の実行を指示する（Ｓ２６）。このとき、注文実行部１３６は取引履歴情報に実行された取引注文と確認情報を対応づけて記録する。確認情報と取引注文の対応付けにより、取引注文が顧客の意思表示に基づいて実行されたことを証明するためである。ＮＯボタン１５６のクリックにより確認入力がなされなければ（Ｓ２０のＮ）、注文は実行されない。
【００２７】
一方、重要確認が必要であれば（Ｓ１４のＹ）、確認表示部１２０は重要確認画面１６０を表示させる（Ｓ１８）。復唱領域１６４に示される文章が読み上げられ、音声データが確認情報として入力されると（Ｓ２２のＹ）、音声認証部１３４は音声認証を実行する（Ｓ２４）。音声により本人認証に成功すると（Ｓ２４のＹ）、注文実行部１３６は業務システム２０４に取引注文の実行を指示する（Ｓ２６）。このとき、注文実行部１３６は取引注文と確認情報を取引履歴情報に対応づけて記録する。音声データによる確認情報が受信されなかったり（Ｓ２２のＮ）、音声認証に失敗したときには（Ｓ２４のＮ）、注文は実行されない。
【００２８】
以上、電子商取引装置１００について実施例に基づいて説明した。
電子商取引装置１００によれば、取引に際して、顧客自らの意思確認が必要か否かを顧客属性により判定できる。このため、Ａ社とは関係のない顧客がＡ社株の取引注文を指示してきたときにも、常に、インサイダー取引にあたらないか確認するといった定型的で不必要な手続きの発生を抑制できる。また、顧客の確認がなされた旨を示す確認情報を取引注文と対応づけて履歴管理を行うことにより、正しい手続きにより取引注文が実行されている旨を証明しやすい構成となっている。更に、顧客の声による音声データを確認情報として保持することにより、いっそう証拠能力を高めることができる。
【００２９】
また、いったん、確認が取れたときには、以降の確認処理を省略・簡略化してもよい。たとえば、ある顧客Ａは、午前中に電子商取引装置１００にアクセスしてきて本人認証を受けたとする。そして、この顧客Ａが午後に再びアクセスしてきたときには、本人認証を省略してもよい。午前中にアクセスがあったとき、電子商取引装置１００は顧客ＡのユーザＩＤを一時的に記録しておき、午後にこの同じユーザＩＤからアクセスがあったときには本人認証を省略するとすれば、セキュリティレベルを過度に下げることなく顧客の利便性を高めることができる。
同様にして、ある顧客Ｂが株式Ｃの売買に関して、インサイダー取引に当たらない旨を表明したとする。この場合、以後、顧客Ｂが株式Ｃを新たに売買するときには、インサイダー取引に関する確認手続きを省略してもよい。あるいは、インサイダー取引に当たらない旨を表明してから、所定期間、たとえば、１〜２ヶ月程度を経過するまでは、顧客Ｂの株式Ｃの売買にあたってインサイダー取引に関する確認を省略してもよい。
【００３０】
書面による取引履歴管理ではなく、簡易確認画面１５０におけるボタンクリックや重要確認画面１６０における音声入力により、顧客は取引資格があることを自ら確認した旨を意思表示できる。このため、顧客および事業者双方の事務負担を抑制しつつ、取引の証跡管理を実現できる。なお、本実施例においては、音声認証部１３４により音声認証をするとして説明したが、本人認証は、顔認証、指紋認証、静脈認証等の各種生体認証により実現されてもよい。
【００３１】
以上、本発明を実施例をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００３２】
本実施例においては、電子商取引装置１００は単体の装置であるとして説明したが、電子商取引装置１００は、複数の装置による機能の集合として定義されてもよい。たとえば、電子商取引装置１００のユーザインタフェース処理部１１０の機能は顧客端末２００において実現され、データ処理部１３０やデータ保持部１４０の機能がサーバ装置にて実現されてもよい。
【図面の簡単な説明】
【００３３】
【図１】電子商取引システムのハードウェア構成図である。
【図２】電子商取引装置の機能ブロック図である。
【図３】簡易確認画面の画面図である。
【図４】重要確認画面の画面図である。
【図５】取引注文の発注処理過程を示すフローチャートである。
【符号の説明】
【００３４】
１００  電子商取引装置、  １１０  ユーザインタフェース処理部、  １１２  入力部、  １１４  表示部、  １１６  注文受付部、  １１８  確認受付部、  １２０  確認表示部、  １３０  データ処理部、  １３２  確認属性判定部、  １３４  音声認証部、  １３６  注文実行部、  １４０  データ保持部、  １４２  顧客属性保持部、  １４４  確認属性保持部、  １４６  取引履歴保持部、  １４８  音声保持部、  １５０  簡易確認画面、  １５２  説明領域、  １５４  ＹＥＳボタン、  １５６  ＮＯボタン、  １６０  重要確認画面、  １６２  説明領域、  １６４  復唱領域、  １６６  再試行ボタン、  １６８  読上完了ボタン、  １７０  キャンセルボタン、  ２００  顧客端末、  ２０２  インターネット、  ２０４  業務システム、  ２０６  電子商取引システム。
【図１】
2009080688.tif 000003
【図２】
2009080688.tif 000004
【図３】
2009080688.tif 000005
【図４】
2009080688.tif 000006
【図５】
2009080688.tif 000007