JP2017102934A - 本人によるワンタップ購入装置、方法およびシステム - Google Patents

Abstract

【課題】盗難を防止しつつ、購買者に対してより合理化したショッピングを提供する。【解決手段】製品コードスナップ写真をリアルタイムで電子購入取引通知に変換して詐欺を最小にする。スマートフォンは、製品梱包から製品識別子をスキャンし、サーバが製品識別子に関係付けられた製品データベースに製品購入提案のアクセスし、ユーザがその財布のクレジットカードに課金することを承認し、製品購入提案や他のクレジットカード提案が（リワードポイント等のために）ユーザのモバイルデバイスに提供される。ユーザが品物を購入した後、店の通路にいる間に、ユーザのスマートフォンが、購買者が製品を持って出ていけるように出口でスキャンするバーコード電子領収書を表示する。ビデオチャットは、カスタマーサービス係によって要求され、取引リスクスコアがビデオチャットの受け入れに基づいて下げられる。【選択図】図１

Description

本発明は、２０１１年３月２５日出願の米国仮出願第６１／４６７，８９０号と２０１１年３月２５日出願の米国仮出願第６１／４６７，９６９号の利益を請求する２０１２年３月２６日出願の米国出願第１３／４２９，６７０号の継続出願であり、その利益を請求し、その内容は、全ての目的に対してその全体を参照により結合する。

本特許文献の開示の一部は、著作権保護を受ける事項を含んでいる。著作権者は、それが特許商標庁に現れる場合、特許ファイルや記録による特許文献や特許開示の全ての者による複製に異議を唱えないものの、それ以外では全ての著作権を保持している。

本開示は、一般に、財務および費用／価格の決定データ処理に関し、特に、現実世界の小売店における電子支援ショッピングに関する。

小売店は現代の生活の要である。それらは、食品や薬などの生活必需品や、宝石や家電などの贅沢品も扱っている。これらの物理的な「現実世界の」店は、店の大部分を占める商品の陳列と棚と正面口や出口近くにあるレジエリアからなる、見慣れた周知のレイアウトを採用している。購買者は店に自由に入り、大抵はショッピングカートや携帯かごを手にして、商品陳列が購入を誘う売り場の品物を見て回る。

購買者取引では典型的に、購買者は店在庫の陳列から品物を選び、購入取引を始める精算場所でその品物を提出する。品物情報は典型的に、販売時点管理（ＰＯＳ）端末デバイスに入力されるか、その情報がバーコードスキャナで商品パッケージ上のバーコードをスキャンすることによって自動的に入力される。購買者は通常、（現金や小切手やクレジットカードやデビットカードベースの支払等の）複数の支払のオプションが与えられるカードベースの。支払いが行われて承認されると、販売時点管理端末はその取引を販売者コンピュータシステムに記録し、紙のレシートが発行されてその商取引が満足に終了したことを示す。

幾つかの店舗では、顧客が店を出るときに、警備員や店の担当者が紙のレシートと顧客のバッグの中の商品を二重チェックする。これにより、万引きや詐欺行為を防止できる。

商取引の迅速化、在庫の追跡および盗難の抑制は進歩してきた。機械的なキャッシュレジスタは、店の電子的な在庫データベースに統合されたＰＯＳ端末と電子レジスタに移行された。統一商品コード（ＵＰＣ）のバーコードは、包装においてほとんど普遍的で、安価なスキャナによるスキャンが可能となっている。無線周波数識別（ＲＦＩＤ）タグ及び／又は二次元バーコード（ＱＲコード（登録商標）（クイックレスポンスコード）や二次元マトリックスコードなど）は、更に製品識別を合理化するだろう。盗難防止装置（使い捨て盗難防止タグとそれらを感知する店の出口付近の盗難防止タワーや柱等）は広く普及している。これらの技術の全ては、店主には小売店の円滑で効率的な営業を与え、購買者にはより合理化された体験を与えることに貢献している。しかし、客の不満がないわけではない。全てのそれら新技術に拘らず、客は品物を購入するために他の客と一列に並んで待つ必要がある。

無人レジ技術は、幾つかの種類の店（スーパーマーケット、大規模小売店、日曜大工店等）には受け入れられた。しかしながら、多くの店は、無人レジ技術を採用することは顧客が一列になって待つことを防げないと感じている。最新の無人レジ装置は高価であり、それらは店の正面の貴重なスペースを占領し、一度に取り扱えるものが多くなるだけである。比較的少ない従業員が同時発生する多数の購買者取引を監視するので、多少の盗難も招く。

購買者にやさしいスマートフォンは、カルフォニア州クパチーノのアップル社から販売されているｉＰｈｏｎｅ(R)携帯電話によって普及され、購買者が品物を購入する店内ショッピング装置として提案されている。（カルフォニア州マウンテンビューの）グーグル社のアンドロイド^TMオペレーティングシステムに基づく電話、（ワシントン州レッドモンドの）マイクロソフト社のウィンドウズ（登録商標）モバイル(R)オペレーティングシステムに基づく電話、カナダのオンタリオのリサーチ・イン・モーション社のブラックベリー(R)スマートフォンなどの他のスマートフォンは、同様の機能を提供するモバイルデバイスである。

スマートフォンおよび他のモバイルデバイスのソフトウェアアプリケーションは、「アプリ」として知られ、バーコードを撮影し、関係付けられた番号を復号できるように開発されている。これらのバーコード読み取りアプリは、バーコードに関係付けられた製品を調べるために、ネットワークへの無線接続を通じてデータベースを待ち行列に入れることができる。

２０１０年４月１日に公開され、アップル社に譲渡された特許文献1は、買い物客がｉＰｈｏｎｅによって店内で品物をスキャンし、それらをショッピングリストに加え、電子的に支払いをすることができることを開示している。ユーザのショッピングリストは編集可能で、電話を通じて複数の品物を一回で購入できる。ユーザは「直ちに購入」ボタンを選択し、その品物の集配準備が整った場合の通知を受けることができる。

購買者にはより合理的な買い物体験を与え、店主には万引きからの保護を与える当業界の需要がある。

米国特許出願公開第２０１０／００８２４４７号公報

本出願は、一般に、店の購入および盗難防止システムにアプリケーションでネットワーク接続された、現実世界の小売店でスマートフォンにより支援されたショッピングに関する。ある場合には、ユーザは自身の携帯電話で品物をスキャンし、指やその他スタイラスの「ワンタップ」によってそれを購入し、電話で電子受領書を受け、ユーザがその品物を持って店を出られるように店の在庫と盗難防止システムが自動的に更新される。大きな購買については、リモート・カスタマーサービス係とのビデオチャットによるユーザ認証を採用することができ、ビデオチャットが受け入れられた及び／又は行われたか否かに基づいて、自動的に詐欺リスクスコアを変更する。更新された詐欺リスクスコアは、盗難防止又は管理システムに関連付けられてもよい。

本出願は、一般に、支払ネットワーク内でクレジットカード承認要求の遮断や、ユーザの電子財布で使用できる異なるカードのユーザへの提示にも関する。それらのカードの使用に対して競合する提案を示すために、異なるカードは自動オークションに参加することができる。異なる製品及び／又は同一若しくは競合する製品を有する競合する販売者が、ユーザが携帯電話に集中している間に宣伝されてもよい。

本発明のある実施例は、モバイルデバイス支援の本人によるショッピングについての認証方法に関する。本方法は、小売店での製品識別子の本人による撮影に基づいて潜在的な購入品の製品識別子をモバイルデバイスによって取得し、小売店で関係付けされたデータベースから上記潜在的な購入品の値段を決定し、潜在的な購入品を購買者の口座に課金する購買者からの同意を表示するように構成されたインターフェース要素をモバイルデバイスに表示し、潜在的な購入品の価格に基づいて第１のリスクスコアを算出する。本方法は更に、閾値と上記第１のリスクスコアを比較し、上記第１のリスクスコアの上記閾値との比較に基づいて、購買者とカスタマーサービス係とのビデオチャットセッションを開始するように構成されたインターフェース要素を含むメッセージを上記モバイルデバイスへ少なくとも一つのサーバから送信し、購買者によるメッセージ中のインターフェース要素の選択に基づいてビデオチャットセッションを開始し、第１のリスクスコアとビデオチャットセッションの開始に基づいて第２のリスクスコアを算出し、品物購入の承認に対する電子受領書をモバイルデバイスで受信する。

幾つかの実施例は、モバイルデバイス支援ショッピングシステムに関する。本システムはモバイルデバイスを有し、それ自身は、製品パッケージから製品識別子を撮影するように構成されたカメラと、製品識別子を使用して価格を調べ、インターフェース要素を含むメッセージを受信するように構成されたネットワークインターフェースと、製品識別子によって識別された製品を購入するための購買者からの同意を表示するように構成されたインターフェース要素を表示すると共に、購買者とカスタマーサービス係とのビデオチャットセッションを開始するように構成されたメッセージのインターフェース要素を表示するように構成された表示部とを有する。本システムは更に、コンピュータプログラムにおける命令を実行する少なくとも一つのサーバコンピュータを有し、上記コンピュータプログラム命令は価格に基づいて第１のリスクスコアを算出するためのプログラムコードと、購買者とカスタマーサービス係とのビデオチャットセッションの開始と価格に基づいて第２のリスクスコアを算出するためのプログラムコードと、品物購入の承認に対して電子受領書を送信するためのプログラムコードを含む。

幾つかの実施例は、小売店におけるモバイルデバイスを使用した品物を自動生産する方法に関する。本方法は、小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影に基づいて潜在的な購入品の製品識別子を取得し、小売店に関連付けられた、潜在的な購入品の販売者を識別し、販売者に基づいて潜在的な購入品の価格を決定し、品物を購入する購買者からの同意をモバイルデバイスによって取得し、購買者の同意に基づいて潜在的な購入品の識別された販売者との購入取引をモバイルデバイスを使用して開始し、購入取引に基づく販売者検証可能コードを有する電子受領書をモバイルデバイスで受信し、モバイルデバイスが小売店でリーダに近接している間に検証可能コードをモバイルデバイスから生成し、検証可能コードが有効である旨の表示を受信し、これにより、購買者が品物を持って小売店から出ることを許可する。

幾つかの実施例は、小売店においてモバイルデバイスを使用して品物を自動清算する方法に関する。本方法は、小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影に基づいて潜在的な購入品の製品識別子を取得し、潜在的な購入品の価格を決定し、購買者からの口座に課金する購買者からの同意を受信し、品物の購入に対して購買者の口座に課金し、口座の課金が成功した旨の表示を受信し、受信した表示に基づいて検証可能コードを有する電子受領書を生成し、購買者のモバイルデバイスに電子受領書を送信し、モバイルデバイスで検証可能コードを読み取り、モバイルデバイスによって読み取られた検証可能コードが有効であることを確認し、購買者が品物を持って小売店から出ることを許可するために検証可能コードが有効である旨の表示を送信する。

幾つかの実施例は、競合する購入口座の提案をモバイルデバイス支援ショッピング購入取引中に提供する方法に関する。本方法は、購買者の第１の支払口座から販売者への支払いに対するアクワイアラからの承認要求を受信し、承認要求を受信することに基づいて購買者に関連付けられた第２の支払口座を使用する提案を決定し、購買者に決定された提案を送信し、購買者から提案の選択を受信し、購買者の第２の支払口座からの支払いを要求するために承認要求を修正し、第２の支払口座に関連付けられたイシュアに修正された承認要求を送信する。

幾つかの実施例は、競合する製品の提案をモバイルデバイス支援ショッピング購入取引中に示す方法に関する。本方法は、購買者の支払口座から第１の販売者への支払いについてアクワイアラから第１の承認要求を受信し、購入される品物の製品識別子を受信し、第１の承認要求を受信することと受信した製品識別子または第１の販売者に基づいて、競合品または第２の販売者についての提案を決定し、提案を購買者に送信し、購買者からの提案の選択を受信し、受信した選択に基づいて第１の承認要求を取り消し、購買者の支払口座から提案の第２の販売者への支払いに対する第２の承認要求を生成し、第２の承認要求を支払口座に関係付けられたイシュアに送信する。

幾つかの実施例は、モバイルデバイス支援ショッピングのための小売店における盗難防止システムを更新する方法に関する。本方法は、小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影に基づいて潜在的な購入品の製品識別子を取得し、潜在的な購入品の価格を決定し、購買者の口座に課金をする購買者からの同意を受信し、品物購入に対して口座に課金し、口座の課金が成功した旨の表示を受信し、品物が小売店から自由に出られる旨の表示を盗難防止システムに送信する。

他の実施例は、機械可読な有形の記憶媒体、および上述の方法の命令を保存又は使用するコンピュータシステムに関する。

本明細書の残りの部分と添付図面を参照することによって、ここに開示および示唆される実施例の性質及び利点の更なる理解が可能になるであろう。

図面は本発明における異なる実施例を示している。これらの図面は、実施例の特定の例示であり、実施例を限定するものとして解釈すべきではなく、例示的な形状や手順を示しているにすぎない。

ある実施例による本人によるワンタップ購入の例示的側面を示すブロック図である。 ある実施例による製品識別子の撮影を示す図である。 図２（ａ）の実施例による製品情報と宣伝情報の表示を示す図である。 図２（ａ）の実施例による「直ちに購入」の様態を示す図である。 図２（ａ）の実施例による購入確認を示す図である。 ある実施例による電子受領書を示す図である。 ある実施例による店盗難防止システムを無力化するための電子受領書の使用を示す図である。 ある実施例による製品識別子の撮影を示す図である。 ある実施例による認証画面を示す図である。 図３（ｂ）の変更された認証画面を示す図である。 ある実施例によるユーザとカスタマーサービス係とのビデオチャットセッションを開始するように構成されたインターフェース要素を含むメッセージを示す図である。 ある実施例によるスマートフォンにおけるカスタマーサービス係とのビデオチャットセッションの開始を示す図である。 ある実施例によるモバイルデバイス上のテキストによる説明要求を示す図である。 ある実施例によるモバイルデバイス上のプライバシー選択画面を示す図である。 ある実施例によるモバイルデバイスに表示される販売者検証可能コードを有する電子受領書を示す図である。 ある実施例によるモバイル機器購入取引を行う例示的側面を示す論理フロー図である。 ある実施例によるモバイル機器購入取引の購入オプションを選択する例示的側面を示す論理フロー図である。 ある実施例による生のカードベース取引データをもたらす、カードベースの取引を行う例示的手続を示すデータフロー図である。 図６（ａ）のデータフロー図の続きを示す図である。 図６（ａ）による生のカードベース取引データをもたらす、カードベースの取引を行う例示的手続を示すデータフロー図である。 ある実施例による生のカードベース取引データの生成をもたらす、カードベースの取引を行う例示的側面を示すデータフロー図である。 図７（ａ）の論理フロー図の続きである。 ある実施例による生のカードベース取引データの生成をもたらす、カードベースの取引を行う例示的側面を示すデータフロー図である。 図７（ｃ）の論理フローの続きを示す図である。 ある実施例による制御部の実施例を示すブロック図である。 ある実施例によるプロセスのフローチャートである。 ある実施例によるプロセスのフローチャートである。 ある実施例によるプロセスのフローチャートである。 ある実施例によるプロセスのフローチャートである。 ある実施例によるプロセスのフローチャートである。 ある実施例によるプロセスのフローチャートである。

小売店におけるモバイルデバイス支援ショッピングは、購入を完了するために、単に購買者に品物をスキャンして指やスタイラスでタップすることを要求するアプリを使用することができる。そのようなアプリ（以下、本人によるワンタップ（ＩＰＯＴ）ソリューションとも言う）は、小売店での購入において取引上の不便を最小化し、これにより、より販売を促進できる。

しかし、そのようなソリューションは、品物を持って店を出るために購買者がそれらの品をレジ係によるスキャニングのために提示する必要がないので、より多くの盗難が生じるかもしれないという点で店主に危険を招く。しかし、電子受領書（進歩した認証）および購買者のスマートフォンと店とのネットワーク構築は、このリスクを低減できる。本願において、当業者が明確に理解できる技術的解決を構成する方法、システムおよび装置について実施例が開示されている。

ユーザは、製品および価格識別子、買い物電子財布、及び品物を持って店を出るための自動近接トークンとして機能することができるパーソナルモバイルデバイスに、アプリをダウンロードすることができる。より高価な品物については、カスタマーサービス係が、購買者を目で確認して疑わしい可能性のある取引のリスクを下げるために、購買者とのビデオチャットを要求することができる。バックグラウンドサーバは、ユーザが最終的に最良の取引を決めることができるように、クレジットカード取引中に競合する提案をユーザに表示できる。

実施例の技術的利点は多い。小売店の客のスマートフォン（客が自身の品物をスキャンし購入するのを可能にする）にアプリを入れることは、店内にレジやＰＯＳ装置その他の資本設備を設ける必要性を下げる。それは、代わりに、現存する装置の消耗を削減し、常時必要とされる装置を少なくするかもしれない。また、それは人がタッチするマン・マシン・インターフェースの数を減らし、買い物客や従業員の表面媒介性の病気の感染を低くする。資本設備削減に加えて、レジ係、世話係、価格チェック、その他の従業員を少なくすることができる。

購買者は、馴れて快適な自身の携帯電話を使用する。精算およびその他のインタラクション時間は、彼らのスマートフォンの速度に依存するので、より速い携帯電話を所有する購買者はわずかに早くサービスを受けることができる。多くの購買者は二年ごとに携帯電話を更新するので、多くの場合に精算速度も数年毎に早くなるであろう。

機械可読な電子受領書を販売者検証可能コード（バーコード等）と結び付けることは、退店を自動化できる。購買者が店を出るときに購買者の紙のレシートをチェックする従業員の代わりに、バーコードはシステムを自動化する。ユーザの電話が店の出口のカメラの近くを通るとき、リーダがバーコードを読み取り、それが有効であると判断し、それを店の在庫の品物と照合し、ユーザのバッグの中の盗難防止タグの検知によって警報が作動しないように自動的に盗難防止警告システムを「安全」とする。スマートフォンと支払承認インフラと店の在庫と盗難防止システムの間のインタラクションは、盗難を防ぎながら資本設備やその他の店で必要とされる資源を削減できる。

図１は本人によるワンタップ購入の例示的側面を示すブロック図である。ある実施例において、ユーザ（例えば１０１）は製品、サービスやその他の提案（製品）を本人が直接見て購入したいと思っている。ユーザは、製品を購入するために、ビルの店頭や倉庫やショー会場や屋外マーケットや材木置場やその他小売店の入口１０２から入る。ユーザは通路１０３で入手可能な製品を自分が見て、製品についてもっとよく知りたいと思うかもしれない。ユーザは、クライアントデバイス１０４ａを使用して製品１０５をスキャンする。

例えば、ユーザが、製品と関係付けられた製品ＩＤ（バーコード、ＲＥＩＤ、ＱＲコード等）の情報を撮影してもよい。ユーザが、その製品と関係付けられた製品ＩＤの画像やビデオやライブストリームなどを得てもよい。クライアントデバイス１０４ａは、得られた情報をサーバに提供する。クライアントデバイスは、製品に関係付けられた製品ＩＤについての撮影した情報を含む（セキュア）ハイパーテキスト転送プロトコル（ＨＴＴＰ（Ｓ））のＰＯＳＴ／ＧＥＴメッセージや電子メールメッセージやショートメッセージサービス（ＳＭＳ）、ＨＴＴＰ／リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）のビデオストリームなどをサーバに送ってもよい。

ある実施例では、サーバは、ユーザが知りたいと思う製品を識別するために製品に関連付けられた製品ＩＤに関する撮影情報を使用してもよい。例えば、サーバはクライアントデバイスによって提供されたメッセージを構文解析し、その構文解析に基づいて製品ＩＤ情報を抽出してもよい。サーバは、データベースにアクセスし、クライアントデバイスからのメッセージから抽出された製品ＩＤ情報に基づいて、ユーザに提供される製品提案を検索してもよい。例えば、サーバは、ユーザに提供する製品提案のリレーショナルデータベースにクエリーを行う構造化問い合わせ言語（ＳＱＬ）命令を発行するために、パイパーテキストプロセッサ（ＰＨＰ）スクリプトを利用してもよい。データベースが、ユーザに提供できる様々な販売者、販売者の位置、提案、割引、クーポン、広告などに関する情報を保存していてもよい。ある実施例では、サーバは、ユーザに提供する製品提案のためにデータベースにクエリーする製品ＩＤ情報と同様に、例えば、グローバル・ポジション・システム（ＧＰＳ）の位置データを使用してクライアントデバイスの位置を利用してもよい。

ある実施例では、サーバはデータベースから得られた結果をクライアントデバイス１０４ｂに提供してもよい。例えば、クライアントデバイスはサーバと通信することができるアプリケーションモジュール（アプリ）を実行してもよい。クライアントデバイスは、そのアプリを介してサーバから得られた結果をユーザに表示してもよい。

ある実施例では、一つの動作（例えば、タップ、モバイルデバイスのタッチスクリーンのスワイプ、キーボードのキーの押下、マウスのワンクリック）を行うことよって、アプリがその場所でその製品の購入についてのオプションをユーザに提供してもよい。

ある実施例では、そのアプリがユーザに様々な代替的なオプションを提供してもよい。例えば、アプリは、ユーザがその製品及び／又は類似の製品を得ることができる代わりの販売者、その製品に相当し得る代わりの製品、販売者間の競争価格情報、割引、クーポン、及び／又はその他のユーザへの提案などをユーザに提供してもよい。ある実施例では、そのアプリが、ユーザが当該他の販売者でその製品を購入すればユーザが得られるリワードポイントを表示してもよい。ある実施例では、他の販売者がそのリワードポイント提供者とより良い関係を有しているので、ユーザがその製品を当該他の販売者で購入すれば、購入取引の支払いがより少ないリワードポイントの使用で済むかもしれないことを、そのアプリが表示してもよい。ある実施例では、購入取引の支払いをするために特定の（又は代わりの）カードを使うならば、ユーザはより多くのリワードポイントを得られるかもしれないことをそのアプリは表示してもよい。ある実施例では、ユーザが代わりの販売者で及び／又は代わりのカードを使用してそのカードを購入するならば、大量のキャッシュバックを得られるかもしれないことをそのアプリが表示してもよい。様々な実施例において、ここで記載されたものを含むおよびそれと同様のユーザへの提案が、様々なエンティティ及び／又はシステム要素（販売者や支払ネットワークやカードイシュアやアクワイアラなどを含んでもいいがそれらに限定されない）からもたらされるようにしてもよい。

ある実施例では、ユーザデバイス上で一つの動作を行うことによって（例えば、ユーザデバイスのタッチスクリーンの一回のタップ）、ユーザ１０１がその場所で現在の販売者及び／又は他の販売者から製品を購入してもよい。そのような実施例では、サーバが、クライアントデバイス及び／又はユーザに関係付けられたカード（例えば、クレジットカード、デビットカード、プリペイドカード等）を使用して、カードベースの購入取引を開始してもよい。例えば、アプリが、その購入取引に利用する、ユーザの仮想電子財布（ｅ財布）からユーザにカードを選ばせてもよい。

ある実施例では、販売者、カードイシュア、アクワイアラ、支払ネットワーク、及び／又は同様のエンティティ及び／又は要素が取引費用の対価によりユーザの支払いが処理される方法を切り替えることについて、サーバがクレジットカード支払ネットワークを形成してもよい。

ある実施例では、サーバがカードベースの購入取引を開始して、ユーザのために購入確認受領書を生成してもよい。サーバは、クライアントデバイス１０８ｂに購入確認受領書を提供する。ある実施例において、ユーザがアプリを介して製品を購入した後直ちに店を出ることを望むかもしれない。

そのような実施例では、ユーザは店の出口で製品購入証拠を提供するように要求されるかもしれない。ユーザは、製品購入の証拠を提供するために、クライアントデバイス上でアプリを介してサーバから取得した購入確認受領書を利用してもよい１０８ａ。その受領書は、購入識別子１０８ｃを含む。購入識別子１０８ｃはバーコードを含むが、他の購入識別子はＱＲコードや受領書の画像や購入行為の動画等を含んでもよい。ユーザは、店の出口でそのような購入確認書を証拠として利用してもよい。従って、ある実施例では、ユーザが店で精算待ちの列を完全に飛ばしてショッピング体験の効率性を得てもよい。

図２（ａ）−２（ｄ）は、製品識別子の撮影と購入を示している。ある実施例では、サーバが様々な要素を介して製品についての製品ＩＤ情報を購買者フレンドリーな製品提供情報に変換し、ワンタップ製品購入を可能にしてもよい。例えば、サーバは、モバイルデバイス２０１でスキャンされた製品識別子２０５を介して製品２１０についての情報２１５を得る。サーバは、この製品識別子情報を詳細な製品情報２２０（価格や製品説明等）やクーポンやプロモーション２２５や広告等に変換してもよい。サーバは、その製品及び／又は関連及び／又は類似製品についての価格情報２３０を提供してもよく、その場所で及び／又は競合販売者で製品を購入するためのオプションをユーザに提供してもよい。ある実施例では、ユーザがいざというときに店員やスキャナに購入の証拠を提示できるように、システムがユーザのために購入の証拠（例えば、そのような情報を見るためのボタン２３５を介して）を提供してもよい。

モバイルデバイス２０１は、ユーザによって個人で所有されてもよいし、店によって客に一時的に支給されてもよいし、または別の方法で購買者に利用可能にされてもよい。デバイスは、（ｉＰｈｏｎｅやアンドロイドベースの携帯電話などの）スマートフォンであってもよい。

図２（ｅ）は、自動的に店の盗難防止システムを無力化する電子受領書を示す。裏面を向いているカメラ２５３とネットワークインターフェース２５４を有するモバイルデバイス２０１は表示部２５５を有する。表示部は、確認バーコード２５１と共に電子受領書２５２を表示する。確認バーコード２５１はその受領書に対応するコードを保有する。また、デジタル証明書２５６はその受領書に対応する。電子受領書は製品識別子、店、および購入取引に関係付けられる。

図２（ｆ）は、統合された盗難防止システム／デバイスを示す。スキャナリーダ２６０はモバイルデバイス２０１の表示部２５５上のバーコード２５１を光学的に読み取る。そのバーコードの数値コードは、残りの盗難防止システムに接続されたサーバ２６５にカメラ２６０から送信される。サーバ２６５は、一致があるかどうかを確認するために、その数値コードでデータベース２６６に問い合わせする。

ある実施例においては、無線信号（例えば、Ｗｉ−ＦｉやＢｌｕｅｔｏｏｔｈ（登録商標）仕様に対応するもの）をモバイルデバイスから送信することができ、その無線信号は検証可能コードを含む。その無線信号は、適切なリーダによって読み取られる。

データベース２６６内に一致があれば、店を出ようとしている盗難防止タグを有する製品に対して盗難防止システムを無力化するように通知される。例えば、その製品に対応する入力に対して、タイムスタンプがデータベースに保存される。盗難防止タワー２６１は品物２１０の盗難防止タグ２５７を検出し、信号がインターフェース２６４を通じてサーバ２６５へ送られる。サーバ２６５は、一致するタグを有する製品についてデータベース２６６にクエリーする。

ある名目上の状況では、その製品は、データベース２６６において、ちょうど発見されたバーコードの数値コードと同一の入力に発見される。一致があることに基づいて、サーバは品物が自由に小売店を出られることを表示する。その表示に基づいて、サイレン音２６３及びアラーム光２６２が無力化され、製品２１０を持つ客は問題なく店を出ることができる。

バーコードに対する一致がデータベース２６６なければ、そのバーコードはおそらく無効である。スキャナの前でモバイルデバイスを保持するユーザに、他のバーコードをスキャンするように要求してもよい。

盗難防止柱２６１によって検出された盗難防止タグ２５７に対する一致がデータベース２６６になければ、アラーム２６２及び２６３が鳴り響くか、店を出ようとする買い物客に注目を集めるように作動する。現在の盗難防止システムの多くは盗難防止タグが検出されるだけで作動してしまうので、一致がある場合にサーバ２６５が盗難防止システムを「無力化する」と言える。

（在庫システムの一部でもよい）データベース２６６は、盗難防止タグの盗難防止デバイスによる検出に基づいて更新されてもよい。購買者が品物をスキャンし、店内で自身のモバイルデバイス上で購入した後、データベースは、その品物に対応するデータベース入力において「販売済だが未だ店内」マーカーを置いてもよい。購買者が盗難防止柱を通って退店して当該品物の盗難防止タグが検出された後で、データベースはデータベース入力に「販売済で退店済」マーカーを置いてもよい。品物が代替可能であり個別に（例えば、シリアルナンバーによって）追跡されない代替的な実施例において、「販売済だが未だ店内」および「販売済で退店済」の品物の数を反映するようにデータベースの量を更新することができる。

「販売済だが未だ店内」と「販売済で退店済」の区別の技術的利点は、品物をより正確に追跡できることである。品物がなくなれば、店は、品物が購入されたのか単に店内に置き忘れられたのかをより正確にまとめることができる。更に、品物が購入された時のタイムスタンプを当該製品が退店する時間と比較することができ、客が購入とともに退店する前に店を物色した時間に関する指標を生成する。店内で異なる時間で購入された異なる商品のタイムスタンプを比較すれば、顧客が最初に店に入ってきて購入するもの（おそらく、購入した最初の品物）と、続いて目についたものや衝動買いしたものとに指標を与えることができる。

図３（ａ）−３（ｄ）は、実施例によるスマートフォン上の様々なインターフェースを示している。ある実施例では、アプリが製品識別子（例えば、バーコード、ＱＲコード）を認識するように構成されてもよい。ある実施例では、ユーザはアプリの機能を有効にするためにアプリにサインインするように要求されてもよい。一旦アプリが有効になれば、スマートフォンのカメラがユーザに本人によるワンタップ購入をする機能を提供してもよい。例えば、クライアントデバイスが、アプリが画像３０３、ビデオデータ、ストリーミングライブ映像などを取得できるカメラを有してもよい。アプリは、入来データを解析し、クエリインターフェース３０２を通じて製品識別子３０４の検索３０１を行うように構成されてもよい。ある実施例では、アプリは、ユーザが製品識別子の認証や解釈を容易にするために、クロスヘアやターゲットボックス等の位置合わせ参照マーカー３０５を使用して製品識別子を位置合わせできるように、位置合わせ参照マーカー３０５を重ねてもよい。ある実施例では、製品識別子を撮影する前に入手可能な商取引を正確にユーザが学べるように、ユーザが製品識別モードと製品提案インターフェース表示画面を切り替えることができるようにするために、アプリがインターフェース要素３０６を含んでもよい。ある実施例では、ユーザがどの製品識別子を撮影したいかをより上手に決定できるように、アプリがユーザに前の製品識別子の撮影を、例えば、ソフト「履歴」ボタン３０７を通じて、を見せてもよい。幾つかの実施例では、ユーザは製品購入を取り消したいと思うかもしれない。アプリは、製品識別子認識手続を取り消しユーザが利用していた前回のインターフェース画面に戻るように、ユーザインターフェース要素３０８を提供してもよい。ある実施例では、製品、ユーザ設定、販売者、提案等についての情報をリスト形式で、ユーザが購入オプションをよりよく理解できるように、例えば、ソフト「リスト」ボタン３０９を通じて、ユーザに提供されてもよい。様々な他の機能が、例えば、「もっと」ソフトボタン３１０を通じて、アプリに提供されてもよい。

ある実施例では、ユーザのクライアントデバイスで実行するアプリが、ユーザ対して様々な機能を提供するアプリインターフェースを含んでもよい。ある実施例では、アプリがユーザの位置（例えば、販売店３１１（図３（ｃ）を参照）の名前、地理的な位置／座標、販売店内の通路についての情報等）の表示を含んでもよい。アプリは、製品購入に対する支払額３１２の表示を提供してもよい。ある実施例では、アプリは、製品購入額を支払うための様々なオプションをユーザに提供してもよい。例えば、アプリは、ユーザがいる販売店を決定し、ユーザを販売者のウェブサイトに導くために、ＧＰＳ座標を利用してもよい。

図３（ｃ）における承認インターフェースは、デフォルト支払口座（Ｖｉｓａ）で支払取引を開始するために、ユーザからワンタップのみを求める。ワンタップ（若しくはスライド、プッシュ、又はその他の選択）は、ユーザが支払口座を通じて品物を効率的に購入し、次の品物へ進むか店を出るのを可能にする。

従来技術においては、購買者は複数の品物を店から全て一度に購入することを期待されていた。クレジットカードや他の金銭取引の一つのみであった。ある実施例では、各品物は個別に店内で購入することができ、それは複数のクレジットカード取引をもたらす。これは取引手数料について割高になるかもしれないが、店と客に、利便性、信用力および店が得る購入注文の追加のデータに関して価値がある。

ある実施例では、システムは、取引処理を促進するためにアプリケーション・プログラミング・インターフェース（ＡＰＩ）を共同販売者に直接提供してもよい。ある実施例では、販売者ブランドのアプリケーションが、ユーザを販売者の取引システムに直接接続できる前述の機能をもつように開発される。例えば、ユーザは様々なカードプロバイダ（例えば３１３）からの幾つかのカード（例えば、クレジットカード、デビットカード、プリペイドカード）から選択してもよい。ある実施例では、アプリはユーザに、口座セクション３１４のユーザの銀行口座（例えば、当座、普通、マネー・マーケット、現在の口座）に含まれる資金を使用して購入額を支払うオプションを提供してもよい。ある実施例では、ユーザは、アプリを介して購入取引に利用するカードや銀行口座等のデフォルトオプションを設定したかもしれない。ある実施例では、そのようなデフォルトオプションの設定により、ユーザは一回のクリック、タップ、スワイプ、及び／又は他の補助ユーザ入力操作を介して購入取引を開始することができる。そのようなインターフェースは、インターフェース要素３１５によって有効にすることができる。ある実施例では、ユーザがそのようなオプションを利用する場合に、購入取引を開始するユーザのデフォルト設定をアプリが利用するようにしてもよい。ある実施例では、アプリは、購入取引（例えば、他の口座セクション３１６）の支払いを行うために、ユーザに他の口座（例えば、グーグル^TMチェックアウト、ペイパル^TM口座）を利用させてもよい。ある実施例では、アプリは、購入取引（インターフェースのセクション３１７、３１８など）に対して支払いを行うために、ユーザにリワードポイント、エアラインマイル、ホテルポイント、電子クーポン、印刷クーポン等を、例えば、製品識別子のような印刷されたクーポンを撮影することで、利用させてもよい。ある実施例では、アプリは、インターフェース要素３１９を通じて購入取引を開始する前に明確な承認を与えるオプションを提供してもよい。インターフェース要素３１９を押すことによって、購買者は適切な製品を購入する同意を示す。ある実施例では、ユーザは購入取引を開始するオプションを選択した後に、アプリは、進捗インジケータ３２０等で、取引の進捗の表示を提供してもよい。ある実施例では、アプリを介して（例えば、ボタン３２１を通じて）、アプリは、ユーザの以前の購入履歴情報をユーザに提供してもよい。ある実施例では、アプリが、ユーザに購入情報を他のユーザと（例えば、電子メール、ＳＭＳ、フェイスブック(R)のウォール投稿、ツイッター^TMのツイート等を介して）共有するオプションを（例えば、インターフェース要素３２２を通じて）提供してもよい。ある実施例では、アプリがクライアントデバイスで撮影された（例えば、店の出口でカスタマーサービス係に製品情報を見せるために）製品ＩＤ情報を表示するオプション（例えば、表示されたＵＰＣバーコード３２４等）をユーザに提供してもよい。ある実施例では、ユーザ、アプリ、クライアントデバイス、及び／又はシステムは、処理エラーに直面するかもしれないし、更なる確認を必要とするかもしれない。その場合、購入取引手続における困難性を解決するために、ユーザがカスタマーサービス係と（例えば、確認チャットボタン３２３を介して）チャットできるようにしてもよい。

ある実施例では、「確認チャット」機能は詐欺防止に利用されてもよい。例えば、サーバが普通でない及び／又は疑わしい取引を検出するかもしれない。取引は、算出された付与数値入力パラメータ（例えば、潜在的な購入品の価格）である関連リスクスコアを有してもよい。もし、そのリスクスコアが閾値より高い（又は低い）ならば、確認チャットビデオ会議が続けて要求されてもよい。

「リスクスコア」は、事象発生の数的確率も含んでもよい。例えば、０．１９１のリスクスコアは、潜在的取引が詐欺である確率が０．１９１であることを表示してもよい。リスクスコアは、最も発生しやすい事象の順序定量も含んでもよい。例えば、「Ａ」のリスクスコアは、「Ａ」は「Ｂ」よりも発生しやすく、「Ｂ」は「Ｃ」よりも発生しやすい集合｛Ａ，Ｂ，Ｃ｝から選択されてもよい。リスクスコアは、リスクスコア付け手段や当業界で既知のものを含んでもよい。

「閾値」は、その閾値以上および以下の値を表す基数または序数を含んでもよい。例えば、０．１９０の閾値は、リスクが大きすぎるために取引が中止されるべきである所定の確率を表示してもよい。

「ビデオチャットセッション」は、表示されるために、一つのデバイスの少なくとも一つのカメラからの画像が表示のために通信路の相手側に送られる、双方向の相互ライブ通信ストリームを含んでもよい。ビデオチャットセッションは、ライブ通信（双方向に送信可能な音声やテキストメッセージ）でなく一方向のみに送信されるビデオを含んでもよい。

図３Ｄは、ユーザがインターフェース要素３５０を押すことでビデオチャットセッションを開始でき又は取消ボタン３２９を押すことで断ることができるインターフェースを示している。待機するカスタマーサービス係のライブストリームビデオ３２８ｂがウィンドウ３２８ｂに表示されている。ビデオチャットがボタン３２９を押すことで断られたら、ユーザは購入取引を完了するためにその店の従業員（例えば、レジ係）に購入物を持っていく必要があるだろう。もし受け入れられれば、ビデオチャットセッションは、コールセンターの遠方のカスタマーサービス従業員に、ユーザが自動化された「ボット」でないことを簡易に確認させることができる。リアルタイム相互ビデオチャットは、ユーザが自動化されたボットでないことを確認する極めて迅速かつ効果的な手段となる。更に、カスタマーサービス係は、ユーザに質問して購入取引本人の真正を確認することができる。様々な実施例において、ユーザとカスタマーサービス係とのビデオチャットセッションを開始するために、サーバは電子メールメッセージ、テキスト（ＳＭＳ）メッセージ、フェイスブック(R)メッセージ、ツイッター^TMツイート、テキストチャット、ボイスチャット、ビデオチャット（例えば、アップル社のＦａｃｅＴｉｍｅ）などをメッセージとしてインターフェース要素で送信してもよい。

ユーザのライブ映像３２８ａは、係員が見る姿をユーザが確認することができるようにモバイルデバイスの表示部に表示されてもよい。ビデオチャットセッション３２６では、ウィンドウ３２８ｂに表示されるカスタマーサービス係が、ユーザの映像を使用してユーザの真正を人的に判断してもよい。ある実施例では、ユーザ（例えば、３２８ａ）の身元を判断するために、サーバは顏認証や生体認証及び／又は同様の認証（例えば、パターン分類手法を使用して）を利用してもよい。ある実施例では、ユーザの自動認識を容易にするためにユーザが映像の焦点を合わせるように、アプリが、参照マーカー３２７（例えば、クロスヘアやターゲットボックス）を提供してもよい。

単にビデオチャットセッションを開くことが、取引の約束において詐欺リスクスコア低下するのに十分であること示してもよい。「ビデオチャット」ボタン３５０が押されると、メッセージがモバイルデバイスから携帯電話局に送信され、そのメッセージはインターネットを介して販売者のウェブサーバに転送される。ウェブサーバは、ビデオ会議サーバとモバイルデバイスとの間の新しい通信ポートを開き、カスタマーサービス係とユーザのライブ映像が相互に交換されるようにする。メッセージの一部は、ビデオチャットセッションが受け入れたこと及びその一部が詐欺判断エンジンに転送されたことを示す。ビデオチャットが電話で受話者によって受け入れられたという事実は、第２の詐欺リスクスコアを算出するように、最初の詐欺スコアを調整するのに利用され得る。

カスタマーサービス係はその会を実際に行う暇がないかもしれないので、第２の詐欺リスクスコアが取引を進めるかどうかを評価することに使用され得る。最初の詐欺リスクスコアがぎりぎり合格であるならば、ビデオチャットセッションが受け入れられたという事実を用いて再計算されたリスクスコアが、販売者に対する取引リスクは今や許容範囲内にあることを表示してもよい。そうであれば、購入は完了されてもよく、その所有者が当該製品を持って店を出ることができるように、その取引の電子受領書が自動でモバイルデバイスに送られる。

ある実施例では、真正の購買者が上記取引を開始しなかったかもしれない。そのような実施例では、ユーザは取消ボタン３２９を使用してその質問を取り消してもよい。サーバは、その時に当該取引を消去及び／又はユーザの代わりに最初の詐欺調査手続を開始してもよい。

ある実施例では、ユーザは、図示されたような承認インターフェースにおいて選択３１５ｂ（図３（ｂ）を参照）を介し、一回の匿名クレジットカード番号を用いて取引を実行する選択をしてもよい。そのような実施例では、ユーザの個人識別情報が販売者及び／又はその他のエンティティに提供されないように、アプリがユーザプロフィール設定を自動で設定してもよい。ある実施例では、ユーザが、一回の匿名機能を可能にするために、ユーザ名およびパスワードを入力することを要求されるようにしてもよい。

モバイルデバイスのアプリは、製品識別子をスキャンする又は撮影すると、人間の介入なく自動的に承認インターフェースが開始されるように構成されてもよい。

ある実施例では、サーバがユーザの真正を確認するために、テキストによる説明要求手続３３０を利用してもよい（図３（ｆ）を参照）。例えば、サーバはテキストチャット、ＳＭＳメッセージ、電子メール、フェイスブック(R)メッセージ、ツイッター^TMツイートなどを介してユーザと通信してもよい。サーバは、説明要求質問３３２をユーザに提示してもよい。アプリは、提示された説明要求質問に答えるためのユーザ入力インターフェース要素（例えば、仮想のキーボード３３３）を提供してもよい。ある実施例では、説明要求質問はサーバによって自動的にランダムに選択されてもよく、ある実施例では、カスタマーサービス係が手動でユーザと通信してもよい。

ある実施例では、真正のユーザは取引を開始しなかったかもしれず、例えば、取引が詐欺である。そのような実施例では、ユーザはテキストによる説明要求を取り消すことができる（例えば、３３１）。サーバは、その場合、取引を取り消し、及び／又はユーザの代わりに詐欺調査手続を開始してもよい。

ある実施例では、ユーザが、例えば、ユーザインターフェース要素３０９を有効にすることによって、ユーザのユーザ・プロファイル及び／又は設定を閲覧及び／又は変更できるようできるようにしてもよい（図３（ａ）を参照）。図３（ｇ）のインターフェース画面において、ユーザ名（例えば、３３５ａ〜ｂ）、口座番号（例えば、３３６ａ〜ｂ）、ユーザセキュリティアクセスコード（例えば、３３７ａ〜ｂ）、ユーザ個人識別番号（ＰＩＮ）（例えば、３３８ａ〜ｂ）、ユーザの住所（例えば、３３９ａ〜ｂ）、ユーザに関連付けられたソーシャルセキュリティ番号（例えば、３４０ａ〜ｂ）、現在のデバイスのＧＰＳ位置（例えば、３４１ａ〜ｂ）、ユーザが現在いる店の販売者のユーザ口座（例えば、３４２ａ〜ｂ）、ユーザのリワード口座（例えば、３４３ａ〜ｂ）などをユーザが閲覧及び／又は変更することができるようにしてもよい。ある実施例では、ユーザは、購入取引を容易にするために、データ・フィールドとそれらの関連値またはデフォルトのどれが送信されるべきか選択できるようにしてもよい。図３（ｇ）の例示的な実施例では、ユーザは、購入取引を処理する通知の一部として送られるフィールドとして、名前３３５ａ、口座番号３３６ａ、セキュリティコード３３７ａ、販売者口座ＩＤ３４２ａ、およびリワード口座ＩＤ３４３ａを選択した。ある実施例では、ユーザは、購買取引を処理する通知の一部として送られるフィールド及び／又はデータ値を切り換えるようにしてもよい。ユーザは、ユーザの電子財布で購入毎に使用したいデフォルト支払口座を指定できる。

ある実施例では、アプリが、ユーザが購入注文送信の一部として選択するために、保存された関連値及び／又はデータ・フィールドの複数の画面を提供してもよい。ある実施例では、アプリがユーザのＧＰＳ位置をサーバに提供してもよい。ユーザのＧＰＳ位置に基づいて、ＩＰＯＴがユーザの状況（例えば、ユーザが店、医院、病院、郵便局などにいるか否か）を決定してもよい。その状況に基づいて、ユーザアプリが、適切なフィールドをユーザに提示し、そこから、ユーザが、購入注文送信の一部として送信するフィールド及び／又はフィールド値を選択してもよい。

例えば、ユーザは医院に行き、通院日の自己負担額の支払いを望むかもしれない。口座番号や名前などの基本取引情報に加えて、アプリは、当事者間の支払いを調整するために、取引処理者と同様に、医療提供者、保険会社に提供される可能性があるカルテ、健康情報を選択する機能をユーザに提供してもよい。ある実施例では、記録が医療保険の携行性と責任に関する法律（ＨＩＰＡＡ）に準拠したデータ・フォーマットで送信されて暗号化され、その記録を閲覧する権限がある受領者だけが、その個人的なユーザ情報を復号および閲覧する適切な復号鍵を有してもよい。

図３（ｈ）は、モバイルデバイスに表示される販売者検証可能コードを有する電子受領書を示す。電子受領書３５２は、バーコードである検証可能コード３５１を含んでいる。店の出口では、検証可能コード３５１を有する電子受領書を、表示部に表示し、カメラやバーコードを読み取れるその他のリーダの近くを通過させることができる。サーバは、バーコードが有効であること（例えば、１／２，１，２，３，４，５，６，７，８あるいはそれ以上の時間の間に購入が行われたこと、および、バーコードと関連付けられた電子受領書が適切に購入を計上していること）を検証することができる。サーバは、検証可能コードが窃盗防止デバイスに対して有効であるというメッセージの表示を送信することができる。この指示は、購買者が製品を持って問題なく退店することができるように、他の動作中の警報を無力化することができる。また、この指示は警備員に示し、ゲートを開け、又は別の方法で購買者の退店を容易にすることもできる。

代替的な実施例においては、モバイルデバイス自体が盗難防止タグを無力化してもよいし、又はユーザが盗難防止タグを無力化することができる設備に誘導されてもよい。その有効な購入を確認されると、盗難防止のタグを無効にするために信号がデバイスまたはキオスクに送られる。

「電子受領書」は、揮発性または不揮発性デジタルメモリ若しくは電子デバイス又は当業界で既知のその他のものに、保存可能な受領書を含む。電子受領書はバーコードなどの機械可読な画像を含んでも含まなくてもよい。

図４は、ある実施例におけるモバイル製品購入取引を実行する例示的側面を示す論理フローチャートである。ある実施例では、システムが製品識別子（例えば４０１）を撮影してもよい。システムは、製品に関する製品情報を得て、ユーザに製品情報を表示してもよい。システムは、ユーザに提供する一以上の提案に基づいて、製品を購入するオプションをユーザに提供してもよい。ユーザが製品を購入することを選択すると（例えば４１０）、システムは購入命令を他の要素及び／又はエンティティ（例えば、販売者、カードイシュア、取得販売者等）に送信してもよい（例えば４２０）。ある実施例では、そのシステムが購入確認受領書を取得し（例えば４２５）（例えば、ユーザが以前の購入を修正しているならば更新されたもの）、ユーザに取得された購入確認受領書を表示してもよい。

図５は、モバイル製品購入取引に対して、購入オプションを選択する例示的側面を示す論理フローチャートを示す。ある実施例では、システムは、クライアントデバイスから製品識別子、更に、クライアント及び／又はユーザ識別子を得てもよい（例えば５０１）。システムは、製品識別子及び／又はクライアント識別子及び／又はユーザ識別子に基づいて、製品情報を製品記録データベースにクエリーをしてもよい（例えば５０５）。システムはデータベースに製品の一致を見つけられなければ（例えば５１０選択肢「Ｎｏ」）、エラーメッセージを生成して返し、エラー処理手続を開始してもよい（例えば５１５）。システムが製品記録データベースに製品の一致を見つけると（例えば５００選択肢「ＹＥＳ」）、そのデータベースから製品に対応する製品情報を得てもよい（例えば５２０）。データベースから得られた情報に基づいて、システムは特別なプロモーションがその製品に利用できるかを判断する（例えば５２５）。利用可能な特別なプロモーションがなければ（例えば５２５選択肢「Ｎｏ」）、システムはそのままの製品情報をユーザに提供してもよい（例えば５３０）。利用可能な特別なプロモーションがあれば（例えば５２５選択肢「ＹＥＳ」）、システムは製品情報とプロモーション情報をユーザに提供してもよい（例えば５３５）。ある実施例では、システムが購入要求をユーザから得してもよい。システムは購入要求をユーザから得ると（例えば５４０選択肢「ＹＥＳ」）、販売者、発行銀行、取得銀行及び／又はその他の購入取引の処理についてのエンティティに、購入指示を提供してもよい。システムは、システムが購入に関する購入表示を提供したエンティティから、通知を受けてもよい。購入が承認されなければ（例えば５５５選択肢「Ｎｏ」）、システムがエラー処理手続を開始してもよい（例えば５６０）。購入が承認されれば（例えば５５５選択肢「ＹＥＳ」）、システムが購入確認情報を取得して（例えば５６５）、購入確認受領書を生成し、購入確認受領書をユーザに提供してもよい（例えば５７０）。

図６（ａ）〜６（ｃ）は、生カードベース取引データをもたらすカードベース取引を実行する例示的手順を示すデータフロー図である。ある実施例では、ユーザ（例えば６０１）は、製品、サービス、提案など（「製品」）を販売者から購入することを希望するかもしれない。ユーザが、パーソナルコンピュータ、モバイルデバイス、テレビ、ＰＯＳ端末、キオスク、ＡＴＭ等の（ただしこれらに限定されない）クライアント（例えば６０２）を介して販売者サーバ（例えば６０３）と通信してもよい。例えばユーザは、ユーザ入力（例えば購入入力６１１）を、その製品を購入するというユーザの希望を示すクライアントに与えてもよい。様々な実施例において、ユーザ入力は、キーボード入力、カードスワイプ、無線周波数識別（ＲＦＩＤ）やニア・フィールド通信（ＮＦＣ）によって動作可能なハードデバイス（例えば、複数の口座を持つ電子カード、スマートフォン、タブレット）を動作可能にすること、マウスクリック、ジョイスティック／ゲーム機のボタンを押すこと、音声命令、タッチセンシティブインターフェースでの一／多タッチ操作、タッチセンシティブディスプレイでのユーザインターフェース要素のタッチなどを含んでもよいが、これらには限定されない。例えば、ユーザは、クライアントデバイスで実行するブラウザアプリケーションを販売者ウェブサイトに向け、ウェブサイトでユーザに提示されたハイパーリンクをクリックすることでウェブサイトから製品を選択してもよい。

別の例として、クライアントは、ユーザのカード（例えばクレジットカード、デビットカード、プリペイドカード、チャージカード）からのトラック１データを得てもよい（以下にトラック１のデータ例など）。
％Ｂ１２３４５６７８９０１２３４５^ＡＰＵＢＬＩＣ／Ｊ．Ｑ．^Ａ９９０１１２００００００００００００００^＊＊９０１^{＊＊＊＊＊＊}？^＊
（ここで、「１２３４５６７８９０１２３４５」は「Ｊ．Ｑ．Ｐｕｂｌｉｃ」のカード番号で、９０１のＣＶＶ番号を持っている。「９９０１１２」はサービスコードであり、^＊＊＊は、カードが使用されるごとにランダムに変わる１０進の数字を表わす。）
ある実施例では、クライアントが購入注文メッセージを生成し（例えば６１２）、販売者サーバに生成された購入注文メッセージを提供してもよい（例えば６１３）。例えば、クライアントで実行されるブラウザアプリケーションが、ユーザの代わりに、拡張マークアップ言語（「ＸＭＬ」）に従ってフォーマットされたデータ形式で、販売者サーバの製品注文詳細を含む（セキュア）ハイパー転送プロトコル（「ＨＴＴＰ（Ｓ）」）ＧＥＴメッセージを提供してもよい。

ある実施例では、販売者サーバは、クライアントから購入注文メッセージを取得して、ユーザからの購入注文の詳細を抽出するために購入注文メッセージを構文解析してもよい。販売者サーバは、取引が処理可能かどうかを決定するために、カードクエリー要求を生成してもよい（例えば６１４）。例えば、販売者サーバは、ユーザが購入注文で提供されたカード口座に購入の支払う十分な資金を有しているかどうかを決定しようと試みてもよい。販売者サーバは、生成されたカードクエリー要求をアクワイアラサーバ（例えば６０４）に提供してもよい（例えば６１５）。例えば、アクワイアラサーバは、販売者の口座を保持するアクワイアラ金融機関（「アクワイアラ」）のサーバであってもよい。例えば、その販売者によって処理される取引の売上額を、アクワイアラによって保持される口座に預けてもよい。ある実施例では、カードクエリー要求が、取引に含まれるユーザへのコスト、ユーザのカード口座詳細、ユーザの請求及び／又は購入情報などの詳細を含んでもよいが、これらに限定されるものではない。例えば、販売者サーバがＸＭＬフォーマットされたカードクエリー要求を含むＨＴＴＰ（Ｓ）ＰＯＳＴメッセージを提供してもよい。

ある実施例では、アクワイアラサーバが、得られたカードクエリー要求を使用して、カード承認要求を生成し（例えば６１６）、カード承認要求を支払ネットワークサーバ（例えば６０５）に提供してもよい（例えば６１７）。例えば、アクワイアラサーバは、販売者サーバから支払ネットワークサーバにＨＴＴＰ（Ｓ）ＰＯＳＴメッセージを転送してもよい。

ここで、支払ネットワークサーバは、カード承認要求６１７で特定されたものよりも購買者に関連付けられている、異なる支払口座を使用する提案を決めてもよい。例えば、自動オークションが、ユーザの電子財布内のカードの異なったカードイシュア間で行われてもよい。オークションが、ユーザに提供したい取引について、トップ１、２、３又はそれ以上のカードイシュアを選んでもよい。あるいは、支払ネットワークサーバが、どのカードイシュアがその購入に適用できる未払い取引／提案を有するかを、単に調べてもよい。例えば、ユーザが花（製品識別子を通じて決算された）を購入しようとしているなら、そのような購入に対するキャッシュバックまたは付加的なロイヤルティポイントを提供する特定のカードイシュアが選択されてもよい。

ＳＭＳメッセージなどで、提案を購買者にアプリを通じて送信することができる。購買者がその提案を選択すると、支払ネットワークサーバは承認要求を再フォーマット、再パッケージ、再構築、又は別の方法で修正し、「勝利した」イシュアにその承認要求を送信してもよい。

別の実施例では、競合する提案及び／又は他の販売者が、ユーザの商取引の自動オークションに参加してもよい。製品識別子によって特定された品物に対して競合する品物の提案、または、同一の品物若しくは競合する品物を販売する第２の販売者の提案が、アプリを介して（ＳＭＳテキストメッセージなどで）ユーザ６０１に送信される。その提案がユーザによって選択されると、支払ネットワークサーバ６０５は、最初の承認メッセージを取り消し、新しい品物の購入についての新しい承認メッセージを生成する。カード承認要求６１７はその中に製品情報を持てないので、購入される製品を異なるメッセージで別途送信してもよく、そのメッセージとカード承認要求６１７は一致する。

ある実施例では、支払ネットワークサーバは、アクワイアラサーバからカード承認要求を取得し、要求の詳細を抽出するためにカード承認要求を解析してもよい。抽出されたフィールドとフールド値を使用して、支払ネットワークサーバが、ユーザのカード口座に対応するイシュアに対してクエリー（例えば６１８）を生成してもよい。

例えば、ユーザがその詳細をクライアントが生成した購入注文メッセージを介して提供したかもしれないユーザのカード口座は、ユーザにカード口座を発行した銀行などのイシュア金融機関（「イシュア」）にリンクされてもよい。イシュアのイシュアサーバ（例えば６０６）が、ユーザのカード口座の詳細を保持してもよい。ある実施例では、データベース（例えば、支払ネットワークデータベース６０７）は、イシュアサーバとイシュアサーバに関連付けられたカード口座番号の詳細を保存してもよい。例えば、データベースは、構造化問い合わせ言語（「ＳＱＬ」）命令に応答するリレーショナルデータベースでもよい。支払ネットワークサーバは、イシュアサーバの詳細についてデータベースに問い合わせるＳＱＬ命令を含むハイパーテキストプリプロセッサ（「ＰＨＰ」）スクリプトを実行してもよい。

イシュアサーバクエリー（例えば６１９）の取得に応じて、支払ネットワークデータベースは、要求されたイシュアサーバデータを支払ネットワークサーバに提供してもよい（例えば６２０）。ある実施例では、支払ネットワークサーバは、アクワイアラサーバからイシュアサーバにカード承認要求を転送するために、イシュアサーバデータを使用して転送カード承認要求を生成してもよい（例えば６２１）。支払ネットワークサーバは、カード承認要求をイシュアサーバに提供してもよい（例えば６２２）。ある実施例では、イシュアサーバ（例えば６０６）はカード承認要求を解析し、要求の詳細に基づいて、データベース（例えばユーザ・プロファイルデータベース６０８）にユーザのカード口座のデータについて問い合わせてもよい。例えば、イシュアサーバはＰＨＰ／ＳＱＬ命令を発行してもよい。

ある実施例では、イシュアサーバは、ユーザデータを得ると（例えば６２５）、ユーザがその口座で利用可能な資金を使用して取引の代金を支払うことができるかを決定してもよい（例えば６２６）。例えば、イシュアサーバは、ユーザが口座に十分な残高が残っているか、口座に関連付けられた十分なクレジットがあるかなどを判断してもよい。イシュアサーバは、ユーザが口座で利用可能な資金を使用して取引の代金を支払うができると判断すると、承認メッセージ（例えば６２７）を支払ネットワークサーバに提供してもよい。例えば、サーバがＨＴＴＰ（Ｓ）ＰＯＳＴメッセージを提供してもよい。

ある実施例では、支払ネットワークサーバは、承認メッセージを取得して、承認の詳細を抽出するメッセージを解析してもよい。ユーザがその取引について十分な資金を所有していると判断すると、支払ネットワークサーバは取引データ記録を、受信したカード承認要求から生成し（例えば６２９）、取引の詳細とデータベース（例えば取引データベース６１０）においてその取引に関係する承認を保存してもよい（例えば６３０）。例えば、支払ネットワークサーバはＰＨＰ／ＳＱＬ命令を発行してもよい。

ある実施例では、支払ネットワークサーバは、承認メッセージ（例えば６３２）を販売者サーバに順次転送することができるアクワイアラサーバへ、承認メッセージ（例えば６３１）を転送してもよい。販売者は、承認メッセージを取得して、それに基づいてユーザがその取引を行うために十分な資金をカード口座に持っていることを判断してもよい。販売者サーバは、そのユーザについての取引の記録を、承認された取引に関する一群の取引データに付け加えてもよい。例えば、販売者は、ユーザ取引に関連するＸＭＬデータを、様々なユーザに対して承認された取引のＸＭＬデータを有するＸＭＬデータファイルに付け加え（例えば６３３）、データベース（例えば販売者データベース６０９）にＸＭＬデータファイル（例えば６３４）を保存してもよい。

ある実施例では、サーバが購入受領書（例えば６３３）を生成して、購入受領書をクライアントに提供してもよい。クライアントはユーザついての購入受領書をレンダリングして表示してもよい（例えば６３６）。例えば、クライアントは、ウェブページ、電子メッセージ、テキスト／ＳＭＳメッセージをレンダリングし、ボイスメールをバッファリングし、着信音を発し、及び／又は、オーディオメッセージを流すなどして、音、音楽、オーディオ、ビデオ、画像、触覚フィードバック、振動アラート（例えば、スマートフォンなどの振動できるクライアントデバイスでの）などを含む出力（但し、これらには限定されない）を提供してもよい。

図６（ｃ）に関して、ある実施例では、販売者サーバが一群の承認された取引の除去を開始してもよい。例えば、販売者サーバは、バッチデータ要求（例えば６３７）を生成し、その要求（例えば６２８）をデータベース（例えば、販売者データベース６０９）に提供してもよい。例えば、販売者サーバは、リレーショナルデータベースに問い合わせるのにＰＨＰ／ＳＱＬ命令を使用してもよい。そのバッチデータ要求に対して、データベースは要求されたバッチデータ（例えば６３９）を提供してもよい。サーバは、データベースから得られたバッチデータを使用して、バッチ除去要求を生成し（例えば６４０）、アクワイアラサーバにバッチ除去要求を提供してもよい（例えば６４１）。例えば、販売者サーバは、アクワイアラサーバに対してメッセージ本体にＸＭＬフォーマット・バッチデータを含むＨＴＴＰ（Ｓ）ＰＯＳＴメッセージを提供してもよい。アクワイアラサーバは、得られたバッチ除去要求を使用してバッチ支払要求を生成し（例えば６４２）、バッチ支払要求を支払ネットワークサーバに提供してもよい（例えば６４３）。支払ネットワークサーバは、バッチ支払要求を解析し、バッチ支払要求に保存された各取引について取引データを抽出してもよい（例えば６４４）。支払ネットワークサーバは、データベース（例えば取引データベース６１０）の各取引について、取引データ（例えば６４５）を保存してもよい。各抽出された取引に対して、支払ネットワークサーバが、イシュアサーバのアドレスについてデータベース（例えば支払ネットワークベース６０７）に問い合わせをしてもよい（例えば６４６）。例えば、支払ネットワークサーバはＰＨＰ／ＳＱＬ命令を使用してもよい。支払ネットワークサーバは、個別支払要求を、取引データを抽出した各取引に対して生成し（例えば６４８）、その個別支払要求をイシュアサーバ（例えば６０６）に提供してもよい（例えば６４９）。例えば、支払ネットワークサーバがＨＴＴＰ（Ｓ）ＰＯＳＴ要求を提供してもよい。

ある実施例では、イシュアサーバは支払命令を生成してもよい（例えば６５０）。例えば、イシュアサーバは、ユーザの口座から資金を差し引く（又はユーザのクレジットカード口座に追加請求する）ための命令を発行してもよい。イシュアサーバは、支払命令（例えば６５１）を、ユーザの口座情報を保存するデータベース（例えばユーザ・プロファイルデータベース６０８）に発行してもよい。イシュアは、資金移転メッセージ（例えば６５２）を支払ネットワークサーバに提供してもよく、資金移転メッセージをアクワイアラサーバに送信する支払ネットワークサーバに送ってもよい（例えば６５３）。

ある実施例では、アクワイアラサーバは資金移転メッセージを解析し、取引を（例えば、要求＿ＩＤフィールドを使用して）販売者に関連付けてもよい。その後、アクワイアラサーバは、資金移転メッセージで指定された資金を販売者の口座（例えば６５４）に移転してもよい。

図７（ａ）−７（ｄ）は、システムのある実施例において、生カードベース取引データの生成をもたらすカードベース取引を実行する例示的側面を示す論理フローチャートである。ある実施例では、ユーザが、ユーザ入力（例えば７０１）を販売者からのユーザの製品購入希望を示すクライアントに提供してもよい。クライアントは、購入注文メッセージ（例えば７０２）を生成し、生成された購入注文メッセージを販売者サーバに提供してもよい。ある実施例では、販売者サーバがクライアントから購入注文メッセージを取得して（例えば７０３）、ユーザからの購入注文の詳細を抽出するために購入注文メッセージを解析してもよい。販売者クライアントが利用できる例示的構文解析手段を、図８を参照して以下に述べる。販売者サーバは、取引が処理可能な否かを決定するために、カードクエリー要求を生成してもよい（例えば７０４）。例えば、購入注文が提供されるカード口座での購入代金を支払うための十分な資金をユーザが有する場合に限り、販売者サーバは取引を処理してもよい。販売者サーバは、生成されたカードクエリー要求をアクワイアラサーバに提供してもよい。アクワイアラサーバは、得られたカードクエリー要求を使用して、カード承認要求を生成し（例えば７０６）、カード承認要求を支払ネットワークサーバに提供にしてもよい。ある実施例では、支払ネットワークサーバが、アクワイアラサーバからカード承認要求を得て、その要求の詳細を抽出するためにカード承認要求を解析してもよい。抽出されたフィールドとフィールド値を使用して、支払ネットワークサーバが、ユーザのカード口座に対するイシュアサーバに対するクエリーを生成してもよい（例えば７０８）。イシュアサーバクエリーの取得に応じて、支払ネットワークデータベースは、要求されたイシュアサーバデータを支払ネットワークサーバに提供してもよい（例えば７０９）。ある実施例では、支払ネットワークサーバが、アクワイアラサーバからイシュアサーバにカード承認要求を転送するための転送カード承認要求を生成するのに、イシュアサーバデータを利用してもよい（例えば７１０）。支払ネットワークサーバは、カード承認要求をイシュアサーバに提供してもよい。ある実施例では、イシュアサーバがカード承認要求を解析し（例えば７１１）、要求の詳細に基づいて、ユーザカード口座データをデータベースに問い合わせてもよい（例えば７１２）。それに応じて、データベースが、要求されたユーザデータを提供してもよい。ユーザデータを得ると、イシュアサーバは、ユーザがその口座で利用可能な資金を使用して取引の代金を支払うことができるかを判断してもよい（例えば７１４）。例えば、イシュアサーバは、ユーザが口座に十分な残高を残しているか、その口座に関連付けられた十分なクレジットがあるかなどを判断してもよいが、データベースからのデータをカード承認要求から得られる取引費用と比較する。イシュアサーバが、口座で利用可能な資金を使用してユーザが取引の代金を払うことができると判断するのなら、サーバは承認メッセージを支払ネットワークサーバに提供してもよい（例えば７１５）。

ある実施例では、支払ネットワークサーバは、承認メッセージを得て、承認の詳細を抽出するメッセージ解析してもよい。ユーザが取引に対して十分な資金を有していると判断すると（例えば７１７選択肢「Ｙｅｓ」）、支払ネットワークサーバは、承認メッセージ及び／又はカード承認要求から取引カードを抽出し（例えば７１８）、カード取引の詳細を使用して取引データ記録を生成してもよい（例えば７１９）。支払ネットワークサーバは、保存のために取引データ記録をデータベースに提供してもよい（例えば７２０）。ある実施例では、支払ネットワークサーバは承認メッセージ（例えば７２１）をアクワイアラサーバに転送し、アクワイアラサーバが販売者サーバに承認メッセージを次に転送するようにしてもよい（例えば７２２）。販売者は、承認メッセージを取得し、その内容を抽出する承認メッセージを分析してもよい（例えば７２３）。販売者サーバは、取引を行うために、ユーザがカード口座に十分な資金を所有しているかを判断してもよい。販売者サーバはユーザが十分な資金を所有していると判断すれと（例えば７２４選択肢「Ｙｅｓ」）、販売者サーバは、ユーザの取引の記録を、承認された取引に関する一群の取引データに加えてもよい（例えば７２５）。販売者サーバは、ユーザに購入受領書を生成してもよい（例えば７２７）。販売者サーバが、ユーザが十分な資金を所有していないと判断すれば（例えば７２４選択肢「Ｎｏ」）、販売者サーバは「承認失敗」メッセージを作成してもよい（例えば７２８）。販売者サーバが、購入受領書や「承認失敗」メッセージをクライアントに提供してもよい。クライアントは、ユーザに購入受領書をレンダリングして表示してもよい（例えば７２９）。

ある実施例では、販売者サーバは、バッチデータ要求を生成し（例えば、図７（ｃ）における７３０）その要求をデータベースに提供することによって、一群の承認取引の除去を開始してもよい。そのバッチデータ要求に応じて、データベースは、販売者サーバに要求されたバッチデータを提供してもよい（例えば７３１）。サーバは、データベースから取得したバッチデータを使用して、バッチ除去要求を生成し（例えば７３２）、そのバッチ除去要求をアクワイアラサーバに提供してもよい。アクワイアラサーバは、得られたバッチ除去要求を使用して、バッチ支払要求を生成し（例えば７３４）、バッチ支払要求を支払ネットワークサーバに提供してもよい。支払ネットワークサーバは、バッチ支払要求を解析し（例えば７３５）、バッチデータ内に保存された取引を選択し（例えば７３６）、バッチ支払要求に格納された取引の取引データを抽出してもよい（例えば７３７）。支払ネットワークサーバは、取引データ記録を生成し（例えば７３８）、取引データと取引をデータベースに保存してもよい（例えば７３９）。抽出された取引に対して、支払ネットワークサーバは、アクワイアラサーバクエリーを、その取引を要求するユーザの口座を保持するイシュアサーバのアドレスに対して生成してもよい（例えば７４０）。支払ネットワークサーバは、そのクエリーをデータベースに提供してもよい。それに応じて、データベースは、支払ネットワークサーバによって要求されたイシュアサーバデータを提供してもよい（例えば７４１）。支払ネットワークサーバは、個別支払要求を、取引データを抽出した取引に対して生成し（例えば７４２）、個別支払要求をイシュアサーバにデータベースからのイシュアサーバデータを使用して提供してもよい。

ある実施例では、イシュアサーバは、個別支払要求を取得して、その要求の詳細を抽出するためにその個別支払要求を解析してもよい（例えば７４３）。抽出されたデータに基づいて、イシュアサーバは、支払命令を生成してもよい（例えば７４４）。例えば、イシュアサーバは、ユーザの口座から資金を差し引く（又はユーザのクレジットカード口座に追加請求する）命令を生成してもよい。イシュアサーバは、支払命令（例えば７４５）を、ユーザの口座情報を保存するデータベースに発行してもよい。それに応じて、データベースは、ユーザの口座になされるデビッド／課金を反映するユーザ口座に対応するデータ記録を更新してもよい。イシュアは、支払命令がデータベースによって実行された後に、資金移転メッセージを支払ネットワークサーバに提供してもよい（例えば７４６）。

ある実施例では、支払ネットワークサーバは、精算と資金供給が必要なバッチに追加の取引があるかを確認してもよい。追加の取引があれば（例えば７４７選択肢「Ｙｅｓ」）、支払ネットワークサーバは、上述の手順に応じて各取引を処理してもよい。支払ネットワークサーバは、バッチの全取引の移転を反映する合計資金移転メッセージを生成し（例えば図７（ｄ）の７４８）、イシュアサーバにその資金移転メッセージを提供してもよい（例えば７４９）。アクワイアラサーバは、それに応じて、資金移転メッセージで指定された資金を販売者の口座に移動してもよい（例えば７５０）。

制御部
図８は、ブロック図で制御部８０１の発明的な側面を示している。本実施例では、制御部８０１は、様々な技術及び／又はその他の関連したデータを通じて、コンピュータとのインタラクションの収集、処理、保存、検索、利用、識別、命令、生成、一致、及び／又は促進を行うことができる。

一般に、（人々及び／又はその他のシステムであるだろう）ユーザは、情報処理を容易にする情報技術システム（例えばコンピュータ）に関与する。また、コンピュータは、情報を処理するためにプロセッサを使用する。そのようなプロセッサ８０３は中央処理装置（ＣＰＵ）とも呼ばれる。プロセッサのある形式は、マイクロプロセッサと呼ばれる。ＣＰＵは、様々な操作を可能にする指示として作用する２進コード化した信号を渡すために、通信回路を使用する。これらの指示は、操作可能でも、及び／又は、メモリ８２９の様々なプロセッサがアクセス可能かつ操作可能なエリア（例えば、レジスタ、キャッシュメモリ、ランダムアクセスメモリ等）の他の指示やデータを包含、及び／又は参照するデータ指示であってもよい。そのような通信指示は、希望の操作を容易にするプログラム及び／又はデータコンポーネントとして、バッチ（例えば、指示のバッチ）に保存、及び／又は、送信されてもよい。これらの保存された指示コード（例えばプログラム）は、希望の操作を行うＣＵＰ回路コンポーネントおよび他のマザーボード及び／又はシステムコンポーネントに連関してもよい。ある種のプログラムは、コンピュータオペレーティングシステムであり、それはコンピュータのＣＰＵで実行され得る。オペレーティングシステムは、ユーザがコンピュータ情報技術および資源にアクセスし操作するのを可能かつ容易にする。情報技術システムで使用され得る幾つかの資源は、データがコンピュータに入出力され得る入出力手段、データが保存されるメモリ記憶部、および情報が処理されるプロセッサを含む。これらの情報技術システムは、後の検索、分析、及び操作のためのデータを集めるのに使用されてもよく、それはデータベースプログラムで促進されてもよい。これらの情報技術システムは、ユーザが様々なシステムコンポーネントにアクセスし操作するインターフェースを提供する。

ある実施例では、制御部８０１は、ユーザ入力デバイス８１１からの一人以上のユーザ、周辺デバイス８１２、任意暗号処理装置８２８及び／又は通信ネットワーク８１３など（これらに限定されない）のエンティティに接続されかつ／または通信してもよい。例えば、制御部８０１は、パーソナルコンピュータ、サーバ、及び／又は様々なモバイルデバイス（携帯電話、スマートフォン（例えば、ｉＰｈｏｎｅ(R)、Ｂｌａｃｋｂｅｒｒｙ(R)、Ａｎｄｒｏｉｄ ＯＳに基づく電話など）、タブレットコンピュータ（例えば、Ａｐｐｌｅ ｉＰａｄ^TM、ＨＰ Ｓｌａｔｅ^TM、Ｍｏｔｏｒｏｌａ Ｘｏｏｍ^TMなど）、ｅＢｏｏｋ ｒｅａｄｅｒ（例えば、Ａｍａｚｏｎ Ｋｉｎｄｌｅ^TM、Ｂａｒｎｅｓ ａｎｄ Ｎｏｂｌｅ‘ｓ Ｎｏｏｋ^TM ｅＲｅａｄｅｒなど）、ラップトップコンピュータ、ノートブック、ネットブック、ゲーム機（例えば、ＸＢＯＸ Ｌｉｖｅ^TM、Ｎｉｎｔｅｎｄｏ(R) ＤＳ、Ｓｏｎｙ ＰｌａｙＳｔａｔｉｏｎ(R) Ｐｏｒｔａｂｌｅなど）、ポータブルスキャナなどを含む、これらに限定されない）を含む（これらに限定されない）ユーザ操作クライアントデバイスに接続されかつ／または通信してもよい。

ネットワークは、一般に、クライアント、サーバ、およびグラフのトポロジーにおける中間ノードの相互運用や相互接続を備えると考えられている。本出願を通じて使われる「サーバ」は、一般に、通信ネットワークの全体で遠方のユーザの要求を処理し返答する、コンピュータ、その他デバイス、プログラム、それらの組み合わせについて言及することに注意されたい。サーバは、それらの情報を、要求する「クライアント」に供給する。ここで使われる「クライアント」は、一般に、処理し要求すること及び通信ネットワークの全体でサーバからの返答を得て処理することが可能なコンピュータ、プログラム、その他デバイス、ユーザ及び／又はそれらの組み合わせを言う。発信元ユーザから送信先ユーザへの情報の通信を容易にし、情報を処理して要求し、及び／又は促進するコンピュータ、その他デバイス、プログラム、またはそれらの組み合わせは、一般に、「ノード」と呼ばれる。ネットワークは、一般に、発信点から送信先への情報の送信を容易にするものと考えられている。特に、発信元から送信先への情報の通信の促進が課されたノードは、一般に、「ルーター」と呼ばれている。ローカルエリアネットワーク（ＬＡＮ）、ピコネットワーク、ワイドエリアネットワーク（ＷＡＮ）、ワイアレスネットワーク（ＷＬＡＮ）などのネットワークの多くの形式が存在する。例えば、インターネットは、一般に、遠方のクライアントとサーバが互いにアクセスし相互運用できる多数のネットワークの相互接続であるとして受け入れられている。

制御部８０１は、メモリ８２９に接続されたコンピュータ構成８０２などのコンポーネント（これに限定されない）を備え得るコンピュータシステムに基づくものでもよい。

コンピュータ構成
コンピュータ構成８０２は、クロック８３０、中央処理装置（「ＣＰＵ」及び／又は「プロセッサ」（これらは相反する記述がない限り、この開示全体にわたって交換可能使用される））８０３、メモリ８２９（例えば、読み出し専用メモリ（ＲＯＭ）８０６、ランダムアクセスメモリ（ＲＡＭ）８０５）など）、及び／又はインターフェースバス８０７を備えてもよく、伝導性及び／又はその他移送性の回路（指示（例えば、２進コード化された信号）が通信、操作、保存等の効果をもたらすように移動し得る）を有する一つ以上の（マザー）ボード８０２上で、システムバス８０４を通じて、最も頻繁に（必ずしもそうではないが）全て相互接続され、かつ／または通信する。任意で、コンピュータ構成は、内部電源８８６に接続されてもよい（例えば、任意で、電源が内部にあってもよい）。任意で、暗号プロセッサ８２６及び／又はトランシーバ（例えばＩＣ）８７４がシステムバスに接続されてもよい。他の実施例では、暗号プロセッサ及び／又はトランシーバは、インターフェースバスＩ／Ｏを介して内部及び／又は外部の周辺デバイス８１２として接続されてもよい。また、トランシーバはアンテナ８７５に接続されてもよく、それによって、様々な通信及び／又はセンサープロトコルの無線送受信をもたらす。例えば、アンテナは、テキサス・インスツルメンツのＷｉＬｉｎｋ ＷＬ１２８３トランシーバチップ（例えば、８０２．１１ｎ、Ｂｌｕｅｔｏｏｔｈ３．０、ＦＭ，グローバル・ポスティング・システム（ＧＰＳ）を提供する（それによって制御部が位置を判断できる））、Ｂｒｏａｄｃｏｍ ＢＣＭ４７５０ＩＵＢ８レシーバーチップ（例えば、ＧＰＳ）、Ｉｎｆｉｎｅｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｘ−Ｇｏｌｄ ６１８−ＰＭＢ９８００（例えば、２Ｇ／３Ｇ ＨＳＤＰＡ／ＨＳＵＰＡ通信を提供する）などに接続されてもよい。システムクロックは、一般的に、水晶振動子を有し、ベース信号をコンピュータ構成の回路を通じて生成する。クロックは一般的に、システムバスや、コンピュータ構成に相互接続された他のコンポーネントに対するベース動作周波数を増減する様々なクロック乗算器に連結される。クロックおよびコンピュータ構成中の様々なコンポーネントが、システムを通じて、情報を具体化する信号を駆動する。そのようなコンピュータ構成において情報を具現化する指示の送受信は、一般に、通信と呼ばれる。これらの通信指示は、更に、送受信されてもよく、本コンピュータ構成を越えた、通信ネットワーク、入力デバイス、他のコンピュータ構成、周辺デバイスなどへの返還及び／又は応答通信の原因であってもよい。当然、上記コンポーネントのいくつかは、互いに直接接続され、ＣＰＵに接続され、及び／又は様々なコンピュータシステムで例示されるように使用される多数のバリエーションで編成することができる。

ＣＰＵは、ユーザ及び／又はシステム生成要求を実行するプログラムコンポーネントを実行するのに最適な少なくとも一つのハイスピードデータプロセッサを備えている。大抵、プロセッサ自体は、統合システム（バス）コントローラ、メモリ管理制御ユニット、浮動小数点演算ユニットなど（これらに限定されない）の様々な特化した処理装置、およびグラフィック処理ユニット、デジタル信号処理ユニットなどのような特化された処理サブユニットも組み込みこんでいる。加えて、プロセッサは、内部の高速アクセス連想メモリを含んでもよく、プロセッサ自身を越えて、メモリ５２９を位置づけアドレス指定することができてもよい。内部メモリは、高速レジスタ、様々なレベルのキャッシュメモリ（例えば、レベル１、２、３、など）、ＲＡＭ等（これらに限定されない）を含んでもよい。プロセッサは、メモリ状態を有する指定メモリアドレス空間に回路をアクセスさせるようにプロセッサが構築および復号できる指示アドレスで、アクセス可能なメモリアドレス領域の使用を通じて、このメモリにアクセスしてもよい。ＣＰＵは、マイクロプロセッサ（ＡＭＤのＡｔｈｏｌｏｎ、Ｄｕｒｏｎ及び／又はＯｐｔｅｒｏｎ、ＡＲＭのアプリケーション、内蔵セキュアプロセッサ、ＩＢＭ及び／又はＭｏｔｏｒｏｌａのＤｒａｇｏｎＢａｌｌおよびＰｏｗｅｒＰＣ、ＩＢＭおよびＳｏｎｙのセルプロセッサー、ＩｎｔｅｌのＣｅｌｅｒｏｎ、Ｃｏｒｅ（２）Ｄｕｏ、Ｉｔａｎｉｕｍ、Ｐｅｎｔｉｕｍ（登録商標）、Ｘｅｏｎ、及び／又はＸＳｃａｌｅ、及び／又は同様のプロセッサなど）でもよい。ＣＰＵは、従来のデータ処理技術に従って、保存された指示（すなわち、プログラムコード）を実行するために、伝導性及び／又は移送性コジット（例えば、（印刷された）電子及び／又は光学回路）を通る指示を通じてメモリと相互に作用する。そのような指示の通過は、制御部内および様々なインターフェースを越えた通信を容易にする。処理要求がより大きなスピード及び／又は容量を指示するのであれば、分散型のプロセッサ（例えば、分散型のアーキテクチャ）、メーンフレーム、マルチコア、並行及び／又はスーパーコンピュータアーキテクチャが同様に使用されてもよい。代わりに、開発要求がより優れた携帯性を指示するならば、より小さなパーソナル・デジタル・アシスタント（ＰＤＡ）が使用されてもよい。

特定の実施例に基づいて、制御部の機能が、ＣＡＳＴのＲ８０５１ ＸＣ２ マイクロコントローラ、ＩｎｔｅｌのＭＣＳ ５１（すなわち，８０５１マイクロ制御部）などのマイクロコントローラを実施例することによって達成されてもよい。また、制御部の特定の機能を実施例するために、幾つかの機能実施例が、特定用途向け集積回路（「ＡＳＩＣ」）、デジタル信号処理（「ＤＳＰ」）、フールド・プログラマブル・ゲート・アレイ（「ＦＰＧＡ」）及び／又は同様の組み込み技術などの組み込みコンポーネントに依存してもよい。例えば、コントローラ・コンポーネント・コレクション（区分等された）及び／又は機能のいくつかが、マイクロプロセッサ及び／又は組み込みコンポーネントを介して（例えば、ＡＳＩＣ、コプロセッサ、ＤＳＰ，ＦＰＧＡ等を介して）実施例されてもよい。代わりに、制御部の幾つかの実施例が、様々な機能や信号処理を達成するように構成され使用される組み込みコンポーネントで実装されてもよい。

特定の実施例によって、組み込みコンポーネントが、ソフトウェアソリューション、ハードウェアソリューション及び／又はハードウェア／ソフトウェアソリューション両方の組み合わせを含んでもよい。例えば、ここで議論された制御部の機能は、ＦＰＧＡ（「論理プロック」と呼ばれるプログラマブル論理コンポーネントを含む半導体デバイス）とハイパフォーマンスＦＰＧＡ Ｖｉｒｅｔｅｘシリーズ及び／又はＸｉｌｉｎｘによって製造されるロー・コストＳｐａｒｔａｎシリーズなどのプログラマブル・インターコネクトを実装することで達成されてもよい。論理ブロックと相互接続が、ＦＰＧＡが製造された後に、制御部の機能のいくつかを実装するために、顧客や設計者によってプログラムされることも可能である。ワンチップ・プログラマブル・ブレッドボードのように、プログラマブル・インターコネクトの階層化は、コントローラシステムの設計者／管理者によって必要に応じて論理ブロックを相互接続さられる。ＦＰＧＡの論理ブロックは、ＡＭＤおよびＸＯＲ、又はより複雑な組み合わせ機能（デコーダや単純な数学関数など）などの基本論理ゲートの機能を行うようにプログラムされ得る。ほとんどのＦＰＧＡにおいて、論理ブロックはメモリ要素を含み、それは単純なフリップ・フロップまたはより完全なメモリのブロックでもよい。幾つかの回路では、ＩＰＯＴは、通常のＦＰＧＡで開発され、それからよりＡＳＩＣ実施例に近い固定されたバージョンに移行されてもよい。代わりの又は対応した実施例は、制御部の機能をＦＰＧＡの代わりに又はＦＰＧＡに加えて最終的なＡＳＩＣに移行されてもよい。実施例によって、前述の組み込みコンポーネント及びマイクロプロセッサの全てを制御部の「ＣＰＵ」及び／又は「プロセッサ」と考えてもよい。

電源
電源８８６は、小さい電子回路ボードデバイス（以下の動力電池：アルカリ、水素化リチウム、リチウムイオン、リチウムポリマ、ニッケルカドミウム、太陽電池等）に動力を供給する標準形式のものでもよい。ＡＣやＤＣ電源の他のタイプが同様に使用されてもよい。太陽電池の場合、ある実施例では、その外装は、太陽電池が光子エネルギーを捉えられる開口を設ける。動力電池８８６は、制御部の相互接続されたサブシークエントコンポーネントの少なくとも一つに接続され、それによって、全てのサブシークエントコンポーネントに電流を供給できる。ある実施例では、電源８８６は、システムバスコンポーネント８０４に接続される。代わりの実施例では、外部の動力源８８６はＩ／Ｏ８０８インターフェースをはさんだ接続を通じて供給される。例えば、ＵＳＢ及び／又はＩＥＥＥ１３９４接続は、その接続を通じてデータと電源の両方を伝達しており、それゆえ適した動力源である。

インターフェースアダプタ
インターフェースバス８０７は、多くのインターフェースアダプタ（慣習的に、入出力インターフェース（Ｉ／Ｏ）８０８、ストレージインターフェース８０９、ネットワークインターフェース８１０など（これらに限定されない）のアダプタカード形式ではない）にアクセスし、接続し、及び／又は通信をしてもよい。任意で、暗号プロセッサインターフェース８２７は、インターフェースバスに同様に接続されてもよい。インターフェースバスは、互いに、また、コンピュータ構成の他のコンポーネントにも、インターフェースアダプタの通信を提供してもよい。インターフェースアダプタは、互換インターフェースバスに適用される。インターフェースアダプタは、慣習的に、スロットアーキテクチャを介してインターフェースバスに接続する。従来のスロットアーキテクチャ（アクセラレーテッド・グラフィクス・ポート（ＡＧＰ）、カードバス、（拡張）業界標準アーキテクチャ（（Ｅ）ＩＳＡ）、マイクロ・チャンネル・アーキテクチャ（ＭＣＡ）、ＮｕＢｕｓ、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ （Ｅｘｔｅｎｄｅｄ）（ＰＣＩ（Ｘ））、ＰＣＩ Ｅｘｐｒｅｓｓ、パーソナルコンピュータメモリカード国際協会（ＰＣＭＣＩＡ）など（これらに限定されない））が採用されてもよい。

ストレージインターフェース８０９は、ストレージデバイス８１４、リムーバブル・ディスク・デバイスなど（これらに限定されない）の多くのストレージデバイスにアクセスし、通信し、及び／又は接続してもよい。ストレージインターフェースは、（ウルトラ）（シリアル）アドバンスト・テクノロジー・アタッチメント（パケットインターフェース）（（Ｕｌｔｒａ）（Ｓｅｒｉａｌ）ＡＴＡ（ＰＩ））、（拡張） 統合ドライブエレクトロニクス（（Ｅ））ＩＤＥ）、電気電子技術者協会（ＩＥＥＥ）１３９４、ファイバーチャンネル、小型コンピュータ用周辺機インターフェース（ＳＣＳＩ）、ユニバーサル・シリアル・バス（ＵＳＢ）、など（これらに限定されない）の接続プロトコルを採用してもよい。

ネットワークインターフェース８１０は、通信ネットワーク８１３にアクセス、通信、及び／又は接続してもよい。通信ネットワーク８１３を通じて、制御部は、ユーザ８３３ａによって、遠方のクライアント８３３ｂ（例えば、ウェブブラウザを有するコンピュータ）から情報を得ることができる。ネットワークインターフェースは、直接接続、イーサネット（登録商標）（ｔｈｉｃｋ、ｔｈｉｎ、ｔｗｉｓｔｅｄ ｐａｉｒの１０／１００／１０００ＢａｓｅＴ等）、トークン・リング・ネットワーク、ＩＥＥＥ８０２．１１ａ−ｘ等の無線通信、など（これらに限定されない）の通信プロトコルを採用してもよい。処理要求がより大きなスピード及び／又は容量を指示するならば、分散型ネットワークコントローラ、アーキテクチャは、プール、負荷平衡に同様に用いられ、かつ／または制御部によって要求された通信バンド幅を増加してもよい。通信ネットワークは、いずれか一つ及び／又は以下の組み合わせであってもよい。直接相互接続、インターネット、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、Ｏｐｅｒａｔｉｎｇ Ｍｉｓｓｉｏｎ ａｓ Ｎｏｄｅｓ ｏｎ ｔｈｅ Ｉｎｔｅｒｎｅｔ（ＯＭＮＩ）、ｓｅｃｕｒｅｄ ｃｕｓｔｏｍ ｃｏｎｎｅｃｔｉｏｎ、広域ネットワーク（ＷＡＮ）、無線ネットワーク（例えば、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）、ｌ−ｍｏｄｅなど（これらに限定されない）のプロトコルを使うもの）など。ネットワークインターフェースは、入出力インターフェースの特化形式として見なされてもよい。更に、多重ネットワークインターフェース８１０が、様々な通信ネットワークタイプ８１３と繋がるように使用されてもよい。例えば、多重ネットワークインターフェースは、ブロードキャスト、マルチキャスト、及び／又はユニキャストネットワークにおける通信を可能とするために採用されてもよい。

入出力インターフェース（Ｉ／Ｏ）８０８は、ユーザ入力デバイス８１１、周辺デバイス８１２、暗号プロセッサデバイス８２８などにアクセス、通信、及び／又は接続してもよい。Ｉ／Ｏは、音声（アナログ、デジタル、モノラル、ＲＣＡ、ステレオ等）、データ（Ａｐｐｌｅデスクトップバス（ＡＤＢ）、ＩＥＥＥ１３９４ａ−ｂ、シリアル、ユニバーサル・シリアル・バス（ＵＳＢ））、赤外線、ジョイスティック、キーボード、ミディ、光学、ＰＣ ＡＴ、ＰＳ／２、平衡、ラジオ、ビデオインターフェース（Ａｐｐｌｅデスクトップコネクタ（ＡＤＣ）、ＢＮＣ、同軸ケーブル、コンポーネント、合成、デジタル、デジタル・ビジュアル・インターフェース（ＤＶＩ）、高詳細度マルチメディアインターフェース（ＨＤＭＩ（登録商標））、ＲＣＡ、ＲＦアンテナ、Ｓ−Ｖｉｄｅｏ、ＶＧＡ等）、無線トランシーバ（８０２．１１ａ／ｂ／ｇ／ｎ／ｘ）、Ｂｌｕｅｔｏｏｔｈ、ｃｅｌｌｕｌａｒ（例えば、符号分割多重アクセス方式（ＣＤＭＡ）、ハイスピードパケットアクセス（ＨＳＰＡ（＋））、高速ダウンリンクパケット接続（ＨＳＤＰＡ）、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ（登録商標））、ロング・ターム・エボリューション（ＬＴＥ），ＷｉＭａｘ等）、など（これらに限定されない）の接続プロトコルを用いてもよい。一つの典型的な出力デバイスは、ビデオディスプレイを含んでもよく、それはビデオインターフェースからの信号を受け入れるインターフェース（例えば、ＤＶＩ回路およびケーブル）を有するブラウン管（ＣＲＴ）や液晶ディスプレイ（ＬＣＤ）に基づくモニタを備えてもよい。ビデオインターフェースは、コンピュータ構造によって作られた情報を合成し、ビデオメモリフレームにおける合成情報に基づいてビデオ信号を生成する。他の出力デバイスは、ビデオインターフェースからの信号を受けとるテレビがある。通常、ビデオインターフェースは、ビデオディスプレイインターフェース（例えば、ＲＣＡ合成ビデオケーブルを受け入れるＲＣＡ合成ビデオコネクタ、ＤＶＩディスプレイケーブルを受け入れるＤＶＩコネクタ等）を容認するビデオコネクションインターフェースを通った合成ビデオ情報を提供する。

ユーザ入力デバイス８１１は、大抵は、周辺デバイスの一種であり、カードリーダ、ドングル、指紋リーダ、グローブ、グラフィックス・タブレット、ジョイスティック、キーボード、マイクロフォン、マウス、リモートコントローラ、網膜リーダ、タッチスクリーン（例えば、容量、抵抗等）、トラックボール、トラックパッド、センサ（例えば、加速度計、間接照明、ＧＰＳ、ジャイロスコープ、周辺機等）、スタイラスペンなどを含んでいてもよい。

周辺デバイス８１２は、Ｉ／Ｏ及び／又は同様の他の設備（ネットワークインターフェース、ストレージインターフェース、インターフェースバスと直接、システムバス、ＣＰＵ等）に接続され、かつ／または通信してもよい。周辺デバイスは、外部、内部及び／又は一部のＩＰＯＴコントローラであってもよい。周辺デバイスは、アンテナ、音声デバイス（例えば、ライン入力端子、ライン出力端子、マイクロフォン入力、スピーカ等）、カメラ（例えば、静止、動画、ウェブカメラ等）、ドングル（例えば、コピープロテックションのため、電子署名を有する安全な取引を保証するため等）、外部プロセッサ（拡張容量（例えば、暗号デバイス５２８）のためのもの）、力フィードバックデバイス（例えば、振動モータ）、ネットワークインターフェース、プリンタ、スキャナ、ストレージデバイス、トランシーバ（例えば、携帯電話、ＧＰＳ等）、ビデオデバイス（例えば、ゴーグル、モニタ等）、ビデオ資源、ｖｉｓｏｒなどを含んでもよい。周辺デバイスは、多くの場合、デバイス（例えば、カメラ）の形式を含んでいる。

ユーザ入力デバイスと周辺デバイスが用いられても、制御部が内蔵の、専用の、及び／又はモニタレス（すなわち、ヘッドレス）のデバイスとして用いられてもよいことに注意されたい。そこで、アクセスはネットワークインターフェース接続を越えて行われる。

マイクロコントローラ、プロセッサ８２６、インターフェース８２７、及び／又はデバイス８２８など（これに限定されない）の暗号ユニットは、制御部と接続され、かつ／または、通信してもよい。Ｍｏｔｏｒｏｌａ Ｉｎｃ．によって製造されたＭＣ６８ＨＣ１６マイクロコントローラは、暗号ユニットに使用、及び／又は暗号ユニットの内部で使用されてもよい。ＭＣ６８ＨＣ１６マイクロコントローラは、１６ＭＨｚの構成で１６ビットの乗算累積指示を活用してもよく、５１２ビットのＲＳＡ秘密鍵操作を行うのに一秒未満を要する。暗号ユニットは、匿名の取引を可能にするのはもちろんのこと、取引する仲介者からの通信の認証を裏付ける。暗号ユニットは、ＣＰＵの一部として構成されてもよい。同等のマイクロコントローラ及び／又はプロセッサが使われてもよい。他の商業的に利用可能な特定の暗号プロセッサは、ＢｒｏａｄｃｏｍのＣｒｙｐｔｏＮｅｔＸと他のセキュリティプロセッサ、ｎＣｉｐｈｅｒのｎＳｈｉｅｌｄ、ＳａｆｅＮｅｔのＬｕｎａ ＰＣＩ（例えば、７１００）シリーズ、Ｓｅｍａｐｈｏｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓの４０ＭＨｚＲｏａｄｒｕｎｎｅｒ１８４、ＳｕｎのＣｒｙｐｔｏｇｒａｐｈｉｃ Ａｃｃｅｌｅｒａｔｏｒｓ（例えば、Ａｃｃｅｌｅｒａｔｏｒ６０００ ＰＣＩｅ Ｂｏａｒｄ、Ａｃｃｅｌｅｒａｔｏｒ５００ Ｄａｕｇｈｔｅｒｃａｒｄ）、５００＋ＭＢ／ｓの暗号指示を行うことができるＶｉａ Ｎａｎｏ Ｐｒｏｃｅｓｓｏｒ（例えば、Ｌ２１００、Ｌ２２００、Ｕ２４００） ｌｉｎｅ、ＶＬＳＩ Ｔｅｃｈｎｏｌｏｇｙの３３ＭＨｚ ６８６８などを含む。

メモリ
一般に、プロセッサに情報の格納及び／又は回復を許容する機械及び／又は具体物は、メモリ８２９と見なされる。しかし、メモリは一般に代替技術および資源であり、それゆえに、任意の数のメモリ実施態様は互いの代わりに又は互いに協力して使用されてもよい。制御部及び／又はコンピュータ構成が様々な形式のメモリ８２９を使用してもよいことが知られている。例えば、コンピュータ構造は、オンチップＣＰＵメモリ（例えばレジスタ）、ＲＡＭ、ＲＯＭ、および他の記憶デバイスの機能が穿孔テープや穿孔カード機構によって提供されるように構成されてもよい。もちろん、そのような実施態様は、極度の操作の遅延をもたらすだろう。標準的な構造では、メモリ８２９はＲＯＭ８０６、ＲＡＭ８０５および記憶デバイス８１４を包括している。記憶デバイス８１４は、従来のコンピュータシステムストレージのいずれでもよい。記憶デバイスは、ドラム、（固定された、及び／又は、取り外し可能な）磁気ディスクドライブ、磁気光学ドライブ、光学ドライブ（すなわち、ブルーレイ^(R)、ＣＤ−ＲＯＭ／ＲＡＭ／記録可能（Ｒ）／書換可能（ＲＷ）、ＤＶＤ−Ｒ／ＲＷ、ＨＤ ＤＶＤ Ｒ／ＲＷ等）、デバイスの配列（例えば、Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ（ＲＡＩＤ））、固体メモリデバイス（ＵＳＢメモリ、半導体ドライブ（ＳＳＤ）等）、他のプロセッサ読取可能な記録媒体、及び／又は同様の他のデバイスを含んでもよい。それゆえ、コンピュータ構造は、一般に、メモリを要し、使用する。

コンポーネントコレクション
メモリ８２９は、プログラム及び／又はデータベースコンポーネント及び／又はデータの集まり（オペレーティングシステムコンポーネント８１５（オペレーティングシステム）、情報サーバコンポーネント８１６（情報サーバ）、ユーザ・インターフェース・コンポーネント８１７（ユーザインターフェース）、Ｗｅｂブラウザコンポーネント８１８（Ｗｅｂブラウザ）、データベース８１９、メールサーバコンポーネント８２１、メールクライアントコンポーネント８２２、暗号サーバコンポーネント８２０（暗号サーバ）、コントローラコンポーネント８３５など（これらに限定されない）（すなわち、集合的なコンポーネントコレクション））を収容している。これらのコンポーネントは、格納され、記憶デバイス及び／又はインターフェースバスを通じてアクセス可能な記憶デバイスからアクセスされてもよい。特殊なプログラムコンポーネント（コンポーネントコレクション内のものなど）は、通常は、ローカル・ストレージ・デバイス８１４に格納されるが、それらはメモリ（周辺デバイス、ＲＡＭ、通信ネットワークを通したリモートストレージ設備、ＲＯＭ，様々な形式のメモリなど）で読み込まれ、かつ／または、格納されてもよい。

オペレーティングシステム
オペレーティングシステム・コンポーネント８１５は、制御部の操作を助ける実行可能なプログラムコンポーネントである。一般的には、オペレーティングシステムは、Ｉ／Ｏのアクセス、ネットワークインターフェース、周辺デバイス、記憶デバイスなどのアクセスを容易にする。オペレーティングシステムは、高い故障耐久性のある、拡張可能な、安全なシステム（Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ ＯＳ Ｘ（サーバ）、ＡＴ＆Ｔ Ｐｌａｎ ９、Ｂｅ ＯＳ、Ｕｎｉｘ（登録商標）とＵｎｉｘライクシステムディストリビューション（ＡＴ＆ＴのＵＮＩＸ（登録商標）、ＦｒｅｅＢＳＤやＮｅｔＢＳＤやＯｐｅｎＢＳＤなどのＢｅｒｋｌｅｙ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＢＳＤ） ｖａｒｉａｔｉｏｎｓ、Ｒｅｄ ＨａｔやＵｂｕｎｔｕなどのＬｉｎｕｘ（登録商標）ディストリビューション）、及び／又は、それと同様のオペレーティングシステムであってもよい。しかし、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ ＯＳ、 ＩＢＭ ＯＳ／２、Ｍｉｃｒｏｓｏｆｔ ＤＯＳ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） ２０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／ＮＴＡ／ｉｓｔａ／ＸＰ （Ｓｅｒｖｅｒ）、Ｐａｌｍ ＯＳなどのより限定的かつ／または低セキュアオペレーティングシステムが、採用されてもよい。オペレーティングシステムは、コンポーネントコレクションにおける他のコンポーネント（それ自身、及び／又はそれと同様のものを含む）に伝達及び／又は通信してもよい。オペレーティングシステムは、非常に頻繁に、他のプログラムコンポーネントやユーザインターフェースなどと通信する。例えば、オペレーティングシステムは、プログラムコンポーネント、システム、ユーザ、及び／又はデータの通信、要求及び／又は返答を包含、通信、生成、取得、及び／又は提供してもよい。オペレーティングシステムは、一度ＣＰＵで実行されれば、通信ネットワーク、データ、Ｉ／Ｏ、周辺デバイス、プログラムコンポーネント、メモリ、ユーザ入力デバイスなどとのインタラクションを可能にし得る。オペレーティングシステムは、制御部に、通信ネットワーク８１３を通じて他のエンティティとの通信を許可する通信プロトコルを提供してもよい。様々な通信プロトコルが、制御部によって、インタラクションの副搬送波の搬送機構（ＴＣＰ／ＩＰ、ＵＤＰ、ユニキャストなど（これらに限定されない））として使用されてもよい。

情報サーバ
情報サーバコンポーネント８１６は、ＣＰＵによって実行される、格納されたプログラムコンポーネントである。情報サーバは、従来のインターネット情報サーバ（Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ ＦｏｕｎｄａｔｉｏｎのＡｐａｃｈｅ、 ＭｉｃｒｏｓｏｆｔのＩｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒなど（これらに限定されない））であってもよい。情報サーバは、アクティブ・サーバ・ページ（ＡＳＰ）、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（Ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃及び／又は．ＮＥＴ、共通ゲートウェイ・インターフェース（ＣＧＩ）スクリプト、動的な（Ｄ）ハイパーテキスト・マークアップ言語（ＨＴＭＬ）、ＦＬＡＳＨ、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｒａｃｔｉｃａｌ Ｅｘｔｒａｃｔｉｏｎ Ｒｅｐｏｒｔ Ｌａｎｇｕａｇｅ（ＰＥＲＬ）、ハイパーテキストプリプロセッサ（ＰＨＰ）、ｐｉｐｅｓ、Ｐｙｔｈｏｎ、ワイヤレス・アプリケーション・プロトコル（ＷＡＰ）、ＷｅｂＯｂｊｅｃｔｓ、などのファシリティを通じてプログラムコンポーネントの実行を容認してもよい。情報サーバは、ファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、セキュア・ソケット・レイヤ（ＳＳＬ）、メッセージング・プロトコル（例えば、アメリカ・オンライン（ＡＯＬ）インスタントメッセンジャー（ＡＩＭ）、Ａｐｐｌｉｃａｔｉｏｎ Ｅｘｃｈａｎｇｅ（ＡＰＥＸ）、ＩＣＱ、インターネット・リレー・チャット（ＩＲＣ）、Ｍｉｃｒｏｓｏｆｔ Ｎｅｔｗｏｒｋ（ＭＳＮ）メッセンジャーサービス、Ｐｒｅｓｅｎｃｅ ａｎｄ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ（ＰＲＩＭ）、インターネット・エンジニアリング・タスク・フォース（ｌＥＴＦ）のセッション初期化プロトコル（ＳＩＰ）、ＳＩＰ ｆｏｒ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ （ＳＩＭＰＬＥ）、ｏｐｅｎ ＸＭＬ−ｂａｓｅｄ Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ（ＸＭＰＰ）（例えば、ＪａｂｂｅｒやＯｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ（ＯＭＡ）のＩｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｓｅｒｖｉｃｅ（ＩＭＰＳ））、Ｙａｈｏｏ！インスタントメッセンジャーサービスなど（これらに限定されない）のセキュア通信プロトコルをサポートしてもよい。情報サーバは、Ｗｅｂページの形式で結果をＷｅｂブラウザに提供し、他のプログラムコンポーネントとのインタラクションを通じてＷｅｂページの操作生成を可能にさせる。ＨＴＴＰ要求のドメイン・ネーム・システム（ＤＮＳ）解決部分が特定の情報サーバに解決された後、情報サーバは、ＨＴＴＰ要求の残りに基づいて、ＩＰＯＴ制御部で指定された位置に情報の要求を解決する。例えば、ｈｔｔｐ：／／１２３．１２４．１２５．１２６／ｍｙｌｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌなどの要求は、要求「１２３．１２４．１２５．１２６」（ＤＮＳサーバによってある情報サーバとしてそのＩＰアドレスで解決された）のＩＰ部分を有し、更に、情報サーバはその要求の「／ｍｙｌｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ」の部分についてのｈｔｔｐ要求を順に解析し、情報「ｍｙｌｎｆｏｒｍａｔｉｏｎ．ｈｔｍｌ」を含むメモリ内の位置として解決してもよい。加えて、他の情報供給プロトコルが、ＦＴＰ通信アクロスポート２１などの様々なポートで採用されてもよい。情報サーバは、それ自身を含むコンポーネントコレクション及び／又はそれと同様のファシリティにおける他のコンポーネントに伝達及び／又は通信を行ってもよい。非常に頻繁に、情報サーバは制御部データベース８１９、オペレーティングシステム、他のプログラムコンポーネント、ユーザインターフェース、Ｗｅｂブラウザなどと通信する。

データベースへのアクセスは、多くのデータベースブリッジ機構を通じて（以下に列挙されるスクリプト言語（例えば、ＣＧＩ）や以下に列挙されるアプリケーション間通信チャンネル（例えば、ＣＯＲＢＡ、ＷｅｂＯｂｊｅｃｔｓなどの）を通じて）達成されてもよい。ウェブブラウザを介するどのデータ要求も、ブリッジ機構を通じて制御部によって要求される適切な文法に構文解析される。ある実施例では、情報サーバは、ウェブブラウザによってアクセス可能なウェブ形式を供給するだろう。そのウェブ形式で提供されるフィールドになされた入力は、特定のフィールドに入れられたとタグ付けられ、解析される。次に、入力されたタームが、そのフィールドタグと共に送られる。フィールドタグは適当なテーブル及び／又はフィールドに対するクエリーを生成するように構文解析ツールに指示する。ある実施例では、タグ付けされたテキスト入力に基づいて適切なｊｏｉｎ／ｓｅｌｅｃｔ命令で検索文字列のインスタンスを作成することによって、構文解析ツールが標準ＳＱＬのクエリーを作成してもよい。結果命令は、ブリッジ機構を通じて制御部へクエリとして供給される。クエリーからクエリー結果を生成すると、その結果はブリッジ機構を通じて送られ、ブリッジ機構によって新しい結果ウェブページの生成とフォーマットのために構文解析されることが可能となる。そのような新しい結果ウェブページは、次に、要求されたウェブブラウザに提供し得る情報サーバに供給される。

また、情報サーバは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び／又は、提供してもよい。

ユーザインターフェース
コンピュータインターフェースは、幾つかの点で自動車操作インターフェースと類似している。ハンドル、ギアシフト、速度計などの自動車オペレーションインターフェース要素は、自動車資源および状態のアクセス、操作、表示を容易にする。チェックボックス、カーソル、メニュー、スクローラ、ウィンドウ（総合的かつ一般的にウィジェットと呼ばれている）などのコンピュータインタラクションインターフェース要素は、同様に、データ、コンピュータハードウェアおよびオペレーティングシステム資源、および状態のアクセス、機能、操作及び表示を容易にする。操作インターフェースは、一般に、ユーザインターフェースと呼ばれる。Ａｐｐｌｅ ＭａｃｉｎｔｏｓｈオペレーティングシステムのＡｑｕａ、ＩＢＭのＯＳ／２、ＭｉｃｒｏｓｏｆｔのＷｉｎｄｏｗｓ２０００／２００３／３．１／９５／９８／ＣＥ／Ｍｉｌｌｅｎｉｕｍ／ＮＴ／ＸＰ／Ｖｉｓｔａ／７（すなわち、エアロ）、ＵｎｉｘのＸ−Ｗｉｎｄｏｗｓ（例えば、Ｋデスクトップ環境（ＫＤＥ）、ｍｙｔｈＴＶ及びＧＮＵネットワークオブジェクトモデル環境（ＧＮＯＭＥ）を含んでもよい）、ウェブ・インターフェース・ライブラリ（例えば、ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、その他インターフェースライブラリ（Ｄｏｊｏ、ｊＱｕｅｒｙ（ＵＩ）、ＭｏｏＴｏｏｌｓ、Ｐｒｏｔｏｔｙｐｅ、 ｓｃｒｉｐｔ．ａｃｕｌｏ．ｕｓ、ＳＷＦＯｂｊｅｃｔ、Ｙａｈｏｏ！ユーザインターフェースなど（これらに限定されない）の使用され得るものいずれか）などのグラフィカル・ユーザ・インターフェースは、ベースラインと情報にアクセスおよび表示する手段を視覚的にユーザに提供する。

ユーザ・インターフェース・コンポーネント８１７は、ＣＰＵによって実行される、格納されたプログラムコンポーネントである。ユーザインターフェースは、既に議論したようなオペレーティングシステム及び／又は操作環境によって、それらと共に、及び／又は、それらの上に提供されるような、従来のグラフィックユーザインターフェースであってもよい。ユーザインターフェースは、テキスト式及び／又は図式的なファシリティを通じて、プログラムコンポーネント及び／又はシステムファシリティの表示、実行、インタラクション、操作、及び／又は、作動を可能にさせる。ユーザインターフェースは、ユーザがコンピュータシステムに影響を与え、相互作用し、かつ／または操作できるファシリティを提供する。ユーザインターフェースは、それ自体を含むコンポーネントコレクション及び／又は類似のファシリティにおける他のコンポーネントに伝達及び／又は通信してもよい。非常に頻繁に、ユーザインターフェースは、オペレーティングシステム、他のプログラムコンポーネントなどと通信する。ユーザインターフェースは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求及び／又は応答を包含、通信、生成、取得、及び／又は提供してもよい。

ウェブブラウザ
ウェブ・ブラウザ・コンポーネント８１８は、ＣＰＵによって実行される、格納されたプログラムコンポーネントである。ウェブブラウザは、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒやＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒなどの従来のハイパーテキスト閲覧アプリケーションでもよい。セキュアウェブブラウジングは、ＨＴＴＰＳ、ＳＳＬなどの方法によって１２８ビット（以上）の暗号化と共に提供されてもよい。ウェブブラウザは、ＡｃｔｉｖｅＸ、ＡＪＡＸ、（Ｄ）ＨＴＭＬ、ＦＬＡＳＨ、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、ウェブブラウザプラグインＡＰＩ（例えば、ＦｉｒｅＦｏｘ、Ｓａｆａｒｉプラグイン、及び／又は同様のＡＰＩ）などのファシリティを通じてプログラムコンポーネントの実行を可能にする。ウェブブラウザや類似の情報アクセスツールは、ＰＤＡ、携帯電話、及び／又は、他のモバイルデバイスに統合されてもよい。ウェブブラウザは、それ自体を含むコンポーネントコレクション、及び／又は同様のファシリティにおける他のコンポーネントに伝達及び／又は通信してもよい。非常に頻繁に、ウェブブラウザは、情報サーバ、オペレーティングシステム、統合プログラムコンポーネント（例えば、プラグイン）などと通信する。例えば、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求及び／又は応答を包含、通信、生成、取得、及び／又は提供してもよい。もちろん、ウェブブラウザと情報サーバに代わって、複合アプリケーションが同様の両方の機能を実行するように開発されてもよい。複合アプリケーションは、同様に、制御部が実行可能なノードからユーザ、ユーザ代理人等への情報の提供および取得に影響を及ぼすだろう。複合アプリケーションは、標準ウェブブラウザを使用するシステム上では無価値かもしれない。

メールサーバ
メールサーバコンポーネント８２１は、ＣＰＵ８０３によって実行される、格納されたプログラムコンポーネントである。メールサーバは、ｓｅｎｄｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ（これらに限定されない）などの従来のインターネットメールサーバでもよい。メールサーバは、ＡＳＰ、ＡｃｔｉｖｅＸ、（ＡＮＳＩ）（ｏｂｊｅｃｔｉｖｅ−）Ｃ（＋＋）、Ｃ＃及び／又は．ＮＥＴ、ＣＧＩスクリプト、Ｊａｖａ、ＪａｖａＳｃｒｉｐｔ、Ｐｅｒｌ、ＰＨＰ、ｐｉｐｅｓ、Ｐｙｔｈｏｎ、ＷｅｂＯｂｊｅｃｔｓなどのファシリティを通じてプログラムコンポーネントの実行を可能にする。メールサーバは、インターネット・メッセージ・アクセス・プロトコル（ＩＭＡＰ）、メッセージング・アプリケーション・プログラミング・インターフェース（ＭＡＰＩ）／Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ、ポスト・オフィス・プロトコル（ＰＯＰ３）、シンプルメールトランスファープロトコル（ＳＭＴＰ）など（これらに限定されない）の通信プロトコルを提供してもよい。メールサーバは、送信された、中継された、及び／または、制御部を通じて及び／又は制御部に移動する受発信メールメッセージのルートを決め、送信し、処理することができる。

メールへのアクセスは、個々のウェブサーバコンポーネント、及び／又は、オペレーティングシステムによって提供された多くのＡＰＩを通じて成されてもよい。

また、メールサーバは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、情報、及び／又は応答を包含、通信、生成、取得、及び／又は、提供してもよい。

メールクライアント
メールクライアントコンポーネント８２２は、ＣＰＵ８０３によって実行される、格納されたプログラムコンポーネントである。メールクライアントは、Ａｐｐｌｅ Ｍａｉｌ、Ｍｉｃｒｏｓｏｆｔ Ｅｎｔｏｕｒａｇｅ、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ、 Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ、Ｍｏｚｉｌｌａ、Ｔｈｕｎｄｅｒｂｉｒｄなどの従来のメール閲覧アプリケーションであってもよい。メールクライアントは、ＩＭＡＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｈａｎｇｅ、ＰＯＰ３、ＳＭＴＰなどの多くの転送プロトコルをサポートしてもよい。メールクライアントはそれ自体及び／又は同様のファシリティを含むコンポーネントコレクションにおける他のコンポーネントに伝達、及び／又は、通信してもよい。非常に頻繁に、メールクライアントは、メールサーバ、オペレーティングシステム、他のメールクライアントなどと通信する。例えば、それは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び／又は提供してもよい。一般に、メールクライアントは、電子メールメッセージを構成及び送信するファシリティを提供する。

暗号サーバ
暗号サーバコンポーネント８２０は、ＣＰＵ８０３、暗号プロセッサ８２６、暗号プロセッサインターフェース８２７、暗号プロセッサデバイス８２８などによって実行される、格納されたプログラムコンポーネントである。暗号プロセッサインターフェースは、暗号コンポーネントによる暗号化及び／又は解読要求の迅速化を可能にするが、代わりに暗号コンポーネントは従来のＣＰＵで起動してもよい。暗号コンポーネントは、提供されたデータの暗号化、及び／又は、復号化を可能にする。暗号コンポーネントは、対称及び非対称的な（例えば、Ｐｒｅｔｔｙ Ｇｏｏｄ Ｐｒｏｔｅｃｔｉｏｎ（ＰＧＰ））暗号化及び／又は複合化の両方を可能にする。暗号コンポーネントは、デジタル証明（例えば、Ｘ．５０９認証フレームワーク）、デジタル署名、デュアル署名、エンベローピング、パスワードアクセス保護、公開鍵管理などの（これらに限定されない）暗号技術を採用してもよい。暗号コンポーネントは、チェックサム、データ暗号化標準（ＤＥＳ）、楕円暗号曲線（ＥＣＣ）、国際データ暗号化アルゴリズム（ＩＤＥＡ）、メッセージダイジェスト５（一方向ハッシュ関数であるＭＤ５）、パスワード、Ｒｉｖｅｓｔ Ｃｉｐｈｅｒ（ＲＣ５）、ラインドール、ＲＳＡ（１９７７年にロン・ライベスト、アディ・シャミルおよびレオナルド・アデルマンによって開発されたアルゴリズムを使用するインターネット暗号化及び認証システム）、セキュアハッシュアルゴリズム（ＳＨＡ）、セキュアソケットレイア（ＳＳＬ）、セキュア・ハイパーテキスト転送プロトコル（ＨＴＴＰＳ）などの（これらに限定されない）多数の（暗号化及び／又は復号化）セキュリティプロトコルを支援する。そのような暗号化セキュリティプロトコルを使用すると、ＩＰＯＴは全ての受信及び／又は発信通信を暗号化することが可能となり、仮想私設ネットワーク（ＶＰＮ）内のノードとして、より広い通信ネットワークを提供することができる。暗号コンポーネントは、資源へのアクセスがセキュリティプロトコルによって禁止される「セキュリティ承認」の処理を促進する。暗号コンポーネントは、保護された資源への承認されたアクセスを可能にする。また、暗号コンポーネントは、コンテンツの独自の識別子を提供してもよい、例えば、デジタルオーディオファイルに対して独自の署名を取得するＭＤ５ハッシュを採用する。暗号コンポーネントは、それ自体及び／又は同様のファシリティを含むコンポーネントコレクションにおける他のコンポーネントに伝達、及び／又は通信してもよい。暗号コンポーネントは、希望されれば安全な取引につながる制御コンポーネントを可能にする通信ネットワークにわたって情報の安全な送信を可能にする、暗号化方式をサポートする。暗号コンポーネントは、制御部で資源の安全なアクセスを容易にし、リモートシステムで保護された資源のアクセスを容易にする。すなわち、それは保護された資源のクライアント及び／又はサーバとして働いてもよい。非常に頻繁に、暗号コンポーネントは、情報サーバ、オペレーティングシステム、他のプログラムコンポーネントなどと通信する。暗号コンポーネントは、プログラムコンポーネント、システム、ユーザ、及び／又は、データ通信、要求、及び／又は、応答を包含、通信、生成、取得、及び／又は、提供してもよい。

データベース
データベースコンポーネント８１９は、データベースとその格納データで具体化されてもよい。データベースは、ＣＰＵによって実行される格納されたプログラムコンポーネントであり、格納されたプログラムコンポーネント部分は格納データを処理するＣＰＵを構成する。データベースは、オラクルまたはＳｙｂａｓｅなどの従来の、耐障害性の、相関的な、拡張可能な、安全なデータベースでもよい。リレーショナルデータベースは、フラットファイルの拡張である。リレーショナルデータベースは一連の関連テーブルからなる。テーブルはキーフィールドを介して相互接続される。キーフィールドの使用は、キーフィールドについてインデックスをつけることでテーブルの結合を可能にする。すなわち、キーフィールドは、様々なテーブルからの情報を結合するディメンジョナルピボットポイントとして作用する。関係は、一般に、主キーを一致させることによってテーブル間で保持されたリンクを特定する。主キーは、リレーショナルデータベースにおけるテーブルの列を独立して特定するフィールドを示す。より正確には、それらは一対多の関係の「一」側でテーブルの列を独立して特定する。

代替的に、データベースは、アレイ、ハッシュ、（リンクされた）リスト、構造体、構造化テキストファイル（例えば、ＸＭＬ）、テーブルなどの様々な標準データ構造を使用して実装されてもよい。そのようなデータ構造は、メモリ及び／又は（構造化された）ファイルに格納されてもよい。別の代替例においては、Ｆｒｏｎｔｉｅｒ、ＯｂｊｅｃｔＳｔｏｒｅ、Ｐｏｅｔ、Ｚｏｐｅなどのオブジェクト指向データベースが使用されてもよい。オブジェクトデータベースは、共通の属性によってグループ化、及び／又は、リンク付けされた多くのオブジェクトコレクションを含むことができる。それらは、幾つかの共通の属性によって他のオブジェクトコレクションに関連付けられてもよい。オブジェクト指向データベースは、オブジェクトがデータの単なる断片ではなく既定のオブジェクト内でカプセル化された他の種類の機能性を有してもよい点を除いて、リレーショナルデータベースと同様に働く。データベースがデータ構造として実装されるなら、データベース８１９の使用は制御コンポーネント８３５などの他のコンポーネントに統合されてもよい。また、データベースは、データ構造、オブジェクト、および関係構造の組み合わせとして実装されてもよい。データベースは、標準データ処理技術を通じて無数のバリエーションで集約及び／又は分散され得る。データベースの部分（例えば、テーブル）は、エクスポート及び／又はインポートされてもよく、上に述べたように分散、及び／又は、統合されてもよい。

ある実施例において、データベース要素８１９は数個のテーブル８１９ａ〜ｊを有する。ユーザテーブル８１９ａは、ｕｓｅｒ＿ｉｄ、ａｐｐｌｉｃａｎｔ＿ｉｄ、ｆｉｒｓｔｎａｍｅ、ｌａｓｔｎａｍｅ、ａｄｄｒｅｓｓ＿ｌｉｎｅ１、ａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｄｏｂ、ｓｓｎ、ｃｒｅｄｉｔ＿ｃｈｅｃｋ＿ｆｌａｇ、ｚｉｐｃｏｄｅ、ｃｉｔｙ、ｓｔａｔｅ、ａｃｃｏｕｎｔ＿ｐａｒａｍｓ＿ｌｉｓｔ、ａｃｃｏｕｎｔ＿ｍｏｄｅ、ａｃｃｏｕｎｔ＿ｔｙｐｅ、ａｃｃｏｕｎｔ＿ｅｘｐｉｒｙ、ｐｒｅｆｅｒｒｅｄ＿ｂａｎｋ＿ｎａｍｅ、ｐｒｅｆｅｒｒｅｄ＿ｂｒａｎｃｈ＿ｎａｍｅ、ｃｒｅｄｉｔ＿ｒｅｐｏｒｔなどのフィールドを含むことができるが、これらに限定されるものではない。ユーザテーブル８１９ａは、制御部で、複数入力口座をサポート、及び／又は、追跡記録してもよい。クライアントテーブル８１９ｂは、ｃｌｉｅｎｔ＿ＩＤ、ｃｌｉｅｎｔ＿ｔｙｐｅ、ｃｌｉｅｎｔ＿ＭＡＣ、ｃｌｉｅｎｔ＿ＩＰ、ｐｒｅｓｅｎｔａｔｉｏｎ＿ｆｏｒｍａｔ、ｐｉｘｅｌ＿ｃｏｕｎｔ、ｒｅｓｏｌｕｔｉｏｎ、ｓｃｒｅｅｎ＿ｓｉｚｅ、ａｕｄｉｏ＿ｆｉｄｅｌｉｔｙ、ｈａｒｄｗａｒｅ＿ｓｅｔｔｉｎｇｓ＿ｌｉｓｔ、ｓｏｆｔｗａｒｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｉｅｓ＿ｌｉｓｔ、ｉｎｓｔａｌｌｅｄ＿ａｐｐｓ＿ｌｉｓｔなどのフィールドを含んでもよいが、これらに限定されるものではない。アプリテーブル８１９ｃは、ａｐｐ＿ＩＤ、ａｐｐ＿ｎａｍｅ、ａｐｐ＿ｔｙｐｅ、ＯＳ＿ｃｏｍｐａｔｉｂｉｌｉｔｉｅｓ＿ｌｉｓｔ、ｖｅｒｓｉｏｎ、ｔｉｍｅｓｔａｍｐ、ｄｅｖｅｌｏｐｅｒ＿ＩＤなどのフィールドを含んでもよいが、これらに限定されるものではない。販売者テーブル８１９ｄは、ｍｅｒｃｈａｎｔ＿ｉｄ、ｍｅｒｃｈａｎｔ＿ｎａｍｅ、ｐｒｏｖｉ ｍｅｒｃｈａｎｔ＿ａｄｄｒｅｓｓ、ｉｐ＿ａｄｄｒｅｓｓ、ｍａｃ＿ａｄｄｒｅｓｓ、ａｕｔｈ＿ｋｅｙ、ｐｏｒｔ＿ｎｕｍ、ｓｅｃｕｒｉｔｙ＿ｓｅｔｔｉｎｇｓ＿ｌｉｓｔなどのフィールドを含んでもよいが、これらに限定されるものではない。イシュアテーブル８１９ｅは、ａｃｃｏｕｎｔ＿ｆｉｒｓｔｎａｍｅ、ａｃｃｏｕｎｔ＿ｌａｓｔｎａｍｅ、ａｃｃｏｕｎｔ＿ｔｙｐｅ、ａｃｃｏｕｎｔ＿ｎｕｍ、ａｃｃｏｕｎｔ＿ｂａｌａｎｃｅ＿ｌｉｓｔ、ｂｉｌｌｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ１、ｂｉｌｌｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｂｉｌｌｉｎｇ＿ｚｉｐｃｏｄｅ、ｂｉｌｌｉｎｇ＿ｓｔａｔｅ、ｓｈｉｐｐｉｎｇ＿ｐｒｅｆｅｒｅｎｃｅｓ、ｓｈｉｐｐｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ１、ｓｈｉｐｐｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｓｈｉｐｐｉｎｇ＿ｚｉｐｃｏｄｅ、ｓｈｉｐｐｉｎｇ＿ｓｔａｔｅ、ｉｓｓｕｅｒ＿ｉｄ、ｉｓｓｕｅｒ＿ｎａｍｅ、ｉｓｓｕｅｒ＿ａｄｄｒｅｓｓ、ｉｐ＿ａｄｄｒｅｓｓ、ｍａｃ＿ａｄｄｒｅｓｓ、ａｕｔｈ＿ｋｅｙ、ｐｏｒｔ＿ｎｕｍ、ｓｅｃｕｒｉｔｙ＿ｓｅｔｔｉｎｇｓ＿ｌｉｓｔなどのフィールドを含んでもよいが、これらに限定されるものではない。アクワイアラテーブル８１９ｆは、ａｃｃｏｕｎｔ＿ｆｉｒｓｔｎａｍｅ、ａｃｃｏｕｎｔ＿ｌａｓｔｎａｍｅ、ａｃｃｏｕｎｔ＿ｔｙｐｅ、ａｃｃｏｕｎｔ＿ｎｕｍ、ａｃｃｏｕｎｔ＿ｂａｌａｎｃｅ＿ｌｉｓｔ、ｂｉｌｌｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ１、ｂｉｌｌｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｂｉｌｌｉｎｇ＿ｚｉｐｃｏｄｅ、ｂｉｌｌｉｎｇ＿ｓｔａｔｅ、ｓｈｉｐｐｉｎｇ＿ｐｒｅｆｅｒｅｎｃｅｓ、ｓｈｉｐｐｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ１、ｓｈｉｐｐｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｓｈｉｐｐｉｎｇ＿ｚｉｐｃｏｄｅ、ｓｈｉｐｐｉｎｇ＿ｓｔａｔｅなどのフィールドを含んでもよいが、これらに限定されるものではない。元帳テーブル８１９ｇは、ｒｅｑｕｅｓｔ＿ｉｄ、ｔｉｍｅｓｔａｍｐ、ｄｅｐｏｓｉｔ＿ａｍｏｕｎｔ、ｂａｔｃｈ＿ｉｄ、ｔｒａｎｓａｃｔｉｏｎ＿ｉｄ、ｃｌｅａｒ＿ｆｌａｇ、ｄｅｐｏｓｉｔ＿ａｃｃｏｕｎｔ、ｔｒａｎｓａｃｔｉｏｎ＿ｓｕｍｍａｒｙ、ｐａｙｏｒ＿ｎａｍｅ、ｐａｙｏｒ＿ａｃｃｏｕｎｔなどのフィールドを含んでもよいが、これらに限定されるものではない。取引テーブル８１９ｈは、ｏｒｄｅｒ＿ｉｄ、ｕｓｅｒ＿ｉｄ、ｔｉｍｅｓｔａｍｐ、ｔｒａｎｓａｃｔｉｏｎ＿ｃｏｓｔ、ｐｕｒｃｈａｓｅ＿ｄｅｔａｉｌｓ＿ｌｉｓｔ、ｎｕｍ＿ｐｒｏｄｕｃｔｓ、ｐｒｏｄｕｃｔｓ＿ｌｉｓｔ、ｐｒｏｄｕｃｔ＿ｔｙｐｅ、ｐｒｏｄｕｃｔ＿ｐａｒａｍｓ＿ｌｉｓｔ、ｐｒｏｄｕｃｔ＿ｔｉｔｌｅ、ｐｒｏｄｕｃｔ＿ｓｕｍｍａｒｙ、ｑｕａｎｔｉｔｙ、ｕｓｅｒ＿ｉｄ、ｃｌｉｅｎｔ＿ｉｄ、ｃｌｉｅｎｔ＿ｉｐ、ｃｌｉｅｎｔ＿ｔｙｐｅ、ｃｌｉｅｎｔ＿ｍｏｄｅｌ、ｏｐｅｒａｔｉｎｇ＿ｓｙｓｔｅｍ、ｏｓ＿ｖｅｒｓｉｏｎ、ａｐｐ＿ｉｎｓｔａｌｌｅｄ＿ｆｌａｇ、ｕｓｅｒ＿ｉｄ、ａｃｃｏｕｎｔ＿ｆｉｒｓｔｎａｍｅ、ａｃｃｏｕｎｔ＿ｌａｓｔｎａｍｅ、ａｃｃｏｕｎｔ＿ｔｙｐｅ、ａｃｃｏｕｎｔ＿ｎｕｍ、ｂｉｌｌｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ１、ｂｉｌｌｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｂｉｌｌｉｎｇ＿ｚｉｐｃｏｄｅ、ｂｉｌｌｉｎｇ＿ｓｔａｔｅ、ｓｈｉｐｐｉｎｇ＿ｐｒｅｆｅｒｅｎｃｅｓ、ｓｈｉｐｐｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ１、ｓｈｉｐｐｉｎｇａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｓｈｉｐｐｉｎｇ＿ｚｉｐｃｏｄｅ、ｓｈｉｐｐｉｎｇ＿ｓｔａｔｅ、ｍｅｒｃｈａｎｔ＿ｉｄ、ｍｅａｒｃｈａｎｔ＿ｎａｍｅ、ｍｅｒｃｈａｎｔ＿ａｕｔｈ＿ｋｅｙなどのフィールドを含んでもよいが、これらに限定されるものではない。バッチテーブル８１９ｉは、ａｐｐｌｉｃａｎｔ＿ｆｉｒｓｔｎａｍｅ、ａｐｐｌｉｃａｎｔ＿ｌａｓｔｎａｍｅ、ａｐｐｌｉｃａｎｔ＿ａｄｄｒｅｓｓ＿ｌｉｎｅ１、ａｐｐｌｉｃａｎｔ＿ａｄｄｒｅｓｓ＿ｌｉｎｅ２、ｃｏｎｓｕｍｅｒ＿ｂｕｒｅａｕ＿ｄａｔａ＿ｌｉｓｔ、ｃｏｎｓｕｍｅｒ＿ｂｕｒｅａｕ＿ｄａｔａ、ａｐｐｌｉｃａｎｔ＿ｃｌｅａｒ＿ｆｌａｇ、ｃｒｅｄｉｔ＿ｌｉｍｉｔ、ｃｒｅｄｉｔ＿ｓｃｏｒｅ、ａｃｃｏｕｎｔ＿ｂａｌａｎｃｅｓ、ｄｅｌｉｎｑｕｅｎｃｙ＿ｆｌａｇ、ｑｕａｌｉｔｙ＿ｆｌａｇｓ、ｂａｔｃｈ＿ｉｄ、ｔｒａｎｓａｃｔｉｏｎ＿ｉｄ＿ｌｉｓｔ、ｔｉｍｅｓｔａｍｐ＿ｌｉｓｔ、ｃｌｅａｒｅｄ＿ｆｌａｇ＿ｌｉｓｔ、ｃｌｅａｒａｎｃｅ＿ｔｒｉｇｇｅｒ＿ｓｅｔｔｉｎｇｓなどのフィールドを含んでもよいが、これらに限定されるものではない。提供テーブル８１９ｊは、ｏｆｆｅｒ＿ｉｄ、ｏｆｆｅｒ＿ｎａｍｅ、ｏｆｆｅｒ−ｂｙｌｉｎｅ、ｍａｅｒｃｈａｎｔ＿ｉｄ、ｐｒｏｄｕｃｔ＿ｉｄ、ｏｆｆｅｒ＿ｄｅｔａｉｌ＿ｌｉｓｔ、ｏｆｆｅｒ＿ｅｘｐｉｒｙ＿ｄａｔｅなどのフィールドを含んでもよいが、これらに限定されるものではない。

ある実施例では、データベースは他のデータベースシステムと相互に作用してもよい。例えば、分散データベースシステムを使用する場合、検索制御部コンポーネントによるクエリーおよびデータアクセスが、データベースと単一データベースエンティティとしての統合データセキュリティレイヤデータベースの組み合わせを取り扱ってもよい。

ある実施例においては、ユーザプログラムは、制御部を更新する機能を有する様々なユーザインターフェース・プリミティブを含んでもよい。また、様々なアカウントが、制御部が仕えるクライアントの種類と環境に依存するカスタムデータベーステーブルを必要とするかもしれない。いずれの固有フィールドも、終始キーフィールドとして指定されてもよいことに留意すべきである。代替的な実施例においては、これらのテーブルは、それら自身のデータベースとそれらのそれぞれのデータベース制御部（即ち、上記テーブルの各々対する個々のデータベース制御部）に分散されている。標準データ処理技術を採用する場合、幾つかのコンピュータ構成、及び／又は、ストレージデバイスでデータベースを更に分散してもよい。同様に、分散データベース制御部の構成が、様々なデータベースコンポーネント８１９ａ〜ｊを統合及び／又は分散することによって、変更されてもよい。制御部は、データベース制御部を介して、各種設定、入力およびパラメータの経過を追うように構成されてもよい。

データベースは、それ自身及び／又は類似のファシリティを含むコンポーネントコレクションにおける他のコンポーネントに伝達、及び／又は、通信してもよい。非常に頻繁に、データベースは、制御部コンポーネント、他のプログラムコンポーネントなどと通信する。データベースは、他のノードとデータに関する情報を包含、保持、及び提供してもよい。

制御部
制御部コンポーネント８３５は、ＣＰＵによって実行される、格納されたプログラムコンポーネントである。ある実施例では、制御部コンポーネントは、前述の図面で説明した制御部の側面のいくつか及び／又は全てを組み込む。そのように、制御部は、様々な通信ネットワークを介して、情報、サービス、取引などのアクセス、取得および提供に影響を与える。

制御部コンポーネントは、制御部コンポーネントを介する製品コードスナップショットを、リアルタイム提供駆動電子購入取引通知などと制御部の使用に変えてもよい。ある実施例では、制御部コンポーネント８３５は、入力（例えば、製品識別子４０１、購入指示（４１０参照）、製品識別子およびユーザ識別子５０１、購入入力６１１、イシュアサーバデータ６２０、ユーザデータ６２５、バッチデータ６３９、イシュアサーバデータ６４７など）等を要し、様々なコンポーネント（例えば、ｍＰＰＴコンポーネント８４１、ＰＯＳコンポーネント８４２、ＣＴＥコンポーネント８４３など）を介した上記入力を、出力（例えば、製品情報表示部４０５、購入確認表示部４２５、そのままの製品情報５３０、製品情報およびプロモーション情報５３５、購入確認領収書５７０、承認メッセージ６２７、取引データ６３０、承認メッセージ６３１〜６３２、バッチ付加データ６３４、購入領収書６３５、取引データ６４５、資金振替メッセージ６５２〜６５３など）に変換する。

ノード間の情報のアクセスを可能とする制御部コンポーネントは、標準開発ツール及び言語を使用することで開発されてもよい。ある実施例では、制御部サーバは、通信を暗号化する復号化及び暗号サーバを採用する。制御部コンポーネントは、それ自身、及び／又は同様のファシリティを含むコンポーネントコレクションにおける他のコンポーネントに伝達、及び又は通信してもよい。非常に頻繁に、制御部コンポーネントは、制御部データベース、オペレーティングシステム、他のプログラムコンポーネントなどと通信する。制御部、プログラムコンポーネント、システム、ユーザ、及び又は、データ通信、要求、及び／又は、返答を包含、通信、生成、取得、及び／又は提供してもよい。

分散制御部
ノード制御部コンポーネントのいずれかの構造及び／又は作用は、開発及び／又は配置を容易にする幾つかの方法で結合、統合、及び／又は、分散されるようにしてもよい。同様に、コンポーネントコレクションは、開発及び／又は配置を容易にする幾つかの方法で結合されてもよい。これを達成するために、コンポーネントを、共通のコードベースに統合したり、統合された方法で必要に応じて動的にコンポーネットをロードできるファシリティに統合したりできる。

コンポーネントコレクションは、標準データ処理及び／又は開発技術を通じて無数のバリエーションで集約及び／又は分散され得る。プログラムコンポーネントコレクションにおけるいずれか一つのプログラムコンポーネントの多数のインスタンスは、負荷バランス及び／又はデータ処理技術を通じてパフォーマンスを向上する単一のノード、及び／又は多数のノードで作成されてもよい。更に、一つのインスタンスが、複数の制御部及び／又は記憶装置（例えば、データベース）で分散されてもよい。一斉に稼働する、全てのプログラムコンポーネントインスタンス及び制御部は、標準データ処理通信技術を通じて成されてもよい。

制御部の構成は、システム開発の状況に依存するだろう。予算、容量、位置、及び／又は基底ハードウェア資源の使用などの（これらに限定されない）要因は、配置要件と構成に影響を与えるかもしれない。構成がより整理及び／又は統合されたプログラムコンポーネントになるか、より分散された一連のプログラムコンポーネントになるか、及び／又は、統合および分散された構成の幾つかの組み合わせとなるかに関わらず、データは通信、取得、及び／又は、提供されてもよい。プログラムコンポーネントコレクションから共通コードベースに統合されたコンポーネントのインスタンスは、データを通信、取得、及び／又は、提供してもよい。これは、データレフェレンシング（例えば、ポインタ）、内部メッセージング、オブジェクトインスタンス変数通信、共有メモリスペース、変数交換などの（これらに限定されない）アプリケーション内データ処理通信技術を通じて成されてもよい。

コンポーネント・コレクション・コンポーネントが互いに個別、別個、及び／又は、外部にあるならば、データを他のコンポーネントとの間で、送受信、取得、及び／又は提供することは、アプリケーション・プログラム・インターフェース（ＡＰＩ）情報経過、（分散）コンポーネントオブジェクトモデル（（Ｄ）ＣＯＭ）、（分散）オブジェクトのリンクと埋め込み（（Ｄ）ＯＬＥ）など）、共通オブジェクト・リクエスト・ブローカー・アーキテクチャ（ＣＯＲＢＡ）、ジニーローカル及びリモート・アプリケーション・プログラム・インターフェース、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ （ＳＯＮ）、遠隔メソッド呼び出し（ＲＭＩ）、ＳＯＡＰ、プロセスパイプ、共有ファイルなどの（これらに限定されない）アプリケーション内データ処理通信技術を通じて達成されてもよい。アプリケーション内通信についての個別部品コンポーネント間、又はアプリケーション内通信についての単一コンポーネントのメモリスペース内で送信されるメッセージは、文法の作成と解析を通じて簡易にされ得る。文法は、文法生成及び機能解析を可能にするｌｅｘ、ｙａｃｃ、ＸＭＬなどの開発ツールを使用して開発されてもよく、それは次々にコンポーネント内およびコンポーネント間で通信メッセージの基礎を形成し得る。

図９は、ある実施例に従ったプロセスのフローチャートである。プロセス９００は、コンピュータ又は他の装置によって実行可能である。動作９０１において、潜在的な購入品の製品識別子が、モバイルデバイスにより小売店での製品識別子の本人による撮影によって取得され、動作９０２において、潜在的な購入品の価格が、その小売店と関係付けられたデータベースから決定される。動作９０３において、潜在的な購入品を購買者の口座に課金する購買者からの同意を表すインターフェース要素（例えば、ボタン）が、モバイルデバイス上に表示される。動作９０４において、第１のリスクスコアが、潜在的な購入品の価格に基づいて算出される。動作９０５において、第１のリスクスコアが閾値と比較される。動作９０６において、第１のリスクスコアと閾値との比較に基づいて、購買者とカスタマーサービス係のビデオチャットセッションを開始するインターフェース要素を有するメッセージがサーバからモバイルデバイスに送信される。動作９０７において、購買者によるメッセージにおけるインターフェース要素の選択に基づいて、ビデオチャットセッションが開始される。動作９０８において、第１のリスクスコアとビデオチャットセッションの開始に基づいて、第２のリスクスコアが算出される。動作９０９において、当該品物の承認された購入についての電子領収書が、モバイルデバイスで受信される。

図１０は、ある実施例に従ったプロセスのフローチャートである。プロセス１０００は、コンピュータ又は他の装置によって実行可能である。動作１００１において、小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影に基づいて、潜在的な購入品の製品識別子が取得される。動作１００２において、潜在的な購入品に対し、小売店に関係付けられた販売者が識別される。動作１００３において、潜在的な購入品の価格が、販売者に基づいて決定される。動作１００４において、モバイルデバイスを使用して、当該品物を購入する購買者からの同意が取得される。動作１００５において、モバイルデバイスを使用して、購買者の同意に基づく潜在的な購入品に対する、識別された販売者との購入取引が開始される。動作１００６において、販売者検証可能コードを有する、購入取引に基づく電子領収書がモバイルデバイスで受信される。動作１００７において、モバイルデバイスが小売店のリーダに近接している間に、モバイルデバイスから検証可能コードが作成される（例えば、表示、無線送信される）。動作１００８において、検証可能コードが有効である旨の表示が受信され、購買者が当該品物を持って小売店を出るのを許可する。

図１１は、ある実施例に従ったプロセスのフローチャートである。プロセス１１００は、コンピュータ又は他の装置によって実行可能である。動作１１０１において、小売店で購買者のモバイルデバイスによって製品識別子の本人による撮影に基づいて、潜在的な購入品の製品識別子が取得される。動作１１０２において、潜在的な購入品の価格が決定される。動作１１０３において、購買者の口座に課金する同意が購買者から受信される。動作１１０４において、購買者の口座に品物の購入が課金される。動作１１０５において、口座課金が成功した旨の表示が受信される。動作１１０６において、領収された旨の表示に基づいて、検証可能コードを有する電子領収書が生成される。動作１１０７において、購買者のモバイルデバイスに、電子領収書が送信される。動作１１０８において、検証可能コードが、モバイルデバイスから読み取られる。動作１１０９において、モバイルデバイスから読み取られた検証可能コードが有効であると検証される。動作１１１０において、購買者が品物を持って小売店を出るのを許可するために、検証可能コードが有効である旨の表示が送信される。

図１２は、ある実施例に従ったプロセスのフローチャートである。プロセス１２００は、コンピュータ又は他の装置によって実行可能である。動作１２０１において、購買者の第１の支払口座から販売者への支払いに対するアクワイアラからの承認要求が領収される。動作１２０２において、承認要求の受信に基づいて、購買者に関係付けられた第２の支払口座を使う提案が決定される（例えば、購買者のイシュアの中でオークションされる）。動作１２０３において、決定された提案が購買者に送信される。動作１２０４において、当該提案の選択が購買者から受信される。動作１２０５において、購買者の第２の支払口座からの支払いを要求するために、承認要求が修正される。動作１２０６において、修正された承認要求が、第２の支払口座に関係付けられたイシュアに送信される。

図１３は、ある実施例に従ったプロセスのフローチャートである。プロセス１３００は、コンピュータ又は他の装置によって実行可能である。動作１３０１において、第１の承認要求が、購買者の支払口座から第１の販売者への支払に対してアクワイアラから受信される。動作１３０２において、購入予定の品物の製品識別子が領収される。動作１３０３において、第１の承認要求の受信と受信した製品識別子に基づいて第２の販売者からの競合品の提案が決定される。動作１３０４において、提案が購買者に送信される。動作１３０５において、提案の選択が購買者から受信される。動作１３０６において、受信された選択に基づいて、第１の承認要求が取り消される。動作１３０７において、購買者の支払口座から、当該提案の第２の販売者への支払に対する第２の承認要求が生成される。動作１３０８において、第２の承認要求が、支払口座に関係付けられたイシュアに送信される。

図１４は、ある実施例に従ったプロセスのフローチャートである。プロセス１４００は、コンピュータ又は他の装置によって実行可能である。動作１４０１において、小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影によって、潜在的な購入品の製品識別子が取得される。動作１４０２において、潜在的な購入品の価格が決定される（例えば、データベースから調べられる）。動作１４０３において、購買者の口座に課金をする同意が購買者から受信される。動作１４０４において、当該口座に品物の購入が課金される。動作１４０５において、当該口座の課金が成功した旨の表示が受信される。動作１４０６において、品物が自由に小売店から出られる旨の表示が盗難防止システムに送信される。動作１４０７において、販売者検証可能コードを有する電子領収書がモバイルデバイスに送信される。

上述したように、本発明は、コンピュータソフトウェアをモジュール又は統合された方式で使用する制御論理形式で実行されてもよいことを留意すべきである。ここで提供された開示と教示に基づいて、当業者は、ハードウェアやハードウェアとソフトウェアの組み合わせを使用して本発明を実行する他の方法及び／又は手法を理解するだろう。

ソフトウェアのコンポーネントやこのアプリケーションで表現される機能のいずれもが、例えば、Ｊａｖａ、Ｃ＋＋やＰｅｒｌ（例えば、従来の又はオブジェクト指向の技術）などの幾つかの適切なコンピュータ言語を使用して、プロセッサで実行されるソフトウェアコードとして実行されてもよい。ソフトウェアコードは、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、磁気媒体（ハードドライブやフロッピー（登録商標）ディスクなど）、光学媒体（ＣＤ−ＲＯＭなど）などのコンピュータ読取可能な媒体で、一連の指示や命令として保存されてもよい。そのような読取可能な媒体のいずれも、一つのコンピュータによる装置上又は装置内に備えられてもよく、システムやネットワーク内の異なるコンピュータによる装置上又は装置内にあってもよい。

本説明は、例示的で制限的ではない。本発明の多くの変形例が、上記開示を検討すれば、当業者に明らかになるだろう。従って、本発明の範囲は、本説明を参照して決定されるべきでなく添付のクレーム（それらの最大の範囲または均等物）を参照して決定されるべきである。

ある実施例からの一つ以上の特徴は、本発明の範囲から逸脱せずに、どの他の実施例の一つ以上の特徴と組み合わされてもよい。

「ａ」、「ａｎ」、又は「ｔｈｅ」の記述は、特にそうでないと指示しない限り、「ｏｎｅ ｏｒ ｍｏｒｅ」を意味することを意図している。

全ての特許、特許出願、公報、及び上述の説明は、全ての目的に対してその内容全体を参考として本明細書に組み込まれる。いずれも従来技術とは認められない。

Claims (40)

1. 小売店で製品識別子の本人による撮影に基づいて潜在的な購入品の前記製品識別子をモバイルデバイスによって取得し、
   前記小売店に関係付けられたデータベースから前記潜在的な購入品の値段を決定し、
   前記潜在的な購入品を購買者の口座に課金する購買者からの同意を表示するように構成されたインターフェース要素を前記モバイルデバイス上に表示し、
   前記潜在的な購入品の価格に基づいて第１のリスクスコアを算出し、
   前記第１のリスクスコアを閾値に比較し、
   前記第１のリスクスコアの前記閾値との比較に基づいて、前記購買者とカスタマーサービス係とのビデオチャットセッションを開始するように構成されたインターフェース要素を含むメッセージを前記モバイルデバイスへ少なくとも一つのサーバから送信し、
   前記購買者による前記メッセージの前記インターフェース要素の選択に基づいてビデオチャットセッションを開始し、
   前記第１のリスクスコアと前記ビデオチャットセッションの開始に基づいて第２のリスクスコアを算出し、
   前記購入品の承認された購入に対する電子領収書を前記モバイルデバイスで受信する、ことを特徴とする方法。
2. 販売者検証可能コードを有する電子領収書を前記モバイルデバイスに送信する、
   ことを更に有することを特徴とする請求項１に記載の方法。
3. 前記モバイルデバイスから前記検証可能コードを読み取り、
   前記検証可能コードが有効であることを検証し、
   前記検証に基づいて、前記検証可能コードが有効である旨の表示を送信する、
   こと更に有することを特徴とする請求項２に記載の方法。
4. 前記検証可能コードは、バーコード、二次元バーコード、ＱＲコード(R)二次元コードからなるグループから選択される、ことを特徴とする請求項２に記載の方法。
5. 製品から製品識別子を撮影するカメラと、前記製品識別子を使用して価格を調べると共にインターフェース要素を含むメッセージを受信するように構成されたネットワークインターフェースと、前記製品識別子によって識別された製品を購入する購買者からの同意を表示するように構成されたインターフェース要素を表示すると共に、前記購買者とカスタマーサービス係とのビデオチャットセッションを開始するように構成された前記メッセージの前記インターフェース要素を表示する表示部と、を備えたモバイルデバイスと、
   コンピュータプログラムにおける命令を実行する少なくとも一つのサーバコンピュータと、
   を有し、
   前記コンピュータプログラム命令は、前記価格に基づいて第１のリスクスコアを算出するためのプログラムコードと、前記購買者と前記カスタマーサービス係とのビデオチャットセッションの開始と前記価格に基づいて第２のリスクスコアを算出するためのプログラムコードと、前記購入品の承認された購入に対する電子領収書を送信するためのプログラムコードと、を含むことを特徴とするシステム。
6. 前記製品と結合された盗難防止タグを検出するリーダと、前記モバイルデバイスの表示部から前記電子領収書の一部を読み取るリーダと、前記リーダに結合されたアラームシステムと、少なくとも一つのサーバと通信し、前記電子領収書が前記盗難防止タグと関係付けられている旨の表示に基づいて前記アラームシステムを無効にするように構成されたネット―ワークインターフェースと、を備えた盗難防止デバイスを更に有することを特徴とする請求項５に記載のシステム。
7. 小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影に基づいて潜在的な購入品の前記製品識別子を取得し、
   前記小売店に関連付けられた、前記潜在的な購入品の販売者を識別し、
   前記販売者に基づいて前記潜在的な購入品の価格を決定し、
   前記購入品を購入する購買者からの同意を、前記モバイルデバイスを使用して取得し、
   前記購買者の同意に基づいて、前記潜在的な購入品の前記識別された販売者との購入取引を、前記モバイルデバイスを使用して開始し、
   前記購入取引に基づく、販売者検証可能コードを有する電子領収書を前記モバイルデバイスで受信し、
   前記モバイルデバイスが前記小売店のリーダに近接している間に、前記検証可能コードを前記モバイルデバイスから生成し、
   前記検証可能コードが有効である旨の表示を受信する、
   ことを特徴とする方法。
8. 前記生成は、前記モバイルデバイスの表示部に前記検証可能コードを表示することを含み、前記検証可能コードは、前記リーダによって光学的に読み取られるように前記表示部にレンダリングされる、
   ことを特徴とする請求項７に記載の方法。
9. 前記検証可能コードは、バーコード、二次元バーコード、ＱＲコード(R)二次元コードからなるグループから選択される、ことを特徴とする請求項８に記載の方法。
10. 前記生成は、前記モバイルデバイスからの無線信号を送信することを含み、前記無線信号は、前記検証可能コードを含み、前記リーダによって読み取られるように構成される、ことを特徴とする請求項７に記載の方法。
11. 前記検証可能コードはデジタル証明書を含む、ことを特徴とする請求項１０に記載の方法。
12. 前記購買者から同意を取得することは、
    前記購買者のデフォルト支払口座を決定し、
    前記モバイルデバイスの表示部に承認インターフェースを表示する、
    ことを含み、
    前記承認インターフェースの前記表示は、前記製品識別子を撮影すると自動的に開始され、前記承認インターフェースは、前記デフォルト支払口座で前記支払取引を開始するために前記購買者からのワンタップを求めるように構成されている、
    ことを特徴とする請求項７に記載の方法。
13. 前記製品識別子は、統一商品コード（ＵＰＣ）バーコード、ＱＲコード(R)二次元コード、および無線周波数識別（ＲＦＩＤ）タグからなるグループから選択される、ことを特徴とする請求項７に記載の方法。
14. 前記潜在的な購入品の価格を決定することは、前記小売店の位置の販売者の在庫データベースにアクセスする、
    ことを特徴とする請求項７に記載の方法。
15. 前記販売者を識別することは、前記モバイルデバイスから地理座標を取得し、
    前記地理座標から前記販売者を調べる、
    ことを特徴とする請求項７に記載の方法。
16. 前記動作が図示された順序で実行される、ことを特徴とする請求項７に記載の方法。
17. 各動作は、メモリと動作可能に結合された前記プロセッサによって実行される、ことを特徴とする請求項７に記載の方法。
18. 一以上の機械に請求項７の動作を行わせる命令を示す情報を具現化する、
    ことを特徴とする機械可読有形記録媒体。
19. コンピュータプログラムにおける命令を実行するコンピュータシステムであって、前記コンピュータプログラム命令は請求項７の動作を実行するプログラムコードを含む、
    ことを特徴とするコンピュータシステム。
20. 小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影に基づいて潜在的な購入品の前記製品識別子を取得し、
    前記潜在的な購入品の価格を決定し、
    前記購買者の口座に課金する前記購買者からの同意を受信し、
    前記購入品の購入を前記購買者の前記口座に課金し、
    前記口座の課金が成功した旨の表示を受信し、
    前記受信した表示に基づいて、検証可能コードを有する電子領収書を生成し、
    前記購買者の前記モバイルデバイスに前記電子領収書を送信し、
    前記モバイルデバイスから前記検証可能コードを読み取り、
    前記モバイルデバイスからの読み取られた前記検証可能コードが有効であることを検証し、
    前記購買者が前記購入品を持って前記小売店から出ることを許可するために前記検証可能コードが有効である旨の表示を送信する、
    ことを特徴とする方法。
21. 前記読み取りは、前記モバイルデバイスの表示部から前記検証可能コードを光学的に読み取ることを含む、
    ことを特徴とする請求項２０に記載の方法。
22. 前記検証可能コードは、バーコード、二次元バーコード、ＱＲコード(R)二次元コードからなるグループから選択される、
    ことを特徴とする請求項２１に記載の方法。
23. 前記読み取りは、前記モバイルデバイスから前記検証可能コードを含む無線信号を受信する、
    ことを含むことを特徴とする請求項２０に記載の方法。
24. 前記検証可能コードはデジタル証明書を含む、ことを特徴とする請求項２２の方法。
25. 前記製品識別子は、統一商品コード（ＵＰＣ）バーコード、ＱＲコード(R)二次元コード、および無線周波数識別（ＲＦＩＤ）タグからなるグループから選択される、
    ことを特徴とする請求項２０に記載の方法。
26. 前記潜在的な購入品の価格を決定することは、前記小売店の位置の販売者の在庫データベースにアクセスする、
    ことを含むことを特徴とする請求項２０に記載の方法。
27. 前記動作は、図示された順序で実行される、ことを特徴とする請求項２０に記載の方法。
28. 各動作は、メモリと動作可能に結合された前記プロセッサによって実行される、ことを特徴とする請求項２０に記載の方法。
29. 一以上の機械に請求項２０の動作を行わせる命令を示す情報を具現化する、
    ことを特徴とする機械可読有形記録媒体。
30. コンピュータプログラムにおける命令を実行するコンピュータシステムであって、前記コンピュータプログラム命令は請求項２０の動作を実行するプログラムコードを含む、
    ことを特徴とするコンピュータシステム。
31. 購買者の第１の支払口座から販売者への支払いに対するアクワイアラからの承認要求を受信し、
    前記承認要求を受信することに基づいて、前記購買者に関連付けられた第２の支払口座を使用する提案を決定し、
    前記購買者に前記決定された提案を送信し、
    前記購買者から前記提案の選択を受信し、
    前記購買者の前記第２の支払口座からの支払いを要求するために、前記承認要求を修正し、
    前記第２の支払口座に関連付けられたイシュアに前記修正された承認要求を送信する、
    ことを特徴とする方法。
32. 購入されるべき品物の製品識別子を受信し、
    前記製品識別子に基づいて、前記第２の支払口座を使用する提案を決定する、
    ことを更に有することを特徴とする請求項３１に記載の方法。
33. 前記提案は、前記第２の支払口座の使用することに対するリワードポイントやキャッシュバックについての提案であることを特徴とする請求項３１に記載の方法。
34. 購買者の支払口座から第１の販売者への支払いについてのアクワイアラからの第１の承認要求を受信し、
    購入される品の製品識別子を受信し、
    前記第１の承認要求と前記受信した製品識別子または第１の販売者に基づいて、競合品または第２の販売者についての提案を決定し、
    前記提案を前記購買者に送信し、
    前記購買者から前記提案の選択を受信し、
    前記受信した選択に基づいて前記第１の承認要求を取り消し、
    前記購買者の前記支払口座から前記提案の第２の販売者への支払いについての第２の承認要求を生成し、
    前記第２の承認要求を前記支払口座に関係付けられたイシュアに送信する、
    ことを特徴とする方法。
35. 前記承認要求を前記購入されるべき品物と一致させる、
    ことを特徴とする請求項３４に記載の方法。
36. 前記提案を決定することは、前記第２の販売者と一以上の他の販売者からの提案の自動オークションを行うことを含む、
    ことを特徴とする請求項３４に記載の方法。
37. 小売店での購買者のモバイルデバイスによる製品識別子の本人による撮影に基づいて、潜在的な購入品の前記製品識別子を取得し、
    前記潜在的な購入品の価格を決定し、
    前記購買者の口座に課金をする前記購買者からの同意を受信し、
    前記購入品の購入を前記口座に課金し、
    前記口座の課金が成功した旨の表示を受信し、
    前記購入品が前記小売店から自由に出られる旨の表示を盗難防止システムに送信する、
    ことを特徴とする方法。
38. 前記購入品が前記小売店から自由に出られる旨の表示に基づいて、前記購入品に結合された盗難防止タグを無効にする、
    ことを更に有することを特徴とする請求項３７に記載の方法。
39. 前記購入品を前記盗難防止デバイスによって検出し、
    前記盗難防止デバイスよる前記購入品の検出に基づいて、前記小売店の在庫システムを更新する、
    ことを更に有することを特徴とする請求項３７に記載の方法。
40. 前記盗難防止システムは、前記小売店の出口の近くのセキュリティタワーを含むことを特徴とする請求項３７に記載の方法。