(57)【要約】  支払いを受信するシステムおよび方法が開示される。この方法は、サイトから、ブラウザに、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することと、ここにおいて、この要求はサイトによって受け付けられる支払い方法の識別を備え、ここにおいて、支払い方法は暗号通貨を使用し、サイトにおいて、支払い方法による支払いを受信することと、ここにおいて、支払い方法は、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して送信された要求に基づいて開始された暗号通貨支払いプロセスにより暗号通貨を使用する、を含む。
2020523716.tif 000002
【特許請求の範囲】
【請求項１】
ブラウザを介して支払いデータを許可する方法であって、
サイトから、前記ブラウザにおいて、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信することと、ここにおいて、前記要求が、前記サイトによって受け付けられる暗号通貨支払い方法の識別を備え、
前記サイトに、前記ブラウザから、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記ブラウザのユーザが、前記サイトによって受け付けられる前記暗号通貨支払い方法を介して前記潜在的な購入の支払いをすることができることを示すデータを送信することと、
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記暗号通貨支払い方法を使用して潜在的な購入が行われることが許可された支払いデータを受信することと
を備える方法。
【請求項２】
前記暗号通貨ウォレットが支払いを行うことを可能にするために、前記許可された支払いデータを暗号通貨ウォレットにポピュレートすることと、
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記暗号通貨ウォレットを開始することと
をさらに備える、請求項１に記載のブラウザを介して支払いデータを許可する方法。
【請求項３】
前記許可された支払いデータが、前記支払いを受信するためのサイトアドレス、買い手の秘密鍵、受信者の公開鍵、電子メールアドレス、受信者識別情報、支払い量、およびユーザコメントのうちの少なくとも１つを備える暗号通貨支払い情報である、請求項２に記載のブラウザを介して支払いデータを許可する方法。
【請求項４】
前記暗号通貨ウォレットが、前記ブラウザを実行しているデバイス上にローカルに記憶されたウォレットおよびウェブベースのウォレットのうちの少なくとも１つを備える、請求項２に記載のブラウザを介して支払いデータを許可する方法。
【請求項５】
前記暗号通貨ウォレットが前記ウェブベースのウォレットであるとき、前記方法が、
前記支払いを処理するためのアプリケーションプログラミングインターフェースを介して前記ウェブベースのウォレットに前記許可された支払いデータを送信すること
をさらに備える、請求項４に記載のブラウザを介して支払いデータを許可する方法。
【請求項６】
前記要求が、前記暗号通貨支払い方法に加えて、前記サイトによって使用されるサポートされる支払い方法を識別する、請求項１に記載のブラウザを介して支払いデータを許可する方法。
【請求項７】
前記許可された支払いデータが、前記暗号通貨ウォレットとのトランザクションに署名するために使用される秘密鍵を備える、請求項２に記載のブラウザを介して支払いデータを許可する方法。
【請求項８】
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払いを受信するためにサイト暗号通貨ウォレットによる使用のために前記サイトにデータを送信すること
をさらに備える、請求項１に記載のブラウザを介して支払いデータを許可する方法。
【請求項９】
前記許可された支払いデータが、前記ブラウザに記憶される、別個のエンティティから前記ブラウザによってアクセスされる、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して前記サイトから受信される、サードパーティから受信される、または、前記ブラウザによって指示されたように前記サードパーティから前記サイトに配達される、請求項１に記載のブラウザを介して支払いデータを許可する方法。
【請求項１０】
前記暗号通貨支払い方法が、購入のためにユーザによって選択されるとき、前記方法が、
支払いを確認するために前記ユーザによる使用のために支払い対話インターフェースと暗号通貨ウォレットインターフェースを混合する前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、混合されたユーザインターフェースを生成すること
をさらに備える、請求項１に記載のブラウザを介して支払いデータを許可する方法。
【請求項１１】
サイトから、ブラウザに、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することと、ここにおいて、前記要求が、前記サイトによって受け付けられる暗号通貨支払い方法の識別を備え、
前記サイトにおいて、前記ブラウザから、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記ブラウザのユーザが、前記サイトによって受け付けられる前記暗号通貨支払い方法を介して前記潜在的な購入の支払いをすることができることを示すデータを受信することと、
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して前記暗号通貨支払い方法を使用して前記潜在的な購入を処理するための前記ユーザからの確認に基づいて、前記暗号通貨支払い方法を使用して支払いを受信することと
を備える方法。
【請求項１２】
暗号通貨ウォレットからサイト暗号通貨ウォレットにおいて前記支払いを受信すること、ここにおいて、許可された支払いデータが、前記支払いを開始するために前記暗号通貨ウォレットをポピュレートする際に使用される
をさらに備える、請求項１１に記載の方法。
【請求項１３】
前記許可された支払いデータが、前記サイト暗号通貨ウォレットを識別するデータおよび量のうちの少なくとも１つを備える、請求項１２に記載の方法。
【請求項１４】
前記暗号通貨ウォレットが、前記ブラウザを動作させるデバイスおよび前記デバイスとは別個のウェブベースのデバイスのうちの１つの上に記憶される、請求項１３に記載の方法。
【請求項１５】
支払いを処理する方法であって、
暗号通貨ウォレットにおいて、購入に関連づけられた許可された支払い情報を受信することと、ここにおいて、前記許可された支払い情報が、ブラウザが、サイトから、前記ブラウザにおいて、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信したことに基づいて、生成され、ここにおいて、前記要求が、前記サイトによって受け付けられる暗号通貨支払い方法の識別を備える、
前記暗号通貨ウォレットから暗号通貨を使用して、前記許可された支払い情報に基づいて、前記支払いを処理することと、
前記暗号通貨を使用して前記支払いの前記処理に関連づけられた確認データを前記ブラウザに送信することと
を備える方法。
【請求項１６】
支払いを受信する方法であって、
サイトから、ブラウザに、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することと、ここにおいて、前記要求が、前記サイトによって受け付けられる支払い方法の識別を備え、ここにおいて、前記支払い方法が暗号通貨を使用し、
前記サイトにおいて、前記支払い方法による支払いを受信することと、ここにおいて、前記支払い方法が、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して送信された前記要求に基づいて開始された暗号通貨支払いプロセスにより前記暗号通貨を使用する
を備える方法。
【請求項１６】
前記暗号通貨支払いプロセスが、第１の通貨を第２の通貨へと変換することを備える、請求項１５に記載の方法。
【請求項１７】
前記暗号通貨支払いプロセスが、買い手が第１の通貨を使用して売り手から品物を購入することと、および、前記売り手が第２の通貨で支払われることを可能にし、ここにおいて、暗号通貨が、前記第１の通貨と前記第２の通貨との間での変換を橋渡しするために使用される、請求項１５に記載の方法。
【請求項１８】
支払いサービスを動作させる方法であって、
前記支払いサービスにおいて、購入に関連づけられた許可された支払い情報を受信することと、ここにおいて、前記許可された支払い情報が、ブラウザが、サイトから、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信したことに基づいて、生成され、ここにおいて、前記要求が、少なくとも一部は暗号通貨を利用する支払いプロセスの識別を備え、
前記暗号通貨を使用して、前記許可された支払い情報に基づいて支払いを処理することと、
前記暗号通貨を使用した前記支払いの前記処理に関連づけられた確認データを前記ブラウザに送信することと
を備える方法。
【請求項１９】
前記支払いを処理することが、買い手から受信された第１の通貨を前記暗号通貨へと変換することをさらに備える、請求項１８に記載の方法。
【請求項２０】
前記支払いを処理することが、売り手に支払うために、買い手から受信された第１の通貨を前記暗号通貨へと変換することと、前記暗号通貨を第２の通貨へと変換することとをさらに備える、請求項１９に記載の方法。
【請求項２１】
サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザにおいて、前記ブラウザと前記サイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、前記購入に関連づけられた支払い要求を受信することと、
前記ユーザから、前記第１のアプリケーションプログラミングインターフェースを介して、前記サイトによってサポートされる支払い方法の選択肢を受信することと、ここにおいて、前記支払い方法が少なくとも一部は暗号通貨を利用し、ここにおいて、支払いトランザクションが、少なくとも一部は支払いサービスによって管理され、
前記支払い要求および前記支払い方法の前記選択肢に応答して、前記ブラウザから、前記ブラウザと前記支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して、前記支払いサービスに支払い要求イベントを通信することと、前記支払い要求イベントが、少なくとも一部は前記暗号通貨を利用して支払いを取り扱うために前記支払いサービスによる使用のためのデータを備える、
を備える方法。
【請求項２２】
前記支払い要求が、前記購入についての情報と、前記サイトによってサポートされる支払い方法の選択肢のセットとを備える、請求項２１に記載の方法。
【請求項２３】
前記支払いサービスによって管理される支払いプロセスが、前記暗号通貨で前記支払いを行う、請求項２１に記載の方法。
【請求項２４】
前記支払いサービスによって管理される支払いプロセスが、（１）第１の通貨から前記暗号通貨へと変換することおよび（２）前記暗号通貨から第２の通貨へと変換することのうちの少なくとも１つを実行することによって、前記支払いを行う、請求項２１に記載の方法。
【請求項２５】
前記支払いサービスによって管理される支払いプロセスが、買い手によって提供される第１の通貨から前記暗号通貨へと変換し、前記暗号通貨から売り手によって受け付けられる第２の通貨へと変換することによって、前記支払いを行う、請求項２１に記載の方法。
【請求項２６】
前記第１の通貨が、第１の法定通貨および第１の暗号通貨のうちの１つを備える、ここにおいて、前記第２の通貨が、第２の法定通貨および第２の暗号通貨のうちの１つを備える、請求項２５に記載の方法。
【請求項２７】
支払いサービスにおいて支払い要求イベントを受信することと、ここにおいて、前記支払いサービスにおいて前記支払い要求イベントを受信することが、
ブラウザが、前記ブラウザとサイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、製品の購入に関連づけられた支払いデータのために前記サイトから支払い要求を受信することと、ここにおいて、前記支払い要求が、製品を購入する要望を示すユーザからの入力に基づいており、前記購入についての情報を備え、
前記ユーザから、前記第１のアプリケーションプログラミングインターフェースを介して、前記支払いサービスの選択肢を受信すること、ここにおいて、前記支払い要求イベントが、前記ブラウザから、前記ブラウザと前記支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して受信される
に基づき、
前記支払いサービスにおいて、少なくとも一部は暗号通貨の使用を備える支払いプロセスを開始するために前記支払い要求イベントを処理することと
を備える方法。
【請求項２８】
前記ブラウザに、前記支払いサービスから、前記第２のアプリケーションプログラミングインターフェースを介して、許可された支払い情報を送信すること、ここにおいて、前記ブラウザが、前記第１のアプリケーションプログラミングインターフェースを介して前記許可された支払い情報を前記サイトに通信する
をさらに備える、請求項２７に記載の方法。
【請求項２９】
前記支払い要求が、前記購入についての情報と、前記サイトによってサポートされる支払い方法の選択肢のセットとを備える、請求項２７に記載の方法。
【請求項３０】
前記支払いサービスによって管理される前記支払いプロセスが、前記暗号通貨で支払いを行う、請求項２７に記載の方法。
【請求項３１】
前記支払いサービスによって管理される前記支払いプロセスが、（１）第１の通貨から前記暗号通貨へと変換することおよび（２）前記暗号通貨から第２の通貨へと変換することのうちの少なくとも１つを実行することによって、支払いを行う、請求項２７に記載の方法。
【請求項３２】
前記支払いサービスによって管理される前記支払いプロセスが、買い手によって提供される第１の通貨から前記暗号通貨へと変換し、前記暗号通貨から売り手によって受け付けられる第２の通貨へと変換することによって、支払いを行う、請求項２７に記載の方法。
【請求項３３】
前記第１の通貨が、第１の法定通貨および第１の暗号通貨のうちの１つを備える、ここにおいて、前記第２の通貨が、第２の法定通貨および第２の暗号通貨のうちの１つを備える、請求項３２に記載の方法。
【請求項３４】
サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザにおいて、前記ブラウザと前記サイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、前記購入に関連づけられた支払い要求を送信することと、
前記第１のアプリケーションプログラミングインターフェースを介して、前記サイトによってサポートされる支払い方法の選択肢を送信することと、ここにおいて、前記支払い方法が、少なくとも一部は暗号通貨を利用し、ここにおいて、支払いトランザクションが、支払いサービスによって少なくとも一部は管理され、ここにおいて、前記支払い要求および前記支払い方法の前記選択肢に応答して、前記ブラウザと前記支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースが、前記支払いサービスに支払い要求イベントを通信し、前記支払い要求イベントが、少なくとも一部は前記暗号通貨を利用する支払いプロセスを介して支払いを取り扱うために前記支払いサービスによる使用のためのデータを備える、
前記支払いプロセスを介して前記支払いを受信することと
を備える方法。
【発明の詳細な説明】
【技術分野】
【０００１】
優先権の主張
[0001]本出願は、現在は２０１６年６月７日に発行された米国特許第９，３６１，６３８号である２０１５年３月３０日に出願された米国非仮特許出願第１４／６７２，８７６号の継続出願である現在は２０１６年３月２２日に発行された米国特許第９，２９２，８７１号である２０１５年８月１０日に出願された米国非仮特許出願第１４／８２２，３６８号の継続出願である現在は２０１６年７月１９日に発行された米国特許第９，３９６，４９１号である２０１５年９月１４日に出願された米国非仮特許出願第１４／８５３，５７９号の継続出願である現在は２０１７年８月１５日に発行された米国特許第９，７３４，５２６号である２０１６年２月９日に出願された米国非仮特許出願第１５／０１８，９５４号の継続出願である２０１６年９月１２日に出願された米国非仮特許出願第１５／２６３，０６６号の継続出願である現在は２０１７年９月１９日に発行された米国特許第９，７６７，５２０号である２０１６年９月１９日に出願された米国非仮特許出願第１５／２６９，４５１号の一部継続出願である２０１７年５月４日に出願された米国非仮特許出願第１５／５８６，９９９号の一部継続出願である２０１７年５月１９日に出願された米国非仮特許出願第１５／６００，３８８号の継続出願である２０１７年５月１９日に出願された米国非仮特許出願第１５／６００，５９９号の継続出願である２０１７年５月２３日に出願された米国非仮特許出願第１５／６０２，８６８号の一部継続出願である２０１７年８月１６日に出願された米国特許出願第１５／６７８，３７８号の継続出願である２０１７年８月１６日に出願された米国特許出願第１５／６７８，６６４号の一部継続出願である２０１７年９月２９日に出願された米国特許出願第１５／７２０，８７８号の一部継続出願である２０１８年４月６日に出願された米国特許出願第１５／９４７，３９５号に対する優先権を主張するものであり、米国特許第９，３６１，６３８号は、２０１４年４月１日に出願された米国仮特許出願第６１／９７３，２８７号に対する優先権を主張するものであり、現在は２０１６年８月３０日に発行された米国特許第９，４３０，７９４号である２０１４年３月３１日に出願された米国非仮特許出願第１４／２３０，８６４号の一部継続出願でもあり、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８４３号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８３４号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８４８号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８６５号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８７９号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８６１号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８７８号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８９２号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８９０号に対する優先権も主張するものである。これらの各々の内容は、その全体が参照により本明細書に組み込まれる。
【０００２】
[0002]本出願は、２０１７年８月１６日に出願された米国特許出願第１５／６７８，６６４号の一部継続出願である２０１７年９月２９日に出願された米国特許出願第１５／７２０，８７８号の一部継続出願であり、米国特許出願第１５／６７８，６６４号は、２０１７年３月２３日に出願された米国仮特許出願第６２／４７５，５７８号、２０１７年１月２６日に出願された米国仮特許出願第６２／４５０，９００号、２０１６年９月２６日に出願された米国仮特許出願第６２／３９９，７６１号、２０１７年９月１９日に出願された米国仮特許出願第６２／５６０，２６１号に対する優先権を主張するものである。これらの内容は、その全体が参照により本明細書に組み込まれる。
【０００３】
[0003]本出願は、現在は２０１６年６月７日に発行された米国特許第９，３６１，６３８号である２０１５年３月３０日に出願された米国非仮特許出願第１４／６７２，８７６号の継続出願である現在は２０１６年３月２２日に発行された米国特許第９，２９２，８７１号である２０１５年８月１０日に出願された米国非仮特許出願第１４／８２２，３６８号の継続出願である現在は２０１６年７月１９日に発行された米国特許第９，３９６，４９１号である２０１５年９月１４日に出願された米国非仮特許出願第１４／８５３，５７９号の継続出願である現在は２０１７年８月１５日に発行された米国特許第９，７３４，５２６号である２０１６年２月９日に出願された米国非仮特許出願第１５／０１８，９５４号の継続出願である２０１６年９月１２日に出願された米国非仮特許出願第１５／２６３，０５７号の一部継続出願である２０１７年９月２９日に出願された米国非仮特許出願第１５／７２０，８７８号の一部継続出願であり、米国特許第９，３６１，６３８号は、２０１４年４月１日に出願された米国仮特許出願第６１／９７３，２８７号に対する優先権を主張するものであり、現在は２０１６年８月３０日に発行された米国特許第９，４３０，７９４号である２０１４年３月３１日に出願された米国非仮特許出願第１４／２３０，８６４号の一部継続出願でもあり、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８４３号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８３４号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８４８号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８６５号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８７９号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８６１号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８７８号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８９２号、２０１４年３月３１日に出願された米国仮特許出願第６１／９７２，８９０号に対する優先権も主張するものである。これらの各々の内容は、その全体が参照によって本明細書に組み込まれる。
【０００４】
[0004]本出願は、２０１７年１０月９日に出願された米国仮特許出願第６２／５６９，８４１号に対する優先権を主張するものであり、その内容は、その全体が参照により本明細書に組み込まれる。
【０００５】
関連出願
[0005]本出願は、現在は２０１６年６月２１日に発行された米国特許第９，３７３，１３８号である２０１５年９月１４日に出願された米国非仮特許出願第１４／８５３，５４５号、現在は２０１６年９月２０日に発行された米国特許第９，４４９，３３８号である２０１６年２月８日に出願された米国非仮特許出願第１５／０１８，４３２号、現在は２０１６年１０月１１日に発行された米国特許第９，４６６，０８１号である２０１６年２月８日に出願された米国非仮特許出願第１５／０１８，４５７号、現在は２０１６年９月６日に発行された米国特許第９，４３６，９５７号である２０１６年２月８日に出願された米国非仮特許出願第１５／０１８，４９７号、現在は２０１６年１２月２０日に発行された米国特許第９，５２４，５１９号である２０１６年２月８日に出願された米国非仮特許出願第１５／０１８，５１４号、２０１６年２月９日に出願された米国非仮特許出願第１５／０１８，９３４号、現在は２０１６年８月３０日に発行された米国特許第９，４３０，７９０号である２０１６年２月９日に出願された米国非仮特許出願第１５／０１８，９２３号、および２０１６年２月９日に出願された米国非仮特許出願第１５／０１８，９３９号に関連し、これらの各々の内容は、その全体が参照により本明細書に組み込まれる。
【背景技術】
【０００６】
１．技術分野
[0006]本開示は、ブラウザが、ブラウザと販売業者サイトとの間でアプリケーションプログラミングインターフェースを使用して支払いプロセスを管理するためのさまざまな実施形態に関する。このケースは、サイトとアプリケーションプログラミングインターフェースとの間の対話を通じて暗号通貨支払いプロセスを提供することに焦点を当てる。
【０００７】
２．序論
[0007]本出願は、製品のオンライン購入およびインターネット上のサイト間のナビゲーションを単純化および管理することに関係するいくつかの問題に対処する。本明細書において対処され、関連特許出願において包含される他の問題も、検討される。この序論は、新規な特徴の検討を含むことがあり、このセクションにおいて検討されるいかなる概念も従来技術であることを認めるとみなされるべきでない。
【０００８】
[0008]本明細書において対処される１つの問題は、ショッピングカートを利用することに関する。ユーザが、第１のサイトにおいて第１の品物を選択し、その品物をショッピングカート内に置き、次いで、購入を完了せず、第２の品物を見るために第２のサイト上に移動した場合、第１の品物についての情報を保存または維持する機構はない。明らかに、ユーザは、その品物に興味を抱いていたが、購入を行う準備があまりできていなかった。さらに、ユーザがたとえば３つの異なるサイトをナビゲートする場合、３つの異なる製品を購入した場合、各サイトが、ワンクリック購入能力とともに構成されたとしても、または、ユーザが各個々のサイトに登録されている場合、ユーザは、依然として、３つの製品を購入するために３つの独立したクリックを行わなければならない。したがって、本明細書において提起される１つの問題は、複数のサイトにまたがるショッピングのための改善された機構に関し、特に、複数の製品の購入を達成するために必要な対話の数を減少させることに関する。いくつかのケースでは、マルチサイトショッピングカートが存在し得る場合、支払い情報を登録またはサービスに提供することをユーザに要求する可能性が高く、これは、ユーザにとって望ましくないことがある。
【０００９】
[0009]本明細書において対処される別の問題は、ワンクリック購入オプションのコンテキストにあり、潜在的な買い手の購入に関する懸念を解消することに関する。購入に関する懸念としては、特にモバイルデバイスに関する、あまりにも多いデータ（支払いアカウント、住所、氏名など）を必要とする複雑なショッピングカートモデル、人々にカートを捨てさせること、選択されていない製品の仕様、または衣類のサイズもしくは色などのパラメータ、または電子デバイスのためのメモリの量があり得る。購入に関する他の懸念としては、製品についての不良なレビュー、または販売業者に関して不十分に反映する記事があり得る。別の懸念としては、購入を確定する前に購入についての疑問を解決することがあり得る。買い手の購入に関する懸念としては、製品、サービス、販売業者、または他の任意のトピックに関係するすべてのものがあり得る。したがって、製品についてのダイアログに移行する手法が購入に関する懸念を解消することを可能にすること、パラメータを確定し、次いで支払いを効率的に確認することを望んでいるだろう。このケースにおける特許請求の範囲は、この問題に対処する。
【００１０】
[0010]本明細書において対処される別の問題は、どのようにして検索エンジンまたはブラウザサイトから宛先サイトにユーザを容易に遷移するかである。この遷移を行う１つの取り組みは、Ｓａｆａｒｉのｏｍｎｉｋｅｙ特徴によって提供された。ｏｍｎｉｋｅｙ拡張機能を使用して、Ｓａｆａｒｉユーザは、入力を処理するために使用することを望むどの代替サイトのインジケータをタイプする。たとえば、入力フィールドに、ユーザが「ａｍａｚｏｎ  ｈｅａｄｐｈｏｎｅｓ」をタイプし、これは、ａｍａｚｏｎ．ｃｏｍを「ｈｅａｄｐｈｏｎｅｓ」で検索し、結果を返すように、入力を処理するアルゴリズムに指示するであろう。この手法に関する課題は、ａｍａｚｏｎタブをクリックし、「ｈｅａｄｐｈｏｎｅｓ」をＡｍａｚｏｎ検索フィールドにタイプすることは、検索の始まりに「ａｍａｚｏｎ」をタイプすることよりも簡単である可能性が高い。さらに、ユーザがａｍａｚｏｎに遷移することを望んでいないことを検索エンジンに告げるために、ユーザは、通常検索を強制する感嘆符「！」を用いて検索を始めなければならないであろう。たいていのユーザ入力がデフォルト検索エンジンによる通常検索を伴う可能性が高いそのような特徴を使用することは、多くの場合に「！」を用いて検索を始めることをユーザに要求する可能性がある。したがって、ユーザを他のサイトに遷移させることにおけるこの取り組みは、依然として問題がある。
【００１１】
[0011]追加の問題は、購入を行うときにクレジットカード情報およびユーザ住所などの支払いデータを入力することをユーザに要求するという長年の課題に関する。Ａｍａｚｏｎ．ｃｏｍのようないくつかのサイトは、「ワンクリック」購入オプションを提供するが、それらの単純化は、制御されたＡｍａｚｏｎ．ｃｏｍ環境内でのみ利用可能である。すべての他の販売業者の場合、ユーザは、支払いデータを入力しなければならず、これは面倒である。Ａｍａｚｏｎ．ｃｏｍの外部のモバイルユーザは、依然として、多くの情報を含み、入力することを必要とし、これは、デスクトップまたはモバイルデバイスのどちらかの上で、オンラインで購入を行うときの変換の数を減少させる。
【００１２】
[0012]本開示は、異種プラットフォーム上での買うボタンの使用を通して生じる、当技術分野における問題にも対処する。本出願は、検索エンジン、ソーシャルメディアなどの上の買うボタンのさまざまな実装を開示する出願に対する優先権を主張するものであるので、この序論の部分は、「従来技術」を特徴づけることを意図されたものではない。同じく、本出願における検討は、出願人が本明細書におけるいかなる主題をも認めることが従来技術であるとみなされるべきでない。
【００１３】  [0013]（公序良俗違反につき、不掲載）、（公序良俗違反につき、不掲載）、（公序良俗違反につき、不掲載）、（公序良俗違反につき、不掲載）、（公序良俗違反につき、不掲載）、（公序良俗違反につき、不掲載）、（公序良俗違反につき、不掲載）、（公序良俗違反につき、不掲載）、および（公序良俗違反につき、不掲載）などのサイト上の買うボタンの有用性を考えると、購入を追跡することに関して具体的な難題が生じる。ユーザが、（公序良俗違反につき、不掲載）上で第１の製品の購入を行い、翌日に、（公序良俗違反につき、不掲載）上で第２の製品を購入することがある。そのような購入を可能にするために、（公序良俗違反につき、不掲載）のようなサイトは、クレジットカード情報または支払いアカウント情報などの購入情報を維持する。任意選択で、購入が容易に処理できるように、ＰａｙＰａｌ（登録商標）またはＡｐｐｌｅ  Ｐａｙとのインターフェースが提供される。買うボタンが拡張している間、ユーザが購入を容易に管理できるように購入を調和させるまたは編成する既存の機構はない。ユーザは、どこで購入が行われたかを忘れることがあり、購入を管理できないまたは購入履歴を調査するときに不満を感じることがある。ｗｗｗ．（公序良俗違反につき、不掲載）のような閉鎖された集合販売業者サイトの場合、購入は、複数の販売業者が製品を入手可能にした状態の単一のサイトを通して制御される。そのようなサイト上でユーザアカウントおよび購入の履歴を管理できることは、かなり容易である。【００１４】
[0014]しかしながら、さまざまなサイト上の買うボタンの目的は、人間がＦａｃｅｂｏｏｋ（登録商標）またはＩｎｓｔａｇｒａｍなどのソーシャルメディアを使用するそれらの「微小の瞬間」における購入を可能にし、買うことを望むものを見ることである。買うボタンを従来の非販売業者サイトに組み込む利益は、ｇｏｏｇｌｅ．ｃｏｍのような検索エンジンおよびソーシャルメディアサイトなどの、人々が時間を費やすサイトからの容易な購入を利用することである。しかしながら、そのような微小の瞬間を利用するために非販売業者サイトにおいて買うオプションを提示することは、まとまりのない異種サイトにわたって広がる購入を管理する困難をもたらす。
【発明の概要】
【００１５】
[0015]本開示は、上記に記載されたさまざまな問題に対処するために、いくつかの技術革新を提供する。開示される多くの解決策のうち、初期請求項セットは、ブラウザアプリケーションプログラミングインターフェースを使用した、サイトとブラウザとの間の対話（要求／応答／など）を通して、全部または一部が暗号通貨購入に対処する。この一般的な概念に関係する多くの異なる例示的な手法がある。請求項は、販売業者サイトによって実行される動作、ブラウザによって実行される動作、支払いサービスによって実行される動作、暗号通貨ウォレットによって実行される動作、ブリッジ暗号通貨を利用して異なる法定通貨の橋渡しをする支払いサービスの動作などを対象とすることができる。この概要では、１つの例示的なシステムおよび方法が説明される。多くの他の例は、以下で本出願の本文に記載される。
【００１６】
[0016]ブラウザ支払いＡＰＩを通しての暗号通貨支払いの使用に関係する例示的な方法は、サイトから、ブラウザに、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することと、ここにおいて、この要求は、サイトによって受け付けられる支払い方法の識別を備える、ここにおいて、この支払い方法は暗号通貨を使用する、サイトにおいて、支払い方法による支払いを受信することと、ここにおいて、支払い方法は、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して送信された要求に基づいて開始された暗号通貨支払いプロセスにより暗号通貨を使用する、を含む。
【００１７】
[0017]本明細書において開示される他の解決策は、購入を行うとき、どのようにしてユーザがいくつかの異なる支払い方法の中から選ぶことができるかを含む。ユーザは、多くの場合、さまざまなアカウント、クレジットカード、デビットカードなどを有する。
【００１８】
[0018]１つの方法は、サイトにおいて、ブラウザを介してサイトにアクセスするユーザが、（１）第１のブラウザもしくは第２のブラウザのうちの１つを使用しているか、または（２）決定をもたらすために第１のアカウントもしくは第２のアカウントを使用して購入を行うことができるかを決定することを含む。したがって、使用されるブラウザタイプは検出可能である、またはユーザのアカウントタイプが検出可能である。決定が、ユーザが、第１のブラウザを使用しているまたは第１のアカウントを使用して購入を行うことができるのどちらかであることを示すとき、方法は、（１）第１のアカウントに関連づけられた動的に修正された第１の買うボタンを提示することと、（２）第１のブラウザに、サイトと第１のブラウザとの間で購入についての情報を通信するためのプロトコルを定義する第１のブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのためにサイトからの購入に関連づけられた第１の情報を有する第１の支払い要求を送信することと、（３）第１のブラウザから、第１のブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、第１のアカウントに関連づけられた第１のデータを受信することと、この第１のデータは、購入を処理することに関連づけられる、を含む。
【００１９】
[0019]決定が、ユーザが、第２のブラウザを使用しているまたは第２のアカウントを使用して購入を行うことができるのどちらかであることを示すとき、方法は、（１）第２のアカウントに関連づけられた動的に修正された第２の買うボタンを提示することと、（２）第２のブラウザに、サイトと第２のブラウザとの間で購入についての情報を通信するためのプロトコルを定義する第２のブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのためにサイトからの購入に関連づけられた第２の情報を有する第２の支払い要求を送信することと、（３）第２のブラウザから、第２のブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、第２のアカウントに関連づけられた第２のデータを受信することと、この第２のデータは、購入を処理することに関連づけられる、を含む。第１のブラウザと第２のブラウザは、異なるブラウザタイプとすることができる。
【００２０】
[0020]別の態様では、開示される方法は、ブラウザを介してサイトとインターフェースするユーザが、選択されたブラウザおよび選択されたブラウザ支払い要求アプリケーションプログラミングインターフェースをもたらすために第１のブラウザ支払い要求アプリケーションプログラミングインターフェースまたは第２のブラウザ支払い要求アプリケーションプログラミングインターフェースを介して支払いを行うことができるかどうかを決定することと、ここにおいて、選択されたブラウザ支払い要求アプリケーションプログラミングインターフェースは、支払いを管理するためにサイトと選択されたブラウザとの間でデータを通信するためのプロトコルを定義する、選択されたブラウザまたは選択されたブラウザを介して可能にされたユーザ支払いアカウントに関連づけられた動的に修正された買うボタンを提示することと、動的に修正された買うボタンとの対話に関連して、選択されたブラウザに、選択されたブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払い要求を送信することと、支払い要求に応答して、選択されたブラウザから、選択されたブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、サイトにおいて支払い情報を受信することとを含む。動的に修正された買うボタンは、ユーザ支払いアカウントに関連づけ可能である。したがって、ユーザが購入を行うためにサイトに行くとき、買うボタンは、使用する支払いサービスを動的に調整することができる。
【００２１】
[0021]このケースは、ブラウザＡＰＩのコンテキストにおいて複数のアカウントをどのようにして管理するに焦点を当てる。方法は、この態様では、ブラウザにおいて、サイトとブラウザとの間で購入についての情報を通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのためにサイトから製品の購入に関連づけられたデータを有する支払い要求を受信することと、ブラウザまたはブラウザインターフェースを介して、製品を購入するための第１の支払い方法と第２の支払い方法との選択肢を提示することと、ここにおいて、第１の支払い方法と第２の支払い方法は各々、ユーザデバイス上に記憶された支払いデータ、ネットワークサーバ上に記憶された支払いデータ、および支払いサービスのうちの１つを含むまたは必要とする、選択された支払い方法をもたらすために第１の支払い方法および第２の支払い方法のうちの１つのユーザから、選択された支払い方法に基づいて、支払い方法の選択を受信することと、支払い要求に応答して、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、選択された支払い方法に関連づけられたデータをサイトに送信することとを含む。これは、ブラウザの観点からである。概念はまた、販売業者サイトの観点から、ならびに支払いプロセッサの観点から、包含可能である。
【００２２】
[0022]別の解決策は、ブラウザまたはユーザのためのログインプロセスを単純化するためのネットワークベースのエンティティのどちらかからＡＰＩを介してユーザログイン証明書をサイトが要求することを可能にする証明書管理アプリケーションプログラミングインターフェースに関する。この点に関する方法は、サイトから、ブラウザにおいて、ユーザがサイトにログインすることを可能にするためにサイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ証明書管理アプリケーションプログラミングインターフェースを介して、サイトのために必要とされるログイン証明書に関連づけられた要求を受信することと、要求に基づいて、（ブラウザから、および／またはネットワークエンティティから）ユーザデータを取り出すことと、サイトに、ブラウザから、ブラウザ証明書管理アプリケーションプログラミングインターフェースを介して、要求に対する応答を送信することとを含む。この応答は、ユーザがそのようなデータを手動でタイプするもしくは入力する必要なしにサイトがユーザをログインさせることを可能にすることができる、ユーザ名、パスワード、コード、指紋、および虹彩スキャンのうちの１つもしくは複数、またはこのデータの任意の組み合わせなどのユーザのためのログイン証明書を含むことができる。この証明書管理ＡＰＩの実施形態は、ブラウザの観点からであってもよいし、サイトの観点からであってもよいし、ユーザデータを記憶するネットワークエンティティの観点からであってもよい。１つまたは複数のＡＰＩは、ＡＰＩを介したログイン証明書のサイトへの通過を最終的に達成するために組み合わせで使用可能である。
【００２３】
[0023]本明細書において開示される別の解決策は、ブラウザとの複数のアプリケーションプログラミングインターフェースを通して支払いプロセッサを用いて支払いプロセスをどのようにして管理するかに関する。この点に関する方法は、販売業者サイトから製品を購入する要望を示すユーザから入力を受信することと（入力は、クリックであってもよいし、ダイアログの一部としての音声入力であってもよいし、バーチャルリアリティ入力であってもよいし、任意の種類の入力であってもよい）入力に基づいて、ブラウザにおいて、ブラウザと販売業者サイトとの間で第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、製品を購入するためのユーザの支払いデータのために販売業者サイトから支払い要求を受信することとを含む。
【００２４】
[0024]支払い要求に応答して、方法は、ブラウザから、ブラウザと支払いサービスとの間で支払い情報を通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して、支払いサービスに支払い要求イベントを通信すること、ここにおいて、この支払いサービスは、支払い要求イベントに基づいて製品のための支払いを処理することができる、を含む。方法は、ブラウザにおいて、支払いサービスから、第２のアプリケーションプログラミングインターフェースを介して、製品のための支払いの確認を受信することと、ブラウザから、第１のアプリケーションプログラミングインターフェースを介して、販売業者サイトに、製品のための支払いの確認を通信することとを含む。支払いサービスは、Ｐａｙｐａｌなどのようなサービスであってよい。この手法は、新しい様式でブラウザおよびいくつかのＡＰＩを利用する、販売業者と支払いサービスとの間の共通インターフェースを可能にする。
【００２５】
[0025]第１のアプリケーションプログラミングインターフェースは、ブラウザと販売業者サイトとの間で支払いデータおよび住所データのうちの少なくとも１つを通信するための第１のプロトコルを定義することができる。第２のアプリケーションプログラミングインターフェースは、ブラウザと支払いサービスとの間で製品の支払いに関連づけられたデータを通信するための第２のプロトコルを含むことができる。支払い要求は、さらに、ユーザの住所の要求を含むことができる。したがって、支払いは、支払いサービスプロバイダによって実行可能であり、住所は、第１のＡＰＩを通してブラウザによって提供されてよい。
【００２６】
[0026]方法は、支払い要求に基づいて、ブラウザから、第１のアプリケーションプログラミングインターフェースを介して、ユーザに製品を配達する際に使用するために販売業者サイトにユーザの住所を送信することをさらに含むことができる。第１のアプリケーションプログラミングインターフェースは、支払いデータおよび／またはユーザについての他のデータについての販売業者サイトからの要求を伴うので、ブラウザ支払い要求アプリケーションプログラミングインターフェースを含むことができる。第２のアプリケーションプログラミングインターフェースは、より具体的には、支払いプロセッサによる支払いの取り扱いを伴うので、支払い取り扱いアプリケーションプログラミングインターフェースと呼ばれることがある。本開示のこの態様は、販売業者の観点からの、ならびに支払いプロセッサの観点からの実施形態も有することができる。
【００２７】
[0027]本明細書において開示される別の解決策は、口頭でのダイアログにおいて製品購入経験をどのようにして提供するかに関する。この点に関する例示的な方法は、メッセンジャーアプリケーションを介して、販売業者サイトとユーザとの間のダイアログの一部として、ユーザから口頭での入力を受信することと、メッセンジャーアプリケーション内で口頭での入力に関連づけられたテキストをユーザに提示することと、ダイアログの一部として、販売業者サイトによって、口頭での応答で口頭での入力に応答することと、メッセンジャーアプリケーション内で口頭での応答に関連づけられた応答テキストを提示することと、ダイアログを介してユーザが販売業者サイトから購入することを要望する製品を識別することとを含む。ダイアログを介したユーザによる口頭での買う対話に基づいて、方法は、ブラウザにおいて、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、販売業者サイトから、製品を購入するためにユーザの支払いデータのための、支払い要求を受信することと、支払い要求に応答して、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのための支払い情報を通信することと、ここにおいて、販売業者サイトは、支払い情報を使用して、製品のための支払いを処理する、を含む。
【００２８】
[0028]方法は、ブラウザにおいて、ブラウザ支払い要求アプリケーションプログラムインターフェースを介して、販売業者サイトから、ユーザのための住所データのための住所要求を受信することを含むことができる。住所要求に応答して、方法は、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、販売業者サイトにユーザのための住所データを通信することを含むことができる。販売業者サイトは、支払い情報を使用して支払いを処理する。支払い情報は、販売業者サイトが製品のための支払いを処理するために使用することができるユーザのための支払いアカウント情報を含むことができる。ブラウザは、ユーザにメッセンジャーアプリケーションを提示することができる。ダイアログは、口頭でのダイアログではなく、テキストダイアログであってもよい。方法はまた、販売業者サイトの観点から特許請求されてもよい。
【００２９】
[0029]他の技術革新は、いくつかの解決策を使用した検索フィールドから宛先サイトへの遷移技法と、任意のウェブサイトを「ワンクリック」すなわち従来利用可能であったよりも少ないクリック購入経験に変えるためにブラウザ支払い要求ＡＰＩを適用することと、ならびに上記で記載されたさまざまな問題および他の問題にも対処する他のソーシャルメディア技術革新とを含む。
【００３０】
[0030]インターネット検索、サーフィン、および購入プロセスに対するいくつかの異なる解決策が開示される。この開示の一態様は、マルチサイト汎用ショッピングカートに当てはまり、特に、Ｗ３Ｃによって実施されるブラウザ支払い要求アプリケーションプログラミングインターフェースの修正バージョンを使用して適用可能である解決策を提示する。一態様では、方法、システム、またはコンピュータ可読記憶デバイスは、ブラウザの観点から動作する。方法は、ブラウザに関連づけられたブラウザショッピングカートアプリケーションプログラミングインターフェースを介して、ブラウザを使用して第１のサイト上でナビゲートするユーザによって閲覧された第１の製品に関連づけられた第１のデータを受信すること、ここにおいて、ユーザは第１のサイト上で製品を購入しない、を含む。ブラウザによってアクセス可能であるような第１のデータ。この記憶装置は、ブラウザとともにであってもよいし、ユーザデバイス上であってもよいし、ネットワークデバイス上であってもよい。ブラウジングは、第１のデバイス上でも発生することができ、第１のデバイスは、モバイルデバイス、デスクトップデバイス、音声インターフェースデバイス、またはユーザがコンテンツを全体的に検索して購入を行うために使用することができる任意のデバイスを含むことができる。方法は、第２の製品の購入を管理するためにユーザにブラウザ支払いインターフェースを提示すること、このブラウザ支払いインターフェースは、ユーザのための支払いデータがブラウザ支払い要求アプリケーションプログラミングインターフェースを通してブラウザから第２のサイトに渡されるブラウザ支払い要求アプリケーションプログラミングインターフェースに関連づけられる、を含む。第２のサイトは、別個のデバイスを通してもアクセス可能であり、この別個のデバイスは、モバイルデバイスであってもよいし、デスクトップデバイスであってもよいし、音声インターフェースデバイスであってもよいし、任意の種類のデバイスであってもよい。ネットワークデバイスは、ユーザによって使用されるさまざまなデバイスにわたって汎用ショッピングカートを協調させることができる。たとえば、検索エンティティは、モバイルデバイス上での第１のブラウザ検索からショッピングカートへと入れられた第１の製品を識別し、次いで、ショッピングカートへと入れることになる第２の製品を識別するために第２のデバイス上での音声指示を使用してユーザを識別することができる。次いで、ユーザは、どちらかのデバイス上で、または任意の時間に、両方の製品を購入することができる。システムは、音声識別を通して、または同じユーザショッピングカートの一部であるように品物を接続する他の手段を通して、ユーザを識別することができる。音声ベースのデバイスは、特定の支払いアカウントに既に関連づけ可能である、または音声識別に基づいて異なる支払いアカウントに調整することができる。たとえば、自宅にいるユーザが、デスクトップコンピュータから第１の製品を汎用ショッピングカートに入れ、次いで、友人の家に行くことがある。ソーシャルネットワーキングデータまたはスピーチ／音声識別を通して、ユーザは、友人の家で音声ベースのデバイスに話しかけることができ、このことは、「これはＭａｒｙ  Ｓｍｉｔｈですか？」と尋ねることによって識別を確認することができ、その時点で、ユーザは、音声コマンドを介して別の品物をショッピングカートに追加し、すべての品物の購入を行うことができる。ソーシャルメディアデータまたは好みは、購入のために友人の音声ベースのデバイスを潜在的に使用するためにＭａｒｙを接続することができる。別個のバイオメトリック確認は、これらのシナリオでは、購入が、適切な人間からであることを確認するためにも提供されることがある。一例では、Ｍａｒｙが友人の家に行ったとき、音声ベースのデバイスまたは他のデバイスは、Ｍａｒｙの携帯電話を通してＭａｒｙを識別することができる。ジオロケーションデータも、Ｍａｒｙのロケーションに基づいて提供可能である。このデータに基づいて、検索エンティティを通して音声ベースのデバイスは、Ｍａｒｙが音声ベースのデバイスを通して友人の自宅でショッピング要求を行うことがあると潜在的に予想するように構成可能である。スピーチ認識モデル、話者識別モデル、または発生することを必要とすることがある他の任意のスピーチ関係の事前構成が、開始可能またはローカルの音声ベースのデバイスに転送可能である。したがって、Ｍａｒｙが音声ベースのデバイスに、「紙タオルを私のショッピングカートに追加してちょうだい」と言ったとき、システムは、Ｍａｒｙの音声を認識し、調節されたスピーチ認識モデルを使用してスピーチを解釈し、「オーケー、Ｍａｒｙ、紙タオルが、ショッピングカートに入っていて、塩と胡椒入れが昨日追加されました。精算しますか？」で応答することができる。
【００３１】
[0031]方法は、第１の製品についての情報をブラウザ支払いインターフェース上で提示することと、ブラウザ支払いインターフェースとのユーザ対話に基づいて、または支払い証明書へのアクセスを有する検索エンティティを通して管理される、第１の製品と第２の製品の両方の支払いを処理することとをさらに含む。第１の製品と第２の製品の両方の支払いの処理は、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介したブラウザ／デバイスと第１のサイトとの間の第１の通信およびブラウザ支払い要求アプリケーションプログラミングインターフェースを介したブラウザ／デバイスと第２のサイトとの間の第２の通信を使用して発生することができる。検索エンティティなどのネットワークベースのエンティティは、複数の製品が単一の販売業者からである場合、さまざまな販売業者または単一の販売業者に支払いを協調させることもできる。違いは、第２のサイトが第２の製品の支払いプロセスのためにブラウザと既に通信していることである。しかしながら、ユーザは第１のサイトから離れてナビゲートしており、そのため、第１のサイトへ戻る通信は、製品を識別し、ならびに以前に検索された製品の第１のサイトに「思い出させる」ために第１のサイトに支払いおよび／または配達データを提供しなければならない。第１の製品と第２の製品の両方の支払いを処理することは、さらに、ブラウザアプリケーションプログラミングインターフェースを通して、第１のサイトが第１の製品の第１の購入を処理することを可能にするデータのパッケージを送信することを含むことができる。データのパッケージは、第１のサイトが、第１の製品のための支払いを処理し、第１のサイトが製品を配達するためにユーザに関連づけられた情報に対処するために支払いデータを含むことができる。方法は、ブラウザ支払いインターフェースを介して１つの製品を購入するために使用されるオブジェクト対話の同じセットを利用して第１の製品と第２の製品の両方の購入のユーザから確認を受信することも含むことができる。言い換えれば、ユーザは既に、第２の製品のための支払いを処理するためにブラウザインターフェース内にいるので、方法は、同じ「ワンクリック」とおそらく１つの指紋認識もしくはＣＶＣコードエントリとを利用して、またはいかなるより少数のステップが第２の製品の購入に利用されても、第１の製品のための支払いも処理することを含むことができる。
【００３２】
[0032]検索エンティティなどのネットワークベースのエンティティが支払いを管理するとき、さまざまな販売業者は、それぞれの支払いおよび指定された住所に住んでいるユーザに製品を配達する指示を受信することができる。検索エンティティは、複数の販売業者が汎用カート内に製品を有する場合に異なる販売業者に割り当て可能である、サービスのための料金を請求することができる。この割り当ては、それぞれの販売業者からの各製品の相対的コストに基づくことができる。
【００３３】
[0033]第１の製品のためおよび第２の製品のための支払いを処理することは、第１のサイトから第１の製品の購入および配達を完了するために第１のサイトにブラウザ支払い要求アプリケーションプログラミングインターフェースを介して第１の情報を通信することと、第２のサイトから第２の製品の購入および配達を完了するために第２のサイトにブラウザ支払い要求アプリケーションプログラミングインターフェースを介して第２の情報を通信することとを含むことができる。ブラウザを使用して第１のサイト上でナビゲートするユーザによって閲覧される第１の製品に関連づけられた第１のデータを受信することはさらに、第１の製品に関連づけられた閾値ユーザ対話に基づいて第１のデータを受信することを含むことができる。たとえば、ユーザは、第１の製品をショッピングカート内に入れる、またはボタンをクリックする、または購入関心がある可能性があることを示すある時間の期間にわたって製品を閲覧することを必要とすることがある。
【００３４】
[0034]第１のサイトの観点からの方法は、第１のサイトから、ブラウザに関連づけられたブラウザショッピングカートアプリケーションプログラミングインターフェースを介して、ブラウザを使用して第１のサイト上でナビゲートするユーザによって閲覧された第１の製品に関連づけられた第１のデータを送信することと、ここにおいて、ユーザは第１のサイト上で製品を購入せず、ここにおいて、ブラウザは、第１のデータがブラウザによってアクセス可能であるように第１のデータを記憶することを管理することができる、ユーザが第１のサイトから離れて第２のサイトにナビゲートした後、第１の製品の支払いを処理するためにブラウザ支払い要求アプリケーションプログラミングインターフェースからデータのパッケージを受信することと、ここにおいて、データのパッケージは、第１の製品を識別し、第１の製品のための支払いを処理するためにユーザに関連づけられた支払いデータを含むことができる、ここにおいて、ユーザは、ブラウザアプリケーションプログラミングインターフェースを使用して第２のサイト上で第２の製品の購入を管理することの一部として提示されたブラウザ支払いインターフェースとの対話を介して第１の製品のための支払いを確認した、を含むことができる。第１のサイトにおいて受信されるデータのパッケージはさらに、第１の製品の配達のためにユーザのための住所情報を含むことができる。方法は、支払い方法を識別し、ショッピングカートを通信するために第１のサイトと第２のサイトの両方から必要とされる任意の通信と、ブラウザの支払い能力、製品データ、第１のサイト上でのユーザの検索に関連づけられたセッションデータ、ユーザデータ、支払いデータ、配達データ、サイズデータ、または第１の製品のための支払いを処理することもしくは異なるサイトからの複数の製品が単一のショッピングカートを介して購入可能であるように第１の製品および第２の製品をブラウザ支払い要求ＡＰＩに関連づけられたブラウザ支払いインターフェースへと集合することに関連づけられた他の任意のデータとを含むことができる。
【００３５】
[0035]ネットワークベースのエンティティが汎用ショッピングカートを管理するとき、販売業者は、一般的には、検索エンジンを介した検索または音声要求からの製品検索結果が製品を汎用カートに入れるためにユーザによって使用可能であるように、エンティティを用いて製品を登録する、または販売業者として登録する。製品は、複数のデバイスにわたって、複数の販売業者からカート内に置かれ得る。検索エンティティ、またはネットワークベースのエンティティは、製品が複数の異なるデバイスからショッピングカート内に置かれるときでも、さまざまな販売業者にわたって支払いプロセスを管理することができる。デバイスはすべて、同じアカウントまたはショッピングカートまたは個人に関連づけられるように協調可能である。協調は、ユーザを識別することによって複数のロケーションにわたっても発生することができる。
【００３６】
[0036]第１のサイトから宛先販売業者サイトへの遷移およびディープリンク状態を管理するための手法も開示される。方法態様は、製品のための広告または任意の種類の通知に関連づけられたオブジェクトとのユーザからの対話を受信することと、この広告または通知は、ブラウザ内で提示される第１のサイトを介して提示される、ディープリンク状態で第１のサイトから宛先販売業者サイトにユーザを遷移させることとを含む。遷移プロセスは、ブラウザからデータを取り出すことと、ユーザがディープリンク状態で第１のサイトから宛先販売業者サイトに遷移することを可能にするためにブラウザからのデータを使用することとを含む。ディープリンク状態は、ユーザが、支払いアカウントデータまたはユーザ住所データを手動で入力することなく購入オブジェクトとの対話を介して製品を購入することを可能にする。ディープリンク状態は、第１のサイトからの遷移後に「ワンクリック」購入経験を可能にすることができる。ブラウザからのデータは、一態様では、ブラウザと宛先サイトとの間でＡＰＩを介して取り出し可能である、または直接的にアクセス可能である。データは、支払いデータ、ユーザデータ、ワンクリック購入データ、住所情報、ブラウザ設定、暗号通貨データなどのうちの１つまたは複数であってよい。
【００３７】
[0037]オブジェクトは、買うボタンとすることができる。オブジェクトは、Ｆａｃｅｂｏｏｋニュースフィードなどの、第１のサイト上でのユーザのニュースフィード内に、広告とともに提示可能である。第１のサイトは、検索サイト、ゲームサイト、バーチャルリアリティ経験、販売業者サイト、メディアサイト、オーディオサイト、またはソーシャルネットワーキングサイトなどの任意の種類のサイトまたはアプリケーションであってよい。宛先販売業者サイト上の購入オブジェクトとの対話は、オブジェクトとの対話後のブラウザを介した第１の対話とすることができる。ブラウザからデータを取り出すことは、宛先販売業者サイトとブラウザとの間のブラウザ支払い要求アプリケーションプログラミングインターフェースを介して自動的に発生することができる。ユーザは、宛先販売業者サイトからさまざまな製品を購入するように購入オブジェクトとの対話を提供する前に、宛先販売業者サイト上で引き続きショッピングすることができる。ブラウザからのデータは、支払いデータ、住所データ、ワンクリック購入パラメータ、ユーザ名、ログイン情報、登録情報、ユーザ設定、およびユーザプロファイルデータ、のうちの１つまたは複数であってよい。他のデータも、ワンクリック購入経験を容易にするために使用可能である。
【００３８】
[0038]本開示は、いくつかの他の問題にも対処する。たとえば、ユーザが購入を完了する前に製品についてのより多くの情報を知り、製品についてのフォローアップ質問をすることを可能にするという問題がある。いくつかのケースでは、ワンクリック購入オプションまたは買うオプションは、サイズまたは色または他のパラメータなどのいくつかの追加データを必要とする製品に対するものであることがある。ユーザが、配達、不良な評判、不良なレビューなどについての他の懸念を有することがある。このシナリオでは、ユーザは、オブジェクトまたはそれ以外と対話することに基づいて、ダイアログアプリケーション完了情報に遷移され、ユーザ懸念を解消し、購入を確定することができる。遷移は、（ニュースフィード内の広告からメッセンジャーアプリケーションに）Ｆａｃｅｂｏｏｋなどの単一のサイト内とすることができる、または遷移は、いくつかのサイトにまたがることがある。たとえば、Ｆａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒアプリケーション（または任意のダイアログアプリケーション）に遷移することは、ユーザが質問を有するまたは製品についての他の選択肢を行うことを必要とする場合、任意の購入を完了する際に助けとなることができる。したがって、任意のサイトにおける、およびプロセスの任意の段階における、ダイアログアプリケーションへの遷移は、購入についてのユーザにさらなるデータを提供する助けとなるために発生することができる。１つの例示的な方法は、支払いプロセス開始オブジェクトに広告を提示することを含むことができる。支払いプロセス開始オブジェクトは、ユーザが検討の製品／品物についてのダイアログに関与し、購入を完了するダイアログアプリケーションへのリンクまたは遷移を含むことができる。遷移および検討は、質問が回答されるまたは情報が収集されると簡単な支払いが発生するように構成される。ブラウザＡＰＩは、任意のコンテキストにおいて、購入が発生することがある任意の段階で、展開可能である。メッセンジャーアプリケーションなどの任意のユーザインターフェースは、「ブラウザ」のようにみなすことが可能であり、購入経験を可能にするためにサイトとの通信を交換するように構成可能である。
【００３９】
[0039]この点に関して、例示的な方法は、ソーシャルネットワーキングサイトが投稿エンティティから投稿された品物を受信し、受信エンティティに送信するように、ソーシャルネットワーキングサイトを通しての品物の投稿を受信することを含む。投稿が、製品データベース内の購入のための製品に関連づけられていないとき、方法は、買うためのオプションなしでソーシャルネットワーキングサイトを通して投稿を送信することを含む。決定が、投稿が製品データベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、方法は、支払いオブジェクトまたは支払い開始オブジェクトとともにソーシャルネットワーキングサイトを通して投稿を送信することを含む。支払いプロセス開始オブジェクトは、製品に関連づけられており、ボタン、ドロップダウンメニュー、またはハイパーリンクのうちの１つを含むことができる。ソーシャルネットワーキングサイトは、支払いプロセス開始オブジェクトに関連づけられた対話を受信し、この対話は、ユーザによって実行される。購入対話に基づいて、方法は、ダイアログの終わりに、ユーザが製品の購入を完了することができるように、支払いプロセスの一部として製品に関するユーザとダイアログ内で関与することを含む。ダイアログのコンテキストとは別個の別の態様では、システムは、支払い対話に基づいて、ディープリンク状態で宛先サイトにユーザを遷移させることができ、このことは、ブラウザ内に記憶されたデータにアクセスすることを通して達成可能である。別の態様では、宛先サイトにおいて、ユーザは、宛先サイト内の買うオブジェクトをクリックすることができ、ブラウザＡＰＩを使用して、製品の支払いを処理するために支払い情報を要求して取り出すことができる。
【００４０】
[0040]ユーザがダイアログに遷移するとき、方法は、そのダイアログの一部として、ユーザから購入対話を受信することと、購入対話に基づいて製品の購入を処理することとを含むことができる。購入を処理することは、ソーシャルネットワーキングサイトのうちの１つの中で、支払いエージェントを介して、またはソーシャルネットワーキングサイトと製品を販売する販売業者サイトとの間、もしくはブラウザと販売業者サイトとの間でアプリケーションプログラミングインターフェースを介して、発生する。ソーシャルネットワーキングサイト、またはブラウザは、購入を処理するためにユーザの支払いデータを記憶することができる。購入が、ソーシャルネットワーキングサイトまたはブラウザと販売業者サイトとの間でアプリケーションプログラミングインターフェースを介して発生するとき、ソーシャルネットワーキングサイト、またはブラウザは、販売業者サイトが製品の購入を処理することができるように、アプリケーションプログラミングインターフェースを通して支払いデータを送信することができる。
【００４１】
[0041]ダイアログは、ユーザが、製品に関連づけられたパラメータを選択することを可能にすることができる。例示的なパラメータは、色、サイズ、形状、構成、および技術的特性のうちの１つまたは複数を含む。配達オプション、他の任意の懸念を解消すること、贈答問題、ディスカウント、クーポンなどは、ダイアログ内で管理可能である。支払いプロセス開始オブジェクトは、買うボタンまたは「ここをクリックして、この品物について話し、買う」という通知を単に含むことができる。ダイアログは、ダイアログアプリケーションを介してユーザと販売業者との間で管理可能である。ダイアログに関与することは、一態様では、ダイアログおよび製品の購入を管理するダイアログアプリケーションに遷移することによって達成可能である。
【００４２】
[0042]本開示内で対処される上記で識別された別の問題は、検索が第１のサイト上のユーザ入力フィールドで始まるときに提示されるオブジェクトを使用する。新しい手法は、第２のサイトにユーザを転送する機構を改善する。ブラウザのユーザインターフェースを介して、入力フィールド内のユーザ入力を受信し、このユーザ入力に応答してオブジェクトの第１のインスタンスを提示するための手法が開示される。言い換えれば、オブジェクトは、検索またはデータが入力フィールドへと入力されるまでユーザインターフェース上に示されない。これは、混乱を減少させる。オブジェクトは、ユーザがオブジェクトと対話するとき、ユーザがオブジェクトに関連づけられた第２のサイトに遷移され、ユーザ入力が第２のサイトの入力フィールドへと埋められるように構成される。ユーザ入力は、まるでユーザが第２のサイトの入力フィールドへとユーザ入力を入力したかのように、第２のサイトにおいて処理される。たとえば、ユーザが第２のサイトにおいて検索を示すためにテキストフィールド内に「ａｍａｚｏｎ」をタイプする必要はない。入力は、どのオブジェクトを提示するべきかを決定するためにシステムによって分析可能である、またはユーザが選ぶことができる代替検索モードを常に提示することができる。以前に説明されたｏｍｎｉｋｅｙ特徴を参照して、ユーザは、遷移する他の第２のサイトを追加することができ、各々は、どこに遷移するべきかブラウザに指示するその必要なキーワードをもつ。この手法に関する課題は、ユーザが、特定のウェブサイトに関連づけられたキーワードを覚えていなければならないであろうことである。「Ａｍａｚｏｎ」は、覚えやすいが、タイプするのは多くの文字である。ユーザは、ショートカット（Ｗｉｋｉｐｅｄｉａ．ｏｒｇの場合は「ｗｉｋｉ」のような）を忘れることがあり、または単に多すぎることがある。したがって、本明細書において開示される解決策は、特定のショートカットを覚える必要性をなくし、単純なクリックを通してあるサイトから別のサイトにユーザ入力を遷移するプロセスを単純化する。
【００４３】
[0043]本開示は、上記で識別された他の必要性にも対処する。たとえば、インターネット上のユーザの購入経験を改善する必要性が、本明細書において対処される。ショッピングカート購入モデルを埋めるフォームは、あまりにも多くのユーザ入力および対話を必要とし、購入を行うためにプロセスを実際に完了するユーザによる変換の数を減少させる。購入の支払いを処理するためにブラウザとサイトとの間で支払いデータを通信するための、および購入プロセスのために必要とされるユーザ対話の数を減少させる、ブラウザ支払い要求アプリケーションプログラミングインターフェースを有する更新されたブラウザが開示される。方法は、ユーザインターフェースを介して、サイトに関連づけられたオブジェクトとのユーザによる対話を受信すること、この対話は、購入を行うユーザ意図を示す、を含む。方法は、対話に基づいて、アプリケーションプログラミングインターフェースを介して、購入に関連した支払いデータのためにサイトから要求を受信することと、サイトに、アプリケーションプログラミングインターフェースを介して、支払いデータを送信することとを含む。支払いデータは、購入を確認し、または購入に関連づけられた製品を処理もしくは配達するために使用可能である。支払いデータは、購入を処理するために必要な任意のタイプの支払いデータを含むことができる。支払いデータは、アカウント番号、支払いデータのトークン化されたバージョン、住所情報、好み、発送選択肢、他のユーザデータなどを含むことができる。
【００４４】
[0044]本出願は、過度に煩わしいフォーム埋め込みを必要とすることから購入プロセスを除外する「ワンクリック」タイプの購入経験を可能にするための買うボタンおよびＡＰＩの開示を含む。本開示の別の態様では、購入を行う目的でフィールドにおける事前埋め込みのためにブラウザまたはエージェントと販売業者サイトとの間でデータを通信するためのＡＰＩが開示される。プロセスは、事前設定されたフィールドを埋めることを含むようにさらに改良可能であるだけでなく、ユーザのための対話型ステップの必要性を減少させるようにさらに簡素化可能である。ＡＰＩ手法は、ユーザが手動で入力しなければならないであろう同じフォームであるフォームに単に自動的に埋めるよりも高度であり得るデータを、販売業者サイトに提供することができる。方法は、一般化された検索エンティティが、一般化された検索エンジンを使用してデータを処理するように、一般化された検索エンティティのユーザインターフェース上に入力フィールドを提示することを含む。検索エンジンは、販売業者サイトと非販売業者サイトの両方にインデックスを付け、検索し、入力フィールド内のユーザ入力を受信する。ユーザ入力は、テキストベースの問い合わせを含み、検索エンジンは、このテキストベースの問い合わせを、販売業者からの販売のための製品の製品データベースと相関づけて、相関を生じさせる。この相関に基づいて、ユーザ入力が検索意図および購入意図のうちの１つに関連づけられているという決定が行われる。決定が検索意図を示すとき、非販売業者サイトを含む検索結果が提示される。非販売業者サイトに関連づけられた検索対話が受信され、非販売業者サイトへの遷移が実行される。決定が購入意図を示すとき、ユーザ入力に関連づけられた買うオプションを含む購入関係検索結果が提示される。購入関係検索結果は、ユーザが購入関係検索結果と対話し、買うオプションと対話することを介して購入を確認するとき、一般化された検索エンジン（または何らかの他の支払いサービス）が、品物の購入を処理することおよび購入関係検索結果に関連づけられた対話を受信することに参加するように構成される。
【００４５】
[0045]方法は、買うオプションとの対話を受信することと、一般化された検索エンティティ（または何らかの他の支払いサービス）において記憶された支払い情報に基づいて品物の購入を管理することとをさらに含むことができる。品物の配達は、一般化された検索エンティティとは別個の販売業者サイトを介して取り扱われる。一般化された検索エンジン（またはブラウザ）は、アプリケーションプログラミングインターフェースを介して販売業者サイトから支払いデータのための要求を受信することによって品物の購入を処理することに参加し、販売業者サイトが品物の購入を処理することができるように販売業者サイトに支払いデータを送信する。ブラウザは、ブラウザＡＰＩを通して、ブラウザＡＰＩを介して販売業者サイトに戻って通信するために、トークンを生成し、またはプロセスの何らかの一部を実行し、ブラウザに情報を戻すように提供することができる別個の支払いサービスと協調することもできる。
【００４６】
[0046]別の態様では、方法は、入力フィールドが、一般化された検索エンジンを使用してデータを処理することに関連づけられるように、ユーザインターフェース上に入力フィールドを提示することを含む。検索エンジンは、販売業者サイトと非販売業者サイトの両方にインデックスを付け、検索し、入力フィールド内のユーザ入力を受信する。ユーザ入力は、テキストベースの問い合わせを含み、検索エンジンは、このテキストベースの問い合わせを、販売業者からの販売のための製品の製品データベースと相関づける。相関が行われ、検索エンジンは、プロセッサを介して、相関に基づいて、ユーザ入力が検索意図および購入意図のうちの１つに関連づけられているかどうかを決定する。決定が検索意図を示すとき、非販売業者サイトを含む検索結果が提示され、非販売業者サイトに関連づけられた検索対話が受信され、非販売業者サイトに遷移することが実行される。決定が購入意図を示すとき、買うボタンの提示という結果になる購入関係検索結果とのユーザからの対話に基づいた、ユーザ入力に関連づけられた購入関係検索結果が提示される。買うボタンに関連づけられた品物の購入は、アプリケーションプログラミングインターフェースを通して支払いデータの要求を受信することによって、少なくとも一部は、管理される。この要求に基づいて、支払いデータが、品物の購入を処理するためにアプリケーションプログラミングインターフェースを介して販売業者サイトに送信される。方法は、販売業者サイトが販売業者サイトに送信された支払いデータに基づいて品物の購入を処理するように、ユーザからの対話に基づいて買うボタンに関連づけられた販売業者サイトに遷移することを含むことができる。
【００４７】
[0047]さらに別の態様は、ＡＰＩを介して販売業者サイトに支払いデータを通信するときにブラウザまたは検索エンジン側から処理することに関する。方法は、グラフィカルユーザインターフェース上で、プレゼンテーションを提示すること、このプレゼンテーションは、ネットワーク上でサイトから受信される、を含む。方法は、ユーザインターフェースを介して、ユーザから、プレゼンテーションとの対話を受信することと、アプリケーションプログラミングインターフェースを介して、ユーザに関する支払いアカウントデータの要求をサイトから受信することとを含む。方法は、支払いアカウントデータが、サイト上での支払い処理のために支払いフィールドにポピュレート（populate）するまたはユーザ対話を単純化するために支払いデータを使用してより高度な処理を実行するために使用可能であるように、サイトに、アプリケーションプログラミングインターフェースを介して、支払いアカウントデータを送信することも含む。プレゼンテーションは、購入のための製品およびサービスのうちの１つを含むことができる。方法は、サイトが、支払いを行うためにユーザに関する支払いアカウントデータを使用して品物のための支払いまたはサービスを処理することを可能にすることを含むことができる。グラフィカルユーザインターフェースは、ブラウザまたはアプリケーションに関連づけ可能である。一態様では、ＡＰＩは、サイト（販売業者サイト）とユーザに関する支払いアカウントデータを記憶することができるブラウザとの間でデータを通信する。
【００４８】
[0048]方法は、ユーザからの確認に基づいて、サイトが、ＡＰＩを通して受信された支払いアカウントデータを利用して、ユーザがサイト上の支払いフィールドを埋める必要なしに品物の購入またはサービスを処理することを可能にするように構成された買うオプションを含むように、プレゼンテーションを更新することをさらに含むことができる。ブラウザまたはＡＰＩを介して通信する他のエージェントは、「今すぐ支払う」タイプのボタンがサイトグラフィックスと一体化するためのグラフィックを提供することもできる。支払いアカウントデータは、ユーザに関する住所データ、支払いアカウント番号、有効期限、セキュリティコード、カード所有者名、およびユーザに関する発送指示、のうちの１つまたは複数をさらに含むことができる。一態様では、支払いアカウントデータは、たとえば、複数のクレジットカードなどの、複数の支払いの方法を含むことができる。
【００４９】
[0049]ＡＰＩを通しての要求は、サイトのためにサポートされる支払い方法、購入の総量値、購入のために表示され得る品物、発送オプション、支払い修飾子、ユーザ電子メールアドレスの要求、ユーザの電話番号の要求、および情報を更新する要求、のうちの１つまたは複数をさらに含むことができる。ブラウザに類似したまたはこれとは別個のユーザエージェントが、アプリケーションプログラミングインターフェースとサイトとの間で支払いアカウントデータを通信することができる。
【００５０】
[0050]別の態様では、方法は、サイトの観点からの概念を含む。このコンテキストにおける方法は、グラフィカルユーザインターフェース上で閲覧するために、プレゼンテーションを送信することと、このプレゼンテーションは、ネットワーク上のサイトからグラフィカルユーザインターフェースを有するデバイスに送信される、ネットワークを介して、ユーザから、プレゼンテーションとの対話を受信することとを含む。方法は、アプリケーションプログラミングインターフェースに、ユーザの支払いアカウントデータの要求を送信することと、サイトにおいて、アプリケーションプログラミングインターフェースを介して、支払いアカウントデータを受信して、支払いプロセスに関連づけられた支払いデータフィールドにユーザに関する支払いアカウントデータをポピュレートして、ポピュレートされた支払いデータフィールドをもたらすこととを含む。サイトは、ユーザに関する支払いアカウントデータを使用して品物の支払いまたはサービスを処理することができる。支払いデータは、１回限りの支払いプロセスのためのデータのトークン化されたパケットとすることができる。ＡＰＩは、ブラウザがユーザに関する支払いアカウントデータを記憶するように、ブラウザとサイトとの間でデータを協調させることができる。プレゼンテーションに関連づけられた品物またはサービスの購入を行うためにユーザから確認を受信すると、方法は、受信されたデータを使用して製品の支払いを処理することを含むことができる。
【００５１】
[0051]方法は、支払いアカウントデータを受信すると、ユーザからの確認に基づいて、ユーザがサイト上の支払いデータフィールドを手動で埋める必要なしにサイトが支払いアカウントデータを利用して製品またはサービスの購入を処理することを可能にするように構成された買うオプションを含むようにプレゼンテーションを更新することをさらに含むことができる。支払いアカウントデータは、トークン、ユーザに関する住所データ、支払いアカウント番号、有効期限、セキュリティコード、カード所有者名、およびユーザに関する発送指示、のうちの１つまたは複数をさらに含むことができる。プレゼンテーションは、サイトのためにサポートされる支払い方法、購入の総量値、購入のために表示され得る品物、発送オプション、支払い修飾子、ユーザ電子メールアドレスの要求、ユーザの電話番号の要求、および情報を更新する要求、のうちの１つまたは複数をさらに含むことができる。ユーザエージェントも、アプリケーションプログラミングインターフェースとサイトとの間で支払いアカウントデータを通信することができる。別の態様では、方法は、グラフィカルユーザインターフェース上で、プレゼンテーションを提示することと、このプレゼンテーションはネットワーク上のサイトから受信される、ユーザインターフェースを介して、ユーザから、プレゼンテーションとの対話を受信することとを含む。方法は、アプリケーションプログラミングインターフェースを介して、サイトからユーザに関する支払いアカウントデータの要求を受信することと、プレゼンテーションに関連づけられた支払いフィールドに支払いアカウントデータを自動でポピュレートすることと、サイトに、アプリケーションプログラミングインターフェースを介して、支払いアカウントデータを送信することとを含む。サイトは、ユーザに関する支払いアカウントデータに基づいて支払いを処理することができる。方法は、支払いフィールドが自動でポピュレートされた後にユーザからの購入の確認を受信することも含むことができる。
【００５２】  [0052]本開示は、ａｍａｚｏｎ．ｃｏｍによって提供されるが、ｇｏｏｇｌｅ．ｃｏｍ、ｆａｃｅｂｏｏｋ．ｃｏｍ、ａｍａｚｏｎ．ｃｏｍなどの複数の異なる会場にまたがる購入を相関づけるように拡張されるなどの、オンライン購入のユーザアカウントを管理する課題にも対処する。購入を現在個々に管理する複数の異なるタイプのサイトにおよびそれから情報を通信するように設計されたＡＰＩが開示される。たとえば、ＡＰＩは、Ｇｏｏｇｌｅの買うボタン（Ｇｏｏｇｌｅ上の購入）、Ｆａｃｅｂｏｏｋの買うボタン、Ｐｉｎｔｅｒｅｓｔの買うボタン、Ａｍａｚｏｎ．ｃｏｍの購入などを通して行われた購入についての変換データを受信することができる。購入管理エンジンは、さまざまなデータを受信し、そのデータを、複数の購入プラットフォームにまたがる単一のユーザアカウントへと相関づける。アカウントは、ブロックチェーン上にも記憶可能である。この手法は、Ａｍａｚｏｎ．ｃｏｍユーザアカウントはａｍａｚｏｎ．ｃｏｍにおいて行われた購入に関してのみ維持され、ｇｏｏｇｌｅ．ｃｏｍまたはｆａｃｅｂｏｏｋ．ｃｏｍなどの異なるタイプのサイトからの購入に関しては維持されないので、ａｍａｚｏｎ．ｃｏｍのユーザアカウントと異なる。しかしながら、相関づけられたデータは、ａｍａｚｏｎ．ｃｏｍ上で購入を管理する利点のすべてに加えて、ａｍａｚｏｎ．ｃｏｍのユーザアカウントも、ｇｏｏｇｌｅ．ｃｏｍ、ｆａｃｅｂｏｏｋ．ｃｏｍ、ｉｎｓｔａｇｒａｍ．ｃｏｍ、ｐｉｎｔｅｒｅｓｔ．ｃｏｍ、ｙｏｕｔｕｂｅ．ｃｏｍ、および他のサイト購入にポピュレート可能であるように、ａｍａｚｏｎ．ｃｏｍのようなインターフェースに送信可能である。完全な相関づけられたデータは、実際に、従来の非販売業者サイト、（（公序良俗違反につき、不掲載）またはｗｉｄｇｅｔｓ．ｃｏｍのような）個々の販売業者サイト、ならびにａｍａｚｏｎ．ｃｏｍのいずれにおいても提示可能である。相関づけられたデータが提示される手段は、購入が行われた買うボタンサイトなどのａｍａｚｏｎ．ｃｏｍによって企図されていない特徴の追加を伴うａｍａｚｏｎ．ｃｏｍを用いるように、ユーザ定義可能である。したがって、ユーザインターフェースは、ｇｏｏｇｌｅ．ｃｏｍから購入された製品、それに続いてｆａｃｅｂｏｏｋ．ｃｏｍから購入された製品、それに続いてａｍａｚｏｎ．ｃｏｍから購入された製品を提示することがある。
【００５３】
[0053]したがって、本明細書において開示される概念は、誰かが購入を行うことを望むが機会を拡大する瞬間だけを伴うことから、「微小な瞬間」について詳しく説明する。ユーザが経験し得る微小な瞬間は、おそらく、前日行われた購入をキャンセルしたい、または昨日の１回の購入のような別の製品を買いたいという要望とすることができる。このようにして、サイト上の、または買うオプションの近くに位置決めされた、ドロップダウンメニューを通して、システムは、ユーザが自分のアカウントにアクセスし、さらなる変更／修正を行うことを可能にする「ユーザアカウント」アクセスオプションを提示することができる。相関およびＡＰＩのために、修正は、すべてのプラットフォームにわたって容易に行われ得る。したがって、１つのユーザインターフェース上で、ユーザは、前日Ｇｏｏｇｌｅの買うボタンを介して購入されたものに加えて余分なウィジェットを買い、ならびにその朝Ｆａｃｅｂｏｏｋを介して行われた購入をキャンセルすることができる。
【００５４】
[0054]上記で説明された購入は、多くの場合に、サイト（Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、Ａｐｐｌｅ  Ｐａｙ、Ａｎｄｒｏｉｄ  Ｐａｙ、Ｓａｍｓｕｎｇ  Ｐａｙなど）と、販売業者（支払いを取り扱っても取り扱わなくてもよいが、一般的には配達を取り扱く）と、配達サービス（Ｆｅｄｅｒａｌ  Ｅｘｐｒｅｓｓ、ＵＰＳなど）との間で協調されるので、提示されるＡＰＩは、どのようなアクションが起きることが必要であっても協調させるために、必要に応じて複数の異なるサイトおよびサービスプロバイダとインターフェースする。したがって、以下のアクションのうちの１つまたは複数は、購入管理エンジンと、販売業者と、ａｍａｚｏｎ．ｃｏｍ（など）と、買うボタンサイト（Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍなど）との間でＡＰＩのどちらの側にも分割可能である。（１）追加の購入を処理すること、（２）購入をキャンセルすること、（４）それを再度買う選択肢を実施すること、（５）製品の返品を提供すること、（６）製品レビューを書くこと、（７）パッケージを追跡すること、（８）配達スケジュールを変えること、（９）支払い方法を変更すること、（１０）苦情を申し立てること、および（１１）買い手、受信者、販売業者、配達提供者、買うボタンサイトその他のうちの１つまたは複数に、取られる任意のアクションの通知を送信すること。
【００５５】
[0055]製品管理エンジンは、異なるプラットフォームにわたって起きることを必要とするさまざまなアクションを協調させることができる。したがって、ユーザが、Ｆａｃｅｂｏｏｋサイトを介して、自分のユーザアカウントに行き、購入をキャンセルする場合、製品配達エンジンは、販売業者、サイト、配達サービスなどにアクションを実施するように通知することなど、さまざまなアクションを協調させることができる。
【００５６】
[0056]別の態様では、製品管理エンジンを介して製品の管理を通して得られる知識およびデータは、広告主にさらに提供可能であり、次いで、広告主は、サイトのいずれかを通して広告または買うボタンオプションをよりインテリジェントに提供することができる。加えて、データは、ユーザがそれを許可した場合、ソーシャルネットワーキングサイトを通して友人または仲間と共有可能である。たとえば、特定の人間が自分のために通常品物のどのサイズまたは色を購入するかについてのデータが、将来の贈答機会のために共有可能である。ソーシャルネットワーク上の友人または仲間は、製品管理エンジンを使用して、贈り物として品物を重複させるのを回避するために、ユーザが過去に特定の品物を購入したかどうかを決定することができる。たとえば、ユーザは、友人Ｂｏｂが去年任意のＬｅｇｏセットを購入したかどうかかどうかを決定するためにエンジンに問い合わせることができる。Ｂｏｂに対する贈り物としてＬｅｇｏセットを購入する決定は、問い合わせ結果が受信された後に、行われ得る。
【００５７】
[0057]ユーザがユーザアカウントにアクセスすることができる「アカウントボタン」はまた、ユーザに対してクリエイティブに提示可能である。たとえば、買うボタンが、本明細書において開示されるように提示されるとき、「購入を管理する」なども提示可能である。そのようなボタンはまた、１つまたは複数の層が提供されてプロセスをなすことができる。たとえば、多くの場合、買うオプションが対話されるとき、ユーザは、製品についてのより多くの詳細、製品を販売する販売業者についての情報、および買うオプションを通して買う機会（本明細書において開示されるように販売業者サイトから他の場所に記憶された購入アカウント情報を使用して）が提示される。この段階では（買うオプションと対話した後だが、完全な購入へと実際に変換する前に）、ユーザが、購入を考慮するモードにあることが知られており、購入履歴をチェック／管理することを望むことがあるので、「購入を管理する」オプションが提示される。購入アカウントからの情報は、広告または応答のプレゼンテーションを買うオプションとの対話におそらく調節するためにも使用可能である。
【００５８】
[0058]本明細書において開示される他の技術革新は、集合購入を行うために複数のウェブサイトにわたってショッピングカート項目を記憶するためにブラウザＡＰＩを利用するクロスサイトショッピングカートを含む。この手法は、たとえば、ブラウザショッピングカートＡＰＩおよびブラウザ支払い要求ＡＰＩの組み合わせを使用して、その各々がブラウザ支払い要求ＡＰＩを介して別個のワンクリック購入手法を使用する、３つの異なるサイトにわたる３つの異なる購入を、集合単一のワンクリック購入プロセスへと減少させることができる。
【００５９】
[0059]さらに別の技術革新は、バーチャルリアリティ、メディア閲覧などの他のコンテキストにおいてブラウザ支払い要求ＡＰＩを適用することを含む。任意のユーザインターフェースはブラウザとみなすことが可能であり、ブラウザ支払い要求ＡＰＩの基本構造およびプロトコルは、ワンクリック購入機会が利用可能にされ得るように、他のシナリオでも実施可能である。
【図面の簡単な説明】
【００６０】
【図１】[0060]システムアーキテクチャを示す図。
【図２Ａ】[0061]例示的な検索フィールドを示す図。
【図２Ｂ】[0062]ユーザ入力を処理するための例示的な方法を示す図。
【図３】[0063]本開示の一態様によるドロップダウンおよびドロップアップメニューを示す図。
【図４Ａ】[0064]本開示の一態様による、第１の例示的な、結果として生じるインターフェースを示す図。
【図４Ｂ】[0065]本開示の一態様による、第２の例示的な、結果として生じるインターフェースを示す図。
【図４Ｃ】[0066]口頭でのダイアログを通して支払いオプションを提供するための方法例を示す図。
【図５】[0067]検索入力に関係するワンクリック購入オプションを提示するための方法例を示す図。
【図６】[0068]受信されたユーザ入力に応答した、結果として生じる別のグラフィカルインターフェースを示す図。
【図７】[0069]例示的なシステム例を示す図。
【図８】[0070]ユーザからの選択を処理するための例示的な方法例を示す図。
【図９】[0071]例に関連づけられたユーザインターフェースを示す図。
【図１０】[0072]別のソースから統合されたユーザインターフェースに向けられた入力に基づいてアクションを遂行するための方法例を示す図。
【図１１】[0073]修正可能なエントリボタンのための例示的な方法例を示す図。
【図１２Ａ】[0074]例示的な修正可能なエントリボタンを示す図。
【図１２Ｂ】[0075]修正可能なエントリボタンをもつ入力フィールドへの入力を示す図。
【図１２Ｃ】[0076]入力フィールドへのユーザタイプとして発生するさまざまな変更および修正を示す図。
【図１２Ｄ】入力フィールドへのユーザタイプとして発生するさまざまな変更および修正を示す図。
【図１２Ｅ】[0077]入力におけるユーザタイプとして発生する修正の方法態様を示す図。
【図１２Ｆ】[0078]ユーザ入力におけるユーザタイプとして発生する修正の別の方法態様を示す図。
【図１３】[0079]例示的なユーザインターフェースを示す図。
【図１４Ａ】[0080]検索アプリケーションプログラミングインターフェース（ＡＰＩ）の動作のための例示的な方法例を示す図。
【図１４Ｂ】[0081]処理の検索エンジン側から検索アプリケーションプログラミングインターフェース（ＡＰＩ）の動作のための別の例示的な方法を示す図。
【図１４Ｃ】[0082]処理の販売業者側から検索アプリケーションプログラミングインターフェース（ＡＰＩ）の動作のための別の例示的な方法を示す図。
【図１５】[0083]アプリケーションプログラミングインターフェース（ＡＰＩ）を介した通信を示す図。
【図１６】[0084]例示的な修正されたブラウザインターフェースのための例示的な方法例を示す図。
【図１７Ａ】[0085]例示的なブラウザインターフェースを示す図。
【図１７Ｂ】[0086]事前にポピュレートされたタブをもつ例示的なインターフェースを示す図。
【図１７Ｃ】[0087]例示的な方法を示す図。
【図１７Ｄ】[0088]別の例示的な方法を示す図。
【図１７Ｅ】[0089]ブラウザＡＰＩを使用する方法を示す図。
【図１７Ｆ】[0090]ブラウザＡＰＩを使用するための別の方法を示す図。
【図１７Ｇ】[0091]ブラウザＡＰＩのためのユーザインターフェースを示す図。
【図１７Ｈ】[0092]ブラウザＡＰＩのための別のユーザインターフェースを示す図。
【図１７Ｉ】[0093]持続的なブラウザショッピングカートＡＰＩを示す図。
【図１７Ｊ】[0094]ショッピングカートブラウザＡＰＩのための方法を示す図。
【図１７Ｋ】[0095]ショッピングカートのためのインターフェースを示す図。
【図１７Ｌ】[0096]クロスサイトショッピングカートのための方法実施形態を示す図。
【図１７Ｍ】[0097]サイトの観点から方法実施形態を示す図。
【図１８Ａ】[0098]販売業者ショッピングカートを事前にポピュレートすることおよびブラウザＡＰＩの使用のための例示的なアーキテクチャを示す図。
【図１８Ｂ】[0099]ブラウザＡＰＩのための方法実施形態を示す図。
【図１８Ｃ】[00100]ブラウザＡＰＩのためのさらに別の方法実施形態を示す図。
【図１８Ｄ】[00101]ブラウザの観点から支払いプロセスを管理するために２つのＡＰＩを使用する別の実施形態を示す図。
【図１８Ｅ】[00102]支払いプロセッサの観点から支払いプロセスを管理するために２つのＡＰＩを使用する別の実施形態を示す図。
【図１８Ｆ】[00103]販売業者サイトの観点から支払いプロセスを管理するために２つのＡＰＩを使用する別の実施形態を示す図。
【図１８Ｇ】[00104]複数の支払い方法選択肢のための別の方法実施形態を示す図。
【図１８Ｈ】[00105]証明書管理ＡＰＩ実施形態を示す図。
【図１９】[00106]事前にポピュレートされた販売業者ショッピングカートのための例示的なユーザインターフェースを示す図。
【図２０Ａ】[00107]販売業者ショッピングカートを事前にポピュレートすることに関係する例示的な方法を示す図。
【図２０Ｂ】[00108]第１のサイトから販売業者エンティティサイトおよびディープリンク状態に遷移するための例示的な方法を示す図。
【図２０Ｃ】[00109]販売業者サイトの観点から、第１のサイトから販売業者サイトおよびディープリンク状態に遷移するための別の例示的な方法を示す図。
【図２０Ｄ】[00110]第１のサイトから遷移を受信するために販売業者サイトの観点から例示的な方法を示す図。
【図２１】[00111]一般化された非購入検索または購入する意図をもつ検索のうちの１つとしてユーザ意図を決定するための方法例を示す図。
【図２２】[00112]図２１に示される方法例とともに使用可能である構成要素のいくつかを示す図。
【図２３】[00113]ウェブサイトを介した検索の代わりのアプリケーションベースの検索ポータルのための方法例を示す図。
【図２４】[00114]インターフェース間の遷移タイプを選択するための方法例を示す図。
【図２５】[00115]広告を提示するための方法例を示す図。
【図２６】[00116]宛先ウェブサイトの小型バージョンを提示するための方法例を示す図。
【図２７】[00117]前処理された状態におけるさまざまな宛先サイトとともにユーザインターフェースを示す図。
【図２８Ａ】[00118]別の方法例を示す図。
【図２８Ｂ】[00119]さらに別の例示的な方法を示す図。
【図２９】[00120]別の方法態様を示す図。
【図３０】[00121]Ｆａｃｅｂｏｏｋ方法例を示す図。
【図３１】[00122]Ｐｉｎｔｅｒｅｓｔタイプソーシャルメディア方法例を示す図。
【図３２】[00123]購入マネージャのための例示的な環境を示す図。
【図３３】[00124]購入マネージャとさまざまなエンティティとの間のさらなる対話を示す図。
【図３４Ａ】[00125]管理購入アクセスボタンとともに今すぐ買う広告を示す図。
【図３４Ｂ】[00126]購入マネージャのためのアカウントインターフェースを示す図。
【図３５】[00127]購入マネージャのためのアカウントインターフェースの別の例を示す図。
【図３６】[00128]別の方法例を示す図。
【図３７】[00129]ブラウザタイプまたはアカウントタイプに基づいて買うボタンを修正する例方法を示す図。
【図３８】[00130]買うボタンを修正する別の例を示す図。
【発明を実施するための形態】
【００６１】
[00131]以下の開示は、オンライン購入を単純化すること、インターネット上でのナビゲーションを単純化すること、統一された入力検索フィールドを提供すること、改善された購入経験のためのブラウザ支払い要求アプリケーションプログラミングインターフェースを提供すること、およびソーシャルメディアネットワークを改善すること、ならびに他の技術革新に関係する、いくつかの異なる技術革新を説明する。したがって、本開示は、ある技術革新から別の技術革新に進み、任意の個々の特徴は、他の任意の特徴または例に関連して利用可能である。
【００６２】
[00132]本開示のさまざまな例が、以下で詳細に説明される。特定の実装が説明されるが、これは、例示のためにのみなされることが理解されるべきである。他の構成要素および構成が、本開示の趣旨および範囲から分かれることなく使用されてよい。特定の方法例が検討されているが、方法例のさまざまなステップは、追加ステップを含む、または特定のステップを除外する、さまざまな順序で、組み合わせて、または置き換えて実施可能である。
【００６３】
[00133]検討される第１の技術革新は、インターネット上の検索機能を改善する統一された入力検索フィールドの概念である。ユーザが１つのロケーションを訪問することのみを必要とするように複数のウェブサイトまたは他の情報ソースへのアクセスを統一し、１つの入力検索フィールドを利用して、検索を実行することまたは製品を購入することなどの、いくつかの異なる潜在的な結果を達成するシステム、方法、およびコンピュータ可読記憶デバイスが開示される。その１つのロケーションは、ウェブサイト、ウェブブラウザ内の検索バー、デスクトップ、ラップトップ、スマートフォン、タブレット、または他のモバイルデバイスの上のアプリケーションなどであることができる。ウェブサイトのコンテキストにおいて検索を実行するためにそのウェブサイトにナビゲートするのではなく、ユーザは、代わりに、一般化された検索フィールドにナビゲートするまたはそれを開くことができる。検索フィールドは、Ｇｏｏｇｌｅ（登録商標）、Ｙａｈｏｏ（登録商標）、またはＢｉｎｇ（登録商標）によって提供される検索エンジンなどの、大規模に他のウェブサイトを巡回してインデックスを付ける検索エンジンへのアクセスを提供することができる。一例では、「大規模に」は、少なくとも２５，０００の異なるドメインを巡回してインデックスを付けることを意味することができる。検索フィールドは、より大きいまたはより小さい巡回ドメインに適用可能である。したがって、一般化された検索エンジンは、購入を行いたいというユーザの意図を示し得る検索を識別し、その意図に従って行動するために迅速に容易なアクセスをユーザに提供する副機能を同時に提供しながら、検索問い合わせに応答して結果をサービスする主な機能を提供することができる。
【００６４】
[00134]一般化された検索フィールドを介して、システムは、ユーザからの入力および結果として得られるコンテキストを暗黙的にまたは明示的に処理および分析することができる。システムは、最近閲覧したまたは開いたウェブページおよびユーザがコンピューティングデバイス上で実行した最近のアクションなどの、ユーザに関する既存のコンテキストのコーパスに基づいて、分析することもできる。最近のアクションは、ユーザに関するカレンダー情報、ロケーションデータ、最近の購入または他のトランザクション、投稿を含むソーシャルネットワーキングデータ、友人に送信されたメッセージ、友人の誕生日、ＹｏｕＴｕｂｅ（登録商標）上で閲覧されたビデオなどを含むことができる。システムは、データソースとして、入力を理解または処理するための直接的または間接的なコンテキストを提供することができる任意の情報を組み込むことができる。たとえば、以前の検索履歴または購入履歴は、直接的なコンテキストを提供することができ、ユーザの友人のソーシャルメディア投稿は、間接的なコンテキストを提供することができる。
【００６５】
[00135]したがって、検索が入力された後、ユーザは、第２にウェブサイトに行く。この手法は、購入を行うウェブページまたは検索結果のウェブページに到達するために、ユーザがブラウザまたはアプリケーションを開いたときに始まって、対話の数を減少させる。
【００６６】
[00136]別の態様では、ドロップダウンまたはドロップ「アップ」メニューが、ワンクリック購入などのオプションを処理するまたはテキスト入力を検索データとして使用してｅＢａｙ（登録商標）などの特定のウェブサイトを検索するためのさらに豊富な機会を提供する。これらのドロップダウンまたはドロップ「アップ」メニューは、検索入力ボックス、検索ボタン、またはユーザインターフェース内の何らかの他の要素のロケーションに基づくことができる。選択可能なオブジェクトが、ユーザが入力を入力した後、第１のインスタンスにおいて提示可能であり、オブジェクトは、ユーザインターフェース上の任意の場所に提示可能である。さらに別の態様では、一般化された検索フィールドは、１つまたは複数の検索ソースから‘従来の’検索結果を依然として提供することができるが、従来の検索結果に加えて、ユーザがたとえば検索結果のリストから直接的に購入を行うために使用することができるワンクリックアクションを提示することができる。
【００６７】
[00137]本開示は、ユーザがユーザ入力を提供し、非常に少ないステップで、購入を完了すること、検索を遂行すること、プログラムを遂行すること、またはオンラインサービスと対話することなどの目的のセットの１つを達成することを可能にする統一された検索フィールドを提供することによって、現在の検索実装における上記で示された欠陥を克服する。ユーザは、テキストとして、またはマルチモーダル入力、ジェスチャ入力、音声入力などを含む他の任意の適切な形で、ユーザ入力を提供することができる。本開示がユーザからの「入力テキスト」または「テキスト」を指すとき、その入力は、テキストとして、または何らかの他の入力モダリティを介して、提供可能であることが理解される。システムは、ウェブ検索などの従来のオプションを使用してユーザ入力を処理することができるが、加えて、システムは、他のウェブサイト上での購入オプションまたはより的を絞った検索オプションを識別する、提示する、および／または遂行するためにユーザ入力を処理することができる。ユーザ入力の処理の柔軟性が拡張するので、システムは、タグクラウドまたはドロップダウンメニューまたはドロップアップメニューまたは横にドロップするメニュー内で、これらのオプションを提示することができる。
【００６８】
[00138]第１の例による基本概念が、以下で示される。例示的なウェブサイトｗｗｗ．ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍは、入力フィールドまたは検索フィールドをもつユーザインターフェースを含むと仮定する。入力フィールドは、たとえば、テキスト入力フィールドとすることができ、またはスピーチ認識を利用して、認識されたスピーチからのテキストをフィールドにポピュレートする音声入力フィールドとすることができる。フィールドは、ブラウザ検索フィールドとすることができる。フィールドは、単なる検索フィールドでなく、ユーザによって提供される決定された入力の意図に基づいて複数の機能が実行可能である、より一般的な入力フィールドである。この検索フィールドは、ｗｗｗ．ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ検索フィールドが入力をどのように処理するかに関して、他の検索フィールドと異なる。通常、ある人間が、ウェブページに到達して、次いで検索し、または検索ウェブサイトを選び、次いで、検索フィールドが、検索のための特定のウェブサイトのコンテキストで条件づけされる。本開示では、ユーザがデータを一般化された入力フィールドへと入力するとき、検索のコンテキストはオープンである。それがＧｏｏｇｌｅ検索またはＡｍａｚｏｎ検索であるという推定または設定はない。結果として得られるコンテキストは、入力の分析に依存する。ユーザインターフェースは、いくつかの異なる検索または処理ボタンを含むことができ、その各々は、入力テキストに対して実行するように処理のタイプを拡張することができる。異なるタイプのボタンは、Ｇｏｏｇｌｅ検索ボタン、Ａｍａｚｏｎ検索ボタン、Ａｍａｚｏｎワンクリック購入ボタン、およびＡｐｐｌｅ．ｃｏｍ購入ボタンを含むことができる。システムは、さまざまなボタンタイプを前もって確立および提供することができる。あるいは、ユーザは、ユーザが何らかの規則性をもって実行することを要望するまたは予想するタスクのための個別化されたボタンの集合をセットアップすることができる。システムは、ユーザの一般的な検索およびアクティビティ傾向、現在のプロモーション、設置の代金を支払う広告主などに基づいて、これらのボタンを生成および提示することができる。ボタンの代わりにまたはこれに加えて、ユーザがフィールドへと入力をタイプするので、システムは、検索結果であろうと、購入であろう、オークションであろうと、または他の任意のウェブサイト宛先であろうと、ユーザに関する宛先とすることができるさまざまなウェブページへと、「ピーク」を提示することができる。この点に関して、最初にウェブサイトに行き、次いで検索フィールドへと検索を入力するのではなく、本開示は、一般的な入力フィールド内にデータを入力し、次いでウェブサイトに行くこと、または購入を行うことと、より改善された入力を処理するさまざまな手段に焦点を当てる。一態様では、オブジェクトは、ユーザが入力フィールド内にデータをタイプし始めた後でのみ、提示される。ユーザがタイプし始めた後に、ドロップダウンメニュー内などの第１のインスタンス内にオブジェクトを導入することは、ユーザインターフェースに対する混乱を減少させ、ユーザが入力を入力する前にユーザインターフェース上��提示することが実現可能でないであろう、メニュー内で選択されることになる複数のオプションを提供することができる。
【００６９】
[00139]Ａｍａｚｏｎまたはオークションウェブサイトのケースなどにおいて、ユーザがｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにナビゲートするとき、Ａｍａｚｏｎ．ｃｏｍに登録されたユーザのケースと同様に、ユーザ情報、デビット／クレジットカード情報、住所情報などが、ユーザプロファイル内に記憶され、利用可能であることが推定される。たとえば、登録または入会プロセスの一部として、ユーザは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍとともにアカウントを確立し、他のウェブサイトにおけるアカウントとｏｎｅ−ｓｅａｒｃｈ．ｃｏｍアカウントを結び付けるために証明書を認証または提供することができる。そのため、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにアカウントを作成することの一部として、ユーザは、Ｇｏｏｇｌｅ．ｃｏｍ、Ａｍａｚｏｎ．ｃｏｍ、ｅｂａｙ．ｃｏｍ、ｎｅｗｅｇｇ．ｃｏｍ、ｔｈｉｎｋｇｅｅｋ．ｃｏｍ、およびｃｈｅａｐｅｒｔｈａｎｄｉｒｔ．ｃｏｍに関する証明書を提供することができる。あるいは、ユーザは、証明書を提供することなくアカウントを‘結び付ける’ことができる。たとえば、ユーザは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにＡｍａｚｏｎ証明書を提供することなく彼または彼女のＡｍａｚｏｎプロファイルに関連づけられたユーザの情報のすべてまたは一部を共有するように、Ａｍａｚｏｎを許可することができる。
【００７０】
[00140]次いで、ユーザがｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにおいて検索を実行するとき、システムは、既存の結び付けられたアカウントを使用して、ワンクリックアクション、または一機能（スピーチ、ジェスチャ、マルチモーダル入力など）アクションを生成することができる。たとえば、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍは、ユーザが、提示された買うオプションと対話するとき、購入アクションを実行することができる。ユーザは、次いで、ユーザポータルまたはユーザ管理インターフェースを介して、追加のアカウントを結び付ける、証明書を更新する、結び付けられたアカウントを削除する、または結び付けられたアカウントのどの部分がｏｎｅ−ｓｅａｒｃｈ．ｃｏｍと共有されるかを管理するために、結び付けられたアカウントを管理することができる。いくつかのウェブサイトは、結び付けられたアカウントを必要としないことがあるが、依然として、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ検索フィールドへと組み込み可能である。これは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍの登録されたアカウントを介してその販売業者に関連づけられた品物に関する支払いを処理し、販売業者が配達を取り扱うことを可能にすることによって、達成可能である。いくつかの電子商取引サイトは、ゲストアカウントを用いた購入を許可し、そのケースでは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍアクションは、購入を完了するために、電子商取引サイトにナビゲートすること、所望の品物をカートに追加すること、支払い情報、配達住所などのユーザについての十分な情報を提供することを含むことができる。別の例では、検索エンジンなどのいくつかのウェブサイトは、アカウントに結び付けられたときに強化可能であるが、結び付けられたアカウントを必要としない。これらの状況では、ユーザは、購入を処理するために既存のアカウントを検索エンジンと結び付けるべきかどうか、または結び付けられたアカウントなしで検索エンジンを使用するべきかどうかを決定することができる。
【００７１】
[00141]ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍウェブサイトは、他のサイトからのブラウザクッキーを検査し、これを使用して、ユーザデータを集め、検索履歴、またはクッキー内に記憶されたもしくはそれを介して利用可能にされた他の任意の情報を集めることができる。ユーザ支払いおよび住所情報、ならびに他の任意のタイプのデータは、ブラウザ内に記憶可能である、またはブラウザによってアクセス可能である。システムは、たとえば、セッションクッキーを使用して、ユーザが特定のウェブサイトとのアクティブなセッションを有するまたは有していたと決定することができ、セッションクッキー内の情報を使用して、ユーザにより提供された入力に応答して購入を遂行するためにワンクリックページのためのＵＲＬを構築することができる。あるいは、システムは、ライブセッションを使用して、ウェブサイトをナビゲートし、所望の品物をショッピングカートに追加し、ユーザに代わって支払いおよび発送情報をポピュレートして、および精算プロセスにおける最終段階をユーザに提示することができ、そのため、ユーザは、購入を完了するために、単に、「発注する」ボタンを一度クリックする、またはｏｎｅ−ｓｅａｒｃｈ．ｃｏｍの統一された入力フィールド内で「ｅｎｔｅｒ」を打つことができる。このようにして、検索から購入までの（または検索から何らかの他のアクションを実行するまでの）ステップの数が激減される。本明細書において提供される例の多くは、購入を行うことについて検討するが、本明細書において開示される原理は、他の非購入トランザクションにも適用可能である。たとえば、システムがウェブサイトにナビゲートし、ショッピングカートに品物をポピュレートし、ユーザの代わりに発送および支払い情報を埋めることができるほぼ同じ手段では、システムは、情報のセットが提供されることを必要とする結果のために、何らかの他のウェブサイトにもナビゲートすることができる。ユーザが、「なぜ私のクレジットスコアがちょうど低下したのですか？」というテキストを入力フィールド内に入力した場合、システムは、主要なクレジット報告事務局、サードパーティクレジット報告集合サービス、または無料クレジット報告サイトのうちの１つを識別することができる。システムは、ユーザに代わって、クレジットスコア情報に到達するために必要な情報を自動的に提供し、そのページを潜在的な結果として、またはユーザ入力に応答したオプションとして、提示することができる。別の例は、ユーザが、入力フィールド内にテキスト「血糖」を入力することを含むことができる。システムは、Ｍｉｃｒｏｓｏｆｔ  ＨｅａｌｔｈＶａｕｌｔなどの確立されたヘルスケア関係ユーザアカウントに自動的にログインし、ユーザ入力に応答した潜在的な結果として最近のラボ報告から血糖レベルをユーザに返すことができる。ワールドワイドウェブ上での多くの類似のタスクは、あるページから次のページへ、そのまた次のページへのナビゲーションと、さまざまな質問に応答した入力を必要とする。ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍシステムは、所望の情報、所望のアクション、または所望の成果を取得するように、ウェブページのこれらのシリーズを通してナビゲートするために、ユーザからの必要とされる入力を短縮または自動化することができる。
【００７２】
[00142]図１は、オンライン購入を完了するためにユーザがウェブページのシリーズを通してナビゲートするために必要とされる時間が減少されるように、ユーザ１０４が１つの検索システムへと情報を入力することを可能にするシステムアーキテクチャ１００を示す。ユーザは、任意のコンピュータまたはスマートフォン１０６などの電子デバイスを介して、１つの検索サーバ１０２と、またはブラウザインターフェースと対話することができる。ユーザがデバイスを介して検索のために情報を入力すると、情報が１つの検索サーバに送信される１０８。次いで、サーバが、たとえば、Ａｍａｚｏｎ、Ｗａｌ−ｍａｒｔ、およびＴａｒｇｅｔなどのさまざまなウェブサイト１１０にユーザ入力を送信する１１２ことができる。ソース１１０の各々は、そのウェブサイト内でユーザ入力を検索するために問い合わせまたはルックアップを実行することができ、品物の価格などのユーザ入力に関係する情報をサーバに返すことができる。同様に、サーバは、入力に関係する情報をユーザに返すことができ、そのため、ユーザは、たとえば、購入する特定の品物についての、より迅速に、より情報に通じた決定を行うことができる。
【００７３】
[00143]図２Ａは、例示的な検索または入力フィールドを示す。この初期例では、ユーザは、「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ  シルバー」などの語句をｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ２００の入力フィールド２０２に入力する。検索フィールドは、任意のサイト上にあることができ、またはブラウザ検索フィールドとすることができる。この時点で、ユーザは、Ｇｏｏｇｌｅ検索２０４、Ａｍａｚｏｎ．ｃｏｍワンクリック購入ボタン２０６、またはＡｍａｚｏｎ．ｃｏｍ検索２０８ボタンなどの、入力を処理するための任意の数のオプションをクリックすることができる。この例では、ユーザは、Ａｍａｚｏｎ．ｃｏｍワンクリック購入ボタン２０６をクリックする。したがって、このフィールドから、システムは、その入力を受信し、入力を処理して、ユーザがＡｍａｚｏｎ．ｃｏｍを通して、３２ＧＢのストレージとシルバーの色を有するｉＰｈｏｎｅ  ５Ｓにナビゲートし、ワンクリック購入ボタンをちょうどクリックしたかのように、購入を遂行することができる。しかしながら、この第１の例では、ユーザは、Ａｍａｚｏｎ．ｃｏｍにナビゲートすることを必要とせず、むしろ、別個のウェブサイト、すなわちｏｎｅ−ｓｅａｒｃｈ．ｃｏｍウェブサイト、またはブラウザインターフェースから、ワンクリック購入を行うことを可能にした。一態様では、ユーザは、特定のボタンをクリックすることすら必要とせず、代わりに、ユーザが通常の検索要求を遂行するであろうように、「ｅｎｔｅｒ」を単に打つことができる。それから、システムは、ユーザがワンクリック購入を行うことを要望する確率が確実性閾値を上回るかどうかを決定するためにテキスト入力を分析することができる、システムは、次いで、購入を遂行する要求として「ｅｎｔｅｒ」入力を処理することができる。
【００７４】
[00144]システムは、ユーザがＡｍａｚｏｎ．ｃｏｍまたはＧｏｏｇｌｅ．ｃｏｍにおいて直接的に入力へとテキストを入力し、検索を単にクリックしたかのように、クリックされたボタンに従って入力を処理することができる。ユーザがＧｏｏｇｌｅ検索２０４をクリックした場合、システムは、Ｇｏｏｇｌｅからの検索結果を返すであろうが、Ｂｉｎｇ、Ｙａｈｏｏ、または何らかの他の検索エンジンからの検索結果を同様に提供することができる。一態様では、システムは、ユーザをＧｏｏｇｌｅ．ｃｏｍに転送させ、ユーザの検索入力を使用して検索を実行させ、ユーザがＧｏｏｇｌｅ．ｃｏｍにおいて検索を最初に行ったかのように結果を提示することができる。別の態様では、システムは、ユーザがユーザの検索入力を使用して検索を実行したかのようにｇｏｏｇｌｅ．ｃｏｍにおいてＵＲＬを生成し、そのＵＲＬをｇｏｏｇｌｅ．ｃｏｍにおいてユーザのために開くことができる。ユーザがワンクリック購入２０６を選択した場合、システムは、ユーザがＡｍａｚｏｎ．ｃｏｍを介して品物にナビゲートし、購入を行ったかのように、Ａｍａｚｏｎ．ｃｏｍを通して品物の購入および配達を処理する。言い換えれば、「ｅｎｔｅｒ」ボタンの機能性は、ユーザ入力の分析に基づいて（動的に、および数回）修正可能である。さまざまな要因に基づいて、初期デフォルトは、購入のコンテキストであってもよいが、ユーザがデータを入力し始めた後、コンテキストはウェブ検索に変化することがあり、次いで、最終的にユーザが入力を入力し終えたとき、「ｅｎｔｅｒ」ボタンは、マッピングに関連づけられた処理、または単に購入のコンテキストを引き起こすことがある。
【００７５】
[00145]ユーザがＡｍａｚｏｎ．ｃｏｍ検索２０８を選択した場合、システムは、その句に関してＡｍａｚｏｎ．ｃｏｍ上で検索結果のビューを返す。言い換えれば、ユーザは、Ａｍａｚｏｎ．ｃｏｍに転送可能であり、自分のアカウントにログイン可能であり、またはアカウントに対する既存のセッションへと参加可能であり、そしてユーザが「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ  シルバー」に関してＡｍａｚｏｎ．ｃｏｍを検索したかのように状態が同等物である（または本質的もしくは機能的に同等である）スクリーンを提示可能である。別の態様では、システムは、ユーザが、単にワンクリック購入ボタンをクリックし、品物を購入することができるように、ディープリンク状態における検索フィールドからＡｍａｚｏｎ．ｃｏｍへの遷移を容易にするためにブラウザ内に記憶されたデータにアクセスする。その状態から、ユーザは、返された品物のリストに目を通し、次いでおそらく品物を選ぶことができ、その時点で、ユーザは、ｉＰｈｏｎｅを「ワンクリック」購入することができるであろう。ある状態に前処理された別個のサイトへとユーザを深く遷移させることは、ディープリンクと呼ばれることがある。これは、ユーザがウェブサイトのトップレベルすなわちホームページに（ｗｗｗ．ａｍａｚｏｎ．ｃｏｍまたはｗｗｗ．ｍｅｒｃｈａｎｔ．ｃｏｍなどに）転送されない場合である。代わりに、遷移は、ユーザがウェブサイトの第２のレベルまたは第３のレベルなどのサイトのより深い部分に連れて行かれるように前処理される。ウェブサイト内のより低いレベルすなわちより深い部分への遷移の一例は、ｗｗｗ．ｍｅｒｃｈａｎｔ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｈａｔｓ／ｇｒｅｅｎｈａｔである。ユーザは、トップレベルすなわちホームページの代わりに、ウェブサイト内の第４のレベルに遷移される。このケースでは、ユーザは、購入をより迅速に完了することができる。図１８Ａに示されるように、ブラウザ１８０６からのデータ（支払いデータ、ユーザデータ、ワンクリック設定、住所データ、登録データなど）は、次の対話が単一のクリック対話とすることができるように、ディープリンク状態における販売業者サイト１８１６上の到着を可能にするために、遷移の一部としてアクセス可能である。
【００７６】
[00146]実際、一例では、システムは、ユーザがＡｍａｚｏｎ．ｃｏｍにおいて始まり、検索語句を入力した場合と同じ様式で、ユーザをＡｍａｚｏｎ．ｃｏｍにリダイレクトする（またはユーザに代わってＡｍａｚｏｎ．ｃｏｍにナビゲートする）ことができる。このケースでは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍのアルゴリズムは、検索入力を受信し、（Ａｍａｚｏｎ．ｃｏｍ検索ボタンをクリックすることによって）ユーザから所望の指示を受信して、ユーザをＡｍａｚｏｎ．ｃｏｍに遷移させるであろう。クッキー内もしくは他の場所に記憶されたまたはＸＭＬを介して送信されたユーザ登録情報またはウェブブラウジング状態情報も、ユーザが遷移においてＡｍａｚｏｎ．ｃｏｍアカウントにログインされるように読まれるまたは転送可能である。データは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍを用いて、またはブラウザもしくはアプリを用いて、記憶可能である。このプロセスの結果は、ユーザが、ブラウザを開いてインターネットをブラウジングし始めたとき、システムは、ユーザが、検索結果に到達するまたは購入を行うためにより少ないクリックまたはユーザ入力を必要とする単一の統一された入力フィールドを介して、任意の数の検索、購入、または他のアクションを開始することを可能にする。
【００７７】
[00147]さらに、ブラウザ上の検索フィールドの観点、およびシステムがどのようにしてブラウザ検索フィールドから宛先サイトにユーザを遷移させるか、ブラウザ機能は、ブラウザそれ自体に固有であることができ、または宛先サイトに関連して開発されたプラグインまたは拡張機能によって強化もしくは可能にされてよい。たとえば、Ｗｉｋｉｐｅｄｉａ、ｅＢａｙ、Ａｍａｚｏｎ、検索エンジンなどが、ブラウザエンティティに関連して、遷移を容易にするためにＡＰＩまたは何らかの他の手段を通してブラウザが宛先サイトにデータを通信する拡張機能を開発することがある。たとえば、Ａｍａｚｏｎ．ｃｏｍは、ブラウザを用いてインストールされたとき、本明細書において説明される機能が達成可能であるようにＡｍａｚｏｎ．ｃｏｍへのユーザ情報の通信を可能にするＡｍａｚｏｎアシスタントのインストール可能な拡張機能を提供することがある。この拡張機能は、ブラウザの機能を強化し、ブラウザの一部になる。ブラウザは、入力フィールド内のユーザ入力を受信するプロセスを実行し、このユーザ入力に基づいて、選択可能なオブジェクトの第１のインスタンスが提示されるドロップダウンメニュー（またはインターフェース上のどこかのオブジェクト）を提示し、このオブジェクトは、宛先サイトに関連づけられる。ユーザからオブジェクトとの対話を受信すると、ユーザは、宛先サイトに自動的に遷移される。宛先サイトは、ユーザが宛先サイトの入力フィールドへとユーザ入力を入力したことの同等物である状態に事前構成される。ユーザは、宛先サイトにおいて結果として得られるその状態に遷移される。いくつかのケースでは、Ａｍａｚｏｎ．ｃｏｍを用いたように、情報は、ユーザが宛先サイトにもログインされた場合宛先サイトに通信可能であり、適切な場合、状態は、ユーザ入力に関連づけられた製品が提示可能であるように構成可能である。ユーザは、「今すぐ買う」ボタンをクリックし、宛先サイトとのユーザ対話を中断することなく購入を行うことができる。別の態様では、購入状態に達するために、何らかの対話が必要なことがある。この状態における対話の量は、Ａｍａｚｏｎ．ｃｏｍなどの宛先サイトに手動で遷移し、ａｍａｚｏｎ．ｃｏｍ入力フィールドへとユーザ入力を入力し、ｅｎｔｅｒを打ち、購入機会に達するためにサイトと引き続き対話するために一般的に必要であろうよりも少ない。
【００７８】
[00148]したがって、一態様では、本開示は、ブラウザまたはブラウザ上のインストールされた拡張機能によって強化されるブラウザ機能性に関する。そのうえ、特許請求の範囲は、ブラウザの観点、ならびにブラウザから遷移を受信し、適切な状態である宛先サイトにおける遷移ユーザを受信するようにユーザ入力を前処理する宛先サイトの観点の両方の機能に対処することができる。
【００７９】
[00149]別の例は、プロセスをさらにもっと単純化する。一般的には、上記で説明されたように、ＧｏｏｇｌｅまたはＡｍａｚｏｎなどのウェブサイトは、ユーザが、「ｅｎｔｅｒ」をクリックすることができ、テキストがＧｏｏｇｌｅウェブ検索として、またはＡｍａｚｏｎ製品検索として処理されるように、単一目的エントリを有する。この第２の例では、検索フィールドは、入力フィールド内のテキストを処理する複数の可能な手段を有する。アルゴリズムは、テキスト入力の意味またはユーザ意図を決定または予測するために入力を分析および処理する。そのような分析を介して、システムは、どのタイプの検索またはアクションをユーザが望むかを決定する。したがって、ユーザがｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにおける、またはブラウザ上の検索フィールドへと「オリンピック」をタイプした場合、オリンピックは、購入のために利用可能なものではないので、システムは、アルゴリズムを介して、ユーザがＡｍａｚｏｎ．ｃｏｍまたはｅＢａｙを「オリンピック」で検索することを望む可能性が低いと決定することができる。しかしながら、ユーザが「オリンピック  ウインドブレーカー  ソチ  ２０１４」などの追加情報を入力した場合、ユーザによって入力された追加情報は今、特定の品物またはカテゴリを対象とするので、システムは、意図の決定を改定することができる。したがって、システムは、提供されたテキストまたはデータに基づいて、ユーザの意図を連続的に評価または決定することができる。システムは、たとえば、各文字または単語が入力されたとき、意図を瞬時に再評価することができる。システムは、意図を予期し、ユーザに関するコンテキスト情報およびこれまで提供されたデータに基づいて、いくつかの予期された意図シナリオに関する結果またはアクションをキャッシュまたはプリロードすることができる。したがって、予期された意図（すなわち、Ｇｏｏｇｌｅ検索対Ａｍａｚｏｎ購入対Ａｍａｚｏｎ検索）が適切であることがわかった場合、システムは既に、その構成要素を所定の位置にもつ、またはその意図をサービスするためにページをフェッチしている。このケースでは、ユーザは、入力に関係する結果をより早く受信する。
【００８０】
[00150]システムは、ユーザプロファイルデータ、ワンクリック購入設定、ソーシャルメディアデータ、履歴データ、時期（休暇が近づいている、サマータイム、友人または家族の一員が一週間以内に誕生日を迎えるなど）などの任意のタイプのデータを利用して、この決定を行うことがある。この例では、システムは、ユーザが、その入力に対してユーザがＧｏｏｇｌｅ検索を意図した「ｅｎｔｅｒ」をいつクリックしたかを決定することがある。たとえば、ユーザが、「Ｐａｕｌ  Ｒｅｖｅｒｅ  アメリカ革命」をタイプした場合、システムは、テキストの意味内容および構造が、製品検索の代わりに情報検索とより密接に提携されることを検出することができ、検索エンジンを通るように検索テキストをルーティングさせることができる。そのケースでは、ユーザがＧｏｏｇｌｅ検索を入力したかのような主な結果が提示される。ユーザがＢｉｎｇ検索を実際に要望したまたはＡｍａｚｏｎ．ｃｏｍ検索を望んだケースでは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ結果画面が代替物を提供することもある。ユーザがその情報をｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにおいて検索フィールドへと入力した場合、ユーザがｅｎｔｅｒを押すと、ユーザがもともとＧｏｏｇｌｅにおいて検索文字列で検索したかのように、システムは、ブラウザに、ｇｏｏｇｌｅ．ｃｏｍにナビゲートさせることができる。あるいは、システムは、ｉｆｒａｍｅもしくはウェブページ内の他の埋め込まれた機構に、または新しいタブもしくはウィンドウとして、対応するＧｏｏｇｌｅ検索ページをロードすることができる。ユーザがｏｎｅ−ｓｅａｒｃｈ．ｃｏｍページにおいて検索を開始した場合であっても、システムは、いくつかのさまざまな遷移のいずれかを利用して、Ｇｏｏｇｌｅ検索ページをユーザに提示することができる。
【００８１】
[00151]一方、ユーザが「リビア  やかん」と入力した場合、システムは、入力テキストを分析して、ユーザが購入を行うことを要望する可能性が高いと決定することができる。したがって、ユーザが「ｅｎｔｅｒ」を打ったとき、システムは、Ａｍａｚｏｎまたは別の適切な電子商取引サイトに検索をルーティングすることができ、または検索に基づいてＡｍａｚｏｎからのワンクリック購入を即時に遂行することができる。ユーザ意図が購入であると決定すると、システムは、ユーザの購入習慣または最低価格、最低価格プラス送料、入手可能性、発送時間もしくは方法、ユーザがショッピングクラブの会員であること、ユーザがオンライン販売業者と取引があるかどうかなどの他の購入関係情報の分析を実行する、またはこれらの、以前に実行された分析に依拠することができる。この分析に基づいて、システムは、どの小売業者が意図閾値を上回るかを決定し、それらの小売業者に容易にアクセスする手段をユーザに提供することができる。システムは、ユーザが要望したものである可能性の順に小売業者を並べ替えることができ、ユーザに提示される小売業者のリストを制限することができる。たとえば、このリストは、値開き、オプションをユーザに提示するために利用可能な画面スペース、または他の要因に基づいて、制限可能である。
【００８２】
[00152]これらの原理の一例では、ユーザは、「大きくて最高のピザ」というテキストをｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ入力フィールドへと入力する。システムは、ユーザのブラウザ履歴、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにおける以前の問い合わせ、さまざまなピザ配達場所でのユーザアカウント、ユーザおよび近くのピザ配達場所のロケーション、ピザ購入のクレジットカードトランザクションデータなどを分析することができる。この情報に基づいて、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍは、ユーザがｅｎｔｅｒを押す前および／または問い合わせ中に、近くのＤｏｍｉｎｏｓ、Ｐａｐａ  Ｊｏｈｎｓ、およびＰｉｚｚａ  Ｈｕｔが営業中であり、ユーザが過去６か月間にこれらの販売業者で購入を行ったと決定することができる。次いで、システムは、ユーザが、大きくて最高のピザを注文するために単に１回クリックすることができるように、これらの販売業者の各々のプレビューを提示することができる。支払いデータは、ブラウザ支払い要求ＡＰＩを通して取り扱い可能である。ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍシステムは、発注されるであろう注文の概要およびユーザがロゴをクリックした場合の関連コストとともに、各ピザ販売業者のロゴを表示することができる。たとえば、システムは、Ｄｏｍｉｎｏｓロゴの下に、「１６”の大きくて最高のピザ、１６．２４ドル、１２３  Ｆａｋｅ  Ｓｔｒｅｅｔ、Ｓｐｒｉｎｇｆｉｅｌｄ、ＯＨに配達、午後６時１５分までに配達」を表示することができる。次いで、ユーザは、発注するためにＤｏｍｉｎｏｓロゴをクリックすることができ、またはユーザは、発注する前に注文のさまざまな側面を修正するために、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍページもしくはＤｏｍｉｎｏｓウェブページと直接的に対話することができる。ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍシステムは、ユーザが検索フィールド内に追加情報をタイプすると、プレビューを動的に更新することができる。ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍシステムは、ユーザがキーボード上の「ｅｎｔｅｒ」を押した場合に遂行されるであろう‘デフォルト’アクションの標識をさらに提供することができる。このようにして、ユーザがデフォルトの結果に満足したとき、またはユーザがテキストを入力した後に１つの結果のみが残っているとき、ユーザは単に、「ｅｎｔｅｒ」を押すことができ、システムは、ピザを発注することなどのアクションを遂行することができる。
【００８３】
[00153]別の例では、ユーザは、「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ  シルバー」という語句をｏｎｅ−ｓｅａｒｃｈ．ｃｏｍへと入力する（「ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ」または類似のサイトへの参照は、ブラウザユーザインターフェースまたは任意のインターフェースも意味することができる）。システムは、購入可能であった１つまたは少数の品物を識別するように、詳細の具体的な量に基づいて、この検索は明らかに製品を対象とすると決定するために、テキストを分析することができる。さらに、検索が１２月８日に遂行された場合、システムは、クリスマスまたは他の休暇付近に贈り物をする雰囲気により、購入要求を認識することにより敏感であるように特にチューニング可能であることができる。アルゴリズムは、アルゴリズムを走らせたことに基づいて、どれが、ユーザがこの製品を単に検索するだけでなくそれを購入することを要望する高い可能性があるという閾値が超えられているという結果になるであろうかを決定するために、さまざまなｉＰｈｏｎｅに対する以前の検索を分析することができる。ユーザが「ｅｎｔｅｒ」を打ったとき、システムは、ユーザが、「ワンクリック」購入を行うオプションとともにＡｍａｚｏｎ．ｃｏｍ上でｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ  シルバーを閲覧しているかのように、その入力を処理する。ここで、そのデータをｏｎｅ−ｓｅａｒｃｈ．ｃｏｍフィールドへと入力し、「ｅｎｔｅｒ」をクリックすることによって、システムは、ユーザに代わって、ユーザが品物の購入を完了したかのように、Ａｍａｚｏｎ．ｃｏｍにおいてステップを実施することができる。システムは、ユーザがウェブサイトにナビゲートし、自分で情報を入力したかのように、ＨＴＴＰ要求を介してこれらのアクションを実行することができる、またはシステムは、確立されたＡＰＩを介して、さまざまなウェブサービスと通信することができる。システムは、発注されたことをユーザに通知し、発送または注文の詳細をユーザに提供することができる。あるいは、システムは、Ａｍａｚｏｎ．ｃｏｍ環境に直接的にユーザを遷移させることができる、または、Ａｍａｚｏｎ．ｃｏｍにおいて、もしくはＡｐｐｌｅ．ｃｏｍなどによってなされ得るようにユーザプロファイルデータを介して製品の購入および配達を処理するウェブサイトによって購入が処理中であることを、ユーザに通知するユーザインターフェースを提示することができる。
【００８４】
[00154]一例では、ユーザは、システムがユーザに代わって発注する前に、注文を確認することができる。別の例では、システムが、ユーザのために自動的に発注し、ユーザは、何もしないことによって、注文を受け入れることを選定することができ、またはボタンをクリックすること、もしくは新しいタブもしくは新しいウィンドウ内で注文ページを開くことなどの、何らかの入力を提供することによって、注文を拒否もしくは修正することを選定することができる。一例では、システムは、シルバーのｉＰｈｏｎｅ  ５Ｓを発注したかもしれないが、ユーザは、考えを変え、ゴールドのｉＰｈｏｎｅ  ５Ｓを注文することを望む。ユーザは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにおいて直接的に注文を修正することができる、またはｏｎｅ−ｓｅａｒｃｈ．ｃｏｍは、注文を修正するためにＡｍａｚｏｎ．ｃｏｍにユーザをリダイレクトすることができる。売り手は、この入力を処理する企業を争うことができ、システムは、誰が最低価格を得ようとしたかについて報告してよい。システムは、ある量の時間以内に購入をキャンセルすることによって、ユーザに‘アウト’を提供することができる。同様に、システムは、ユーザがｉＰｈｏｎｅ  ５Ｓをちょうど発注したところであることを検出し、‘クールダウン’期間を実施することができ、‘クールダウン’期間中、システムは、何らかの追加のまたは明示的なユーザからの承認なしに、ユーザに代わって追加のｉＰｈｏｎｅを自動的に注文しない。
【００８５】
[00155]システムは、誤っているまたは意図的でないように見える注文を締めくくるまたは確認することができる。たとえば、新しいユーザが、システムがどのようにして機能するかをわからない場合、彼または彼女は、ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ  シルバーを複数回検索し、不注意で複数の電話を注文することがある。システムは、そのような潜在的に意図的でない購入パターンを検出する内蔵機構を有し、そのようなパターンが検出されたときユーザに代わって購入を行うことに進む前に、何らかの高いレベルのユーザ承認または確認を組み込むことができる。子供または許可されていない人が、特定の支出限度を上回る購入を行うことができないように、または閾値を上回る購入が、電子メールもしくはテキストメッセージもしくは何らかの他の機構を介して認証を必要とするように、ユーザは、アカウントに対するセキュリティ対策または購入限度を確立することができる。システムが、許可されていない購入を検出した場合、システムは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍアカウント全体に対する、または特定のログインロケーションに対する、購入トランザクションを一時的に停止するまたは全体的にこれを防止することができる。
【００８６】
[00156]「ｅｎｔｅｒ」ボタンを使用して、予測された意図に基づいて入力を処理することは、曖昧さという結果になり得る。ユーザが、Ａｍａｚｏｎ．ｃｏｍを介して製品を検索するとき、ユーザは、所望のサイズ、色、運送会社などをもつ適切なモデルにナビゲートする。次いで、ユーザがＡｍａｚｏｎ．ｃｏｍワンクリック購入を行うとき、ユーザは、購入を行う前に、製品についてのデータのすべてを知る。本明細書において開示されるモデルでは、システムは、製品の曖昧さも扱うことができる。ユーザがｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにおいて「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ」を入力し、利用可能な色は、ブラック、シルバー、およびゴールドと仮定する。アルゴリズムは、入力テキストに基づいて、ユーザが購入を行うことを要望する可能性が高いと決定し、それに応じて入力テキストを処理する。システムは、最も人気のある色を選択し、それに応じてその未知のパラメータを埋めることができる。システムは、人気のあるサイズおよび色に基づいて、最も人気のあるモデルを選択することができるが、システムは、ユーザに類似した人々にとって最も人気のあるモデルを決定するために人口統計データを組み込むことができる。たとえば、ユーザが「ｉＰｈｏｎｅ  ５」を入力する場合、システムは、十代の少女に対してはイエロー１６ＧＢ  ｉＰｈｏｎｅ  ５Ｃ、または彼女の父に対してはブラック６４ＧＢ  ｉＰｈｏｎｅ  ５Ｓを選択することができる。システムは、この購入に対して可能性があるユーザ好みを決定するために、類似のデバイスまたは関係デバイスの過去の購入をさらに分析することができる。ユーザが既に登録され、ブラウザ、アプリケーション、またはウェブサイトを介して、システムが、誰が検索をしているかを知っている場合、複数のウェブサイトなどにわたっての以前の検索に基づいた、ユーザ好み、履歴、分類モデルが、ｏｎｅ−ｓｅａｒｃｈ入力フィールドを分析するために適用可能である。ユーザが、すべてシルバーである電子機器の購入を過去に行った場合、システムは、ユーザがシルバーｉＰｈｏｎｅ  ５Ｓを希望する可能性が高いと仮定し、それに応じてカートにポピュレートすることができる。同様に、ユーザが、以前のモバイルデバイスの購入において最大記憶容量モデルを一貫して購入していた場合、システムは、最大記憶をもつｉＰｈｏｎｅ  ５Ｓをカートに自動的にポピュレートすることができる。
【００８７】
[00157]上記の例に戻ると、ユーザは、「ｅｎｔｅｒ」をクリックし、システムは、「お客様はブラックｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢを購入しました。代わりにシルバーを希望する場合は、「ｅｎｔｅｒ」を打ってください」と述べるユーザインターフェース画面を提示する。言い換えれば、システムは、最も人気のある色を選び、「ｅｎｔｅｒ」を再度打つことを介して、色などのパラメータを変更するオプションを提示することができる。この「ｅｎｔｅｒ」の第２の打つことは、以前のブラックｉＰｈｏｎｅの注文をキャンセルし、それをシルバーのものと置き換える、またはシステムは、購入要求を単に更新することができる。プロセス中のその時点では、この「ｅｎｔｅｒ」の第２の打つことは、ユーザが、適切な特徴をもつシルバーｉＰｈｏｎｅを閲覧しており、他のアクションは、その代金を請求し、配達させるように行われることを必要としないようにワンクリック購入ボタンを打ったかのようである。システムは、ある時間の期間が、ユーザが、購入を確定または完了する前に注文を修正することを可能にすることを待機しながら、ブラックｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢなどの特定の品物を保留にするようにＡＰＩを介して販売業者と統合されることができる。
【００８８】
[00158]プロセスは、繰り返されることも可能である。システムは、「お客様は今、シルバーｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢを購入しました。ゴールドのものを希望する場合は、ｅｎｔｅｒを打ってください」をユーザに提示することができる。ｅｎｔｅｒを今回打つことは、シルバーｉＰｈｏｎｅの注文をキャンセルし、それをゴールドｉＰｈｏｎｅと置き換える。ユーザがこの段階で他に何もしない場合、システムは、ゴールドｉＰｈｏｎｅの注文を確定し、販売業者は、ユーザがゴールドｉＰｈｏｎｅを受け取るように注文を遂行し、販売業者は、通常のやり方で注文の代金をユーザに請求する。もちろん、ボタンクリックは、さまざまなパラメータを変更し、注文を変更するために、ユーザに提供可能である。インターフェースは、「お客様はｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢブラックを購入しました。これらのパラメータのいずれかを変更するには、ここをクリックしてください」と言うことができる。システムは、記憶装置のサイズ、モデル、運送会社、色、発送オプションなどを変更するために、さまざまなオプションを提示することができる。しかしながら、ユーザが何もしない場合、システムは、注文の手配をし、予測されたパラメータを使用してユーザに代わって販売業者に発注する。諒解され得るように、プロセスは、ユーザが、ブラウザまたはアプリケーションが開かれた時間から、以前に必要とされたよりも少ない対話または少ないステップで所望の製品の購入を行うのに成功することを可能にする。
【００８９】
[00159]別の例では、システムは、単一検索のコンテキストにおいて、またはＡｍａｚｏｎ．ｃｏｍ、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ、もしくは購入者がクレジットカード、住所などのデータを登録している他の任意のウェブサイトにおいて、ワンクリック購入能力をもつオートコレクト特徴またはオートコンプリート特徴を含むことができる。ウェブサイト検索フィールドは、ユーザが検索語句をタイプしたとき、オートコンプリート特徴が、ユーザが要望し得る概念を自動的に完了する、またはその時点までのテキスト入力に基づいて提案もしくは推奨されたオプションのリストを提示する、のどちらかを行うことができるように、「オートコンプリート」を含むことができる。ユーザは、さまざまなオートコンプリートオプションを調査して１つを選択し、したがって、問い合わせの残りを引き続き打ち込む必要性を緩和することができる。この例では、システムは、入力フィールドを介して部分的ユーザ入力（または全入力）を受信し、そして、オートコンプリートオプションを生じさせるために入力を分析するとき、システムは、オートコンプリートオプションのリスト内に「ワンクリック」購入オプションを含むことができる。したがって、このオプションは、テキストの第１の部分に対するデフォルトモードおよびテキストの第２の部分に対する第２のモードから変化することができる。言い換えれば、ユーザが、「ｉＰｈｏｎｅ」というテキストを部分的ユーザ入力として入力した場合、その段階で、システムは、「ｉＰｈｏｎｅ  ５Ｓ  １６ＧＢ＜ワンクリック購入＞」を識別し、「オートコンプリート」オプションの１つとして提示することができる。そのケースでは、オートコンプリート特徴のこの修正されたリストは、品物を購入するために、ユーザからのクリックの数およびテキストの量を減少させる。言い換えれば、ドロップダウンまたはドロップアップ（またはユーザインターフェース上の他の任意のロケーション）特徴は、標準的なオートコンプリート特徴を探すという概念に限定されず、むしろ、購入オプションまたは他のウェブサイトへのジャンプなどの他のオプションとオートコンプリートを混ぜる。通常、ユーザは、オートコンプリートオプションのうちの１つを選ぶであろう。そのことは、ユーザを品物または品物のリストのどちらかに連れて行き、次いで、ユーザは、１つの特定の品物に絞り込むために再度クリックしなければならず、次いで、その時点で、ユーザは、品物を「ワンクリック」購入できる立場にある。しかしながら、ユーザが、オートコンプリートリスト内の「ワンクリック購入」の変形をクリックした場合、システムは、即時に発注することができる。オブジェクトが、Ｗｉｋｉｐｅｄｉａ．ｏｒｇなどの別のサイトに遷移するために、ドロップダウンメニュー内に提示されることがある。以前の手法は、遷移するために、はるかに多くのデータを入力フィールドへとタイプすることをユーザに要求した。たとえば、Ｓａｆａｒｉに関する以前の手法は、「ａｍａｚｏｎ  カメラ  レンズ」をタイプすることをユーザに要求し、これは、入力がａｍａｚｏｎ．ｃｏｍに対するものであり、ａｍａｚｏｎに遷移することが意味されたことをブラウザに示した。しかしながら、ブラウザに命令を提供するために余分な文字がタイプされることを要求することは、第２のサイトに手動で遷移するだけよりも多くの入力およびステップを必要とした可能性が高い。したがって、本開示は、どこに遷移するべきかをブラウザに告げるキーワード命令をタイプする必要なしに入力フィールド内の正確なテキストに対して機能することができる、提示されることになるオブジェクトを提供する。これらのオブジェクトは、任意の場所に提示可能であり、ユーザがタイプし始めた後、または入力の第１の部分が評価された後に、テキストが入力フィールド内にないが、第１のインスタンス内に提示されるとき、それらが見えないまたは提示されないように動的とすることができる。
【００９０】
[00160]システムは、入力フィールドリストを介してさまざまなワンクリックオプションを提示することができる。たとえば、「ｉＰｈｏｎｅ」をタイプする段階において、最も人気のあるｉＰｈｏｎｅが５Ｓであり、３２ＧＢおよびシルバー色をもつ場合、システムは、そのオプションを、ワンクリック購入オプションを用いて、購入のためのオートコンプリートオプションのリスト上のトップまたは最初に置くことができる。次に人気のあるモデルは、ブラックの１６ＧＢ  ｉＰｈｏｎｅであることがあり、これを、システムは、オートコンプリートリスト内で次に表示することができる。競合企業も、ワンクリック購入のためにオートコンプリートリスト内に提供を提供することができる。ユーザがタイプするにつれて、および１つのオプションが所望のオプションになる可能性が高くなるにつれて、メニュー内の位置も動的に変化することができる。入力フィールドのすぐ下のオプションは、ユーザが「ｅｎｔｅｒ」キーを打ったときに、すなわち、いかなるオブジェクトもクリックせずに、提供されるオプションとすることができる。競合企業は、関係するが検索対象テキストを含まないオートコンプリートワンクリック購入オプションを提示する権利を購入することができる。たとえば、ユーザが「ｉＰｈｏｎｅ」を検索するとき、システムは、「Ｓａｍｓｕｎｇ  Ｇａｌａｘｙ  Ｓ４」をワンクリック購入するために、オートコンプリートエントリを提示することができる。システムは、これらのオートコンプリートリスト内に宣伝資料をさらに提示することができる。しかしながら、スペースは限られているので、宣伝資料も限られることがある。そのような宣伝の一例は、Ａｍａｚｏｎ．ｃｏｍにおいて「Ｓａｍｓｕｎｇ  Ｇａｌａｘｙ  Ｓ４−２０％オフ＜ワンクリック購入＞」を広告するオートコンプリートリストである。企業は、オートコンプリートリストの下の広告スペースを購入することができ、または特定のキーワード、特定の製品、ブランドなどに関するオートコンプリートリスト内で製品を上げるために割増金を支払うことができる。しかしながら、システムは、ビジネスインテリジェンスまたはさまざまな販売業者からのフィードバックを使用して、オートコンプリートオプションが検索対象テキストを含まない場合でも、品物Ｘを検索するどんな人々が最終的に購入することになるのかに基づいた結果をオートコンプリートオプション内に含むこともできる。
【００９１】
[00161]同様に、システムは、ユーザの行動を追跡することができ、広告主に対して割増金付きで、あるユーザの注意の価格を決めることができる。たとえば、ユーザが数週間にわたって毎日スマートフォンを再検索している場合、ユーザが、最近の大量の時間を、スマートフォンを再検索することに使っており、近い将来に購入を行う可能性があるので、最上位スマートフォンの広告主は、オートコンプリートオプションの形で広告することを用いて、興味のある関わった買い手をターゲットにするために割増金よりも高い価格を支払うことがある。このナビゲーションの履歴に基づいて、メニューは、ユーザの所望のアクションを表す可能性が高くなることがあるので、関係品物をメニュー内でより上位に提示することがある。
【００９２】
[00162]システムは、オートコンプリートオプションのドロップダウンリスト内に「ワンクリック」購入オプションを提供することができる。加えて、オートコンプリートは、ユーザによって選択される場合、販売業者サイトにおけるワンクリック購入の前に１つのステップのコンテキストにユーザを置くリストを含むことができる。言い換えれば、ユーザが、Ａｍａｚｏｎ．ｃｏｍのようなウェブサイト上で「ｉＰｈｏｎｅ  ５Ｓ」を入力した場合、Ａｍａｚｏｎ．ｃｏｍは、品物のいくつかのリストをユーザに提示する。ユーザは、結果を単一の品物に絞り込むために、それらの品物のうちの１つをクリックしなければならず、その時点で、クリックのカウントは、「ワンクリック」購入のコンテキストにおいて始まる。その単一の品物を閲覧しながら、ユーザは、次いで、「ワンクリック」購入オプションが提示される。Ａｍａｚｏｎ．ｃｏｍでのユーザのログイン成功を含む、そのようなコンテキストは、品物が識別され、コンテキストはユーザがワンクリック購入を行うことができるようなものである時点にユーザがナビゲートした「ワンクリック前」ウェブページとして特徴づけられるであろう。課題は、ワンクリック前ページに到達することが、あまりにも多くのクリックおよび対話を要することである。
【００９３】
[00163]したがって、オートコンプリートリストは、ユーザが販売業者のウェブサイト内で「ワンクリック前」段階に即時にジャンプするための単純な手段を提供することができる。オートコンプリートリストは、その段階において「ワンクリック」購入オプションを含むことができるだけでなく、ユーザを「ワンクリック前」購入ページに連れて行くオプションも含むことができるであろう。その時点で、一般的には、ユーザが、より多くの情報に基づいた購入決定を行うことができるように、品物、大きい写真、レビュー、格付け、製品の詳細などについてのより多くの情報がある。よく知られている製品の場合は、ユーザは、オートコンプリートリストから直接的に購入するためにワンクリック決定を行うことができるが、他の製品の場合、ユーザは、製品が、意図された目的に適しているまたは何らかの他のユーザニーズに適合することを検証することを望むことがある。以前の、オートコンプリートオプションをクリックした結果は、入力フィールドへと入力された検索であるかのように、そのオプションを処理することである。しかしながら、それは、購入の準備が整っている１つの品物をもつ「ワンクリック前」ページではなく、検索結果のリストを返す。したがって、この代替特徴は、ワンクリック前購入ページに到達するために必要な対話の数を減少させる。
【００９４】
[00164]購入オートコンプリートタイプオプションは、ドロップ「アップ」リスト上に提示されることがあり、検索または従来のオートコンプリートオプションは、従来のドロップ「ダウン」メニュー上に提示されることがある。選択するオブジェクトは、ユーザインターフェース上の任意のロケーション内に提示されることがある。マルチモーダル対話も、オーディオ、ジェスチャ、または他の可能な対話型モードを含むために発生することがある。言い換えれば、リストの方向性は、リストされた品物の機能性を示すことができる。この方向性は、横方向であってもよいし、何らかの他の方向または角度であってもよい。たとえば、さまざまなワンクリック購入およびワンクリック前オートコンプリートリストはすべて、ドロップ「ダウン」メニューであるが、対向する４５度の角度とすることができる。システムは、タグフィールドまたはタグクラウド構成内にオプションを提示することもでき、最も可能性の高いオプションが、最も大きいアイコン、テキスト、グラフィック、または選択のための他の視覚的手掛かりとともに、入力フィールドの最も近くに提示される（それらが、マウスの見地からアクセスするのに最も迅速で容易である）。
【００９５】
[00165]前述のように、ブラウザまたは検索エンジンは、ユーザが第２のサイトを検索し、ｅｎｔｅｒを打って入力を処理するかのように、任意の第２のサイトにユーザを遷移させ、入力フィールド内のユーザ入力を前処理するように構成されることもある。本開示は、ユーザが第２のサイトの入力フィールドへとユーザ入力を入力したかのように、ある状態の第２のサイトにユーザを容易に遷移させることを包含する。この点に関して、図２Ｂに示される例示的な方法は、ブラウザのユーザインターフェースを介して、およびプロセッサを介して、入力フィールド内のユーザ入力を受信すること（２１０）と、このユーザ入力に応答してオブジェクトを提示すること（２１２）とを含む。一態様では、オブジェクトは、入力フィールド内に入力がないとき、インターフェース上に提示されない。オブジェクトの第１のインスタンスは、何らかの入力が提供された後、またはシステムが、オブジェクトが提示されるべきユーザ入力に基づいて識別するとき、とすることができる。このことは、インターフェース上の混乱を減少させる。オブジェクトは、ユーザがオブジェクトと対話するとき、方法が、オブジェクトに関連づけられた第２のサイトにユーザを遷移させること（２１４）と、ユーザ入力を第２のサイトの入力フィールドへと埋めること（２１６）と、ユーザがユーザ入力を第２のサイトの入力フィールドへと入力したかのように第２のサイトにおいてユーザ入力を処理させること（２１８）とを含むように構成される。オブジェクトは、入力がどこで処理されるかおよびブラウザがユーザをどこに遷移させるかを示す画像とともに提示可能である。インターフェースは、１つまたは複数のオブジェクトを提示することができ、複数のオブジェクトのうちの各オブジェクトは、ユーザが各それぞれのオブジェクトと対話するときにユーザが遷移する異なるワンクリック検索エンジンを含む。この点に関して、「ワンクリック検索エンジン」は、ｙａｈｏｏ．ｃｏｍ、ｂｉｎｇ．ｃｏｍ、ａｍａｚｏｎ．ｃｏｍ（すなわち、任意の販売業者サイト）、ｅｂａｙ．ｃｏｍ、Ｗｉｋｉｐｅｄｉａ．ｏｒｇなどの、ユーザが遷移する任意の第２のサイトを含むことができる。入力フィールドを有する任意の第２のサイトは、この概念に従って、遷移され得る。ユーザは、ドロップダウンメニューの一部として現れるターゲットサイトまたは第１のサイトの入力フィールド内のユーザ入力に応答して提示される品物のリストを選択することができる。ステップは、遷移することと、埋めることと、ステップを引き起こすこととを含むことができ、ユーザがユーザ入力を第２のサイトの入力フィールドへと入力し、第２のサイトがユーザ入力を処理するかのように、ある状態における第２のサイトへのユーザの遷移という結果になる。第２のサイトをブラウザにシグナリングするために「ｗｉｋｉ」または「ａｍａｚｏｎ」のようなキーワードを打ち込むことをユーザに要求する以前の手法と区別するために、本概念は、そのようなシグナリングを必要とせず、ユーザが第２のサイト内での正確なユーザ入力を処理し、第２のサイトに遷移するためにクリックするまたはこれと対話することができるオブジェクトを提供する。さらに、以前��手法は、通常の検索が望ましい（具体的には「ａｍａｚｏｎ  カメラ  レンズ」に関するなどの）場合、ユーザは、「！」のような記号を入力フィールドにキーボードから入力することが必要とされた。明らかに、この手法に必要とされる余分なステップは、理想的でなかった。本開示は、遷移を行うために必要とされるキーストロークおよび入力の数を減少させる。あらゆる減少されるステップまたはキーストロークは、特にモバイルデバイス検索では有益である。実際、「ａｍａｚｏｎ  カメラ  レンズ」という正確な語句を使用したａｍａｚｏｎ．ｃｏｍに対する検索は、ａｍａｚｏｎ．ｃｏｍの入力フィールドに正確に適用された場合、ユーザが望んだものと異なる結果、つまり、単なる「カメラ  レンズ」を返すことがあるので、以前の手法を適用することは問題があるであろう。
【００９６】
[00166]このプロセスのステップは、検索エンジンサイトによって、ブラウザ検索フィールド、アプリケーション、他の任意のエンティティ、または入力フィールドを有する任意のサイト（ａｍａｚｏｎ．ｃｏｍで始まり、ｇｏｏｇｌｅ．ｃｏｍに遷移するなど）から、実行可能である。たとえば、ブラウザは、多くの場合、インターネットを検索するために使用可能である入力フィールドをヘッダ部分内に有する。ユーザは、その入力フィールドに対するデフォルトの検索エンジンがｇｏｏｇｌｅ．ｃｏｍなのか、ｙａｈｏｏ．ｃｏｍなのか、それとも他の検索エンジンなのかを選択することができる。しかしながら、ブラウザは、提示された（動的である場合）とき、クリックされるとき、またはユーザによって対話されたとき、ユーザ入力が第２のサイトの入力フィールドをポピュレートし、そのユーザ入力が第２のサイトによって処理される状態に事前構成された第２のサイト（それ自体の第２のサイトの入力フィールドを有する）へ遷移させるオプションを提供することもできる。これは、ユーザがナビゲートし、一般的な検索エンジンから要望する結果に到達する効率的な手段を明らかに提供する。
【００９７】
[00167]別の態様は、ブラウザのユーザインターフェースを介して、入力フィールド内のユーザ入力を受信し、このユーザ入力に応答してオブジェクトを提示するための手法を含む。オブジェクトは、単一のクリックがあれば、ユーザがある手段で前処理された別のウェブサイトに遷移可能であるように構成される。ユーザ入力は、第２のサイトに渡され、本質的に自動的に第２のサイトの入力フィールドに埋められる。バックグラウンドプロセスは、ブラウザまたはシステムが、第２のサイトが入力を処理して、第２のサイトがユーザ入力に基づいて処理状態にあるような応答を返すように、第２の入力フィールド内でユーザ入力のエントリを引き起こすことを伴う。次いで、システムは、処理状態にあるオブジェクトに関連づけられた第２のサイトにユーザを遷移させる。このことは、ユーザがあるサイトから他のサイトに遷移するために関与しなければならないであろう対話の数を減少させる。オブジェクトは、ユーザ入力を入力した後、１回のクリックのみが、処理状態で第２のサイトに遷移するために必要とされるように提示される。このことは、入力フィールド内のユーザ入力とともにｅｎｔｅｒを単に打ち、検索結果を得て、それから、ユーザが、検索結果をクリックし、別のウェブサイトに遷移することがあることとは異なる。
【００９８】
[00168]図３は、例示的な１つの検索フィールドおよびドロップダウンメニュー特徴３００を示す。この例では、単一のフィールド３０２（サイトまたはブラウザ入力フィールド上にあることができる）は、ユーザが、利用可能である検索の他に他のオプションを識別するためにシステムが分析する入力を提供することを可能にする。この例では、ユーザが、フィールド３０２内に「ｉＰｈｏｎｅ  ５Ｓ」を入力する。アルゴリズムは、その入力を分析して、検索が、ある製品を対象とすることを認識する。システムは、現在の製品、購入パターン、製品の人気、ユーザまたは他のユーザの購入履歴、製品の入手可能性などのデータベースにアクセスすることができる。システムは、１つまたは複数の販売業者データベースへのＡＰＩ呼び出しを介してデータベースにアクセスすることができる。アルゴリズムは、このデータを使用して、ユーザが検索を要望するかそれとも購入する特定の製品を要望するかの、より正確な決定を行うことができる。このケースでは、「ｉＰｈｏｎｅ  ５Ｓ」という入力は明らかに製品であり、したがって、この知識は、ドロップダウンメニューオプションの構造を駆動および制御する助けとなる。
【００９９】
[00169]フィールド３０２内のユーザ入力は製品であるので、例示的なドロップダウンメニューオプションは、標準的なＧｏｏｇｌｅ検索３０４を含むことができる。これは第１のオプションであるが、システムは、アルゴリズムが、ユーザがＧｏｏｇｌｅ検索を要望する可能性が低いと決定した場合にこのオプションをより低く置くように、ドロップダウンメニューを配置することができる。システムは、たとえば、入力フィールド３０２により近くに、またはマウスカーソルにより近くに、より可能性の高いオプションを提示することができる。ユーザが、そのオプションを選択した場合、返される結果は、ユーザが「ｉＰｈｏｎｅ  ５Ｓ」をＧｏｏｇｌｅ検索として入力したかのようなものであろう。ドロップダウンメニューは、Ａｍａｚｏｎ．ｃｏｍワンクリック購入オプション３０６を含むことができる。ユーザがこのオプションを選択した場合、システムは、ユーザがＡｍａｚｏｎ．ｃｏｍ上におり、ｉＰｈｏｎｅ  ５Ｓを検索し、ユーザが「ワンクリック」するために選択することができる画面において、ユーザのために製品の購入を遂行するかのように、入力を処理することができる。別の変形形態では、システムは、ｏｎｅ−ｓｅａｒｃｈページにおいて、ドロップダウンメニューまたはドロップアップメニューから直接的に、ワンクリックオプションを提示することができる。そのため、ユーザは、ユーザがＡｍａｚｏｎ．ｃｏｍにおけるワンクリック点にナビゲートし、「今すぐ注文」ボタンをクリックしたかのように、Ａｍａｚｏｎ．ｃｏｍに発注するために、ボタン、画像、またはリンクをクリックすることができる。このケースでは、図４Ａは、選定オプション３０６からユーザに提示された、結果として得られる画面４００を示す。画面４００は、ｉＰｈｏｎｅ  ５ＳがＡｍａｚｏｎ．ｃｏｍを介して購入されたことをユーザに知らせるデータ４０２を含む。色が提供されなかったとき、システムは、ユーザのためまたは類似のユーザのために、最も可能性の高い色を選定することができる。このケースでは、システムは、シルバーを選択した。３２ＧＢの記憶装置サイズも、購入データの一部として示される。
【０１００】
[00170]人々がおそらく間違ったキーを打ったまたは間違ったドロップダウンメニューオプションを選定したときの望ましくない購入または意図されていない購入のケースでは、システムは、ユーザが、購入をキャンセルする４０４または購入を修正する４０６ことを可能にする。ユーザは、製品に応じて任意の数の異なるオプションを修正することができる。例として示されるオプションは、色をシルバーからゴールドまたはブラックに変更することを含む。同様に、システムは、記憶装置サイズを１６ＧＢに変更するオプションを表示することができる。「アクセサリを追加」などのオプションは、ユーザを充電器、ケース、および車載装置などのアクセサリを選定するために別の対話型画面へと導くことができる。システムは、どの修正オプションを提示するべきか、および各オプションのための信頼スコアに基づいた、これらの修正オプションを提示する順序を決定することができる。統計学的信頼スコアは、過去の購入またはユーザ好みを使用して、システムによって決定可能である。たとえば、システムは、ユーザがシルバーｉＰｈｏｎｅ  ５Ｓを望む９５％の信頼スコアを有することがあり、色を修正するオプションを表示することができない、またはあまり目立たない場所もしくは様式でオプションを表示することができる、またはメニューもしくは他の‘隠された’ロケーションを通して色を変更するオプションを提供することができる、のいずれかである。この手法は、ユーザが、どのシステムがあまり確実でないかについてのオプションのみについて懸念を抱かされ、これを容易に修正することができるように、システムが購入または品物オプションをユーザに提示することを可能にすることができる。他のオプションも、購入プロセスを開始するが、製品の特徴に関する追加の選択をユーザから受信するまたはダイアログにおいてユーザと関わり合う、次いで、ダイアログの後で購入を終える（およびおそらく、ドロップダウンメニューまたは別個のダイアログアプリケーションと同様に、購入がダイアログアプリケーション内で処理される）オブジェクトを介して提示可能である。システムは、実際の品物それ自体についての詳細だけでなく、配達住所、請求先住所、支払い方法、または配達方法などの、注文を取り巻く詳細についても、修正するオプションを提示することができる。システムは、たとえばユーザがプルダウンメニュー内の間違ったメニュー項目を不注意でクリックした場合にユーザがある販売業者から別の販売業者に注文を切り換えることを可能にすることすらできる。
【０１０１】
[00171]フィールド４０２内に見られるように、購入を処理しているエンティティがＡｍａｚｏｎ．ｃｏｍである場合、システムは、Ａｐｐｌｅ．ｃｏｍを通して購入を処理するオプションを提示することもできる。これらのオプションのいずれかが選定された場合、ユーザは、修正ボタン４０８を選択し、注文が修正され、自動的に引き続き処理される。もちろん、システムは、ユーザプロファイル、購入（クレジット／デビット／ＰａｙＰａｌなどのアカウント）、住所、および他の任意の情報を有し、容易に購入／処理エンティティ間でシームレスに移動することができる。ユーザが、ウェブサイト上でプロファイルおよびアカウントをセットアップするとき、認可およびアクセスしやすさの能力が確立および承認される。このようにして、購入を完了するためのエンティティ間の動作は、必要に応じて分割可能である。したがって、購入エンティティと処理エンティティ間でシームレスに移動する動作の一例は、システムが、注文を埋めることを取り扱うために、販売業者または小売パートナーなどの別の処理エンティティと協調しながら、１つのエンティティ（Ｇｏｏｇｌｅなど）に登録された支払いアカウントが、品物の代金を支払うために使用されることを可能にすることによって品物の購入および配達トランザクションを取り扱うシステムを含むことができる。以下で示されるように、購入／処理エンティティ間での遷移は、ユーザと販売業者との間のダイアログを可能にし、次いで、ダイアログアプリケーションにおいて購入を完了することができるダイアログアプリケーションに遷移することも含むことできる。
【０１０２】
[00172]図４Ａは、遷移して、または対話を使用して買い手の懸念を解消するもしくは買い手が単に「今すぐ買う」オプションの代わりに追加の対話を介して特定のパラメータを選択することを可能にすることについての別の態様も示す。序論において見られるように、いくつかのケースでは、ユーザとの個人的な対話は、購入を完了する前に懸念を解消し、特定のパラメータを選択するオプションを提供する助けとなることができる。本開示は、この入力を容易に達成し、次いで、購入を効率的に完了するためのいくつかの解決策を提供する。たとえば、図３は、品物のパラメータが選定可能であり、購入対話が、遷移されたロケーション（このケースではドロップダウンメニュー）へと組み込まれるように構成されたドロップダウンメニューへの、入力フィールドからの遷移も示す。より詳細な質問に対して、ユーザは、より多くの情報を受信または提供し、次いで、ダイアログインターフェースを通して実際の購入を処理する能力を有するようにユーザと関わり合うようにも構成されたダイアログに遷移することがある。図４Ａは、ユーザが他のオプションも選ぶことができるより包括的なダイアログを表す。ダイアログは、ＳＭＳアプリケーション、電子メールアプリケーション、ソーシャルネットワーク内のメッセンジャーアプリケーション、自然言語システム内でユーザと話し、会話するアバターなどとすることができる。したがって、最終的な購入が行われ得るダイアログへの「遷移」は、製品についてのより多くのパラメータを受け取り、次いで購入を終えるように構成されたドロップダウンメニュー項目、テキストダイアログ、スピーキングダイアログ、ビデオダイアログなどを含むことができる。ブラウザＡＰＩは、メッセージングアプリケーションまたはボット内で対話することの一部として、サイトへの支払いデータを処理するために使用可能である。
【０１０３】
[00173]以下の例は、ソーシャルネットワーキングのコンテキストにおいて、そのようなダイアログプロセスをどのように管理するかに関して提供される。システムが支払いプロセスの一部としてユーザをダイアログに遷移させることができる例示的な方法では、方法は、ソーシャルネットワーキングサイトが投稿エンティティから受信エンティティに投稿された品物を受信および送信するように、ソーシャルネットワーキングサイトを通して品物の投稿を受信することを含む。投稿が、製品データベース内の購入のための製品に関連づけられていないとき、方法は、買うためのオプションなしでソーシャルネットワーキングサイトを通して投稿を送信することを含む。決定が、投稿が製品データベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、方法は、支払いプロセス開始オブジェクトが、ボタン、ドロップダウンメニュー、またはハイパーリンクのうちの１つを含むことができるように、製品に関連づけられた支払いプロセス開始オブジェクトとともにソーシャルネットワーキングサイトを通して投稿を送信することと、支払いプロセス開始オブジェクトに関連づけられた対話を受信することとを含み、この対話は、ユーザによって実行される。購入対話に基づいて、方法は、ダイアログの終わりに、ユーザが製品の購入を完了することができるように、支払いプロセスの一部として製品に関してユーザとダイアログ内で関わり合うことを含む。
【０１０４】
[00174]方法は、ダイアログの一部として、ユーザから購入対話を受信することと、その購入対話に基づいて製品の購入を処理することとを含むことができる。購入を処理することは、ソーシャルネットワーキングサイトのうちの１つの中で、支払いエージェントを介して、またはソーシャルネットワーキングサイトと製品を販売する販売業者サイトとの間のアプリケーションプログラミングインターフェースを介して、発生する。購入は、本明細書において開示されるブラウザ支払い要求アプリケーションプログラミングインターフェースを通して発生することもできる。ブラウザ、ソーシャルネットワーキングサイト、デジタルウォレット、ネットワークストレージサービスは、購入を処理するために、ユーザに関する支払いデータを記憶することができる。購入が、ソーシャルネットワーキングサイトと販売業者サイトとの間でアプリケーションプログラミングインターフェースを介して発生するとき、ソーシャルネットワーキングサイトは、販売業者サイトが製品の購入を処理することができるように、アプリケーションプログラミングインターフェースを通して支払いデータを送信することができる。購入が、ブラウザと販売業者サイトとの間でブラウザアプリケーションプログラミングインターフェースを介して発生するとき、ブラウザは、販売業者サイトが製品の購入を処理することができるように、アプリケーションプログラミングインターフェースを通して支払いデータを送信することができる。
【０１０５】
[00175]ダイアログは、ユーザが、製品に関連づけられたパラメータを選択することを可能にすることができる。例示的なパラメータは、色、サイズ、形状、構成、および技術的特性のうちの１つまたは複数を含む。配達オプション、他の任意の懸念を解消すること、贈答問題、ディスカウント、クーポンなどは、ダイアログ内で管理可能である。支払いプロセス開始オブジェクトは、買うボタンまたは「ここをクリックして、この品物について話し、買う」という通知を単に含むことができる。対話は、ダイアログアプリケーションを介してユーザと販売業者との間のように管理可能である。ダイアログに関与することは、一態様では、ダイアログおよび製品の購入を管理するためのダイアログアプリケーションに遷移することによって達成可能である。
【０１０６】
[00176]図３は、他の概念も示す。特徴３０８は、Ａｐｐｌｅ検索を表す。ユーザが、このオプションを選択した場合、次の返されるフィールドは、ユーザがＡｐｐｌｅ．ｃｏｍ上でｉＰｈｏｎｅ  ５Ｓを検索したかのようなものであろう。その製品に関してＡｐｐｌｅによって提示される情報は、ユーザに提示されるであろう。任意選択で、システムは、Ａｐｐｌｅ．ｃｏｍにログインするための証明書を提供または確認するようにユーザを促すことができる。ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍからＡｐｐｌｅ．ｃｏｍへの遷移は、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍから発生したので、システムは、新しいＡｐｐｌｅ．ｃｏｍウェブページ内で、ユーザがさらなる検索のためにｏｎｅ−ｓｅａｒｃｈ．ｃｏｍに戻ることを可能にするオプションを提示することができる。たとえば、システムは、ブラウザ内で、Ａｐｐｌｅ．ｃｏｍウェブサイトを提示しながら、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍ検索に戻るためのフレームを提供することができる。このフレームは、ユーザが元の入力テキストを修正することを可能にすることができ、これは、フレームに関連して提示される提示されるＡｐｐｌｅ．ｃｏｍウェブサイトの側面を動的に変更することができる。
【０１０７】
[00177]図３の特徴３１０は、ｅＢａｙ付け値オプションを表す。このケースでは、ユーザが、このオプションを選択した場合、システムは、ユーザをｅＢａｙに送り、ユーザがｅＢａｙ．ｃｏｍに行って「ｉＰｈｏｎｅ  ５Ｓ」をｅＢａｙ検索フィールド４１２内に入力したかのように、図４Ｂの例示的なユーザインターフェースに示されるような、画面４１０を提示する。特徴４１４は、１９９ドルでの現在の付け値をもつｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢに関する選択可能な返された品物を表す。特徴４１６は、１７５ドルでのｉＰｈｏｎｅ  ５Ｓ  １６ＧＢであり、特徴４１８は、１５０ドルでのｉＰｈｏｎｅ  ５  １６ＧＢを表す。これらのすべては、発生し得る処理の種類の例である。上記で見られたように、「ｏｎｅ−ｓｅａｒｃｈに戻る」ボタン４２０も、ｏｎｅ−ｓｅａｒｃｈフィールドへ戻る容易なアクセスのために、画面内に含まれ得る。システムは、ｏｎｅ−ｓｅａｒｃｈフィールドに戻ることが、以前のページへの戻るナビゲーションコマンドの代わりにオーバレイを除去することを伴うように、オーバレイとしてｉＰｈｏｎｅ  ５ＳのためのＡｐｐｌｅ．ｃｏｍ、ｅＢａｙ．ｃｏｍ、またはＡｍａｚｏｎ．ｃｏｍ購入ページなどの示された宛先ページに遷移することができる。インターフェース４１０は、図１８Ａに示される、本明細書において開示される販売業者に支払い情報を提供するための要求および応答を交換するためにブラウザＡＰＩ１８１８を介して販売業者サイト１８１６と対話するブラウザ１８０６とすることができる。ブラウザ４１０は、支払いを管理し、支払いを許可し、トークンを生成する、などのために、ブラウザ１８０６と支払いサービス１８１０との間の第２のＡＰＩ１８１２を利用するエージェントとしても機能することができる。さらなる対話のため、および支払い処理を取り扱うために、検索サイト、ソーシャルメディアサイト、または他の任意のサイトなどの初期サイトから、ブラウザ４１０に遷移することがあるであろう。
【０１０８】
[00178]図３は、ドロップダウンメニュー内のＡｍａｚｏｎ検索３１２も示す。ユーザが、このオプションを選定するとき、システムは、ユーザがＡｍａｚｏｎ．ｃｏｍ上でｉＰｈｏｎｅ  ５Ｓを検索したかのように、画面を提示することができる。そこから、ユーザは、ユーザがＡｍａｚｏｎ．ｃｏｍ上でブラウジングし始めたかのように、ショッピングおよび検索をし続けることができる。オブジェクト３１２は、ユーザによって選択可能であり、ユーザがデータを入力フィールド３０２へとタイプした後、ユーザへのその第１のプレゼンテーションを有することができる。このことは、インターフェース上の混乱を減少させる。一態様では、ドロップダウンメニューは、ユーザが他の任意の対話なしにデータをフィールドへと入力すると、自動的に下に降りる。言い換えれば、図３に示されるように、ドロップダウンメニューを生じさせるためにクリックするボタンはない。このことは、入力フィールド３０２内のユーザ入力データを用いてａｍａｚｏｎ．ｃｏｍ（または他の任意のサイト）に遷移するために必要な対話を減少させる。別の態様では、ユーザがキーボード上の「ｅｎｔｅｒ」キーを打ち（すなわち、ボタンはクリックされない）、これは、システムに入力を処理させ、ドロップダウンメニューを生じさせることができる。メニューは、単に、選択のためにユーザに提示されるオブジェクトまたはフィールドとすることもできる。言い換えれば、メニューは、具体的には、ドロップダウンメニューでなくてもよい。たとえば、図２Ａのオプション２０６は、オプションを提示させるために、２０２におけるユーザ入力、またはユーザがキーボード上で「ｅｎｔｅｒ」を打ったことに基づいて、提示可能である。図３のドロップダウンメニューは、Ａｐｐｌｅ．ｃｏｍ３１４を介して直接的に製品を購入するオプションを含むことができる。ユーザが、そのオプションを選択した場合、Ａｐｐｌｅ．ｃｏｍに「ワンクリック」購入オプションがないと仮定すると、ユーザは、非常に少ない対話で購入を完了できる点に導かれることができる。たとえば、システムは、購入される準備のできた製品を示すショッピングカートにユーザを導くことができる。１つのオプションでは、システムは、製品を見て、ショッピングカートへと製品（ｉＰｈｏｎｅ  ５Ｓ）を置ける点にユーザを導く。別の態様では、システムは、ユーザに代わってショッピングカートモデルをナビゲートし、購入を完了し、それによって、トランザクションをワンクリック購入とすることがある。
【０１０９】
[00179]図３は、本開示の別の例も示す。このケースでは、「ドロップダウン」メニューがさまざまなタイプのデータを含むので、オプションは、「ドロップダウン」メニューならびに「ドロップアップ」メニューを含むことができる。購入オプションは、特徴３１６および３１８に示されるようにドロップ「アップ」されてもよく、検索オプションまたはより伝統的なオプションのすべてが、ドロップ「ダウン」可能である。システムは、必要に応じて、左、右、斜めに、または任意の方向、方位、もしくは角度で、メニューを提示することができる。購入オプションを検索タイプオプションから分離することは、不注意による購入の数を減少させることもできる。この例では、図３のドロップダウンメニューは、特徴３０４、３０８、３１０、および３１２はさらなる検索を伴うので、これらのみを含んでよい。システムはそれぞれ、「ドロップアップ」メニュー３１８および３１６内に品物３０６および３１４を位置決めすることができる。アルゴリズムは、ユーザが検索を要望した場合は最も可能性の高い検索を、ユーザが品物を購入し、それらを第１のオプションとしてメニュー内で下に、および第１のオプションとして上に位置決めすることを要望した場合は最も可能性の高い購入を、予測することができる。ユーザは、キーボードまたはタッチスクリーン上の矢印ボタンを使用して、所望のオプションを選択することができる。あるいは、ドロップダウンメニューまたはドロップアップメニューは、ユーザがマウスを使用することなくオプションを選択するために押すことができるショートカットキーを示すことができる。たとえば、メニューは、ユーザが、さまざまなドロップアップメニューオプションを選択するａｌｔ−１、ａｌｔ−２、もしくはａｌｔ−３、またはｃｔｒｌ−１、ｃｔｒｌ−２、もしくはｃｔｒｌ−３、またはさまざまなドロップダウンメニューオプションを選択するための何らかの他の単一のキーもしくはキー組み合わせを押すことができることを示すことができる。システムは、ユーザが類似のキーボードショートカットを使用してアクティブ化することができる自動完了オプションを提示することができる。たとえば、ユーザが「ｉＰｈｏｎｅ」をタイプした場合、システムは、「ｉＰｈｏｎｅ」の後に「Ｓ６４」を押すと、「ｉＰｈｏｎｅ  ５Ｓ  ６４ＧＢ」にオートコンプリートするであろうことを示すことができる。そのようなオートコンプリートキーボードショートカットのタイプおよび量は、ユーザの決定された意図、ならびにシステムがその点まで製品の属性を理解するとき製品の属性に応じて、広く変化することができる。音声アクティビティまたはジェスチャ入力または他の任意のタイプの入力は、ユーザが所望のオプションを選択することを可能にすることができる。
【０１１０】
[00180]いくつかのケースでは、システムは、検索フィールド内のデータは購入のために意図されていないと決定することができる。たとえば、ユーザが「Ｓｏｕｔｈ  Ｄａｋｏｔａ」というテキストを入力した場合、システムは、ユーザが購入を行うことを要望しないことを識別することができる。そのケースにおける「ドロップダウン」メニューは、従来の検索オプションを単にリストしてもよいし、Ｓｏｕｔｈ  ＤａｋｏｔａＴシャツまたはラシュモア山の記念品などのＳｏｕｔｈ  Ｄａｋｏｔａに関係する品物をワンクリック購入するオプションをリストしてもよい。一態様では、ユーザは、たとえば、購入が要望されておらず、むしろ、ユーザの意図は、プロジェクトのためにＳｏｕｔｈ  Ｄａｋｏｔａに関する調査を実行することであることをシステムに示すために、「Ｓｏｕｔｈ  Ｄａｋｏｔａを調べる」を入力することができる。この例では、システムは、さまざまな信頼性レーティングを有するソースからドロップダウンメニュー内に表示される調査結果を返すことができる。ユーザは、たとえば、信頼性または人気に基づいて、必要に応じてドロップダウンメニューからソースを選択することができる。
【０１１１】
[00181]ユーザは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍフィールド内に提示される購入オプションをガイドするために、検索フィールド内にヒントまたは簡潔な命令を追加することもできる。たとえば、ユーザは、「ｂｕｙ  ａｍａｚ  ｉＰｈｏｎｅ  ５Ｓ」というテキストを提供することができる。これらのヒントは、ユーザが購入機能を要望しており、所望の販売業者はＡｍａｚｏｎであることをアルゴリズムに告げる。アルゴリズムは、正規表現を使用して、利用可能な販売業者のデータベースを検索し、所望の販売業者はＡｍａｚｏｎであると決定し、ユーザは驚くべきｉＰｈｏｎｅを買うことを要望すると決定しないことができる。販売業者の曖昧さを解消するために、アルゴリズムは、たとえば、ユーザアカウント内に記憶された以前の検索に基づいて、決定をさらに行うことができる。これらのタイプのヒントに基づいて、システムは、図３に示されるドロップダウンメニューから、特徴３０４、３０８、３１０、３１２、および３１４をなくすことができる。そのケースでは、ユーザは、ただ「ｒｅｔｕｒｎ」を打ってよく、最も可能性の高い所望の製品が自動的に購入され、発送のために処理される。ユーザがｅｎｔｅｒを打ったときに実行されるｅｎｔｅｒ機能におけるこの動的な変更についての情報は、検索フィールド内で、たとえば、ユーザによってタイプされたテキストの右に、提示可能である。図４Ａに示される購入をキャンセルするボタン４０４および購入を修正するボタン４０８などの、キャンセルまたは修正するオプションは、もちろん、提示可能である。
【０１１２】
[00182]一例では、統一された入力フィールドは、スマートフォン、タブレット、または他のモバイルコンピューティングデバイス上でダウンロード可能またはインストール可能なアプリケーションの一部である。機能性も、ウェブサイト上の統一された検索フィールドに適用されてよい。アプリケーションは、本明細書において開示される任意のウェブサイトが可能であるように、カスタマイズ可能とすることができる。アプリケーションは、複数の異なるタイプの処理にとって一般的である単一の入力フィールドを含む。たとえば、アプリケーションは、Ｓｋｙｐｅまたは通話などのいくつかの異なるオプションとともに、入力フィールドを提示することができる。したがって、フィールドは、連絡先に関する検索を入力するために使用可能である。ユーザは、フィールド内に「ｍｏｍ」とタイプし、次いで、Ｓｋｙｐｅ（登録商標）ビデオ会議オプション、またはＦａｃｅＴｉｍｅ（登録商標）オプションを選択することができる。システムは、ビデオ会議要求を延長するまたは通話を行うことによって、適切なコンテキストに従って、入力フィールドを処理する。本明細書において開示される統一されたフィールド概念は、ユーザ入力の処理がウェブ検索または購入に関係することに限定されないことに留意することは、重要である。他の機能性は、統一されたフィールドから実施可能である。通話、ビデオ会議、スマートフォン上の任意のセンサのトリガ、写真を撮影すること、テキストを送ること、など。これらの特徴が従う場合のいくつかの例である。統一されたフィールド内に、ユーザが、「Ｍａｒｋ  Ｓ．、一緒にランチに行きせんか？」というテキストを入力することがある。次いで、ユーザは、「テキストを送る」、オンラインチャットルームでチャットすること、またはソーシャルメディアウェブサイト上でコメントを投稿すること、などの処理オプションを選択することがある。
【０１１３】
[00183]図４Ｃは、製品を購入するために口頭でのダイアログおよび／またはメッセンジャーアプリケーションを使用する方法例を示す。テキストダイアログも用いられてよい。以下は、口頭での入力とテキスト構成要素の両方を用いた口頭でのダイアログの一例であり、類似の手法がただ、ユーザがテキストを介して対話することを用いて、適用されてよい。この点に関する例示的な方法は、メッセンジャーアプリケーションを介して、販売業者サイトとユーザとの間のダイアログの一部として、ユーザから入力を受信すること（４３０）と、メッセンジャーアプリケーション内の入力に関連づけられたテキストをユーザに提示し、ダイアログの一部として、販売業者サイトによって、応答で入力に応答すること（４３２）と、メッセンジャーアプリケーション内で応答に関連づけられたテキストを提示すること（４３４）と、ダイアログを介してユーザが販売業者サイトから購入することを要望する製品を識別すること（４３６）とを含む。ダイアログを介したユーザによる買う対話に基づいて、方法は、ブラウザにおいて、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、販売業者サイトから、製品を購入するためにユーザの支払いデータのための、支払い要求を受信すること（４３８）と、支払い要求に応答して、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのための支払い情報を通信することと、ここにおいて、販売業者サイトは、支払い情報を使用して、製品のための支払いを処理する（４４０）と、を含む。
【０１１４】
[00184]方法は、ブラウザにおいて、ブラウザ支払い要求アプリケーションプログラムインターフェースを介して、販売業者サイトから、ユーザのための住所データのための住所要求を受信することを含むことができる。住所要求に応答して、方法は、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、販売業者サイトにユーザのための住所データを通信することを含むことができる。販売業者サイトは、支払い情報を使用して支払いを処理する。支払いは、販売業者サイトが製品のための支払いを処理するために使用することができるユーザのための支払いアカウント情報を含むことができる。ブラウザは、ユーザにメッセンジャーアプリケーションを提示することができる。方法は、口頭での入力なしでも、テキストダイアログを介して発生することがある。
【０１１５】
[00185]販売業者サイトの観点からの方法は、メッセンジャーアプリケーションを介して、販売業者サイトとユーザとの間のダイアログの一部として、販売業者サイトからユーザへのプロンプトを送信することと、ダイアログの一部として、販売業者サイトにおいて、ユーザ入力を受信することと、ユーザ入力に基づいて、ユーザがダイアログを介して販売業者サイトから購入することを要望する製品を識別することとを含むことができる。ダイアログを介したユーザによる買う対話に基づいて、方法は、ブラウザに、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、販売業者サイトから、製品を購入するためにユーザの支払いデータのための、支払い要求を送信することと、支払い要求に応答して、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのための支払い情報を受信することとを含むことができる。支払い情報を使用して、販売業者は、製品の支払いを処理することができる。もちろん、販売業者の観点からのこの態様は、テキストのみまたは口頭でのダイアログのみの手法、およびユーザが話し中であり、販売業者も話し中であるが、ダイアログのテキストバージョンが、追従すること、および購入のためのオプションを選択するためにビデオまたは画像などの、ユーザ対話のためにユーザに提示される手法を含むことができる。
【０１１６】
[00186]いくつかの基本的システム構成要素および概念を開示して、本開示は、次に、図５に示される例示的な方法例に目を向ける。わかりやすくするために、方法が、方法を実施するように構成された図７に示される例示的なシステム７００に関して説明される。本明細書において略述されたステップは例示的であり、あるステップを除外、追加、または修正する組み合わせを含む、ステップの任意の組み合わせで実施可能である。
【０１１７】
[00187]図５は、一般的な方法例を示す。システムが、ユーザ入力を受信する（５０２）。システムが、ユーザ入力を処理する際に製品データベースにアクセスする（５０４）。たとえば、新しい製品が発売されたばかりで、オンラインで購入するために利用可能である場合、システムは、ユーザが「ｉＰｈｏｎｅ  ５Ｓ」を入力するとき、システムが、その情報にアクセスすることができるように、その入力を製品と合致させることができる。システムは、ユーザ意図の決定のために入力を分析する（５０６）。たとえば、ユーザが、「Ｒｈｏｄｅ  Ｉｓｌａｎｄ」を入力した場合、システムは、ユーザがＲｈｏｄｅ  Ｉｓｌａｎｄを購入することを要望する、非常に低い可能性を計算することができる。ユーザプロファイル、ユーザ検索および購入履歴、ならびに他の任意のデータは、ユーザが何を要望するかの選択肢を迅速に行うことを可能にするように、拡張可能メニューをどのようにして構築するかを決定するために、アルゴリズムによって使用可能である。しかしながら、ユーザが追加のテキストを入力すると、システムは、それに応じてオートコンプリートオプションを更新することができる。たとえば、ユーザが「Ｒｈｏｄｅ  Ｉｓｌａｎｄ  料理本」を入力した場合、システムは、何らかの時点で、ユーザは、州ではなく、料理本に興味がある可能性があると決定することができ、料理本は購入可能な品物である。次いで、システムは、ユーザが追加のテキストを引き続き入力すると、自動的にオートコンプリートオプションを即時に適合させることができる。
【０１１８】
[00188]図５は、次に、システムが、ドロップダウンメニュー（５０８）またはさまざまなオプションまたはオブジェクトのプレゼンテーションをユーザインターフェース内の任意のロケーションに構築することを示す。この構築は、企業が、オプションがどのように提示されるかについての代金を支払うことがあるので、マーケティングの側面も含むことができる。Ａｍａｚｏｎ．ｃｏｍ、または製品製造業者は、そのオプションを選択して製品を購入するようにユーザに勧めるために、ユーザがその製品を買うことを要望し得ると思われる場合、少額の代金を支払って、グラフィックスまたはマルチメディアコンテンツとともに製品を提示することができる。システムは、ユーザが選定するためのオプションのメニューまたは他の構造化されたプレゼンテーションを提示する（５１０）。オプションは、ユーザ入力が、アルゴリズムを介して、購入が要望され得ることを示すとき、１つまたは複数の購入オプション（５１２）を含む。
【０１１９】
[00189]別の態様では、分類器が、一般的な統一された検索フィールド内のユーザ入力を処理することができる。この分類器は、ユーザの意図を決定し、どのウェブサイトまたはアプリケーションを入力に応答して提供するべきかを選択するように訓練可能である。分類アルゴリズムは、多くの場合、スピーチまたは通話を処理する際に使用される。たとえば、いくつかの分類特徴は、通話を処理し、国内、国際、ボイスメール、会議などのようなさまざまな通話タイプに分類することができる。いくつかのケースでは、ユーザが対話型音声応答システムに電話すると、分類器は、以前の通話を使用してユーザ入力を処理し、ユーザが経理に話しかけるまたは請求書を支払うことを望むと結論づけるように訓練可能である。たとえば、ユーザが、通話中に、「請求書を支払いたい」または「私のアカウントについて助けが必要です」と言うことがある。その入力を分類することによって、システムは、通話を適切な人間、宛先、またはエンティティにルーティングすることができる。
【０１２０】
[00190]分類に使用される技術は、統計学、データマイニング、パターン認識、機械学習、ならびに、いくつかのケースでは、ニューラルコンピューティングおよび人工知能を含む。一般的な分類システム手法は、入力を受信すること、入力を前処理すること、入力をセグメント化およびラベル付与すること、入力から特徴を抽出すること、後処理、ならびに入力を最終的に分類して決定に到達することを伴う。これらの原理は、多くの分野で適用されているが、これらの技術は、新しい分類ドメインに適用可能である。新しい分類ドメインは、ユーザが入力を提供するブラウザ上などの統一された入力フィールドのコンテキストまたは意図であり、その入力は、多くの異なるウェブサイト、アプリケーション、またはアクションに適用可能である。今すぐ、ある人間がＧｏｏｇｌｅ．ｃｏｍに行ったとき、仮定は、ユーザがインターネットを検索することを望むというものである。ユーザがＡｍａｚｏｎ．ｃｏｍに行ったとき、ユーザは、何かを買うことを望む。ユーザは、これらの異なる機能のために異なるウェブサイトに行かなければならず、追加の不必要なマウスクリックを必要とする。本開示は、１つの点で、ユーザが検索するまたは製品を買うことを望むという仮定がないウェブサイト上のフィールド内のユーザ入力を処理する分類器の導入を提供する。分類器は、分類決定を介して、ユーザの意図が何かを決定する。
【０１２１】
[00191]本明細書において‘意図分類器’と呼ばれる分類器を訓練するために、システムは、ある時間の期間にわたってユーザのウェブ使用状況を監視することができる。分類器は、１人のユーザまたは複数のユーザのデータを利用することができる。たとえば、２０〜３０歳の男性、または女性、または特定のマイノリティもしくは宗教団体などの特定の人口統計の人々に関する、ａｍａｚｏｎ．ｃｏｍ入力フィールド内の入力と比較して、Ｇｏｏｇｌｅ入力フィールドにおける入力の訓練データを生成することができる。訓練データは、好ましくは、何らかの点で、個々のユーザに特有である。ユーザがブラウザにログインし、したがって、ブラウザがそのユーザの訓練データまたは関連のある訓練データに接続することができる場合、システムは、統一された入力フィールド内のユーザ入力をより効率的に処理することができる。システムは、訓練データが、入力がどのクラス（すなわち、検索、購入、Ｗｉｋｉｐｅｄｉａなど）に属するかを提供することができるように、教師あり学習（または教師なし学習または半教師あり学習）を使用して、訓練セットにラベル付与することができる。訓練データは、購入フィールドではなく検索フィールドを介して提供される入力を伴う。オークション、医学的アドバイス、ｔｗｉｔｔｅｒ入力テキスト、Ｆａｃｅｂｏｏｋ入力テキスト、または他の任意のソーシャルネットワーキング入力テキストなどの、他のフィールドも、適用することができる。一般的な概念は、ユーザがデータをフィールドに入力したときに所望の機能が何かに関する仮定はないというものである。
【０１２２】
[00192]訓練モデルにとって有用であり得る他のデータは、個人的なユーザ情報である。たとえば、ユーザが、ａｍａｚｏｎ．ｃｏｍにおいてワンクリック購入を行うために登録されている場合、ユーザが「Ａｎｄｒｏｉｄ  ４．４  ＫｉｔＫａｔ」とタイプすると、システムは、Ａｎｄｒｏｉｄ  ４．４をもつ最も人気のあるスマートフォンの購入を完了するために可能なクリックおよびコンピュータ対話の最短数が、Ａｍａｚｏｎ．ｃｏｍを通してであることを知る。そうでない場合、ユーザは、別のウェブサイトに送られることがあり、ショッピングカートモデルを経由して、クレジットカードを入力し、購入を完了するために大量の余分な時間および労力を要しなければならない。したがって、ユーザが１つまたは２つの購入ウェブサイトに登録されていることを知ること（したがって、迅速な「ワンクリック」購入を可能にすること）は、分類の結果を駆動することができる。
【０１２３】
[00193]別の例では、このケースにおける分類器は、検索、ブラウズ、今すぐ購入する、ゲームをする、ソフトウェアを更新する、電子メールを送る、ツイートを送る、Ｆａｃｅｂｏｏｋをチェックする、Ｓｋｙｐｅを介して通話を行う、などの分類タイプを有することができる。訓練されたモデルのための分類データのうちのいくらかは、ｇｏｏｇｌｅ．ｃｏｍ、ａｍａｚｏｎ．ｃｏｍ、Ｗｉｋｉｐｅｄｉａ．ｃｏｍなどの間の入力フィールド内で使用されるさまざまなタイプの入力から引き出され得る。分類器を訓練するためのシステムは、どのウェブサイトが使用中であるかに関連して、さまざまなタイプの入力を調べることができ、訓練データを作成する。他のケースでは、通常、ユーザは、Ｓｋｙｐｅアプリまたは他の通話アプリに進み、通話を行うために母親を選定するので、ユーザが「母に電話する」とタイプした場合、そのような入力は、入力フィールド内に提供されないであろう。したがって、他のケースでは、訓練は、入力のその「コマンド」タイプをキャプチャする異なる手段で、発生することがある。しかしながら、始めたときにおける入力の所望の意図の仮定はないので、そのような訓練は、ユーザが１つの入力フィールドで始まる機能のホストを実行することを可能にするために使用可能である。
【０１２４】
[00194]ユーザは、このケースでは、所望の入力に関するヒントを提供することもできる。入力全体が「ｉＰｈｏｎｅ  ５Ｓを買う」であるようにユーザが「ｉＰｈｏｎｅ  ５Ｓ」の前に「買う」をタイプすることが、手をマウスへと動かし、そのマウスをブラウザ内のａｍａｚｏｎ．ｃｏｍタブもしくはアイコンをクリックするように動かすこと、または「ｗｗｗ．ａｍａｚｏｎ．ｃｏｍ」をＵＲＬ用入力フィールドにタイプすることよりも迅速であることがある。明らかに、買うための提案は、購入が意図であることを分類器に告げる。現在、「ｉＰｈｏｎｅ  ５Ｓを買う」とタイプすることは、依然として、検索結果が提供される検索アルゴリズムを介して考えられている。システムは、ユーザがｉＰｈｏｎｅ  ５Ｓのための広告またはプロモーションページに進むことを可能にするスポンサー付き広告を示すことができるが、それらは、依然として、購入を行うことが実際に可能である点に到達するために追加のクリックを要する。さらに、システムは依然として、ユーザがワンクリック以内に購入／配達を完了することを可能にしないウェブページ（ｇｏｏｇｌｅ．ｃｏｍ）上に結果を提示することができる。
【０１２５】
[00195]したがって、本開示による分類アルゴリズムは、ユーザまたは類似のユーザがさまざまなウェブページ上の入力フィールドを介して提供したさまざまな種類の入力を含む訓練データを利用して、ユーザはどのウェブページを開くことを要望するのか、またはユーザがウェブページ上でどのアクションを実行することを要望するかを説明する意図を決定することができる。システムは、他のデータを使用して、時刻、時期、友人の誕生日のようなソーシャルメディアデータ、休暇、気象情報、どのウェブサイト上でユーザは購入を行ったか、およびユーザは以前にどのウェブサイトに登録したかなどの決定を行うことができる。
【０１２６】
[00196]たとえば、分類器は、ユーザは購入を行うことを望むと決定することがある。分類器は、検索する意図または購入を行う意図の基本的な決定をすることができる。次いで、分類器は、履歴、ユーザプロファイル、登録、最も良い価格、ユーザの住所に最も近いアウトレットなどに基づいて、どの販売業者でユーザが購入を行うことを望む可能性があるかを決定するために２つ目のステップを取ることができる。ユーザが、アカウントをａｍａｚｏｎ．ｃｏｍでセットアップした場合、システムは、可能性の高い主な宛先としてａｍａｚｏｎを選定し、適切なステップを取ることがある。たとえば、システムは、ａｍａｚｏｎ．ｃｏｍにおいて事前入力された入力語句をもつ新しいタブを作製することができ、または、ユーザがタブを開き、ユーザがただ購入を完了するために「ワンクリック購入」ボタンをクリックすることができるａｍａｚｏｎ．ｃｏｍウェブサイト内の状態であることができる新しいタブを作製することができる。システムは、新しいタブ内、統一された入力フィールドと同じページ内で、または何らかの他のやり方で、新しいページを提示することができる。
【０１２７】
[00197]システムは、より伝統的なメニューの代わりに、タグフィールドなどの完全に異なる形でオプションを提示することができる。図６は、各選択可能なオプションに関連づけられたパラメータが関連性に基づいて選定されるオプションを示す。たとえば、システムは、さまざまなオプションのためのタグフィールド内での品物の位置決め、サイズ、形状、色、詳細を選択および修正することができる。特徴６０２は、Ａｍａｚｏｎワンクリック購入である。特徴６０４はＧｏｏｇｌｅ検索であり、特徴６０６はｅＢａｙ検索である。タグクラウドまたはワードクラウドでは、品物のサイズ、形状、色、および他の詳細は、品物についての情報を提供することができる。この例では、Ａｍａｚｏｎワンクリック購入６０２は、大きなフォントで、太字で、検索フィールド３０２の近傍に、リストされる。大きなフォントは、システムが、検索フィールド内に入力されたテキストに非常に関連があると決定したことを示すことができる。太字フォントは、品物をクリックすることが、購入をトリガすることを示すことができる。ｅＢａｙ検索６０６も同様に大きく、ｅＢａｙ検索６０６も非常に関連があることを潜在的に示すが、その品物６０６に関連づけられたワンクリック購入はないので、太字ではない。Ｇｏｏｇｌｅ検索６０４は、より小さいフォントで側方に提示され、あまり関連がないまたは重要でないことがあることを示す。これらの品物のさまざまな詳細は、ユーザが検索フィールド３０２内の追加の情報を入力するとき、スムーズでアニメーション化されたやり方で変化することができる。たとえば、ユーザが、特定の所望のｉＰｈｏｎｅについてのより多くの情報を入力すると、システムは、サイズを次第に増加させる、検索フィールドのより近くへと移動させる、より太い線で描画させる、などのように、ユーザインターフェース上のＡｍａｚｏｎ６０２オプションを調整することができる。システムは、これらの詳細を、ますます関連性のある品物が、ますます発見可能な場所に、またはますます目立つように、提示されるように、アニメーションとしてユーザに提供することができる。
【０１２８】
[00198]図６は、選択可能なオプションをどのようにしてｏｎｅ−ｓｅａｒｃｈ入力フィールドから構造化し、提示するかのさまざまなオプションを示す。一態様では、従来のドロップダウンオプションが、図６の特徴６０２のように提示される購入オプションとともに通常のやり方で提示可能であり、したがって、どの品物が標準的なドロップダウンメニューであるか、自動完了タイプオプションであるか、およびどれがワンクリック購入タイプオプションであるかのさらなる区別を提供する。システムは、タグフィールド内に、または他の例において、ターゲットとされる広告を提示することができる。たとえば、図６では、ユーザは、「Ａｍａｚｏｎ  ｉＰｈｏｎｅ  ５Ｓを買う」を入力した可能性がある。これは、ユーザがＡｍａｚｏｎを介してその製品を買うことを望む高い可能性または確率という結果になり、したがって、システムに、大きいフォントで入力フィールド３０２の近くにオプションを示す特徴６０２を提示させる。言い換えれば、より高い使用状況またはストーリーに対する興味またはクラウド入力から、より大きい語句を作成するタグクラウドのように。特徴６０４は、同じ製品に対してより安い価格を提供し得る競合企業からの有料広告を表すことができる。そのような情報は、特徴６０４として表されるアイコンまたは広告の一部として提示されてもよい。
【０１２９】
[00199]開示される概念、方法、および技法を実施するために用いられ得る、図７の基本的な汎用システムまたはコンピューティングデバイスの説明が、示される。図７を参照すると、例示的なシステムおよび／またはコンピューティングデバイス７００は、処理ユニット（ＣＰＵまたはプロセッサ）７２０と、読み出し専用メモリ（ＲＯＭ）７４０およびランダムアクセスメモリ（ＲＡＭ）７５０などのシステムメモリ７３０を含むさまざまなシステム構成要素をプロセッサ７２０に結合するシステムバス７１０とを含む。システム７００は、プロセッサ７２０と直接的に接続された、その近傍に接続された、またはその一部として統合された、高速メモリのキャッシュ７２２を含むことができる。システム７００は、プロセッサ７２０による迅速なアクセスのために、メモリ７３０および／または記憶デバイス７６０からキャッシュ７２２にデータをコピーする。このようにして、キャッシュは、データを待機する間のプロセッサ７２０の遅延を回避する性能ブーストを提供する。これらおよび他のモジュールは、さまざまな動作またはアクションを実行するようにプロセッサ７２０を制御することができる、または制御するように構成可能である。他のシステムメモリ７３０も、使用のために利用可能であってよい。メモリ７３０は、異なる性能特性をもつ複数の異なるタイプのメモリを含むことができる。本開示は、複数のプロセッサ７２０をもつコンピューティングデバイス７００上で動作してもよいし、より大きい処理能力を提供するために一緒にネットワーク化されたコンピューティングデバイスのグループまたはクラスタ上で動作してもよいことが諒解可能である。プロセッサ７２０は、任意の汎用プロセッサと、プロセッサ７２０を制御するように構成された、記憶デバイス７６０内に記憶されたモジュール１  ７６２、モジュール２  ７６４、およびモジュール３  ７６６などのハードウェアモジュールまたはソフトウェアモジュールと、ならびにソフトウェア命令がプロセッサへと組み込まれた特殊目的プロセッサとを含むことができる。プロセッサ７２０は、複数のコアまたはプロセッサ、バス、メモリコントローラ、キャッシュなどを含む、内蔵型コンピューティングシステムであってよい。マルチコアプロセッサは、対称的であってもよいし、非対称的であってもよい。プロセッサ７２０は、複数の、物理的に別個のプロセッサを異なるソケット内に有するシステム、または単一の物理チップ上に複数のプロセッサコアを有するシステムなど、複数のプロセッサを含むことができる。同様に、プロセッサ７２０は、複数の別個のコンピューティングデバイス内に配置されているが通信ネットワークなどを介して連携する複数の分散プロセッサを含むことができる。複数のプロセッサまたはプロセッサコアは、メモリ７３０もしくはキャッシュ７２２などのリソースを共有することができる、または独立したリソースを使用して動作することができる。プロセッサ７２０は、状態機械、特定用途向け集積回路（ＡＳＩＣ）、またはフィールドＰＧＡを含むプログラマブルゲートアレイ（ＰＧＡ）のうちの１つまたは複数を含むことができる。
【０１３０】
[00200]システムバス７１０は、さまざまなバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってよい。ＲＯＭ７４０などに記憶された基本入力／出力（ＢＩＯＳ）は、スタートアップ中などにコンピューティングデバイス７００内の要素間で情報を転送する助けとなる基本ルーチンを提供し得る。コンピューティングデバイス７００は、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ、テープドライブ、ソリッドステートドライブ、ＲＡＭドライブ、リムーバブル記憶デバイス、安価なディスクの冗長アレイ（ＲＡＩＤ）、ハイブリッド記憶デバイスなどの、記憶デバイス７６０またはコンピュータ可読記憶媒体をさらに含む。記憶デバイス７６０は、プロセッサ７２０を制御するためのソフトウェアモジュール７６２、７６４、７６６を含むことができる。システム７００は、他のハードウェアモジュールまたはソフトウェアモジュールを含むことができる。記憶デバイス７６０は、ドライブインターフェースによってシステムバス７１０に接続される。ドライブおよび関連づけられたコンピュータ可読記憶デバイスは、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピューティングデバイス７００に関する他のデータの不揮発性記憶装置を提供する。一態様では、特定の機能を実行するハードウェアモジュールは、特定の機能を実行するために、プロセッサ７２０、バス７１０、ディスプレイ７７０などの必要なハードウェア構成要素に関連して有形コンピュータ可読記憶デバイス内に記憶されたソフトウェア構成要素を含む。別の態様では、システムは、プロセッサおよびコンピュータ可読記憶デバイスを使用して、プロセッサによって遂行されるときプロセッサに動作、方法、または他の特定のアクションを実行させる命令を記憶することができる。基本的な構成要素および適切な変形形態は、デバイス７００が、小さいハンドヘルドコンピューティングデバイスであるか、デスクトップコンピュータであるか、それともコンピュータサーバであるかなどの、デバイスのタイプに応じて修正可能である。プロセッサ７２０が、「動作」を実行するために命令を遂行するとき、プロセッサ７２０は、動作を直接的に実行するおよび／または別のデバイスもしくは構成要素が動作を実行することを容易にする、動作を実行するように別のデバイスもしくは構成要素に指示する、もしくは動作を実行するために別のデバイスもしくは構成要素と協働することができる。
【０１３１】
[00201]本明細書において説明される例示的な例は、ハードディスク７６０を用いているが、磁気カセット、フラッシュメモリカード、デジタル多用途ディスク（ＤＶＤ）、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）７５０、読み出し専用メモリ（ＲＯＭ）７４０、ビットストリームなどを含むケーブルなどの、コンピュータによってアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読記憶デバイスも、例示的な動作環境において使用されてよい。有形コンピュータ可読記憶媒体、コンピュータ可読記憶デバイス、またはコンピュータ可読メモリデバイスは、過渡波、エネルギー、搬送波信号、電磁波、および信号それ自体などの媒体を明確に除外する。
【０１３２】
[00202]コンピューティングデバイス７００とのユーザの対話を可能にするために、入力デバイス７９０は、スピーチのためのマイクロホン、ジェスチャ入力またはグラフィカル入力のためのタッチセンシティブ画面、キーボード、マウス、モーション入力、スピーチなどの任意の数の入力機構を表す。出力デバイス７７０は、当業者に知られているいくつかの出力機構のうちの１つまたは複数とすることもできる。いくつかの例では、マルチモーダルシステムは、ユーザが、コンピューティングデバイス７００と通信するために複数のタイプの入力を提供することを可能にする。通信インターフェース７８０は、一般に、ユーザ入力およびシステム出力を支配および管理する。任意の特定のハードウェア構成上で動作することに関する制限はなく、したがって、示された基本的なハードウェアは、展開されるとき、改善されたハードウェアまたはファームウェア構成と容易に置換され得る。
【０１３３】
[00203]説明をわかりやすくするために、例示的なシステム例は、「プロセッサ」とラベルが付与された機能ブロックすなわちプロセッサ７２０を含む個々の機能ブロックを含むように提示される。これらのブロックが表す機能は、限定するものではないが、汎用プロセッサ上で遂行するソフトウェアの等価物として動作することを専用とする、プロセッサ７２０などの、ソフトウェアおよびハードウェアを遂行することが可能であるハードウェアを含む、共有ハードウェアまたは専用ハードウェアのどちらかの使用を通して提供され得る。たとえば、図７において提示される１つまたは複数のプロセッサの機能は、単一の共有プロセッサによって提供されてもよいし、複数のプロセッサによって提供されてもよい（「プロセッサ」という用語の使用は、ソフトウェアを遂行することが可能であるハードウェアをもっぱら指すと解釈されるべきでない）。例示的な例は、マイクロプロセッサおよび／またはデジタル信号プロセッサ（ＤＳＰ）ハードウェアと、上記で説明された動作を実行するソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）７４０と、結果を記憶するためのランダムアクセスメモリ（ＲＡＭ）７５０とを含むことがある。超大規模集積回路（ＶＬＳＩ）ハードウェア例、ならびに汎用ＤＳＰ回路と組み合わせたカスタムＶＬＳＩ回路も、提供されることがある。
【０１３４】
[00204]さまざまな例の論理演算は、（１）一般的使用コンピュータ内のプログラマブル回路上で動作する、コンピュータにより実施されるステップ、動作、もしくは手順のシーケンス、（２）特殊使用プログラマブル回路上で動作する、コンピュータにより実施されるステップ、動作、もしくは手順のシーケンス、および／または（３）プログラマブル回路内の相互接続された機械モジュールもしくはプログラムエンジンとして実施される。図７に示されるシステム７００は、記載された方法のすべてまたは一部を実施することができる、記載されたシステムの一部とすることができる、および／または記載された有形コンピュータ可読記憶デバイス内の命令に従って動作することができる。そのような論理演算は、モジュールのプログラミングに従って特定の機能を実行するようにプロセッサ７２０を制御するように構成されたモジュールとして実施可能である。たとえば、図７は、プロセッサ７２０を制御するように構成されたモジュールである、３つのモジュールＭｏｄ１  ７６２、Ｍｏｄ２  ７６４、およびＭｏｄ３  ７６６を示す。これらのモジュールは、記憶デバイス７６０上に記憶され、実行時にＲＡＭ７５０またはメモリ７３０にロードされてもよいし、他のコンピュータ可読メモリロケーション内に記憶されてもよい。
【０１３５】
[00205]コンピューティングデバイス７００の全体までとそれを含む、例示的なコンピューティングデバイス７００の１つまたは複数の部分は、仮想化可能である。たとえば、仮想プロセッサは、仮想プロセッサと同じタイプの物理プロセッサが利用可能でないときですら特定の命令セットに従って遂行するソフトウェアオブジェクトとすることができる。仮想化層または仮想「ホスト」は、仮想化された動作を実際の動作に翻訳することによって、１つまたは複数の異なるコンピューティングデバイスまたはデバイスタイプの仮想化された構成要素を可能にすることができる。しかしながら、最終的に、あらゆるタイプの仮想化されたハードウェアは、何らかの基礎となる物理ハードウェアによって実施または遂行される。したがって、仮想化算出層は、物理的算出層の上で動作することができる。仮想化算出層は、仮想マシン、オーバーレイネットワーク、ハイパーバイザ、仮想スイッチング、および他の任意の仮想化アプリケーションのうちの１つまたは複数を含むことができる。
【０１３６】
[00206]プロセッサ７２０は、仮想プロセッサを含む、本明細書において開示されるすべてのタイプのプロセッサを含むことができる。しかしながら、仮想プロセッサを参照するとき、プロセッサ７２０は、仮想化層内で仮想プロセッサを遂行することに関連づけられたソフトウェア構成要素と、仮想化層を遂行するために必要な、基礎となるハードウェアとを含む。システム７００は、コンピュータ可読記憶デバイス内に記憶された命令を受け取る物理的プロセッサまたは仮想プロセッサ７２０を含むことができ、これは、プロセッサ７２０にある動作を実行させる。仮想プロセッサ７２０を参照するとき、システムは、仮想プロセッサ７２０を遂行する基礎となる物理的ハードウェアも含む。
【０１３７】
[00207]本開示内の各ケースでは、「Ａｍａｚｏｎ」またはＡｍａｚｏｎ．ｃｏｍ」への参照は、あらゆる購入／配達または電子商取引ウェブサイト、ならびに品物またはサービスを提供する、従来の、電子商取引を行っていない会社のためのウェブサイトを包含するのに十分なほど広い。「Ｇｏｏｇｌｅ」サイトへの参照または検索は、任意の一般化された検索エンジンを指す。多くの事例において、本明細書において記載された原理は、システムがユーザに代わって、特定の、意図されたアクションを成し遂げるために操作または横断することができる、他の非検索および非商取引サイトに適用可能であり得る。
【０１３８】
[00208]図７のシステムは、バーチャルリアリティデバイスも表すことができる。デバイスは、完全に含まれるヘッドセットとすることができ、またはＳａｍｓｕｎｇデバイスもしくはｉＰｈｏｎｅもしくは他のモバイルデバイスなどのモバイルデバイスを受け入れるヘッドセットを含むことができる。この点に関して、図７の特徴は、そのようなヘッドセットの構成要素を含むことができる。入力デバイス７９０は、バーチャルリアリティ環境内にある間、静止画像または映像を撮影するためのカメラ、ユーザによる購入の容易な確認のためにヘッドセットの側面に構成可能である指紋読み取り装置などの、１つまたは複数の異なるタイプの入力デバイスを表すことができる。出力デバイス７７０は、ユーザが画像を閲覧する画面を表すことができる。通信インターフェース７８０は、他のデバイス、アクセスポイント、基地局などとの、Ｗｉ−Ｆｉ、またはセルラー通信手段もしくは他のワイヤレス通信手段を提供することができる。裁定インターフェース７８０は、２つの構成要素間でデータを通信するための、リムーバブルモバイルデバイスとヘッドセットとの間のインターフェースも表すことがある。メモリ７３０は、当技術分野で使用される任意の標準的なメモリ、ならびにＡｐｐｌｅ  Ｐａｙなどの支払いプロセスにおいて使用するためのセキュアな様式で支払い情報および／または他のユーザ情報を記憶するために使用可能であるセキュアな要素を表すことができる。
【０１３９】
[00209]一例では、バーチャルリアリティヘッドセットは電気的構成要素を含み、したがって、指紋読み取り装置は、ヘッドセットの上または側面に構成可能である。指紋読み取り装置構成要素は、ヘッドセットに組み込まれ、ユーザがバーチャルリアリティ環境にいる間にアクセスするのが容易な位置に構成可能である。このシナリオでは、ユーザが、バーチャルリアリティ環境内で購入を行い、そこで、指紋許可を必要とする支払いプロセス使用する場合、ユーザは、購入を完了するためにヘッドセットの側面に指紋を提供してよい。バーチャルリアリティ環境、命令は、指紋読み取り装置が位置決めされたヘッドセット上のエリアを指す可能性すらある画面上でユーザに提供される可能性がある。バーチャルリアリティヘッドセットは、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して販売業者サイトと通信することが可能であるように構成された類似の機能性をもつブラウザソフトウェアまたはソフトウェアまたはファームウェアも含む可能性がある。したがって、仮想環境を提示するアプリケーションが、ブラウザとして機能する可能性がある。この点に関して、ブラウザＡＰＩプロトコルを用いてプログラムされると、必要な支払いおよび他のユーザデータを記憶する、またはそのようなデータをたとえば、Ｍｉｃｒｏｓｏｆｔウォレット、およびａｎｄｒｏｉｄウォレット、ウォレットへの暗号の流れ、およびＡｐｐｌｅ  ｐａｙウォレットなどに記憶するユーザのモバイルデバイスからワイヤレスでアクセス可能である、外部支払いおよび／もしくは他のユーザデータにアクセスする通信能力を有する、のどちらかである。一態様では、ブラウザＡＰＩは、ブラウザのＡＰＩの別個のインスタンスが一度に２つの別個のサイト上のブラウザＡＰＩインターフェース支払いダイアログに関与することができる場合、一度に２つの購入を処理することが可能にされる。ユーザが２つを同時にしようと試みる場合、システムは、１つのインターフェースを第１のインターフェースとして、第２のインターフェースを第２のインターフェースとして識別し、同時に２つの別個のサイトに対する支払いを別個に管理することができる。
【０１４０】
[00210]いくつかのバーチャルリアリティセットは、バーチャルリアリティ環境において野球のバットまたは釣竿などの品物を提示するために使用可能であるハンドヘルド構成要素も含む。これらは、ヘッドセットとワイヤレスで通信し、ユーザがバットを振っている場合はバットが仮想世界内に現れるように、各ユニットの位置および移動を監視する。これらのハンドヘルド構成要素は、ユーザが左手にハンドヘルドユニットを保持していて、仮想環境において購入を行うことがあるように、それらの上に指紋識別も有することができる。次いで、ユーザは、確認用指紋を提供するために、右手人差し指でセンサに触れることができる。データは、Ｂｌｕｅｔｏｏｔｈ（登録商標）または他のプロトコルを通して、または本明細書において開示される情報を利用して購入を行うことができるユーザデバイスもしくはヘッドセットにワイヤードで、通信可能である。
【０１４１】
[00211]図８は、例示的な方法を示す。各ケースにおいて、「ウェブサイト」がどのように言及されようと、アプリケーションまたはサイトも、モバイルアプリケーションがデータにアクセスするために使用されるときなどに、適用される可能性がある。システムは、方法のステップを実行する。システムは、ウェブサイトのユーザインターフェース上で入力フィールドを提示し（８０２）、入力フィールド内のユーザからのユーザ入力を受信する（８０４）。システムは、入力を分析して、ユーザが、検索を望んだのか、購入を行うことを望んだのか、通話を行う、またはビデオを視聴するなどの何らかの他の機能を実行することを望んだのかを決定する。システムは、オプションのセットを提示し、オプションのセットの各オプションは、入力フィールドの外部で提示され、ユーザがサードパーティウェブサイトの入力フィールドへとユーザ入力を入力したかのようにユーザ入力を処理することに関連づけられる（８０６）。もちろん、１つのオプションが提示される可能性もある。図２および図３は、処理のためのオプションのセットを提示する例を提供する。この手法の構成要素は、入力フィールドは、１つの特定のコンテキストにおいて入力を処理するように事前指定または事前設計されておらず、入力フィールドは、入力を処理するさまざまな手段にオープンであり、したがって、データを入力するために、あるウェブサイトから別のウェブサイトにナビゲートするために必要なクリックの数を減少させることである。システムは、オプションのセットの選定されたオプションのユーザ選択を受信し（８０８）、選定されたオプションに従ってユーザ入力を処理する（８１０）。
【０１４２】
[00212]オプションのセットの第１のオプションは、検索エンジンに関連づけ可能であり、オプションのセットの第２のオプションは、購入処理エンジンに関連づけられる。選定されたオプションが第２のオプションであり、購入処理エンジンに関連づけられている場合、システムは、ユーザ入力に関連づけられた品物を識別し、品物の購入およびユーザへの品物の配達を処理する。選定されたオプションが第１のオプションであり、検索エンジンに関連づけられている場合、システムは、ユーザ入力に関連づけられた検索を実行するためにユーザ入力を処理し、検索結果を返す。方法は、オプションのセットのためのそれぞれのタイプを識別することと、それぞれのタイプに基づいて、グループ内のオプションのセットを提示することも含むことができる。
【０１４３】
[00213]ユーザ入力は、テキスト入力、マルチモーダル入力、ジェスチャ入力、もしくは音声入力、またはそれらの任意の組み合わせのうちの少なくとも１つを含むことができる。ユーザは、オプションのセットがどのように提示されるかを支配する好みを記憶する既存のアカウントを有することができる。ブラウザＡＰＩは、インターフェースがブラウザインターフェースと考えられる場合にユーザが品物を買うことが可能にされる可能性があるテレビジョンインターフェースなどの任意の種類のインターフェースにおいて、働く可能性もある。
【０１４４】
別のソースから統合されたユーザインターフェースに向けられた入力に基づいたアクションの遂行
[00214]図９は、入力フィールドから宛先サイトに遷移する例に関連づけられたユーザインターフェースを示す。この例示的なユーザインターフェースでは、ユーザは、統一された入力フィールド９０２へと「ｉＰｈｏｎｅ  ５Ｓ」というテキストを入力する。ブラウザは、このテキストをｏｎｅ−ｓｅａｒｃｈサーバに通信し、ｏｎｅ−ｓｅａｒｃｈサーバは、ナビゲーション宛先を返す。ウェブブラウザは、インターフェース内で下にある他のページをのぞき込む穴であるように見える「裂け目」９０４、９０８をページ内にレンダリングすることができる。この裂け目は、２つの位置考慮事項、すなわち、ホストページ内の裂け目の位置と、宛先ページ上への裂け目のビューを有する。システムは、提示する裂け目のロケーションおよびサイズを決定するとき、これらの位置の両方を考慮することができる。ユーザは、その宛先ウェブサイトにナビゲートするために、裂け目をクリックすることができる。そのケースでは、裂け目は、異なるページにナビゲートするためにリンクをクリックすると同じ様式で遷移することができる、または、裂け目が以前のページを完全に置き換えるまで裂け目の境界を拡張するなどの、アニメーション化された遷移を提示することができる。裂け目は、ユーザが、移動する、最大化する９０６ａ、拡張する９０６ｂ、９１０ｂ、プレビューする９１０ｃ、９０６ｄ、閉じる９１０ａ、ページに行く９０６ｃ、または裂け目上で何らかの他のアクションを実行するように裂け目を操作することができるように、それぞれの裂け目の縁に沿って適合されるさまざまな制御部９０６、９１０、９１４を含むことができる。さらに、ユーザは、ワンクリック購入ボタン９０５またはショッピングカートを閲覧するボタン９０７などの、裂け目内に示される露出されたユーザインターフェース要素を直接的に操作することができる。いくつかの裂け目は、通話を行うためのＳｋｙｐｅアプリケーションへのビューなどの、他の非ウェブアクションを示すことができる。システムは、たとえば、より重要な裂け目の方がマウスカーソル９１６または統一された入力フィールドに近いように、統一された入力フィールド内に入力されたテキストから決定された意図に対するより近い合致である裂け目を位置決めすることができる。システムは、マウス９１６が裂け目により近づくにつれて裂け目を動的に拡張し、マウス９１６がより遠ざかるにつれて裂け目を縮小することができる。裂け目縁は、標準的な幾何学的形状を含む任意の形状とすることができ、または、鋭いもしくは滑らかである、もしくは動的で、さまざまな要因に基づいて変化することができる、より複雑な縁を有することができる。
【０１４５】
[00215]タッチベースのインターフェースでは、ユーザは、タッチジェスチャを使用して、裂け目を操作することができる。たとえば、ユーザは、裂け目をタップアンドホールドして、裂け目をページ上であちこちに移動させ始めることができる。ユーザは、スワイプして、裂け目内のページのビューを移動させることができる、または挟んで、裂け目内に表示されるページ上でズームすることができる。ユーザは、裂け目をダブルタップして、裂け目内に表示されるページにナビゲートすることができる。システムは、ホストページと同じズーム比で裂け目内にコンテンツを表示することができる、または、裂け目内に表示されるコンテンツを縮小して、コンテンツのより広いビューを表示することができる。
【０１４６】
[00216]図１０は、別のソースから統合されたユーザインターフェースに向けられた入力に基づいてアクションを遂行するための例示的な方法を示す。この例では、この方法を実行するシステムが、統一された入力フィールド内のユーザ入力を受信する（１００２）。システムは、ユーザ入力を分析して、分析をもたらす（１００４）。システムは、分析に基づいて、別個のサイトまたはアプリケーションからの下にあるユーザインターフェースの少なくとも一部分を明らかにする少なくとも１つの裂け目を動的に提示し、下にあるユーザインターフェースは、ユーザ入力を統合させる（１００６）。システムは、裂け目に関連づけられた機能を実行するための制御入力をユーザから受信する（１００８）。次いで、システムは、機能を実行することができる（１０１０）。
【０１４７】
修正可能なｅｎｔｅｒボタン
[00217]分類器を介して決定された意図に基づいて、および統一された入力フィールドに提供されたテキストに基づいて、統一された入力フィールドに関連づけられた検索ボタンを動的にモーフィングまたは適合させる、システム、方法、およびコンピュータ可読記憶デバイスが開示される。一般的には、統一された入力フィールドは、２つの主な構成要素、すなわち、テキスト入力フィールドと、このテキスト入力フィールドを介して提供された入力に基づいて検索を遂行する検索ボタンとを有する。検索ボタンは、一般的には、「検索」または「進む」というテキストまたは同様に一般的なもので、ラベル付与される。しかしながら、ユーザが検索語句を入力すると、システムは、何らかの他の、より具体的なアクションを識別することができ、異なるテキストまたはグラフィカルなラベルを動的に表示するように検索ボタンを修正することができるだけでなく、それに応じて、ボタンと関連づけられたアクションを修正することもできる。加えて、システムは、単一の検索ボタンを複数のボタンへと拡張することができる。
【０１４８】
[00218]たとえば、ユーザは、「Ａｐｐｌｅ」というテキストを入力する。その時点で、分類器は、「Ａｐｐｌｅ」というテキスト文字列は、検索ボタン上のラベルを修正するのに十分なほど具体的なアクションまたは品物に結び付けられると決定しない。そのため、検索ボタンは、変更されないままである。ユーザは、「Ａｐｐｌｅ  ｉＰｈｏｎｅ」というテキストを引き続き入力する。その時点で、分類器は、追加のテキストに基づいて、いくつかの特定の品物もしくはアクションは可能性があるが、品物もしくはアクションのあまりにも多くが利用可能である、または検索ボタンを修正するための確実性閾値を上回るものがないことを識別する。ユーザは、「Ａｐｐｌｅ  ｉＰｈｏｎｅ  ５Ｓ」というテキストを引き続き入力し、その時点で、分類器は、ｉＰｈｏｎｅのモデルである５Ｓを識別する。次いで、ユーザの好みまたは他の利用可能なデータに基づいて、分類器は、ゴールド６４ＧＢ  ｉＰｈｏｎｅ  ５ＳなどのｉＰｈｏｎｅ  ５Ｓの特定の変種を識別することができる。したがって、システムは、もはや「検索」と言わず、代わりに「ｉＰｈｏｎｅ  ５Ｓ、６４ＧＢ、ゴールドを購入する」と言うように、検索ボタンのラベルを修正することができる。ユーザは、その時点で、そのアクションを遂行し、示されたｉＰｈｏｎｅ  ５Ｓを購入するために、キーボード上のｅｎｔｅｒを単に打つことができる。したがって、ｅｎｔｅｒ機能は動的であり、デフォルトモードにおける第１の時間から、ユーザが検索問い合わせをタイプし始めた後の第２の時間における第２の機能に変化する。
【０１４９】
[00219]検索ボタンを修正する代替として、システムは、追加のボタン、またはドロップダウンもしくはドロップアップするメニュー、または他の任意のインターフェースを生成し、検索ボタンの隣に提示することができる。システムは、異なるキーまたはキーの組み合わせが異なるボタンをアクティブ化する標識を提供することができる。たとえば、ｅｎｔｅｒを打つことは、「検索」ボタンに関連づけられた機能をアクティブ化し、ｃｔｒｌ−ｅｎｔｅｒを打つことは、「ｉＰｈｏｎｅ  ５Ｓ、６４ＧＢ、ゴールドを購入する」ボタンの機能をアクティブ化する。オブジェクトの上でカーソルを移動させることは、ユーザが「ｅｎｔｅｒ」を打つときに実行される機能の変更をトリガまたはアクティブ化することができる。システムが追加のボタンを提示すると、ユーザは、さまざまな関連づけられたアクションをアクティブ化するために追加のボタンもクリックすることができる。
【０１５０】
[00220]いくつかのケースでは、修正されたボタンは、何らかの追加の一義化を依然として必要とすることができる。たとえば、修正されたボタンは、「ｉＰｈｏｎｅ  ５Ｓ、６４ＧＢを購入する」とラベル付与可能である。ユーザが、修正されたボタンをアクティブ化するためにｅｎｔｅｒを押すと、システムは、「ゴールドの場合は１回、シルバーの場合は２回、またはブラックの場合は３回、ｅｎｔｅｒを押してください」を言うようにボタンを修正することなどの、追加のダイアログまたはボタン修正を提示することができる。ユーザが、その入力を提供した後、システムは、「Ａｐｐｌｅから購入するには１回、Ａｍａｚｏｎから購入するには２回、ｅｎｔｅｒを押してください」を言うように、ボタンラベルを修正することができる。システムは、これらの追加のメッセージを用いてボタンラベルを修正することができる、または、それらをページ上の何らかの他のロケーションに提示することができる。このようにして、ユーザは、所望のアクションまたは購入に関連づけられたテキストを迅速に入力し、容易に、手をキーボードとマウスの間であちこち移動させることなく、さまざまなオプションを選択することができ、非常に単純でなじみの深い入力を使用して一義化決定木の間でナビゲートすることができる。
【０１５１】
[00221]ユーザがミスをするまたは選択をキャンセルすることを望む場合、ユーザは、入力したテキスト内の文字を削除するためにｂａｃｋｓｐａｃｅを単に打ち、これがコンテキストを潜在的に変更し、修正されたボタンおよび対応する１つまたは複数のアクションのリセットをトリガすることができる。ユーザがミスをし、選択を取り消すことを望む場合、ユーザは、単にｅｓｃａｐｅキーを打つ、または戻ることをシステムに示す何らかのキーボード、マウス、もしくは他の入力を提供することができる。
【０１５２】
[00222]システムは、ユーザの行動パターンおよび好みを学習し、それに応じて適合することができ、したがって、経時的に、システムは、ユーザの意図を正確に決定または分類するためにユーザからの入力をますます必要としなくなることができる。たとえば、システムは、ユーザがどの品物を既に購入したのか、ユーザがどの品物について友人または家族と検討したのか、どの贈答イベントが間近に迫っているのかなどを知ることができる。すべてのこれらのデータポイントに基づいて、分類器は、ユーザの可能なまたは可能性のある意図に関する、より正確な推測を行うことができる。
【０１５３】
[00223]マウスとキーボードとを有さず、代わりに一般的にはタッチセンシティブスクリーンまたはスタイラスを装備するモバイルデバイスでは、上記に記載された手法が修正されることがある。たとえば、従来のデスクトップスタイル検索フィールドおよび検索ボタンペアにおけるボタンを修正する代わりに、システムのモバイル変形形態は、スクリーン上の仮想キーボード、音声入力、または何らかの他の入力手法を介してテキストを入力するために、ユーザに検索フィールドを提供することができる。ユーザがテキストを入力すると、システムは、検索フィールドからドロップダウン様式でワンクリックアクションのリストを提示することができる。ワンクリックアクションのうちのいくつかは、従来の様式で検索を実施していることがあるが、他のワンクリックアクションは、Ａｍａｚｏｎ．ｃｏｍ内の、ユーザが既にログインしており、購入するために「ワンクリック」を単に遂行しなければならない段階などの、ウェブサイト内で特定の段階にナビゲートすること、またはｅＢａｙに、もしくはショッピングカートに既に追加された所望の品物をもつオンライン販売業者のショッピングカートの最終的な精算フェーズにおいて、付け値することを含むことがある。ユーザは、リスト内のワンクリックアクションをスワイプして画面から出すことによって、それらを却下することができる。
【０１５４】
ユーザが入力を入力したときの調整可能なｅｎｔｅｒ機能
[00224]本明細書において開示される別の概念は、ユーザが入力を入力するときのユーザ入力を処理するｅｎｔｅｒ機能を動的に修正するための手法に関する。たとえば、ユーザが、入力フィールド内にテキストをタイプし始めたとき、デフォルト機能は、テキストに対するＧｏｏｇｌｅ検索であることがある。しかしながら、ユーザがテキストの第２の部分をタイプすると、ユーザがｅｎｔｅｒを打ったときに発生する機能は、テキストに対するＡｍａｚｏｎ．ｃｏｍ検索へと修正可能である。ｅｎｔｅｒ機能の変更の視覚的な標識は、メニューシステム内に、または選択可能なオブジェクトを介して、提示可能である。図１１は、方法例を示す。方法例内のステップは、任意の順序で実行可能であり、追加のステップを含むまたは説明されるステップのうちのいくつかのうちのすべてもしくは一部を除外する他の組み合わせまたは順列で実行可能である。システムは、検索する第１のモードと入力フィールド内のユーザからの入力に基づいてワンクリック購入および配達を実行する第２のモードとの間でモーフィングする入力フィールドおよびボタンをユーザインターフェース内に提示することができ、このボタンは、ユーザがｅｎｔｅｒキーを押したことに基づいて、そのそれぞれの機能を実行する（１１０２）。ユーザインターフェースは、入力を受信しながら、購入される品物を一義化するためにどのキーエントリが必要とされるかをユーザに示す一義化情報を提示することができ、購入されることが望まれる品物における信頼水準が閾値を満たすようにユーザからキーエントリを受信すると、ボタンは、第２のモードへとモーフィングすることができる。ボタンの第１のモードは、ボタンに対するデフォルトモードとすることができる。
【０１５５】
[00225]システムは、ユーザから入力フィールドへの入力を分析して、ユーザが検索を実行することを要望するか購入を行うことを要望するかを決定し、決定をもたらすことができる（１１０４）。決定が、ユーザが購入を行うことを要望することを示す場合、システムは、ボタンを第２のモードに設定し、ｅｎｔｅｒキーを押すこと以外のユーザからのさらなる入力なしにユーザの登録されたアカウントに従って購入および配達されるであろう品物についてのデータを提示することができる（１１０６）。システムは、入力フィールドエンティティに関連づけられた登録されたアカウントから品物の支払いを処理し、ビジネスパートナーの販売業者を通して品物の配達を協調させることによって、品物を買い、配達するプロセス全体を管理することができる。品物は、製品またはサービスとすることができる。システムは、品物が、ユーザが入力に基づいて購入することを要望する可能性の最も高い品物である確率に基づいて、購入および配達される品物を選択することができる。たとえば、分類器は、購入のユーザ履歴、検索のユーザ履歴、時刻、時期、ソーシャルメディアデータ、休暇についての情報、ユーザプロファイルデータ、および／またはユーザアカウント残高情報に基づいて、確率および品物を決定することができる。購入および配達データは、本明細書において開示されるブラウザＡＰＩを通して、宛先販売業者サイトとユーザのブラウザとの間で取り出し可能である。第２のモードは、ユーザがＡｍａｚｏｎ．ｃｏｍ（または他の任意の二次サイト）にナビゲートし、ユーザ入力内に入力して、検索をクリックしたかのような、ユーザ入力に基づいた検索状態における（Ａｍａｚｏｎ．ｃｏｍなどの）第２の宛先サイトへの遷移も含むことができる。
【０１５６】
[00226]図１２Ａは、一般化された入力フィールド１２０２とモーフィング可能な検索ボタン１２０４とをもつユーザインターフェース１２００を示す。検索ボタン１２０４は、実際は、一般化された機能ボタンである。システムは、問い合わせまたは他の入力を入力するようにユーザ１２０６に指示することができる。この手法の違いは、「検索」ボタンを打つことによって実行される機能がユーザ入力に応じて異なることである。これは、図を通してステップごとに説明される。図１２Ｂは、「Ａｐｐｌｅ」１２１２という単語の、フィールド１２０２へと入れられ始める、インターフェース１２１０内の入力を示す。システムは、ユーザが「検索」１２０４をクリックしたまたはｅｎｔｅｒボタンを打ったときに実行される機能を変更または修正するべきかどうかを決定するためにこの入力を処理する。図１２Ｃは、ユーザインターフェース１２２０内での「Ａｐｐｌｅ  ｉＰｈｏｎｅ」１２２２という追加の入力を示す。システムは、その入力を引き続き処理し、単にＧｏｏｇｌｅタイプ検索とは対照的に、おそらくユーザが購入の機能を実行することを要望すると決定し始めるであろう。図１２Ｄは、入力が「Ａｐｐｌｅ  ｉＰｈｏｎｅ  ５Ｓ」１２３２を含むようにより具体的であり続けるインターフェース１２３０を示す。ユーザ入力を分析する際の閾値点において、システムは、特定の機能が望ましい十分高い信頼度に達する。これは、検索履歴データ、または履歴とは無関係なテキスト自体に基づいてよい。ここで、システムは、「検索」から「ｉＰｈｏｎｅ  ５Ｓ、６４ＧＢ、ゴールドを購入する」１２３４にボタン１２０４を変更する。ユーザ入力において識別されないオプションは、一義化も発生することができるようにテキストに挿入可能である。しかし、このインスタンスでは、システムは、統一された一般化された入力フィールド（検索および購入が行われ得る）から、ユーザが、「ｅｎｔｅｒ」を押して、または図１２Ｄのボタン１２０４をクリックして、購入の処理および配達を完了することを可能にする。
【０１５７】
[00227]諒解され得るように、手法は、ユーザがｅｎｔｅｒを打つまたはアイコンをクリックする１２０４ときに実行される機能の動的修正ことを可能にする。図３に示されるなどのいくつかのインターフェースでは、デフォルトプロセス３０４は、入力フィールド３０２のすぐ下に提示される。したがって、図３のインターフェースの状態を考えると、ユーザがｅｎｔｅｒを打った場合、「ｉＰｈｏｎｅ  ５Ｓ」という単語に対するＧｏｏｇｌｅ検索が実行されるであろう。ｅｎｔｅｒキーを打ったときに動的に変化する結果に関して説明される原理を適用することは、ユーザが入力をタイプすることであり、一例では、ユーザが「Ａｐｐｌｅ  ｉＰｈｏｎｅ  ５Ｓ」を入力フィールド３０２内でタイプし続ける場合、メニュー内の項目の順序が、Ａｍａｚｏｎ検索オプション３１２が、デフォルトＧｏｏｇｌｅ検索３０４オプションがある位置に移動されるように、修正されることがある。これは、図１２Ｄにおける変更ボタンのような、ｅｎｔｅｒを打つことが、ユーザがタイプし始めたときに実行されるであろうものとは異なるプロセスを実行することの、ユーザへの標識であろう。
【０１５８】
[00228]さらなるインターフェースは、どのさまざまなボタンがユーザによってクリックするために提示されるかを含むことができる。ボタンは、ユーザが「ワンクリック」を介して購入を行うための異なるオプションを示すことができる。ユーザが単に検索することを望むことがある可能性が依然としてある場合、検索ボタンも利用可能にされ得る。これらのうちの１つが、ユーザがキーボード上の「ｅｎｔｅｒ」を打った場合に、その特定の強調されたボタンが購入または検索として入力を処理するものであることを識別するために、何らかの手段で強調可能である。このようにして、ユーザは、最初にウェブサイト（ＧｏｏｇｌｅまたはＡｍａｚｏｎ．ｃｏｍのような）にナビゲートし、次いでユーザ入力データを入力するのではなく、最初に入力データを入力し、次いで、機能を実行することができる。別のインターフェースは、ユーザが、「ｉＰｈｏｎｅ  ５Ｓ、６４ＧＢ、ゴールドを購入する」をタイプすることによって、直接的なヒントを与えることを可能にする。このケースでは、システムは、次いで、ユーザが、ストアピックアップ内のために、発送情報をもつＡｐｐｌｅ、もしくはその価格および発送情報をもつＡｍａｚｏｎを通して１２５６、または運送業者を通して、それを購入するためのオプションを提示することができる。システムは、必要な購入情報（クレジットカード、デビットカード、配達住所など）がインターフェース内でワンクリック購入としてユーザに提示されるように、この購入情報をさまざまなウェブサイトと交渉する。これは、現在、ユーザにとって利用可能ではなく、Ａｍａｚｏｎ．ｃｏｍのような、そのような情報を登録させた別個のウェブサイトにナビゲートしなければならない。
【０１５９】
[00229]検索ボタンがどのようにモーフィング可能であるかの別の例では、いくつかのブラウザにおいて、上部にある入力フィールドは、ＵＲＬを入力する、またはＧｏｏｇｌｅ検索を入力する、のどちらかのために使用可能である。検索を始めたとき、タイプしたものの右に、何が進行中であるかを示すタグがある。たとえば、このようなものである。「歯科医Ｄｕｎｋｉｒｋ  Ｍａｒｙｌａｎｄ  −  ｇｏｏｇｌｅ検索」。「ｇｏｏｇｌｅ検索」という言い回しは、ユーザがタイプしたものではなく、ブラウザがテキストをＧｏｏｇｌｅ検索として扱っているという標識である。このテキストは、もちろん、タイプされているテキストが分析されるにつれて、「ｅｎｔｅｒ」が打たれたときに何が起こるかについてのユーザへの標識が変化することができるようにもモーフィング可能である。たとえば、ユーザが、タイプし始め、「ａｐｐｌｅ  −  ｇｏｏｇｌｅ検索」を見ることがある。しかしながら、ユーザが引き続きタイプすると、それが、「ａｐｐｌｅ  ｉＰｈｏｎｅ  ５Ｓ  −  Ａｍａｚｏｎ検索」と変化することがある。ユーザが引き続きタイプし、一義化すると、それは、「ａｐｐｌｅ  ｉＰｈｏｎｅ  ５ｓ  ６４ＧＢ  シルバー  −  Ａｍａｚｏｎワンクリック購入」という結果になる場合がある。この時点で、ユーザは、「ｅｎｔｅｒ」を打つことができ、システムは、所望の製品が購入され、ユーザに配達されることが可能であるように、製品を識別するために必要な情報と、購入アカウント情報（１つのエンティティと一緒にあることができる）と、配達情報とを協調させる。配達は、支払い処理を取り扱う１つのエンティティから、第２の販売業者エンティティによって管理可能である。
【０１６０】
[00230]図１２Ｅは、ユーザ入力のデフォルト処理から第１の宛先サイト（ユーザ入力に基づいたデフォルトＧｏｏｇｌｅ検索など）に、第２の宛先サイト（Ａｍａｚｏｎ．ｃｏｍ、Ｗｉｋｉｐｅｄｉａ、または任意のサイトなどの）に変更するプロセスに対処する例示的な方法を示す。方法は、ブラウザ上で入力フィールドを提示することであって、このブラウザは、デフォルト宛先サイトに従って、入力を処理するようにブラウザに示すユーザ対話に基づいて、入力フィールド内の入力を一般に処理するように構成される、提示すること（１２４０）と、入力フィールドへのユーザ入力を受信すること（１２４２）とを含む。ユーザ入力は、１つのケースでは、特定のウェブサイトへのＵＲＬではなく、検索語句である場合がある。ユーザ入力に基づいて、方法は、ユーザが入力フィールドへとユーザ入力を入力した場合にユーザが遷移する第２の宛先サイトを示すオブジェクトを動的に提示すること（１２４４）と、オブジェクトによって示されるユーザ入力を処理するようにブラウザに示す処理対話をユーザから受信すること（１２４６）と、この処理対話に基づいて、デフォルト宛先サイトから第２の宛先サイトに変化すること（１２４８）と、ユーザ入力に従って処理された状態で第２の宛先サイトにユーザを遷移させること（１２５０）とを含む。
【０１６１】
[00231]図１２Ｅに示されるプロセスの一例として、ブラウザが、デフォルト処理設定としてＧｏｏｇｌｅ検索を有すると仮定する。ユーザが、キーボード上のｅｎｔｅｒにおいて「ｎｏｒｔｈ  ｄａｋｏｔａ」を入力したまたは入力を処理するように示すオブジェクトをクリックした場合、ユーザに提示される結果は、「ｎｏｒｔｈ  ｄａｋｏｔａ」という単語に対するＧｏｏｇｌｅ検索結果であろう。しかしながら、異なるユーザ入力に基づいて、およびブラウザ上の以前の検索履歴またはナビゲーションによってガイドされる一態様では、ブラウザは、ボタン、オブジェクト、入力フィールド内に自動的に提示される追加のテキスト、またはメニュー内の項目を介して、ユーザがキーボード上のｅｎｔｅｒを打ったまたはオブジェクトをクリックした場合、ユーザ入力はデフォルト手法によって処理されず、ユーザがｅｎｔｅｒをクリックしたときに異なる宛先サイトまたは検索が実行されるように、変更または遷移が発生することを示すことができる。ユーザは、「ａｐｐｌｅ  ｉＰｈｏｎｅ  ５Ｓ」を入力して、ｅｎｔｅｒを打つことがあり、ユーザがタイプしているときのユーザ入力の分析に基づいて、システムは、デフォルトプロセスから、入力を処理してｗｗｗ．ａｐｐｌｅ．ｃｏｍまたはｗｗｗ．ａｍａｚｏｎ．ｃｏｍまたは任意のサイトにユーザを遷移させることに変更することができる。したがって、ユーザがｅｎｔｅｒを打ったことなどに基づいて発生する処理は、ユーザがタイプしている間、動的に変化する。システムは、ユーザがｅｎｔｅｒを打ったことに基づいて、入力がＡｍａｚｏｎ．ｃｏｍにおける製品を言うことに関係しない場合、通常のデフォルトＧｏｏｇｌｅ検索を処理する、または入力の分析が、入力が製品関係でない可能性があることを示す場合、システムは、ユーザがｅｎｔｅｒをＡｍａｚｏｎ．ｃｏｍ検索、もしくは他の販売業者サイト検索へと打った結果を変更し、宛先サイトに遷移する、のどちらかである。
【０１６２】
[00232]図１２Ｆは、ユーザ入力の処理を動的に変更する別の態様を示す。方法は、デフォルト宛先サイトに従って入力を処理するユーザ入力フィールドを提示すること（１２６０）と、入力フィールド内のユーザ入力を受信すること（１２６２）と、ユーザ入力に基づいて、ユーザが入力フィールド内にユーザ入力を入力した場合、ユーザがデフォルト宛先サイトとは異なる第２の宛先サイトに遷移することを示すオブジェクトを自動的に提示すること（１２６４）と、ユーザ入力を処理するために確認をユーザから受信すること（１２６６）とを含む。方法は、この確認に基づいて、第２の宛先サイトにユーザを遷移すること（１２６８）をさらに含む。確認は、ユーザがｅｎｔｅｒボタンを打つこと、ユーザ入力が処理されるべきことを示す何らかの他のタイプの入力を提供すること、またはキーボード上のｅｎｔｅｒキーを押すこととすることができる。メニュー内の項目の順序は、タイプ中にデフォルトサイトが変化するように、ユーザがタイプするにつれて動的に調整することもできる。ユーザが、タイプしながらこれらの変更を監視し、選定された宛先サイトに遷移するワンクリック機会に到達することができる。ワンクリックは、キーボード上のｅｎｔｅｒボタン、またはユーザ入力を処理するためのクリックオブジェクトとすることができる。他の入力が必要でないことが留意される。オブジェクトの提示は、ユーザからの他の任意の手動対話のない、ユーザ入力フィールドへの入力のタイピングに基づく。ユーザがタイプするとオブジェクトが動的に提示されることによって、ユーザがタイプするときの入力の分析に基づいて、ユーザは、ｅｎｔｅｒボタンに接触しなくてもよいことが留意される。したがって、宛先サイトの変更プロセスは、ユーザがタイプにつれて、動的に発生することができる。
【０１６３】
[00233]別の例は、上記の検討に基づいて、宛先サイトの観点からとすることができる。したがって、どんなデータの協調または通信が必要であっても、Ａｍａｚｏｎ．ｃｏｍ、ｅＢａｙまたはＷｉｋｉｐｅｄｉａまたは他の任意のサイトなどの宛先サイトが、デフォルト宛先サイトが二次宛先サイトに修正されるように入力フィールド内のユーザ入力から遷移を受信する場合があるように、実施形態として含まれるであろう。この実施形態は、上記で記載されたプロセスを介して遷移が可能にされた宛先サイトにおけるそのような遷移を受信することを含むであろう。
【０１６４】
[00234]本開示の別の態様は、プロセスのタイミングに関する。第１の時間は、ユーザが入力フィールドへとデータを入力する前の時間および／またはユーザが入力フィールドへと入力をタイプし始める時間の一部分として確立可能である。第１の時間において、ｅｎｔｅｒ機能は、ユーザが入力をタイプし、ｅｎｔｅｒキーを打つときのデフォルトアクションとして確立される。たとえば、デフォルトｅｎｔｅｒ機能がＧｏｏｇｌｅ検索である場合、第１の時間において、ユーザが入力フィールドへとテキストをタイプし始めるとき、デフォルトｅｎｔｅｒ機能はＧｏｏｇｌｅ検索であり、これは、ユーザが入力フィールド内のテキストとともにｅｎｔｅｒを打つ場合、Ｇｏｏｇｌｅ検索はテキストに対して実行されることを意味する。ユーザが入力をタイプし始めた後である第１の時間の後である第２の時間において、システムは、ｅｎｔｅｒ機能を変更することができる。たとえば、ユーザが１つの単語または２つの単語をタイプし（ユーザが第１の単語または第２の単語の後にｅｎｔｅｒを打つ場合、第１のデフォルト機能が実行されるであろう）、第３の単語をタイプした後、全体的な入力または入力の一部に基づいて、システムは、ユーザが第３の単語の後にｅｎｔｅｒを打ったとき、異なる機能が実行されるべきであると決定する。システムは、次いで、ｅｎｔｅｒ機能をデフォルト機能から新しいｅｎｔｅｒ機能に変更する。システムは、購入意図というよりも検索意図を示す場所または他の質疑ではなく、製品がフィールドに入力されると決定することがある。グラフィカルオブジェクトも、ｅｎｔｅｒ機能が変化したことをユーザに知らせるように、第２の時間において変化することができる。オブジェクトは、ボタン、ドロップダウンメニューもしくは他のメニュー内の項目、またはメニュー内で識別されたｅｎｔｅｒ機能が変化するようなメニューの再配置とすることができる。この変更は、ユーザ入力がない、自動的であってもよいし、または、ｅｎｔｅｒ機能のうちの１つもしくは複数の変更もしくはｅｎｔｅｒ機能の変更のグラフィカル標識が、変更を発生させることができる、提案される新しいｅｎｔｅｒ機能がどのようなものであるかの識別の上でカーソルを移動することなどの、ユーザがメニュー項目または変更をトリガする他のオブジェクトと対話することによってトリガ可能である。一態様では、ユーザによる入力は、ウェブサイトのＵＲＬではなく検索語句に関係することも留意される。ブラウザ上のいくつかの入力フィールドは、ユーザがデフォルトＧｏｏｇｌｅ検索またはｗｗｗ．ｗｅｂｓｉｔｅ．ｃｏｍのＵＲＬを入力することを可能にし、そのケースでは、ユーザが「ｅｎｔｅｒ」を打ったとき、ユーザはｗｗｗ．ｗｅｂｓｉｔｅ．ｃｏｍに遷移される。したがって、１つのシナリオにおける入力は、ＵＲＬまたはウェブサイト識別子とは異なる。
【０１６５】
[00235]別の態様では、ユーザ入力は、第１の部分および第２の部分として特徴づけ可能である。図１２Ａ〜図１２Ｃは、データのない入力フィールド、すなわち「ａｐｐｌｅ」および「ｉｐｈｏｎｅ」という単語などの、検索問い合わせの始まりを示す。このテキストは、ユーザ入力の第１の部分を表すことができる。ユーザが第１の部分を入力している間、デフォルトｅｎｔｅｒ機能１２０４は動作可能である。ユーザが検索ボタンをクリックしたまたはキーボード上のｅｎｔｅｒを打った場合、デフォルト検索機能が実行される。ユーザがユーザ入力の第１の部分を入力すると、ｅｎｔｅｒ機能は、ユーザがユーザ入力の第１の部分の少なくとも一部を入力しながらｅｎｔｅｒボタンと対話する場合、方法は、デフォルト宛先サイトに従ってユーザ入力の第１の部分を処理することを含むように設定される。図１２Ｄは、「５ｓ」という追加のテキストを示し、これは、ユーザ入力の第２の部分を表すことができる。ユーザをユーザ入力の第２の部分を入力し始めるにつれて、ｅｎｔｅｒ機能は、ユーザがユーザ入力の第２の部分の少なくとも一部を入力しながらｅｎｔｅｒボタンと対話する場合、方法は、図１２Ｄでは購入機能１２３４として示されている、第２の宛先サイトに従ってユーザ入力を処理することを含むが、ユーザが第２の宛先サイトの検索フィールドへとユーザ入力を入力したかのように処理されたユーザ入力とともに、Ａｍａｚｏｎ．ｃｏｍなどの第２の宛先サイトへの遷移を含む可能性があるように変更または設定される。デフォルト機能から二次機能へのｅｎｔｅｒ機能の遷移は、タイピングに基づいて自動的に発生することができ、入力フィールドの隣のオブジェクト、または、ドロップアップメニューもしくはドロップダウンメニューに対して行われる調整内に提示可能である、または何らかのユーザ対話によってトリガ可能である。
【０１６６】
[00236]図１３は、入力フィールド１３０２がさまざまなオプション１３０８という結果になるデータ１３０４を提示させる、ユーザインターフェース１３００のスマートフォンバージョンを示す。モバイルキーボード１３０６も示されている。ここで、ｏｎｅ−ｓｅａｒｃｈ入力フィールド１３０２は、ユーザが、一般化された入力を置き、入力を処理するためにスクロールするさまざまな「ワンクリック」オプション１３０８を有することを可能にする。他のユーザインターフェース１３００は、もちろん、モバイルデバイスまたはコンピュータのために企図されている。インターフェース１３００に関連づけられたアプリケーションおよび／またはバックエンドは、ユーザが異なるソースからのオプション１３０８に目を通し、選定されたソースから単に「ワンクリック」することを可能にするように、さまざまなウェブサイト、ベンダーなどとともに、購入および配達情報を前処理することができる。さらに、システムは、ユーザがブラウジングし、購入の前により多く調べることができるように、完全に「ワンクリック」段階ではなく検索結果段階において、前処理された入力を段階に提示することができる。たとえば、検索エンティティが支払いを処理するために支払い情報を記憶し、配達を取り扱う販売業者と通信している場合などに、結果１３０８は、広告が今すぐ買うオプションに関連づけられ、本明細書において開示される原理に従って処理されるであろうことを示すことができる。図１３で見られ得るように、販売業者が買い手との関係を維持することができるが、購入プロセスは、買うオプション特徴および本明細書において開示されるＡＰＩを使用して簡略化されるように、さまざまな販売業者ブランディングが、応答において提供可能である。
【０１６７】
[00237]一態様では、さまざまな宛先オプション１３０８は、ユーザが問い合わせをタイプするにつれて、位置を切り換えることができる。たとえば、ユーザが、第１の時間においてユーザ入力の第１の部分をタイプし始めたとき、最上位レベルオプションは、ユーザがｅｎｔｅｒを打つときにどの機能が実行されるかを示す検索エンジンであるかもしれない。ユーザが、ユーザ入力の第２の部分、すなわち、図１３に示すようにたとえば「５ｓ」を引き続きタイプするにつれて、宛先機能は、異なる最上位レベル宛先機能が提示されるように、その入力に基づいて調整することがある。したがって、ユーザが、ユーザ入力の第２の部分のうちの少なくともいくつかをタイプした後にｅｎｔｅｒを打った場合、ユーザ入力は、メニュー項目１３０８の最上位レベルにあることによってユーザに識別される二次機能に従って処理される。
【０１６８】
汎用検索アプリケーションプログラミングインターフェース（ＡＰＩ）
[00238]統一された入力フィールドに提供される入力を処理する分類器によって決定された意図に基づいてＵＲＬを置き換える、システム、方法、およびコンピュータ可読記憶デバイスが開示される。典型的なウェブ検索では、ユーザは、検索フィールドを選択するためにクリックし、テキストを入力し、結果ページがロードされるのを待機し、結果ページ内の所望のリンクをクリックして、最終的に、所望のリンクがロードされるのを待機した後に、それに到達する。このプロセスは、多くのステップを必要とする。統一された入力フィールドは、このプロセスを単純化することができる。
【０１６９】
[00239]たとえば、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍは、統一された入力フィールドを提供することができる。ユーザは、「ｉＰｈｏｎｅ  ５Ｓ」に対する検索など、統一された入力フィールドを介して、入力を提供する。システムは、ユーザプロファイルおよび入力されたテキストに基づいて、検索結果のリスト内の最上位にランクされたページなどの、最も可能性の高い所望のページを識別することができる。システムは、ｅｎｔｅｒを押すことまたはボタンをクリックすることが、上記で略述された中間ステップなしに検索結果からその最上位にランクされたページにユーザを遷移させることを示すように、統一された入力フィールドに関連づけられた「検索」ボタンを修正することができる。しかしながら、ユーザが、「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢシルバー」などの追加の情報を入力する場合、分類器は、テキストに基づいて、ユーザプロファイルまたは検索履歴に関連して、ユーザの意図が、示されたｉＰｈｏｎｅを購入することであると決定することができる。この状況では、システムは、ユーザがＡｍａｚｏｎ．ｃｏｍページまたはＡｐｐｌｅ．ｃｏｍページに既にナビゲートし、ｉＰｈｏｎｅ  ５Ｓ、３２ＧＢ、シルバーを選択し、ｉＰｈｏｎｅをカートに追加し、高度な段階または潜在的に精算プロセス内の最終段階にあるかのように、Ａｍａｚｏｎ．ｃｏｍページまたはＡｐｐｌｅ．ｃｏｍページに直接的にリンクするように検索ボタンを修正することができる。Ａｍａｚｏｎ．ｃｏｍのケースでは、システムは、示されたｉＰｈｏｎｅのワンクリック購入をユーザが行う準備のできたページにユーザを遷移するように、ボタンを修正することができる。あるいは、システムは、ユーザが、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍに行き、統一された入力フィールド内にテキストを入力し、ｅｎｔｅｒを打ってＡｍａｚｏｎを通して購入することができるように、ワンクリック購入ボタンをクリックするアクションも含むようにボタンを修正することができる。このケースでは、統一された入力フィールド内にテキストを入力した後にｅｎｔｅｒを打つことは、遂行したばかりの注文の購入概要につながることができ、ユーザが、発送オプション、製品オプション、請求情報、または他の注文詳細を修正することを潜在的に可能にする。別の変形形態では、システムは、ユーザが、統一された入力フィールド内にｅｎｔｅｒを打ったことに基づいて、またはソーシャルメディアサイトもしくは任意のサイトとの対話に基づいて、自動的に発注し、アクセサリを購入するためにウェブページ、購入される品物に関係するサービス、技術的サポートページ、または何らかの他の関係するウェブリソースに、ユーザを遷移させることができる。
【０１７０】
[00240]したがって、システムは、たとえば、ユーザが統一された入力フィールド内のｅｎｔｅｒを打ったまたは任意のサイト上での入力もしくは対話を処理するとき、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍの統一された入力フィールドまたは任意のサイトからＡｍａｚｏｎ上のワンクリック購入ページにユーザを即時に遷移させることができる。システムは、ユーザが統一された入力フィールド内のｅｎｔｅｒを押したことに基づいて購入が完了されるように、遷移アクション内に購入も含むことができる。この点に関して、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍは、購入を取り扱うが、次いで、品物の配達を完了するためにＡｍａｚｏｎ．ｃｏｍまたは販売業者などの第２のエンティティと協調するであろう。
【０１７１】
[00241]システムは、ユーザ入力に基づいて、異なるオプションまたは異なる宛先を提示することができる。たとえば、システムは、「ａｌｔ−ｅｎｔｅｒ」を押すとＡｍａｚｏｎ．ｃｏｍ上で購入を自動的に行うが、「ｅｎｔｅｒ」だけを押すと、Ａｍａｚｏｎ．ｃｏｍ上の所望の品物のためのワンクリック購入ページにユーザを遷移させるというメッセージまたは標識を提示することができる。システムは、「ｓｈｉｆｔ−ｅｎｔｅｒ」を押すと、ユーザが「発注する」をクリックする準備のできた、Ａｐｐｌｅ．ｃｏｍ上の事前にポピュレートされたショッピングカートページにユーザを遷移させることを述べるユーザにメッセージを提示することができる。複数の異なるキーおよび／またはキー組み合わせは、統一された入力フィールド内の入力に基づいて、異なる挙動をトリガすることができる。さらに、さまざまなアクションおよびそれらのアクションをトリガするキー組み合わせは、ユーザが統一された入力フィールド内に追加のテキストを入力する、または統一された入力フィールド内のテキストを修正するにつれて、変化することができる。
【０１７２】
[00242]ユーザは、ユーザが既存のアカウントを有する異なる小売業者では価格差が２０％よりも大きくない限り、またはユーザが既存のアカウントを有さない異なる小売業者では価格差が３０％よりも大きくない限り、すべての購入がＡｍａｚｏｎ．ｃｏｍにデフォルトでなることを示すなどの、システムと好みを確立することができる。このようにして、システムは、ユーザが確立するルールまたはポリシーに基づいて、インテリジェントに機能することができる。
【０１７３】
[00243]一態様では、システムは、ユーザが確立する財政的ポリシーに基づいて、インテリジェントに機能することができる。システムは、異なる小売業者における潜在的な購入価格をユーザが確立した財政的ポリシーと比較することができ、それに応じて決定を行うことができる。たとえば、既存のポリシーは、毎月、ユーザは、５００ドルなどの、ある額の金銭をオンラインで消費することに制限されていることを述べることができる。ユーザがオンライン消費限度に近づいたとき、システムは、特定の購入が、その月の間にこれ以上金額を消費することをユーザから完全に奪うことをユーザに忠告することができる。次いで、ユーザは、この追加の情報を用いて購入決定を行うことができる。たとえば、ユーザは、金銭的な制約により、最も高価なｉＰｈｏｎｅを買う代わりに、適度な価格のついたｉＰｈｏｎｅを買うことを選ぶことがある。または、ユーザは、ユーザが、最も高価なｉＰｈｏｎｅを買うのを、より多いオンライン消費金額を有する翌月まで待機することを選ぶことがある。ユーザは、それが、仕事用電話機などの即時の必要品であると感じたので、ユーザが、それが、確立された財政的ポリシーに違反しているとしても、いずれにしろ購入を進めることを決定することがある。システムがユーザに代わってインテリジェントに機能することを可能にする他のルールまたはポリシーが企図される。この手法は、ブラウザショッピングカートが複数の購入サイトにわたって適用することができる、図１７Ｉに示されるシナリオにも適用することができる。複数の品物がさまざまなサイトからショッピングカートに入れられ、購入を行う前に、ユーザが購入を行ったかのようにユーザの財政的条件を分析して勧告を行うであろうポリシーが、購入が確定する前に適用される場合がある。この勧告は、購入のいずれかを行わないこと、ショッピングカート内の１つの品物のみを購入すること、および／または他の任意の組み合わせを行うことを含むことができる。適用されるアルゴリズムに従ってユーザの財政的条件が適切な状態で維持可能であるような提案。２０１３年１０月２日に出願された出願番号１４／０４６，４４４は、本明細書において開示されるブラウザショッピングカートモデルに適用可能ないくつかの概念を含む。この出願は、参照により本明細書に組み込まれる。
【０１７４】
[00244]ユーザがｅｎｔｅｒをクリックすると、システムは、ユーザがショッピングカート内のページのシリーズをクリックしそれを通して、ナビゲートし、次に各ページをロードし、ブラウザ側でデータを自動的に入力したかのように、新しいＵＲＬまたは宛先サイトに即時に遷移することができる、または、システムは、品物を選択すること、その品物をカートに追加すること、発送および支払い情報などを入力または選択することなど、ユーザが「発注する」を単にクリックする最終的な段階まで至ることに関連づけられたさまざまなサブタスクを達成するために、標的ウェブサイトと直接的に通信することができる。ブラウザＡＰＩは、支払いプロセスを管理するために使用される場合がある。そのようなサブタスクの一例は、ｏｎｅ−ｓｅａｒｃｈエンティティが、支払い情報を処理し、品物を配達する販売業者と配達データを協調させることである。システムは、ユーザが、統一された入力フィールド内のｅｎｔｅｒを打った後、ユーザにページを提示する前に、これらのステップのすべてを事前実行することができる。
【０１７５】
[00245]図１４Ａは、方法例を示す。方法例内のステップは、任意の順序で実行可能であり、追加のステップを含むまたは説明されるステップのうちのいくつかのすべてもしくは一部を除外する他の組み合わせまたは順列で実行可能である。システムは、第１のユーザインターフェース内で、第１のウェブサイトに関連づけられた第１の入力フィールドを提示する（１４０２）ことができる。システムは、ユーザから第１の入力フィールドへの入力を分析して、ユーザが検索を実行することを要望するか購入を行うことを要望するかを決定し、決定をもたらす（１４０４）ことができる。決定は、ユーザが購入を行うことを要望する信頼水準が閾値を超えたことを示すことができる。
【０１７６】
[00246]決定が、ユーザが購入を行うことを要望することを示す場合、入力および／またはおそらくｅｎｔｅｒキー以外のユーザからの他の任意の入力なしで、システムは、第２のユーザインターフェースが第２の入力フィールドを有する第２のウェブサイトに、ユーザインターフェースを自動的に遷移させる（１４０６）ことができる。システムは、第２のウェブサイトに関連づけられた第２の入力フィールドに入力を事前にポピュレートする（１４０８）ことができる。システムは、ユーザが、自動遷移後の、入力に関連づけられた製品がユーザからワンクリックアクションを介して購入および配達のために処理可能である状態であるように、第２の入力フィールド内の入力を使用して第２のウェブサイトを前処理する（１４１０）ことができる。システムは、たとえば、第１のウェブサイトおよび／またはブラウザのうちの１つからＡＰＩを介して第２のウェブサイトにユーザデータを送信することができる、または製品がワンクリックアクションを介して購入および配達のために処理可能である状態をもたらす第２のウェブサイトのショッピングカートモデル内を自動的にナビゲートすることができる。システムは、ブラウザのユニフォームリソースロケータフィールド内の第１のウェブサイトをブラウザのユニフォームリソースロケータフィールド内の第２のウェブサイトと置き換えることによって、第２のウェブサイトにユーザインターフェースを自動的に遷移することができる。システムは、入力を使用して前処理された第３の入力フィールドを有する第３のウェブサイトをさらに準備することができ、ユーザは、第２のウェブサイトではなく第３のウェブサイトが提示されるべきであることを示すために、切り換え入力を提供することができる。別の例では、第１のサイトは、品物のための支払いを処理し、品物の配達のために必要な情報を提供するために第２のサイトと協調することができる。
【０１７７】
[00247]図１４Ｂは、検索エンジン視点からの、ＡＰＩを介した検索エンジンと販売業者との間の処理の一例を示す。方法は、一般化された検索エンティティのユーザインターフェース上で入力フィールドを提示することであって、この一般化された検索エンティティは、販売業者サイトと非販売業者サイトの両方にインデックスを付け検索する一般化された検索エンジンを使用してデータを処理する、提示すること（１４１２）と、入力フィールド内の問い合わせを受信すること（１４１４）と、この問い合わせを販売業者からの販売のための製品の製品データベースと相関づけて相関をもたらすこと（１４１６）とを含む。方法は、この相関に少なくとも一部は基づいて、問い合わせが、決定をもたらすために検索意図および購入意図のうちの１つに関連づけられると決定すること（１４１８）を含む。決定が検索意図を示すとき、方法は、非販売業者サイトを含む検索結果を提示し、非販売業者サイトに関連づけられた検索対話を受信して、この検索対話に基づいて、非販売業者サイトに遷移すること（１４２０）を含む。決定が購入意図を示すとき、方法は、購入関係検索結果が、ユーザが購入関係検索結果と対話し、買うオプションと対話することを介して購入を確認するとき、一般化された検索エンティティは、品物の購入の処理を開始するように構成されるように、問い合わせに関連づけられた買うオプションを含む購入関係検索結果を提示すること（１４２２）を含む。一般化された検索エンティティが支払い情報を記憶する、または、サードパーティ支払い処理サービスが支払い情報を記憶し、ブラウザが支払いデータを記憶することができ、これらのエンティティの一方または両方が、ＡＰＩなどの通信インターフェースを介して、製品データベースからの製品のための広告情報と支払い情報を交換するために販売業者サイトと通信する。処理の任意の情報は、ブラウザ、非商業サイト、および／または販売業者サイトとの間で、ＡＰＩのどちらかの側で発生することができる。
【０１７８】
[00248]図１４Ｃは、図１４Ｂに類似したプロセスを、しかし販売業者視点から示す。方法は、販売業者サイトから、通信インターフェースを介して販売業者サイトと一般化された検索エンティティとの間で通信を確立すること（１４２４）を含む。この一般化された検索エンティティは、このケースでは、上記で説明された動作を実行する。すなわち、一般化された検索エンティティは、一般化された検索エンティティのユーザインターフェース上で入力フィールドを提示し、一般化された検索エンティティは、販売業者サイトと非販売業者サイトの両方にインデックスを付け検索する一般化された検索エンジンを使用してデータを処理する（１４２６）、入力フィールド内の問い合わせを受信し（１４２８）、この問い合わせを販売業者からの販売のための製品の製品データベースと相関づけて相関をもたらし（１４３０）、この相関に少なくとも一部は基づいて、問い合わせが、決定をもたらすために検索意図と購入意図のうちの１つに関連づけられると決定する（１４３２）。決定が検索意図を示すとき、一般化された検索エンティティは、非販売業者サイトを含む検索結果を提示し、非販売業者サイトに関連づけられた検索対話を受信して、この検索対話に基づいて、非販売業者サイトに遷移する（１４３４）。決定が購入意図を示すとき、一般化された検索エンティティは、問い合わせに関連づけられた買うオプションを含むことができる購入関係検索結果を提示し、この購入関係検索結果は、ユーザが購入関係検索結果と対話し、買うオプションと対話したことを介して購入を確認するとき、一般化された検索エンティティが品物の購入の処理を開始するように構成される（１４３６）。次いで、販売業者サイトは、通信インターフェースを介して、購入が達成されたことについてのデータおよび買い手への製品の配達を管理するために必要な情報を受信することができる（１４３８）。
【０１７９】
[00249]図１５は、アプリケーションプログラミングインターフェース（ＡＰＩ）１５０２を介した通信を示す例示的なシナリオ１５００を示す。ｏｎｅ−ｓｅａｒｃｈサーバ、ウェブサーバ、ソーシャルメディアサイト、支払いサービス、または何らかの他のコンピューティングデバイスは、ＡＰＩ１５０２を介してアクセス可能なサービスを提供することができる。ＡＰＩ１５０２によって提供されるサービスは、ＡＰＩ１５０２へのＪａｖａＳｃｒｉｐｔ（登録商標）呼び出しなどを通して、ウェブブラウザまたは他のウェブクライアントにページをサービスするウェブサーバ、モバイルデバイス用アプリケーションから、またはウェブブラウザから、アクセス可能とすることができる。この例では、ブラウザは、第１のウェブサイト１５０４にナビゲートし、ＡＰＩ１５０２に依拠することなく、ＨＴＭＬ、ＣＳＳ、ＪａｖａＳｃｒｉｐｔ、画像、メタデータ、または他のデータなどの第１のウェブサイトのためのデータを第１のウェブサイトサーバ１５０６から取り出す。次いで、ブラウザが、第１のウェブサイト１５０４のためのデータを解析し、ページをレンダリングして、スクリプトまたはウェブサイトのための他の遂行可能な命令をロードするとき、データの１つまたは複数の部分は、ＡＰＩ１５０２にリンクされる、またはこれを参照する。たとえば、テキストフィールドに関連づけられた属性または命令は、ＡＰＩ１５０２を介して検索データを要求するようにブラウザに指示することができる。ＡＰＩ１５０２は、要求をどのように管理するかについての複雑さを取り扱い、したがって、ブラウザ１５０４は、どのサーバが要求を取り扱っているか、結果を達成するためにデータがどのように処理されるかなどを必ずしも知らないまたは配慮しない。ウェブブラウザ１５０４の見地から、データはＡＰＩ１５０２にサブミットされ、ＡＰＩは、結果として得られるデータを提供する、または結果として得られるアクションを実行する。例示的なアクションは、サイト１５０４において支払いを処理するために支払いデータを提供すること、または第２のサイト１５０８において支払いサービスと通信することを含むことができる。このケースでは、テキストフィールドは、テキストフィールド内で入力されたテキストに基づいてＡＰＩ１５０２に要求をサブミットするようにブラウザに指示することができる。したがって、ユーザが、「ｉＰｈｏｎｅ  ５Ｓ  ６４ｇｂを買う」というテキストを入力するにつれて、第１のウェブサイトをロードしたブラウザ１５０４は、１文字ずつ、１語ずつ、または何らかの時間間隔（など２５０ミリ秒）で、ＡＰＩ１５０２にテキスト文字列をサブミットすることができる。さらに、ページローディングおよびレンダリングプロセスの一部として、ブラウザ１５０４は、ユーザのためのユーザデータをサブミットすることができる、または、ＡＰＩ１５０２を用いて既存のセッションを確立、再確立、もしくはこれにリンクすることができ、そのため、ＡＰＩ１５０２は、適切な決定を行うのに十分なユーザについてのコンテキストデータを有する。ウェブブラウザ１５０４からテキストを受信したことに応答して、ＡＰＩ１５０２は、データを分析する、１つまたは複数の���クションの応答、ウェブブラウジング宛先、購入することが要望される品物などを決定することができる。次いで、ＡＰＩ１５０２は、Ｎの最良リストに対して１つまたは複数のアクションのリストを選別することができ、これは、ユーザが使用しているデバイスまたはブラウザのタイプに基づくことができる。たとえば、限られた画面スペースをもつモバイルデバイス上では、Ｎの最良リストは、３つのアクションまたは宛先に限定可能であるが、より十分な画面スペースをもつデスクトップまたはラップトップコンピュータ上では、Ｎの最良リストは、１０のアクションまたは宛先に限定可能である。最良のアクションまたは宛先を決定することの一部として、ＡＰＩ１５０２は、第２のウェブサイト１５０８と通信することができ、これは、支払いサービスまたは他の任意のサービスもしくはデータを提供することができる。アクションが、第２のウェブサイト１５０８を用いたワンクリック購入アクションである場合、ＡＰＩ１５０２は、ユーザまたはブラウザ１５０４に代わって、第２のウェブサイト１５０８における適切なロケーションにナビゲートする、適切なデータフィールドを自動的にポピュレートする、アカウントを作成する（必要な場合）またはユーザのためのアカウントにログインする、ユーザが買うボタンをクリックしたときに第２のウェブサイトからＡＰＩを通して支払い要求を受信する、支払いデータで応答するなどのために、第２のウェブサイト１５０８と交渉することができる。ＡＰＩ１５０２は、ＡＰＩ要求に応答して、これらのタスクのすべてを自動的に取り扱い、その情報を第１のウェブサイト１５１０におけるブラウザに戻して渡すことができ、第１のウェブサイト１５１０は、これらの可能な宛先またはアクションをユーザに提示する。ユーザが、第２のウェブサイトに関連づけられた宛先またはアクションを選択する場合、ブラウザは、ＡＰＩ１５０２が作成または修正した第２のウェブサイト１５０８とのセッションを直接的に継続することができる。このようにして、ＡＰＩ１５０２は、さまざまなアクションまたは宛先が、ユーザが選択して開く準備が整っているように、ウェブサイト間で協調し、ＡＰＩ呼び出しに応答してユーザデータを自動的に入力し、ユーザに代わってさまざまなアクションまたは宛先に事前ナビゲートすることができる。第２のウェブサイトに到着すると、買うボタンが提示され、ユーザが買うボタンをクリックした場合、第２のサイトは、支払いを処理するために、ブラウザＡＰＩを通して支払い情報を要求し、ブラウザＡＰＩを介してアカウントおよび住所またはトークンなどの支払いデータを受信することができる。図１５は、図１８Ａ、および販売業者サイト１８１６と支払いサービス１８１０との間のブラウザ１８０６による協調を管理するための２つのＡＰＩ１８１８、１８１２の使用と協調して、閲覧可能であることに留意されたい。言い換えれば、図１５および図１８Ａは、一態様では、どのようにＡＰＩが第１のサイトと第２のサイトまたは支払いプロセッサとの間の支払いデータおよび支払い処理を管理するために使用されるかを示す。
【０１８０】
[00250]ＡＰＩの使用を適用する例示的な方法は、次のとおりである。方法は、ユーザインターフェース上で入力フィールドを提示することであって、この入力フィールドは、販売業者ウェブサイトと非販売業者ウェブサイト（またはソーシャルメディアサイトなどの他の任意のサイトまたはメッセンジャーアプリケーション）の両方にインデックスを付け検索する一般化された検索エンジンを使用してデータを処理することに関連づけられる、提示することと、ユーザ入力（それぞれのサイトの機能に基づいて、入力フィールドの入力の他に他のタイプの入力とすることができる）をもたらすために入力フィールド内でユーザから入力を受信することと、一般化された検索エンジンがユーザ入力を処理するべきであることを示すユーザ入力に関連づけられた対話を受信することとを含む。ユーザ入力が検索意図を示すことが決定されるとき、方法は、非販売業者ウェブサイトを含むことができる検索結果を提示することと、非販売業者ウェブサイトに関連づけられた検索対話を受信することと、非販売業者ウェブサイトにユーザを遷移させることとを含む。ユーザ入力が、購入意図を示すことが決定されるとき、方法は、アプリケーションプログラミングインターフェースを介して、品物に関連づけられたデータを販売業者サイトから受信することであって、この品物は、ユーザ入力に基づいて選択される、受信することと、品物に関連づけられた今すぐ買うオプションを含むことができる購入関係検索結果を提示することと、今すぐ買うオプションに関連づけられたユーザ対話を受信することと、このユーザ対話に基づいて、購入データをもたらすために、一般化された検索エンジンまたはブラウザにおいてユーザのための記憶された支払い情報を介して品物のための支払いを処理することとを含む。方法は、次いで、アプリケーションプログラミングインターフェースを介して販売業者サイトに購入データを通信することを含むことができ、それによって、販売業者サイトは、ユーザへの品物の配達を管理することができる。
【０１８１】
[00251]販売業者側から、プロセスは次のとおりである。方法は、販売業者サイトから、通信インターフェースまたはアプリケーションプログラミングインターフェースを介して、販売業者サイトと一般化された検索エンティティ（またはソーシャルメディアサイトなどの任意のサイトまたは他の任意のアプリケーション）との間の通信を確立することを含む。一般化された検索エンティティは、ユーザインターフェース上で入力フィールドを提示する（またはそれぞれのサイトに基づいた他の機能）ように動作し、この入力フィールドは、販売業者サイトと非販売業者サイトの両方にインデックスを付け検索する一般化された検索エンジンを使用してデータを処理することに関連づけられる。一般化された検索エンティティは、入力フィールド内のユーザ入力を受信する。ユーザ入力が検索意図を示すとき、一般化された検索エンティティは、非販売業者サイトを含むことができる検索結果を提示し、非販売業者サイトに関連づけられた検索対話を受信して、非販売業者サイトにユーザを遷移させる。ユーザ入力が購入意図を示すとき、一般化された検索エンティティは、ユーザ入力に関連づけられた買うオプションを含む購入関係検索結果を提示し、この検索結果は、販売業者サイトから提供された品物を含む。一般化された検索エンティティは、買うオプションに関連づけられた購入対話を受信する。プロセスの販売業者側は、次のとおりである。ユーザ入力が購入意図を示すとき、方法は、通信インターフェースを介して、販売業者サイトにおいて、一般化された検索エンティティからまたはブラウザから支払い情報を受信することであって、この支払い情報は、品物のための購入対話に関連づけられる、受信することと、販売業者サイトを介して品物の配達を処理することとを含む。このようにして、販売業者サイトまたはアプリケーションは、その品物のプレゼンテーションおよびそのうちの１つの販売を達成するために、アプリケーションプログラミングインターフェースまたは通信インターフェースを介して通信し、通信を受信することができる。
【０１８２】
[00252]図１５は、ＡＰＩを介して通信するウェブサイトを示しているが、そのＡＰＩは、デバイス上の２つのアプリケーション間の通信も可能にする場合がある、またはウェブサイトとデバイス上のアプリケーションとの間の通信を引き起こす場合があることも留意される。ＡＰＩは、ブラウザとサイトとの間にもあることができる。ＡＰＩは、２つのエンティティ間の協調が容易にされ得るように、その各々が異なる目的を有する、２つの異なるエンティティの手段、またはユーザとインターフェースする手段であることが意図されている。
【０１８３】
ソーシャルネットワーキングアプリケーション
Ｔｗｉｔｔｅｒ
[00253]この例の別の態様は、上記で言及された、Ｔｗｉｔｔｅｒなどのソーシャルネットワーキングアプリケーションに概念がどのように適用されるかである。Ｔｗｉｔｔｅｒは、通常は１４０文字に等しいまたはこれ未満の短いメッセージをユーザが送信し読むことができるソーシャルネットワーキングアプリケーションまたはサービスである。登録されたユーザは、ネットワークを通してフォロワーに送信される「ツイート」を投稿することができる。ユーザは、画像およびビデオも投稿することができる。登録されていないユーザは、ツイートを読むことができる。ユーザは、ウェブサイト、モバイルデバイスアプリケーションを通して、または何らかの他のアプリケーションを通して、サービスにアクセスする。Ｔｗｉｔｔｅｒのようなソーシャルネットワークに適用する本明細書において開示される概念の一例は、次のとおりである。方法は、ソーシャルネットワーキングサイトのユーザインターフェース上で入力フィールドを提示することであって、この入力フィールドは、ソーシャルネットワーキングサイト内でソーシャルネットワークのためにデータを処理することに関連づけられる、提示することを含むことができる。ソーシャルネットワーキングサイトは、Ｔｗｉｔｔｅｒのケースでは、短い１４０文字またはこれ未満のテキストベースのメッセージを送信者からフォロワーに送信することができる。画像またはビデオも、このサイトを通して、製品を指すまたは参照するメタデータとともに送信可能である。画像またはビデオのケースでは、メタデータは、製品データベースを参照し、買うオプションの処理およびプレゼンテーションをトリガする画像またはビデオに関連づけ可能である。これは、Ｔｗｉｔｔｅｒアカウント、Ｆａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍ、Ｐｉｎｔｅｒｅｓｔなどに適用されるであろう。これらの例における一般的な手法は、以下で図３０およびその関連づけられた検討において説明される。
【０１８４】
[00254]通常、ユーザが入力フィールドへとデータを入力し、データ（テキスト、写真、および／またはビデオなど）は、そのユーザのフォロワーに送信される。方法は、ソーシャルネットワーキングサイトを通して入力フィールドまたは機構を提示することと、入力フィールド内のテキストベースのユーザ入力を受信することと、第１の決定をもたらすために、テキストベースのユーザ入力を使用して、テキストベースのユーザ入力が販売業者からの販売のための製品の製品データベースに関連づけられているかどうかを決定することとを含むことができる。これは、ユーザ入力のリンクまたは分析を通してなされ得る。この点に関して、たとえば、ｔｗｉｔｔｅｒユーザは、ツイートへとテキストを入力することができ、システムは、そのテキストを分析して、入力が製品データベースを参照するかどうかを決定し、したがって、販売、広告、購入、または他の意図に関連づけ可能である。ユーザ入力が製品データベースを参照しない場合、システムは、ユーザ入力は販売に関係しておらず、ソーシャルネットワーキングシステムを通して送信可能にされたにすぎないと決定することができる。言い換えれば、ユーザは、単に、第１の意図（フォロワーと情報を共有するための通常のツイート意図）に従ってソーシャルネットワーキングサイトを通して通常のやり方配信または送信される通常のツイートをシステムに提供していることがある。
【０１８５】
[00255]しかしながら、決定が、ユーザが特定の製品データベースを参照したことを、したがって販売関係意図を示すとき、方法は、テキストベースのユーザ入力に関連づけられた買うオプションとともに、ソーシャルネットワーキングサイトを通して、テキストベースのユーザ入力を送信することを含む。このケースでは、たとえば、テキスト入力は、広告を送信するため、または製品を買うため、または製品を販売するための意図を示す、製品データベースまたはサービスへのリンクを提供することができる。意図が販売関係意図または購入関係意図である場合、ソーシャルネットワークを通してツイートを単に送信することに加えて、システムは、協調し、テキスト入力に関連づけられた買うボタンを提示することができる。本明細書において開示されるＧｏｏｇｌｅ例によく似て、ソーシャルネットワーキングサイトまたはソーシャルネットワーキングサイトに関連づけられたサービスは、ユーザ支払い処理情報を記憶し、したがって、そのような情報を一度入力することのみをユーザに求めることができる。したがって、ツイートの受信者は、ツイートの少なくともいくらかのテキストを見るだけでなく、買うボタンを見て、システムは、買うオプションに関連づけられた購入対話を受信することができる。次いで、システムが、ツイートに関連づけられた品物内（in item）の購入を処理する。ＡＰＩを通して、本明細書において述べられるように、購入は（ソーシャルネットワーキングサイトによって）処理可能であり、配達は、ＡＰＩを通して協調されるように販売業者によって管理可能である。このプロセスは、ソーシャルネットワーキングを通して販売の変換を増加させる。「テキストベースの入力」が本明細書において言及される各ケースでは、代替手法は、製品データベースにアクセスするために必要な情報を提供するメタデータをもつ画像またはビデオを受信することとすることができ、処理は、類似の様式で継続する。もちろん、類似の手法は、Ｆａｃｅｂｏｏｋなどのような任意のソーシャルネットワーキングサイトを通して使用可能である。
【０１８６】
[00256]別の態様は、製品を販売している販売業者の観点からソーシャルネットワーキングサイトを通して買うオプションを取り扱うことである。この態様では、方法は、販売業者から、販売業者と、ソーシャルネットワーキングサイト内で１４０文字またはこれ未満の短いメッセージを処理および送信するソーシャルネットワーキングサイトとの間で、通信を確立することを含むことができる。ＡＰＩは、そのような通信が発生することができるものを通して確立可能である。ソーシャルネットワーキングサイトは、ユーザインターフェース上で入力フィールドを提示し、入力フィールド内のテキストのユーザ入力を受信して、テキストのユーザ入力が、決定をもたらすためにテキストベースのユーザ入力を使用して販売業者からの販売のための製品の製品データベースに関連づけられているかどうかを決定する。たとえば、ＵＲＬは、製品のデータベースにアクセスするツイート内に置くことが可能であり、販売業者は、そのデータベースを通して製品を提供させることができる。
【０１８７】
[00257]決定が、テキストのユーザ入力において製品データベースへの参照がないことを示すとき、ソーシャルネットワーキングサイトは、ツイートを送信することまたはＦａｃｅｂｏｏｋ投稿を投稿することなどの、通常のやり方でソーシャルネットワーキングサイトを通してテキストのユーザ入力を送信する。決定が、テキストのユーザ入力が販売のための製品の製品データベースを参照することを示し、したがって、販売関係意図を示すとき、サイトは、テキストのユーザ入力に関連づけられた品物のための買うオプションとともに、ソーシャルネットワーキングサイトを通してテキストのユーザ入力を送信する。したがって、ツイートまたは投稿を読むまたは受信する人々は、その品物に関連づけられた買うオプションを見る。受信者は、ソーシャルネットワーキングサイトまたはＡｐｐｌｅ  ＰａｙもしくはＰａｙｐａｌのような別のサービスを通して支払い情報を記憶させることができ、したがって、このサービスを通して提供されるすべての異なる販売業者からの製品は、支払い情報などを入力するために、その販売業者に転送される必要なしに購入可能である。次いで、販売業者は、買うオプションに関連づけられた購入対話が受信された（すなわち、受信者が買うボタンをクリックした）という標識を受信し、購入対話を提供した人への品物の配達、または購入対話に基づいて配達を処理することを処理する。次いで、ソーシャルネットワーキングサイトは、販売業者への品物の支払いを行うことができる。ソーシャルネットワーキングサイト、またはそのエージェントは、販売を処理するための少額の料金を請求することもある。テキストのユーザ入力を使用してテキストのユーザ入力が販売業者からの販売のための製品の製品データベースに関連づけられているかどうかを決定することは、アプリケーションプログラミングインターフェースを介してソーシャルネットワーキングサイトと製品データベースとの間で通信または相関づけることを含むことができる。品物の配達を処理することは、品物の支払いが完了したという情報をソーシャルネットワーキングサイトから受信することと、アプリケーションプログラミングインターフェースを通して品物を販売している販売業者がその人に品物を発送することができるという情報を受信することとを含むことができる。
【０１８８】
[00258]Ｔｗｉｔｔｅｒ例は、販売業者観点からの処理に関する。このケースでは、販売業者は、ソーシャルネットワーキングサイトのユーザインターフェース上の入力フィールド内で１４０文字またはこれ未満の短いメッセージを投稿する。ソーシャルネットワーキングサイトは、入力フィールド内のテキストベースのユーザ入力を受信し、決定をもたらすためにテキストベースのユーザ入力を使用して、テキストベースのユーザ入力が、販売業者からの販売のための製品の製品データベースに関連づけられているかどうかを決定する。決定が、テキストのユーザ入力において製品データベースへの参照がないことを示すとき、ソーシャルネットワーキングサイトは、ソーシャルネットワーキングサイトを通してテキストベースのユーザ入力を送信する。決定が、テキストベースのユーザ入力が、販売のための製品の製品データベースを参照することを示し、したがって、販売関係意図を示すとき、ソーシャルネットワーキングサイトは、テキストベースのユーザ入力に関連づけられた買うオプションとともにソーシャルネットワーキングサイトを通してテキストベースのユーザ入力を送信し、買うオプションに関連づけられた購入対話を受信して、購入対話に基づいて品物の購入を処理する。次いで、販売業者は、投稿エンティティにおいて、品物が購入されたことを示す購入データを受信する。したがって、販売業者は、ＡＰＩを通して、受信者が品物の購入を行っており、販売業者が品物を発送するべきであるという通知を受信する。
【０１８９】
[00259]別の態様では、方法は、ソーシャルネットワーキングサイトのユーザインターフェース上で入力フィールドを提示することであって、この入力フィールドは、ソーシャルネットワーキングサイト内で１４０文字またはこれ未満の短いメッセージを処理および送信することに関連づけられている、提示することと、入力フィールド内の少なくともユーザテキストを含むユーザ入力を受信することと、ユーザ入力に基づいたテキストが、相関をもたらすために販売業者によって販売のための製品のデータベース内の製品に相関するかどうかを決定することとを含むことができる。テキストに相関する製品がないとき、方法は、ソーシャルネットワーキングサイトを通してユーザ入力を送信することを含む。テキストに相関する製品があり、したがって、販売関係意図を示すとき、方法は、ユーザ入力に関連づけられた買うオプションとともにソーシャルネットワーキングサイトを通してユーザ入力を送信することと、買うオプションに関連づけられた購入対話を受信することと、購入対話に基づいて品物の購入を処理することとを含む。
【０１９０】
[00260]別の態様では、ソーシャルメディアサイト上で店舗ボタンをクリックすることは、製品に関連づけられた販売業者サイトにユーザを遷移させることができる。この遷移は、ユーザが販売業者サイトから製品を買うことができるように、ブラウザからデータにアクセスして、ワンクリック購入状態で販売業者サイトに遷移することができる。ブラウザＡＰＩは、ユーザから支払いデータを要求および受信するために使用可能である。
【０１９１】
支払いプロセスの一部としてのソーシャルネットワーキングダイアログの使用
[00261]以下の検討は、本明細書において開示されるいくつかの特徴を一緒に組み合わせたものである。ソーシャルネットワーキングの買うボタンの概念は、ユーザが、絞り込み、より多くの特徴を選択するために、ダイアログに遷移することができる、図３および図４において参照されるダイアログ特徴と組み合わされる。買うオプションは、ダイアログ要素に組み込まれ得る。以下の検討は、リモートサイトから、ユーザが通信することを可能にするダイアログアプリケーションを有するソーシャルネットワーキングサイトへとダイアログに遷移する概念も含み、購入がダイアログを介して完了可能であるように、支払いプロセスおよびリモートサイト上で閲覧される製品のためのデータがダイアログへと遷移される。
【０１９２】
[00262]上記で述べられたように、この本出願における特許請求の範囲は、支払いトランザクションに対するダイアログ構成要素に焦点を当てる。本開示は、ユーザが購入を完了する前に製品についてのより多くの情報を知り、製品についてのより多くの質問をすることを可能にする問題に対処する。いくつかのケースでは、ワンクリック購入オプションまたは買うオプションは、サイズまたは色または他のパラメータなどの何らかの追加のデータを必要とする製品に関するものであることがある。ユーザが、配達、不良な評判、不良なレビューなどについての他の懸念を有することがある。このシナリオでは、オブジェクトは、ダイアログアプリケーションまたは対話にユーザを遷移させることができる製品を購入するプロセスに沿って何らかの段階において提示可能である。ダイアログから、ユーザは、情報を完成させ、購入を確定することができる。遷移は、（ニュースフィード内の広告からメッセンジャーアプリケーションまでのＦａｃｅｂｏｏｋなどの）単一のサイト内とすることができる、または遷移は、いくつかのサイトにまたがることがある。たとえば、Ｆａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒアプリケーション（または任意のダイアログアプリケーション）に遷移することは、ユーザが質問を有するまたは製品についての他の選択肢を行うことを必要とする場合、任意の購入を完了する際に助けとなることができる。したがって、任意のサイトにおいて、プロセスの任意の段階における、ダイアログアプリケーションへの遷移は、さらなるデータを提供する助けとなるために発生することができる。ダイアログアプリケーションは、ブラウザの減少されたバージョンとなることができるｗｅｂｖｉｅｗインターフェース内で提示可能である。１つの例示的な方法は、広告に支払いプロセス開始オブジェクトを提示することを含むことができる。支払いプロセス開始オブジェクトは、ユーザが検討の製品／品物についてのダイアログに関与し、購入を完了する、ダイアログアプリケーションへのリンクまたは遷移を含むことができる。遷移および検討は、質問が答えられるまたは情報が収集されると、簡単な支払いが発生することができるように構成される。遷移は、ドロップダウンメニュー内の品物のリストを下り、特徴を選択しており、購入トランザクションを完了するように構成されたドロップダウンメニュー内の項目を介して購入を行っていることができる。
【０１９３】
[00263]この点に関して、例示的な方法は、ソーシャルネットワーキングサイトを通しての品物の投稿を受信することを含み、このソーシャルネットワーキングサイトは、投稿された品物を受信し、投稿エンティティから受信エンティティに送信する。投稿が、製品データベース内の購入のための製品に関連づけられていないとき、方法は、買うオプションまたはアクションオプションへの何らかの他の対話型呼び出しなしでソーシャルネットワーキングサイトを通して投稿を送信することを含む。任意選択で、決定が、投稿が製品データベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、方法は、製品に関連づけられた支払いプロセス開始オブジェクトとともにソーシャルネットワーキングサイトを通して投稿を送信することであって、支払いプロセス開始オブジェクトが、ボタン、ドロップダウンメニュー、またはハイパーリンクのうちの１つを含む、送信することと、支払いプロセス開始オブジェクトに関連づけられた対話を受信することとを含み、この対話は、ユーザによって実行される。投稿エンティティは、ユーザのニュースフィードなどのソーシャルメディアサイトにおいて買うボタンを用いて、製品ベースまたは広告ベースの投稿を直接的に投稿することもできる。購入対話に基づいて、方法は、ダイアログの終わりに、ユーザが製品の購入を完了することができるように、支払いプロセスの一部として製品に関してユーザとダイアログ内で関わり合うことを含む。ダイアログは、ブラウザＡＰＩが、販売業者が支払いデータを受信することを可能にするために、販売業者とブラウザとの間で通信するために利用可能であるように、ｗｅｂｖｉｅｗブラウザのようなブラウザを介して提示可能である。したがって、ソーシャルネットワーキングサイト上での任意の対話型状態から、ニュースフィードから、または広告などから、ユーザは、ブラウザ支払い要求ＡＰＩ能力をもつように構成されたメッセンジャーｗｅｂｖｉｅｗのような、ブラウザインターフェースに遷移され、ブラウザを通して販売業者サイトと対話することができ、支払いの時間がきたとき、販売業者は、支払いデータを要求し、品物の支払いを処理するために支払いデータを受信するために、ブラウザＡＰＩを介してブラウザインターフェースと通信することができる。
【０１９４】
[00264]方法は、ダイアログの一部として、ユーザから購入対話を受信することと、購入対話に基づいて製品の購入を処理することとを含むことができ、購入を処理することは、ソーシャルネットワーキングサイトのうちの１つの中で、支払いエージェントを介して、またはソーシャルネットワーキングサイトまたはブラウザと製品を販売する販売業者サイトとの間のアプリケーションプログラミングインターフェースを介して、発生する。ソーシャルネットワーキングサイトまたはブラウザは、購入を処理するためにユーザの支払いデータを記憶することができる。購入が、ソーシャルネットワーキングサイトまたはブラウザと販売業者サイトとの間でアプリケーションプログラミングインターフェースを介して発生するとき、ソーシャルネットワーキングサイト、またはブラウザは、販売業者サイトが製品の購入を処理することができるように、アプリケーションプログラミングインターフェースを通して支払いデータを送信することができる。
【０１９５】
[00265]ダイアログは、ユーザが、製品に関連づけられたパラメータを選択することを可能にすることができる。例示的なパラメータは、色、サイズ、形状、構成、および技術的特性のうちの１つまたは複数を含む。配達オプション、他の任意の懸念を解消すること、贈答問題、ディスカウント、クーポンなどは、ダイアログ内で管理可能である。支払いプロセス開始オブジェクトは、買うボタンまたは「ここをクリックして、この品物について話し、買う」という通知を単に含むことができる。対話は、対話アプリケーションを介してユーザと販売業者との間で管理可能である。ダイアログに関与することは、一態様では、ダイアログおよび製品の購入を管理するためのダイアログアプリケーションに遷移することによって達成可能である。
【０１９６】
[00266]ｓｉｔｅ．ｃｏｍ（またはアプリ）における状態が、買うボタンを含む場合、そのような買うボタンは、本明細書において開示されるように、ブラウザ、エージェント、または最終的な支払い処理のためにブラウザからサイトに支払い情報を渡すなどの他の様式を通して支払いを処理するブラウザＡＰＩまたは他のＡＰＩに関連して提示可能である。
【０１９７】
[00267]任意のサイトまたはアプリケーションからユーザから販売業者への支払いを可能にするように構成されたダイアログアプリケーションに遷移する一例が続く。ユーザは、ｓｉｔｅ．ｃｏｍなどのサイトまたはアプリケーション上にいると仮定する。一般的には、サイトは、ユーザが製品もしくはサービスの購入を行うまたは何らかの種類の支払いを提供することが可能であることに近い状態である。購入または支払いに向けて進行中のこの段階では、サイトは、ユーザおよびユーザがＦａｃｅｂｏｏｋ  ＭｅｓｓｅｎｇｅｒもしくはＳＭＳアプリケーション、電子メールアプリケーション、またはユーザが製品もしくはサービスについてのより多くの情報を得るもしくは質問をするために対話することができる他の任意のアプリケーションなどのダイアログアプリケーションを通して支払いを行う能力についての情報を取得するために、ＡＰＩを介して対話することができる。サイトは、要求を行い、転送を行うために必要なデータを受信することによって対話することができる。たとえば、サイトは、ユーザがＦａｃｅｂｏｏｋアカウントを有するかどうか、それらがＦａｃｅｂｏｏｋを通して支払いを行うように構成されているかどうか、またはそれらが購入を可能にするためにデータをブラウザに関連してＦａｃｅｂｏｏｋ上に記憶したかどうかを質問するデータ要求を行うことがある。他のデータは、ＰａｙＰａｌ、Ａｐｐｌｅ  Ｐａｙ、またはＡｎｄｒｏｉｄ  Ｐａｙ、または必要とされる他の任意のタイプのデータをもつアカウントであってよい。次いで、情報は、製品の支払いを達成するために使用可能である。
【０１９８】
[00268]ＡＰＩなどを通して、支払いがダイアログアプリケーションを通して行われる可能性がある確認が提供される場合、サイトは、購入へのパスに沿った任意の段階において、ユーザインターフェース上でオブジェクトを提示することができる。オブジェクトは、「チャットおよび支払い」または「ダイアログ／質問をする」または「この製品についてのＦａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒに行く」である可能性がある。一般的には、オブジェクトは、オブジェクトとのユーザ対話が、ｓｉｔｅ．ｃｏｍとは別個であることができるダイアログアプリケーションへの遷移を引き起こすように構成される。たとえば、遷移は、検討のためのＦａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒに対するものであることができる。この段階における１つの問題は、ｓｉｔｅ．ｃｏｍが、ユーザが誰であるかを知っているかどうかである。この段階では、遷移がユーザのダイアログアプリケーションおよび／またはＦａｃｅｂｏｏｋにログインするために必要なデータを通信することができるように、サイトが、ユーザが誰であるかを知っている、またはＡＰＩもしくは場合によってはユーザ名を介してアクセスすることができることが仮定される。ユーザ情報は、ｇｏｏｇｌｅ．ｃｏｍもしくは検索エンジン、またはブラウザ、または他のサービスのようなサイトから来ることができる。したがって、すべての必要な情報、パスワード、暗号化、セキュリティ、名前などが、サイト上のオブジェクトとの対話に応答して、ユーザが製品についてのサイトとのメッセージングを始めることができるように構成されたダイアログがユーザに提示されるように、交換される。画像、価格、サイズ、量、または他のデータなどの項目が提供される。ユーザがサイト上で製品を選定し、そのようなデータを割り引きまたはクーポンなどとして入力した場合、それらのパラメータのうちの１つまたは複数は、ダイアログアプリケーションに渡され得る。したがって、ダイアログアプリケーション内のビューは、製品／サービスの写真、価格、送料（配達または住所データのためのユーザのロケーションによって確認可能である）、割り引き、配達住所、発送指示などのうちの１つまたは複数を含むことができる。次いで、ユーザは、どのサイズまたは色をユーザが望むかなどの、より多くの詳細を求めることができる。ユーザは、販売業者に質問することができる。サイトは、従業員またはロボットまたはダイアログアプリケーションがユーザと対話することができるように、必要な遷移を提供することができる。ユーザは、ダイアログアプリケーションを通して、「格付けとは何ですか、大きいものは売られていますか、または赤色のものはありますか」などの、任意の種類の自然言語の質問をすることがある。
【０１９９】
[00269]ダイアログを容易にするために、システムが自然言語インターフェースを有する場合、製品および製品に関する可能性の高い検討に調節可能な、スピーチ認識モデル、口頭による言語理解モデル、発音モデル、スピーチ生成モデルなどのダイアログモデル。製品の特性（色、サイズ、技術的特徴など）のすべてを記憶する辞書が、認識、理解、およびスピーチ生成を改善するためにロード可能である。製品または類似の製品を購入した友人についての詳細などの社会的情報が、Ｆａｃｅｂｏｏｋを通して提供可能である。ダイアログは、「ご友人のＪｏｈｎがこれを２週間前に買い、４／５の格付けを与えました」を含む可能性がある。ダイアログが、生きている人間とのものであるにせよ、自動化されたシステムとのものであるにせよ、そのような情報は使用可能である。たとえば、本明細書において開示される、複数のチャネルにまたがってユーザの購入を追跡および管理する購入管理システムは、そのデータを、ソーシャルネットワーク内の友人の購入履歴および／または経験のように、ＡＰＩを通して、または何らかの他の手段を通して、ダイアログ管理システムに通信することができる。その情報は、質問に答え、ユーザと対話するために、ダイアログアプリケーションにとって利用可能にされ得る。ダイアログアプリケーションがスピーチベースである場合、スピーチ認識モデル、口頭による言語理解モデル、スピーチ生成モデルなどのうちの１つまたは複数は、ダイアログ経験を改善するために、そのようなデータを用いて動的にまたは事前に更新可能である。たとえば、ある音素、単語、語句、名前、製品名などは、その特定のユーザに対するダイアログアプリケーションに焦点を合わせるために、これらのスピーチ処理モデルへとロード可能である。アニメーション化されたキャラクタが、買い手と関わり、質問を受信して、回答を提供するために生成される場合もある。キャラクタは、友人、家族、好きな俳優などの特性に少なくとも一部は基づいて、選定可能である。買い手について取得されたソーシャルネットワーキングデータは、製品についてのダイアログ内でユーザと関わるアニメーション化されるエンティティの音声、性別、政治的傾向、人種などを選択するために使用可能である。事前に合成されたスピーチユニットは、製品および製品を購入した友人について収集可能である。個人情報も、ダイアログに組み込み可能である。たとえば、エンティティは、「明日は素敵なお誕生日だね、Ｊａｎｅ。どうすれば、あなたがこの椅子を購入するのを手伝えますか？黒い椅子が欲しいですか？」と言うことができる。したがって、ユーザが、ダイアログにユーザを遷移させる購入プロセス開始オブジェクトをクリックすると、ダイアログ管理システムは、その特定の製品に関してダイアログ内でドメイン固有経験を生成するために、製品についてのデータ、製品レビューデータ、製品に関連づけられた友人／家族データ、ユーザについてのソーシャルメディアデータなどのために販売業者などのさまざまなロケーションからテキストおよびデータを取得することができる。したがって、提示される態様は、ユーザをより快適にし、親しみやすい環境にいるようにすることができる。アクセント、人��、ジョーク、視覚的特性、ダイアログ応答、タイミングなどは、ユーザが椅子の色として赤色のみを選定することを望む場合でも、その販売業者と通信するとき社会的により気持ちの良い経験を有することができるように、特定のユーザのために調節可能である。
【０２００】
[00270]上記で述べられたように、遷移オブジェクトは、たとえば、検索エンジンに対する検索の結果である広告の一部として、提示可能である。したがって、「買うボタン」は、本明細書では、その広告の一部として開示されているが、買うボタンは、「メッセンジャー」、または「ダイアログ」、またはユーザを製品についての販売業者とのダイアログに連れて行く遷移ボタン上の何らかの他のラベルが付随可能である。もちろん、広告は、単に遷移ボタンのみを含むことができる。システムが、支払い可能なダイアログシステムにユーザを遷移しているとき、販売業者のための労働者またはサイトは、ダイアログが開始することが可能な通知を受信することができる。その人は、製品が提示可能である。生きている人に提供されるデータは、最も関連のあるデータが、質問にすばやく答え、販売につながることを助けるようにダイアログ内で生きている人を助けることができるように編成可能である。友人が製品を買った場合、その情報が提供される。潜在的な買い手がイタリアに旅行したばかりであり（Ｆａｃｅｂｏｏｋ投稿を通して知られている）、この買い手がイタリアに戻った場合に製品が関連のあり得る場合、その情報は、労働者に提供可能である。したがって、分析は、１つまたは複数のソーシャルメディアサイト上でのユーザのソーシャルメディアアクティビティ、友人および連絡先データ、ならびに／またはその製品に関連し、この買い手とのダイアログにおける使用のために集約されて労働者に提示されることがある利用可能な他の任意のデータから作成可能である。労働者は、非常に多くの情報を一度に提示させることのみができるので、情報は、買い手がダイアログシステムと対話するにつれて、情報が変化し、修正可能であるように、動的に変化していることが可能である。たとえば、買い手が、「友人の誰かがこれを買いましたか？」を文字通りに尋ねることがあり、システムは、そのデータを自動的に処理して、労働者に提示する、または自動的にその質問に情報で答えることができる。この種類の情報は、ユーザがソーシャルメディアサイトを通して購入を行うと、より利用可能になる。ＡＰＩは、その情報とともに提供されることもある。たとえば、買い手の５人の友人が、Ｇｏｏｇｌｅ検索を通して、またはｓｉｔｅ．ｃｏｍなどから直接的に、その製品を購入した場合、その情報は、Ｆａｃｅｂｏｏｋの友人データが共有されることによく似て、共有可能である。適切な認可が適切であると仮定して、友人が、そのような情報が共有されることを可能にする場合、ＡＰＩは、サイトが、「友人の誰かがこれを買いましたか」という質問に応答して、それがＦａｃｅｂｏｏｋ上になく、そのデータベース内に直接的にある場合であっても、その製品または類似の製品を誰が買ったかを決定するために買い手のＦａｃｅｂｏｏｋ友人の問い合わせを公式化することを可能にするために使用可能である。ＡＰＩは、「ＪｏｈｎはこれをＡｍａｚｏｎ．ｃｏｍ上で買いました。Ｊａｎｅは、これをＡｒｌｉｎｇｔｏｎ  ＶＡのＢｅｓｔ  Ｂｕｙで買いました。Ｆｒｅｄは、先週Ｆａｃｅｂｏｏｋを通して類似の製品を買いました」で応答することがある。購入の回数、誰が割り引きを得たか、誰がクー���ンを使用したか、誰がギフトカードを使用したか（ＦｒｅｄがＪａｎｅ  Ｓｍｉｔｈからのギフトカードを使用した）も提供可能である。個人に関する購入データは、情報データベースにおいて識別および集約可能であり、次いで、特定の製品についてのダイアログモードで買い手に情報を提供するために上記のシナリオにおいてアクセス可能である。
【０２０１】
[00271]販売業者格付け、製品格付け、製品に関する顧客格付け、返品率、苦情などの他の情報は、もちろん、ユーザに利用可能とすることができる。その情報の概要は、システムが広告からまたはサイトからダイアログアプリケーションに遷移するときに自動的に提供可能である。これが重要であるのは、ワンクリック購入に関するいくつかのケースでは、ユーザが、買う前に販売業者および製品についてのこれらの種類の格付けを知ることを望むからである。ダイアログアプリケーションに飛び込むことによって、ユーザは、ユーザが有し得る懸念を解消し、ダイアログアプリケーション内で購入を完了するように、より多くの情報を迅速に見出すことができる。
【０２０２】
[00272]システムが自動化されている、または口頭でのダイアログシステムの一部である場合、その情報は集約可能であり、更新された言語モデル、認識モデル、口頭による言語理解モデルなどが、ダイアログに対してコンパイルおよび生成可能である。したがって、友人の名前、製品名、ロケーション、製品の特性などはすべて、非常に調節されたスピーチ処理システムが、口頭でのダイアログシステムとの対話ができる限りクリーンで正常であるように提供可能であるように、組み合わせ可能である。
【０２０３】
[00273]質問が尋ねられ、回答される、またはさらなるパラメータが提供されるとき、ダイアログにおける対話は、購入オブジェクトを提示することが適切である点に達する。ユーザ／買い手は、「買う準備ができた」と書くまたは言うことがあり、ユーザが「今すぐ買う」などのオブジェクトを見ることができるダイアログメッセンジャーを通してのサイトからの応答。
【０２０４】
[00274]この時点におけるユーザは、今すぐ買うボタンと対話することができ、本明細書において開示されるように、ダイアログアプリケーションを通して、支払いが行われるように引き起こされ得る。ＡＰＩを通して、ダイアログアプリケーションは、製品についての支払い情報のすべてを知って、そのデータを使用して、支払いプロセスを管理することができる。ダイアログアプリケーションは、支払いをローカルに処理し、支払い情報データをサイトに通信する、または別の支払いサービスを使用することができる。サイトは、支払うための暗号通貨オプションも提供することができる。クーポン、割り引きなどが提示可能である。サイトは、ブラウザ支払い要求ＡＰＩを利用して、支払いデータを要求し、支払いを処理するために必要な情報を、ブラウザＡＰＩを介して受信することもできる。サイトに利用可能なクーポンがある場合、クーポンについての情報は、ブラウザによって管理されるインターフェースがクーポンコードのためのオプションを提示するまたはクーポンデータを挿入もしくは提供することができるように、ＡＰＩ通信の一部として送信可能である。したがって、ブラウザＡＰＩインターフェースは、クーポン情報を受信し、その情報を、販売への適用のためにサイトに戻すように送信することができる。パラメータまたはコーディングは、クーポンを受信して特定の販売に適用する能力をオンまたはオフにするためのＡＰＩの一部として実施可能である。ユーザは、価格設定は、買うボタンとのユーザ対話またはダイアログ内で買うことを確定する前にクーポン減額を組み込むことができるように、販売を確定するまたは「買う」ボタンを打つ前にクーポン情報を提供することもできる。ダイアログが、デバイス上の主なブラウザとは別個のｗｅｂｖｉｅｗまたは他のブラウザを通して管理される場合、ダイアログを提示するブラウザは、主なブラウザ（Ｃｈｒｏｍｅ、Ｓａｆａｒｉ、Ｆｉｒｅｆｏｘ、Ｍｉｃｒｏｓｏｆｔ  Ｅｄｇｅなど）と通信して、支払いデータを取り出すことができる。支払いデータを要求するためのトリガポイントは、ボタンクリック、「私は、これを今すぐ買うことを望みます」という口頭命令、ジェスチャ、または購入意図の他の任意の標識とすることができる。
【０２０５】
[00275]支払いの後、この段階におけるユーザは、ダイアログアプリケーション内にいる間、サイトに戻るまたはソーシャルメディアアプリケーション内に引き続きいることを望むことがある。さらなるオブジェクトが、ユーザをサイトまたは他の場所に戻すために、ダイアログアプリケーション内で提示可能である。たとえば、ユーザがサイトに戻る場合、それは、ユーザが購入を行ったばかりであるかのような状態にあるサイトとすることができる。次いで、ユーザは、サイト上で製品を購入したかのように、引き続き配達を監視する、返品を取り扱うことなどを行うことができる。サイトは、通常のやり方で製品の配達を管理する。このようにして、このプロセスは、任意の状態における任意のサイトまたはアプリケーションから、ソーシャルネットワークの一部である支払い可能ダイアログアプリケーションなどへの遷移を引き起こすことができる。この手法の１つの有益な結果は、ダイアログアプリケーションが、直接的に製品購入の一部である、販売業者と買い手との間の個人的な対話を可能にすることができることである。したがって、この手法は、支払いが可能にされたダイアログアプリケーションへのアクセスを、関連づけられたダイアログアプリケーションまたはソーシャルネットワーキングサイトの外部に拡張することができる。買い手が迅速および容易に有し得る懸念を解消できる能力は、変換を増加させ、より幸福な顧客に提供する。
【０２０６】
[00276]さらに、いくつかのケースでは、販売業者またはｓｉｔｅ．ｃｏｍは、顧客との対話に対する制御を失うことを望まない。そのため、サイトから遷移することが、望ましいことでないことがある。しかしながら、Ｆａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒなどのダイアログアプリケーションへのこの遷移は、対話を、ＦａｃｅｂｏｏｋアカウントまたはＭｅｓｓｅｎｇｅｒアカウントへとログインしたユーザとソーシャルメディアアカウントへとログインした販売業者との間のソーシャルメディア対話へと変換する。したがって、遷移は、実際は、ただソーシャルメディアアプリケーションを通してだが、買い手と販売業者との間の直接的接続を依然として維持する。したがって、販売業者は、対話の制御を失わず、ソーシャルメディアを通して買い手との直接的な個人的接続を改善することができ、これは、非常に望ましい結果である。
【０２０７】
[00277]実際に、経験をさらに強化するために、他の販売業者のブランディングが、ダイアログアプリケーションに対するメディアによりブランディングされたバックグラウンドなどの経験へと組み込み可能である。買い手との個人的向上（uplifting）交換を有する機会は、非常に重要である。通常、ダイアログアプリケーション内で、ユーザが質問をタイプし、応答が販売業者から提供される。おそらく検討されている製品の写真を除いて販売業者のための一般的なブランディングはない。ダイアログアプリケーションは、ブランディングパッケージが販売業者に利用可能な機会を提供することができる。したがって、ユーザと販売業者との間のダイアログ内にいる間、滝の背景画像が提供されることがある、ビデオが提供されることがある、またはあるトーンを設定する音楽が再生されることがある。色、境界、ヘッダ、オブジェクト、フォント、フォントサイズ、合成音声などが、その販売業者のために調節されることがある。通常、ダイアログアプリケーションは、販売業者とのダイアログに不動産を提供することのみを必要とするので、小さい。しかしながら、このコンテキストでは、単に質問を受信し、その質問に答えることに加えて、ブランディング取り組みが望まれる場合、ダイアログアプリケーションは、サイズに関して拡張され（デスクトップまたはラップトップコンピュータまたはより大きな画面をもつ任意のデバイス上である場合）、販売業者と直接的に対話するときユーザにはるかに豊富な経験を提供するように改訂されることがある。これが重要なのは、単なる迅速なダイアログおよび支払いよりも、販売業者との関係をはるかに深めることができるからである。
【０２０８】
[00278]これがどのように機能することができるかの一例として、買い手が広告上の遷移オブジェクトをクリックすると仮定する。これは、購入につながる情報収集対話を開始するので、情報収集および購入（purchase）対話オブジェクトまたは購入（purchasing）対話オブジェクトと呼ばれることがある。したがって、それは、購入の即時確認を提供しないが、ユーザから情報を収集することおよび／または追加の情報をユーザに提供することのうちの１つを提供するダイアログまたは対話を開始する。ユーザは、販売業者の店頭の画像をもつ、より大きなウィンドウを含むように拡張されたメッセンジャーアプリケーションに遷移される。ユーザは、「私は、このウィジェットに類似しているが、サイズおよび色が異なるものが欲しい」と言う／書くことがある。システムは、より大きなウィンドウ内または同じサイズのウィンドウ内ですら、異なるサイズおよび色をした代替の類似したウィジェットを提示することがある。ユーザは、それらをスクロールし、購入のために所望のものを選択することができる。ユーザが、文字通りそこにいるかのようにユーザがブラウジングし得るストア内の棚の上に代替品物を置くように構成され得るストア内の仮想空間を進むことがある画面が提示されることがある。
【０２０９】
[00279]別の態様では、ダイアログアプリケーションへの遷移は、ストリーミングオーディオまたはビデオなどの他の任意の製品にも関係することがある。たとえば、ユーザは、Ｎｅｔｆｌｉｘ．ｃｏｍ上におり、映画についての、より多くの情報を望むことがあり、ユーザは、遷移オブジェクトをクリックし、ダイアログアプリケーションに連れられ、映画についての販売業者と話すことがある。ダイアログアプリケーションは、購入（ブラウザＡＰＩを利用した）および／またはメディアのダウンロードを確認するように構成されることがある。したがって、ダイアログアプリケーションは、製品購入だけでなく、他のデジタルメディア配信にも使用されることがある。メディアは、現在のデバイス（ダイアログが生じている）にダウンロードされてもよいし、後で視聴するために何らかの他のデバイスもしくはアカウントにダウンロードされてもよい。したがって、サイトからダイアログアプリケーションへの遷移のこのプロセスの別の要素は、何かを買うこと以外の他の結果を提供することができる。医師、歯科医、または他の専門家との約束は、サービス、メディア配信、および／または購入、スポーツイベントのチケットを買うこと、注文をキャンセルすること、注文を管理すること、顧客の苦情などについてのダイアログの後で、行われることがある。これらのインスタンスの多くでは、他の当事者とのダイアログは、何らかの結果を達成するのに非常に有用であろう。ここで、プロセスは、問題についての生産的なダイアログを可能にするように構成されたダイアログアプリケーションへの遷移を可能にし、結果を「ワンクリック」できる能力を提示することができる。したがって、製品を購入することに加えて、ユーザは、問題について法律事務所と対話し、弁護士に会う約束を確認する、または歯科約束時間を確認もしくは変更することがある。したがって、遷移オブジェクトはカレンダー、メディア配信システムもしくはサイト上、Ｏｕｔｌｏｏｋ内、電子メールもしくはテキストメッセージ、またはユーザがダイアログ内で別の当事者と関わる理由がある他の任意のロケーション内で、提示可能である。たとえば、ユーザは、カレンダー上で次の火曜日に、歯科医との約束を見る場合がある。そのような約束が企業とのものであることが知られている場合、遷移オブジェクトが、カレンダー上に提示可能である。そのオブジェクトをクリックすると、歯科医とのダイアログアプリケーションにユーザを遷移させる。次いで、ユーザは、「これを木曜日の午後３時に移すことができますか？」とタイプするまたは言うことができる。歯科医からの応答が「はい」の場合、結果として得られるアクション（購入ではなく）は、カレンダー更新とすることができる。ダイアログアプリケーションは、そのような変更を行うために、ＡＰＩまたは別の機構を通して、カレンダーアプリケーション、または他のアプリケーションと統合可能である。
【０２１０】
[00280]この点に関して、ダイアログアプリケーションは、ダイアログに基づいて電子メールまたは通話を開始するために使用されることもある。ＭＳ  Ｗｏｒｄのような他のアプリケーションが起動される場合がある、またはドキュメントが取り出される場合がある。したがって、ダイアログアプリケーションへの遷移が、任意の発信源から来ることができ、購入を行うことに加えて、任意の数の生産的な、結果として得られるアクションが取られ得る。ダイアログアプリケーションを使用した後にユーザが遷移される結果として得られるロケーションは、取られる具体的なアクションと、ユーザが最後に望む可能性があるところに依存することができる。
【０２１１】
[00281]ダイアログアプリケーションは、ソーシャルメディアダイアログアプリケーションでなくてもよい。たとえば、Ｇｏｏｇｌｅのような検索エンジンが、登録されたユーザ間のメッセージングまたはＧｏｏｇｌｅとＦａｃｅｂｏｏｋとの間のメッセージングを可能にした場合、任意のダイアログアプリケーションは、これらのアイデアを実施することがある。
【０２１２】
[00282]次に、広告または他のインターフェース上に遷移ボタンを置く決定は、動的であってよい。システムは、製品を分析することがあり、製品がより複雑であるまたはより高い価格にされている場合、消費者が、買う前に、製品についてより多く話すことを望むことがある。製品は、何らかの悪いレビューまたは悪いプレスをなされたことがあるかもしれない。人々が、ソーシャルメディアサイト上に悪いことを投稿していたり、悪いコメントを行ったりしているかもしれない。そのようなケースでは、ダメージコントロールは、ある時間の期間にわたって、遷移オブジェクトが製品通知上に置かれ、説明が行われ得るようにインターフェースするように関与する必要があることがある。遷移オブジェクトは、迅速に購入していないまたは別のサイト（Ａｍａｚｏｎ．ｃｏｍなど）に移動してレビューを調べることを望んだ履歴を有する個々のユーザに提示されることがある。一般的には購入に至るユーザからの対話のタイミングは、ある役割を果たすことができる。たとえば、ユーザが、購入を行う前に長い時間にわたって休止した場合、システムは、その時間中に、いかなる質問にも答えるための遷移ボタンを提示することができる。おそらく、製品は新しく、対話は、購入を増加させ、購入に対する肯定的なフィードバックを提供するためにたとえばＡｍａｚｏｎ．ｃｏｍ内のコメントに人々を遷移する助けとなることができる。おそらく、短い販売期間があり、遷移ボタンは、潜在的な買い手と販売について話すために使用される。ボタンは、「最近の悪いレビューと理由について話す」などのさらなる情報を提供することができる。気象、休暇シーズン、潜在的な買い手の来たるべき誕生日または記念日、買い手の友人の購入選択肢などの他のパラメータが分析され、ダイアログアプリケーションに遷移ボタンを提示するべきかどうかおよび／またはどのように提示するかのための基礎として使用可能である。鍵は、製品についての実際の質問（ｏｐｉｎｉｏｎｓ．ｃｏｍが言ったのと同じくらい悪い？）が存在することがある場合に回答可能であり、買い手の懸念が解消可能であるように、戦略的で、ユーザまたは製品に対して調節された遷移ボタンのプレゼンテーションを行うことである。
【０２１３】
[00283]本明細書において開示されるいかなる特徴も、他の任意の特徴と混合および合致可能である。一例として、本明細書において開示される「裂け目」特徴は、メッセンジャーに遷移するあるサイトからＦａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒへのものとすることができる。さらに、メッセンジャーのみが、そのまわりのメインサイトとともに示されることがある。次いで、全体的なユーザインターフェースは、サイトビュー上に重ね合わされたメッセンジャー／ダイアログを含むことができる。この重ね合わされたメッセンジャー／ダイアログのグラフィックスは、第２のサイト（Ｆａｃｅｂｏｏｋまたは他のサイト）によって提示および実行可能であり、したがって、購入またはダイアログを通して取られる他のアクションは、第２のサイトによって管理される。または、メッセンジャー／ダイアログのグラフィックは、最終的な「買う」対話が行われ得るメインサイトにユーザを戻って遷移させることができる。ＡＰＩは、買い手が購入（または他の目的）に向かってより高度な状態でサイトに戻り、次いで、サイトから遷移したときにいたように、ダイアログ／メッセンジャーアプリケーションにおよびこれから遷移することができる。ブラウザＡＰＩは、任意の購入シナリオにおいて、ナビゲーションおよび購入プロセスの任意の段階で使用可能である。言い換えれば、サイトを離れてメッセンジャー／ダイアログに行ったとき、買い手は、最終的な「買う」オブジェクトが提示されている状態でないことがある。買い手は、製品をプルアップしたばかりかもしれない。したがって、ダイアログが、買う準備が整っていることを示す場合、そのデータは、買い手が戻ったときにより高度な状態が提示可能であり、その時点においてワンクリックで買うことができる、または支払い情報が、配達ロケーション、価格などの他の任意選択の情報とともに提示可能であるように、サイトに戻すように通信可能である。次いで、状態は、支払いのための最終的な確認状態であることがある。状態は、最終的な状態の前の１つまたは複数のステップであってもよい。たとえば、ダイアログは、買い手がｖｉｓａまたはビットコインを使用することを望むことを確認することがある。ダイアログは、そのような情報を確認しないことがある。ｓｉｔｅ．ｃｏｍの状態は、買い手が戻ったときに、それに対応することがある。ダイアログは、このコンテキストにおいて、ブルーという色または大というサイズなどの選択肢を行う助けとなるためだけでなく、買い手がデビットアカウントまたはｖｉｓａを使用することを望むことを確認するために使用されることがある。情報の各々は、買い手が支払いの最終的な確認のために戻った場合、ｓｉｔｅ．ｃｏｍの状態を前進させることができる。
【０２１４】
メッセンジャーアプリケーション内でのグループ支払い
[00284]本開示は、メッセンジャー支払いアプリケーションプロセスをさらに拡張する。Ｆａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒは、ある人から別の人への、次に、ある人から企業への、支払いを可能にする。可能にされていないものは、メッセンジャー内でのグループ支払いまたは支払いの共有をする能力である。これは、メッセンジャーアプリケーション自体がインターネットに基づいており、インターネット中心問題とは、１人の人が支払いを行うことに現在限定されていることであるので、この問題に対処する。
【０２１５】
[00285]グループチャット中であり、ギフトを買うことを望む場合、たとえば、システムは、グループチャット内の各当事者を識別し、チャット内で購入され得る広告または製品提供を構成することがあるが、コストは、グループの間で分割される。グループの予約も、そのようなアプリケーションを通して行われることがある。グループチャットの各メンバーは、同じ提供を見ることができる。提示された「今すぐ買う」オプションは、それをクリックした第１の人によって支払われてよく、または、コストがグループのメンバーの間で平等に（または不平等に）分担される「支払いを平等に分ける」オプションが提示されることがある。システムは、各グループメンバーが支払いを分担することを確定することを要求するようにセットアップされてよく、または、支払いは発生しない。グループチャットでは、進捗情報が提供されることがある（「Ｊａｎｅ、Ｊｏｈｎ、およびＪｉｌｌが確定しました。Ｇｅｏｒｇｅ、Ｍａｒｔｙはいる？」）。グループ支払い対話は、「グループ支払いチャットボット、私たちは、この帽子のコストを分担することを望みます」のような呼び出しを介して、メッセンジャーアプリ内で「呼び出される」ことがある。選択可能なオブジェクトまたはドロップダウンメニュー項目も、グループとしてのために処理される／支払われることがある支払いオプションを提示するようにシステムを構成することがある。ブラウザＡＰＩは、各個々のメンバーがメッセージ／要求および支払い情報を交換するために使用されることがある。
【０２１６】
[00286]予約、イベントをスケジューリングすること、メッセージを送ること、慈善寄付をすることなどの、いかなるグループ機能も同様に達成され得る。対話は、グループのために構成され、グループのためにも調節可能である。ほとんどのケースでは、グループは、同じ対話型オブジェクトを見るが、異なるメンバーが異なる特徴を見てもよい。
【０２１７】
[00287]一態様では、買うボタンがメッセンジャーアプリケーション内で提示され、それが３人以上の人々とのグループチャットである場合、システムは、グループ支払いのためのオプションが開始されるようにプレゼンテーションを修正することができる。このシナリオでは、ユーザは、販売業者と検討し、姉妹を会話に追加することを望むことがある。彼女は、製品に飛び付き、製品を見ることができ（多分、その製品は母親のためのギフトである）、次いで、「今すぐ買う」オプションが提示されるとき、それは、Ｊｉｍに対して「あなたは＄１５を支払い、Ｊａｎｅは＄１５を支払う」、Ｊａｎｅに対して「あなたは＄１５を支払い、Ｊｉｍは＄１５を支払う」などの、各ユーザに対する別個のオブジェクトを含むことができる。ユーザは、１人の人がより多く支払うように、チャット内で額も調整することがある。これは、「Ｊｉｍ、今月は不足しているから、あなたは＄２０を支払うことができる？私は＄１０支払う」というダイアログを通して行われることがある。システムは、テキストを分析し、チャットで何が合意されたかを反映するように額およびオブジェクトを自動的に調整することができる。
【０２１８】
[00288]代わりに、３人の友人のグループが、チャットしており、結婚祝いを探しているので販売業者を追加することを要望することができる。メッセンジャーアプリケーションでは、彼らは、Ａｍａｚｏｎ．ｃｏｍまたはＴａｒｇｅｔ．ｃｏｍ（仮に、夫婦がＴａｒｇｅｔに登録されているとしよう）とのチャットを呼び出すことができる。これは、アプリケーション内で、または別個のインターフェースを介して、行われ得る。アプリ内で、ユーザは、「やあ、ｔａｒｇｅｔ．ｃｏｍ、ログインしてください」と言うことがあり、ユーザの入力を分析するシステムは、ターゲットを表すライブまたは自動化されたシステムのどちらかに接続する。決定点は、少なくとも始まるために、グループチャットである場合はライブユーザが接続され、そうでない場合は自動化されるものであることがある。
【０２１９】
[00289]次いで、チャットを通して、彼らは、販売のためのさまざまな品物を提示し、質問に答え得る販売業者と関わり得る。対話し、品物について合意すると、「今すぐ買う」オブジェクトがチャット内で提示されてよく、各ユーザは、等しい割り当て分または等しくない割り当て分を支払ってよく、本明細書において開示されるように支払いは処理されてよい。このようにして、課題の解決策は、支払い機構がチャット内で完了されることが可能にされるグループチャットに参加する個人の間で支払いが分けられることを可能にすることである。サービスまたはブラウザ通信および協調は、人がどの額を支払うかに関するいかなる曖昧さをも解消し得る。
【０２２０】
[00290]ユーザは、ちょうど他の任意のユーザのように販売業者をグループチャット「ｔｏ」フィールドにリストすることによって、販売業者チャットを開始することがある。ユーザは、「ｊａｎｅ  ｄｏｅ、ｊｏｈｎ  ｒｏｅ、ｔａｒｇｅｔ．ｃｏｍ」を入力し、ｔａｒｇｅｔユーザとのグループチャットを始めることもある。このケースでは、販売業者は、チャットまたはメッセージが交換され得、製品が購入され得るように、ソーシャルネットワーク内の「友人」としてリストされることがある。Ｔａｒｇｅｔユーザは、画面上で、グループチャット内の各人、ブラウジング履歴、およびその人を、彼ら（グループ）は何を買うことに関心を持ち得るかに集中させる助けとなるために利用可能な他の任意のデータについての情報を提示することがある。彼ら全員が結婚しようとしている友人を持っており、その友人がＴａｒｇｅｔに登録されていることなどの、グループに共通する情報も提示可能である。したがって、ｔａｒｇｅｔユーザは、「やあ皆、これはＦｒｅｄの結婚のためですか？彼は、まだ銀器セットを持っていません」と言うことができる。グループは、次いで、品物の写真を見て、それの支払いをグループとしてすることがある。
【０２２１】
[00291]上記で述べられたように、グループ内の各人についてのデータが受信され、販売業者とユーザのグループとの間の対話をガイドするために分析可能である。どの選択可能なオブジェクトを提示するべきか、それらのオブジェクトにどのようにラベル付与するか、何の機能がそれぞれのオブジェクトに関連づけられているか、異なるインターフェースを異なるユーザに提示するべきかどうかなどに関する決定は、分析に基づくことができる。
【０２２２】
[00292]Ｊｏｈｎがあるブラウザ（Ｃｈｒｏｍｅなど）を使用しており、Ｍａｒｙが別のブラウザ（Ｍｏｚｉｌｌａなど）を使用している場合、システムは、ユーザはどの種類のアカウントを用いて支払うことができるかを識別するために異なるブラウザと通信することができ、グループメッセージ内で見られる通信のタイプを改善するために、要求、応答、データ、および任意の種類の情報を交換することができる。ＡＰＩは、最終的にユーザが購入を行うコストを分担することを可能にするために、個々の人々によって使用される個々のアプリケーションまたはブラウザと、販売業者ウェブサイトまたはサイト、他の支払いプロバイダ、サービスエンティティなどとの間でデータを通信することができる。
【０２２３】
Ｆａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍ、Ｐｉｎｔｅｒｅｓｔ、Ｙｏｕｔｕｂｅを利用した、投稿意図の決定
[00293]もちろん、類似の手法は、Ｆａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍ、Ｐｉｎｔｅｒｅｓｔ、Ｙｏｕｔｕｂｅなどのような任意のソーシャルネットワーキングサイトを通して使用可能である。各ケースでは、販売関係意図が投稿に関連づけられているか購入関係意図が投稿に関連づけられているかの決定は、それぞれのサイトを通して投稿の受信者によって購入可能である製品またはサービスへの参照のための入力（多くの場合テキストであるが、必ずしもテキストを必要とせず、Ｐｉｎｔｅｒｅｓｔ内のような画像を含むことができる）を分析することを伴うことができる。分析が、多くの場合に製品／サービスのデータベース内で見出される、そのような製品またはサービスへの参照をもたらさない場合、それぞれのサイトは単に、今すぐ買うオプションのないソーシャルネットワーキングサイトを通して、送出者データ（ツイート、Ｆａｃｅｂｏｏｋ投稿、Ｉｎｓｔａｇｒａｍ上の写真、Ｐｉｎｔｅｒｅｓｔなど）を送信または投稿する。そのケースにおけるサイトは、従来の様式で入力を処理する。言い換えれば、設定されるべきパラメータまたは具体的な結果を必ずしも必要としない決定は、メモリ内に記憶される。たとえば、ツイートが、製品データベースを指すＵＲＬを含まず、システムが、そのようなデータのための入力を分析している場合、製品データベースへの参照の欠如は、それ自体として、その投稿のためにソーシャルネットワーキングサイトを通して提示される今すぐ買うオプションがないという決定であることができる。入力が、製品データベースへの参照を含むとき、サイトは、ユーザ入力を処理することによってサイトが提示するいかなる結果の受信者または閲覧者に買うボタンが提示される非従来の処理を実施することができる。サイトは、製品の迅速で容易な購入を可能にするために、または販売業者サイトにおいてショッピングを継続するために、ユーザが依然としてサイト内にいる間に品物を購入することまたはディープリンクで販売業者サイトに容易に遷移することのどちらかを行うことを可能にするために追加のコーディングおよび処理を含む。たとえば、赤色ハンマーの写真が、関連づけられた買うボタンとともに提示される場合、サイトは、ユーザが赤色ハンマー写真をクリックするとき、ユーザが赤色ハンマーを検索し、購入を行う準備ができたかのように、販売業者サイトとのディープリンクに遷移可能である。ディープリンクに遷移されると、ユーザは、このケースでは、ハンマーを容易に単に購入する、またはショッピングカートに入れ、ショッピングを継続するまたは販売業者サイト上での購入を処理し続けることができる。ディープリンクはまた、メッセンジャーアプリケーション内で質問が尋ねられ、次いで答えられ、次いで購入が行われることを可能にするメッセンジャーアプリケーションへの効率的な遷移を提供するための、ユーザ、販売業者、製品、ソーシャルメディアデータなどについてのデータを受信するダイアログアプリケーションへの遷移であってよい。
【０２２４】
[00294]ユーザが製品を検索、ログイン、および／または支払い情報を入力したかのように宛先サイトの状態に構成されたディープリンクの使用、それによって、ユーザは、支払い情報を入力することなく、またはログインすることなく、購入プロセスを完了することができる。これは、ブラウザからの遷移中に、支払いデータ、ワンクリック購入設定、住所情報、ログイン情報などのデータにアクセスすることを通して達成可能である。たとえば、ワンクリック設定がアクセスされ、「オン」に設定された場合、ユーザは、ワンクリック購入状態の宛先サイトに到着することができる。ａｍａｚｏｎ．ｃｏｍのようなサイトがソーシャルネットワーキングサイト上の受信者に投稿をサブミットするとき、このサイトは、受信者の識別についての情報を有する。その受信者がａｍａｚｏｎ．ｃｏｍに登録しており、ａｍａｚｏｎ．ｃｏｍに支払い情報を提供した場合、受信者が、今すぐ買うオブジェクトまたは購入を行う要望を示すオブジェクトをクリックするとき、受信者は、ユーザが製品を検索したかのような状態のサイトにユーザが遷移され、サイトはユーザが製品を「ワンクリック」購入することができる状態である「ディープリンク」を用いて、製品に関連づけられたソーシャルネットワーキングサイト投稿からａｍａｚｏｎ．ｃｏｍなどの投稿サイトに遷移することができる。これが可能であるのは、ソーシャルネットワーキング投稿からサイトへの遷移が、ユーザがサイトにログインされることを可能にすることと、ユーザが最小のさらなるクリックで製品を購入することができるインターフェースをユーザに提示することとを含むからである。遷移プロセスは、ブラウザからユーザデータにアクセスすることを含むことができる。データは、支払いデータ、ログインデータ、ワンクリック許可設定、パラメータ設定、支払いデータ、住所データなどとすることができる。
【０２２５】
[00295]画像が投稿エンティティから受信者のグループに投稿される、ＩｎｓｔａｇｒａｍまたはＰｉｎｔｅｒｅｓｔなどのソーシャルネットワーキングケースでは、プロセスは、次のように動作することができる。方法は、ソーシャルネットワーキングサイトを通して画像の投稿を受信することであって、ソーシャルネットワーキングサイトは、投稿エンティティから受信エンティティに投稿された画像を受信および送信する、受信することを含む。システムは、関連づけられたテキストベースのデータまたはメタデータのために画像を分析することができる。テキストデータは、画像についての情報を提供するメタデータまたは他のデータとすることができ、画像内の品物に関連づけられた製品データベース、たとえば在庫データベースを参照することができる。システムは、関連づけられたテキストベースのデータが、決定をもたらすために投稿エンティティからの販売のための製品データベース内の製品を識別するかどうかを決定する。たとえば、システムは、製品データベース内の品物の在庫があると決定することができる。決定が、製品データベース内の製品への参照がないことを示すとき、システムは、今すぐ買うボタンのないソーシャルネットワーキングサイトを通して入力された画像を送信する。このようにして、画像の投稿は、通常の、従来のやり方でソーシャルネットワーキングサイトを通過する。決定が、画像が製品データベース内の製品を参照することを示し、したがって、購入関係意図または販売関係意図を示すとき、システムは、画像に関連づけられた買うオプションをもつソーシャルネットワーキングサイトを通して、画像を送信する。システムが、買うオプションに関連づけられた購入対話を受信するとき、購入対話に基づいて品物の購入を処理するシステム。これは、ソーシャルネットワーキングサイトにステップの非従来のシリーズを提供するために追加のコードを実施することを伴う。
【０２２６】
[00296]画像が、投稿エンティティからの製品データベース内の製品に関連づけられているかどうかを決定することは、アプリケーションプログラミングインターフェースを介してソーシャルネットワーキングサイトと製品データベースとの間で通信することを含むことができる。ソーシャルネットワーキングサイトは、支払いを処理し、販売業者などの投稿エンティティに販売を通信することができる。次いで、販売業者は、品物を配達することができる。本明細書の他の場所で述べられるように、システムは、購入に移動するプロセス内の状態から、ユーザと販売業者との間のダイアログを可能にし、次いでダイアログアプリケーション内で支払いを処理するように構成されたダイアログアプリケーションに、ユーザを遷移させることもできる。ＡＰＩは、メッセンジャーアプリケーションを介してダイアログに関与した後に（ダイアログの一部として、またはダイアログアプリケーション内で）「ワンクリック」購入を可能にするために、発信元サイト、メッセンジャーアプリケーション、販売業者サイト、ユーザ、支払いエージェントなどの間でデータを通信するために使用される。
【０２２７】
[00297]品物の配達を処理することは、品物の支払いを管理することと、品物を発送するためにアプリケーションプログラミングインターフェースを通して品物を販売したことを投稿エンティティに知らせることとを含むことができる。ユーザまたは販売業者は、どのように画像および買うオプションが提示されるかを支配する好みを記憶する既存のアカウントを有することができる。買うオプションは、ソーシャルネットワーキングサイトが、購入を行っている受信者の購入データを記憶するので、販売を完了するためにソーシャルネットワーキングサイトから販売業者サイトに移動または遷移する必要もなく発生することができる、ワンクリック購入オプションを含むことができる。
【０２２８】
[00298]１つの例は、販売業者の観点から画像共有サイトのための上記のプロセスも包含し、販売業者は、上記で説明されたように動作するソーシャルネットワーキングサイト上に画像を投稿することができる。この場合、販売業者は、販売のための製品データベース内の製品の確認時に、ソーシャルネットワーキングサイトが、買うボタンとともに画像を提示し、購入を確認すると、販売業者が配達を処理することができるように購入を販売業者に知らせるように、製品データベースを指すまたはこれにアクセスするテキストデータとともに画像を投稿する。
【０２２９】
[00299]販売業者側からの、ソーシャルネットワーキングサイト内の買うオプションのための処理に関して、方法は、販売業者などの投稿エンティティによる、ユーザが画像、テキスト、またはビデオを共有するソーシャルネットワーキングサイトを通しての画像、テキスト、またはビデオの投稿を含むことができる。ソーシャルネットワーキングサイトは、一般的には、投稿エンティティから受信エンティティに、投稿された画像、テキスト、またはビデオを受信および送信するように構造化される。ソーシャルネットワーキングサイトは、画像またはビデオに関連づけられたテキストデータまたはメタデータを使用して、決定をもたらすために投稿エンティティからの販売のための製品データベース内に製品があるかどうかを決定する。ソーシャルネットワーキングサイトは、画像またはビデオが、ソーシャルネットワーキングサイトと製品データベースとの間のアプリケーションプログラミングインターフェースを介して投稿エンティティからの製品データベース内の製品に関連づけられているかどうかを決定することができる。
【０２３０】
[00300]決定が、製品データベース内の製品への参照がないことを示すとき、サイトは、製品を買うオプションなしに受信エンティティにソーシャルネットワーキングサイトを通して画像またはビデオを送信するが、従来の様式で実行する。決定が、画像またはビデオが製品データベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、サイトは、買うオプションとともにソーシャルネットワーキングサイトを通して画像またはビデオを送信し、ソーシャルネットワーキングサイトのユーザが購入対話をもたらすために買うオプションと対話したデータを受信する。次いで、販売業者（投稿エンティティ）は、購入対話に基づいて品物の配達を処理する。ソーシャルネットワーキングサイトは、それ自体の機構を通して品物の支払いを処理することができる、またはＡｐｐｌｅ  Ｐａｙなどのようなサービスを使用することができる。投稿エンティティは、ソーシャルネットワーキングサイトが品物の支払いを処理した後、支払いデータをソーシャルネットワーキングサイトから受信することができる。ソーシャルネットワーキングサイトのユーザが購入対話と対話するとき、販売業者は、投稿エンティティのサイト上のディープリンクにおいて、ソーシャルネットワーキングサイトからソーシャルネットワーキングサイトのユーザの遷移を受信することができる。これは、支払い処理がソーシャルメディアサイトの外部で販売業者によって発生することができる任意選択の手法である。ソーシャルネットワーキングサイトは、ソーシャルネットワーキングサイトのユーザが品物を購入することができる投稿エンティティのサイト内の状態である投稿エンティティのサイト内のディープリンクに、ユーザを遷移させることができる。このケースでは、投稿エンティティは、ソーシャルネットワーキングサイトのユーザから品物の支払いを受信することができる。
【０２３１】
[00301]たとえば、販売業者観点から、方法は、販売業者などの投稿エンティティから、ソーシャルネットワーキングサイト上で画像、テキスト、またはビデオを投稿することを含むことができる。ソーシャルネットワーキングサイトは、投稿エンティティから受信エンティティに、投稿された品物を受信および送信することができ、この投稿された品物は、テキスト、画像、およびビデオのうちの少なくとも１つを含むことができる。ソーシャルネットワーキングサイトは、関連づけられたテキストベースのデータまたはメタデータのための画像、テキスト、またはビデオを分析し、関連づけられたテキストベースのデータまたはメタデータが、決定をもたらすために投稿エンティティからの販売のための製品データベース内の製品を識別するかどうかを決定する。決定が、製品データベース内の製品への参照がないことを示すとき、ソーシャルネットワーキングサイトは、買うオプションなしに、言い換えれば、従来のやり方で、ソーシャルネットワーキングサイトを通して画像、テキスト、またはビデオを送信する。決定が、画像、テキスト、またはビデオが製品データベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、ソーシャルネットワーキングサイトは、画像またはビデオに関連づけられた買うオプションをもつソーシャルネットワーキングサイトを通して画像、テキスト、またはビデオを送信し、買うオプションに関連づけられた買い手から購入対話を受信する。買うオプションは、対話するとき、製品についてのダイアログに関与し、次いで製品のためのダイアログアプリケーション内の支払いを処理するように構成されたダイアログアプリケーションへの遷移を引き起こし、したがって、買い手の懸念を思い巡らせ（revolve）、支払いを処理することをより容易およびより単純にするオブジェクトも含むことができる。投稿エンティティは、単に、買うボタンをもつソーシャルメディアサイト上に製品ベースの投稿を投稿することもできる。
【０２３２】
[00302]ソーシャルネットワーキングサイトが、生産物を購入するために対話を受信すると、製品の販売を完了する必要性がある。販売業者観点から、販売業者は、次いで、ソーシャルネットワーキングサイトから、投稿エンティティによって動作されるサイト内のディープリンクへの、買い手の遷移を受信する。販売業者は、投稿エンティティからの品物の購入および配達を処理する。一態様では、販売業者は、ソーシャルネットワーキングサイトのユーザが品物を購入することができる投稿エンティティのサイト内の状態である投稿エンティティのサイト内のディープリンクを、遷移後のユーザに提示する。ソーシャルネットワーキングサイト上に投稿された画像、テキスト、またはビデオ内に提示される品物は、購入された同じ品物とすることができる。ブラウザＡＰＩは、ユーザが販売業者サイト上に到着すると、支払いデータを管理するために、販売業者とブラウザとの間で使用可能である。販売業者サイトは、支払いおよび住所情報を既に記憶させることがあり、遷移は、ワンクリックパラメータがブラウザ内で設定されることのみを必要とする場合がある。一態様では、関連づけられたテキストベースのデータが、決定をもたらすために投稿エンティティからの販売のための製品データベース内の製品を識別するかどうかの決定は、ソーシャルネットワーキングサイトと製品データベースとの間のアプリケーションプログラミングインターフェースを介して実行される。
【０２３３】
[00303]別の態様では、方法は、Ｆａｃｅｂｏｏｋを含むソーシャルネットワーキングサイトを通して画像またはビデオの投稿を受信することと、画像またはビデオに関連づけられたデータを識別することと、データが、決定をもたらすために投稿エンティティからの販売のための製品のデータベース内の製品を識別するかどうかを決定することとを含む。決定が、製品データベース内の製品への参照がないことを示すとき、方法は、今すぐ買うボタンのないソーシャルネットワーキングサイトを通して画像またはビデオを送信することを含む。決定が、画像またはビデオが製品のデータベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、方法は、製品を買うために画像またはビデオに関連づけられた買うオプションをもつソーシャルネットワーキングサイトを通して画像またはビデオを送信することと、買うオプションに関連づけられた購入対話を受信することと、購入対話に基づいて製品の購入を処理することであって、購入を処理することはＦａｃｅｂｏｏｋ内で発生する、処理することとを含む。
【０２３４】
[00304]Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ、および他の任意のソーシャルネットワーキングサイトは、テキスト、および投稿に関連したビデオ、画像、または他のユーザ入力などの任意選択の他の入力を含むユーザ入力を処理することができる。ユーザ入力の組み合わせは、特定の非商取引サイトの構造に依存することができる。たとえば、Ｔｗｉｔｔｅｒのユーザ入力は、Ｆａｃｅｂｏｏｋのユーザ入力とは異なる。両方とも、テキストのみまたはテキストおよび他のユーザ入力を含むことができる投稿を伴う。それぞれのソーシャルネットワーキングサイトは、その機能に従ってユーザ入力を処理する。画像と、ロケーションまたは製品データベース内の製品について説明する何らかの説明またはメタデータとが入力可能である。ユーザ入力は、このケースでは、ソーシャルメディア上で投稿することは、投稿がソーシャルネットワーキングサイトを通して処理されるとき、買うボタンを含むべきであることを示す、製品データベース内の製品への参照を含む、非商取引サイトに従ってユーザ入力の任意の組み合わせを含むことができる。投稿は、非商取引サイトの処理に応じて、個々のユーザまたは自動化されたシステムによって準備および投稿可能である。
【０２３５】
タブに基づいて修正されたブラウザインターフェース
[00305]統一された入力フィールドに提供される入力を処理する分類器によって決定された意図に基づいてタブを事前にポピュレートする、システム、方法、およびコンピュータ可読記憶デバイスが開示される。典型的なウェブ検索では、ユーザは、検索フィールドを選択するためにクリックし、テキストを入力し、結果ページがロードされるのを待機し、結果ページ内の所望のリンクをクリックして、最終的に、所望のリンクがロードされるのを待機した後に、それに到達する。このプロセスは、多くのステップを必要とする。ブラウザ内のタブを事前にポピュレートする統一された入力フィールドは、このプロセスを単純化することができる。
【０２３６】
[00306]たとえば、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍは、統一された入力フィールドを提供することができる。ユーザは、「ｉＰｈｏｎｅ  ５Ｓ」に対する検索など、統一された入力フィールドを介して、入力を提供する。システムは、ユーザプロファイルおよび入力されたテキストに基づいて、その時点に入力されたテキストを使用してユーザが検索を遂行する検索結果のリストからなど、ｎ個の所望される可能性の最も高いページを識別することができる。次いで、システムは、ブラウザ内で新しいタブを作成して、ｎ個の所望される可能性の最も高いページをポピュレートするように、ユーザのブラウザに指示することができる。ｎの値は、ユーザの好み、既に開いているタブ、どれくらい多くのページが信頼閾値を超えたか、利用可能なメモリ、ネットワーク帯域幅、どのページがロードされる準備が整っているか、タブにポピュレートされるページ内のダイバーシティなどに基づいて変化してよい。一変形形態では、システムは、ブラウザ内で３つの新しいタブを自動的に作成し、ポピュレートすることができ、この３つの新しいタブは各々、統一された入力フィールドを介して提供される入力に応答して異なる可能性のある所望の結果をもつ。１つのタブは、Ａｍａｚｏｎワンクリック購入ページとすることができ、１つのタブは、Ａｐｐｌｅ．ｃｏｍにおけるポピュレートされたショッピングカートの最終ページとすることができ、１つのタブは、ＡＴ＆Ｔを通した２年のサービス契約とともにｉＰｈｏｎｅ  ５Ｓを購入するためのサービス契約の最終ページとすることができる。このようにして、ユーザは、タブを自動的に選択し、ブラウジングし、比較して、ユーザはどのタブを要望するかを決定することができる。しかしながら、この段階では、入力データは、特定の購入に至るのに十分な情報を必ずしも提供しない。したがって、システムは、ｉＰｈｏｎｅ  ５ＳについてのＡｐｐｌｅ情報ページ、ｉＰｈｏｎｅ  ５ＳについてのＷｉｋｉｐｅｄｉａページ、またはｉＰｈｏｎｅ  ５Ｓの人気のあるビデオレビューのようなページを選択することができる。
【０２３７】
[00307]しかしながら、ユーザが「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ  シルバー」などの追加の情報を入力した場合、分類器は、テキストに基づいて、ユーザプロファイルまたは検索履歴に関連して、ユーザの意図が、示されたｉＰｈｏｎｅを購入することであることを決定することができる。この状況では、システムは、ブラウザ内で購入固有タブをロードすることができる。たとえば、システムは、ユーザがそこに既にナビゲートし、ｉＰｈｏｎｅ  ５Ｓ、３２ＧＢ、シルバーを選択し、ｉＰｈｏｎｅをカートに追加して、精算プロセスにおける高度な段階または潜在的に最終的な段階にあるかのように、Ａｍａｚｏｎ．ｃｏｍまたはＡｐｐｌｅ．ｃｏｍページにタブを直接的にロードすることができる。Ａｍａｚｏｎ．ｃｏｍのケースでは、システムは、示されたｉＰｈｏｎｅのワンクリック購入をユーザが行う準備の整ったタブをロードすることができる。あるいは、システムは、ユーザが、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍに行き、統一された入力フィールド内でテキストを入力して、Ａｍａｚｏｎを通して購入するためにｅｎｔｅｒを打つことができ、結果として得られる購入ページが、ユーザのための新しいタブ内に自動的にロードされるように、ワンクリック購入ボタンをクリックするアクションを自動的に実行するタブをロードすることができる。このケースでは、統一された入力フィールド内にテキストを入力した後にｅｎｔｅｒを打つことは、遂行したばかりの注文の購入概要とともに新しいタブをロードさせることができ、ユーザが、発送オプション、製品オプション、請求情報、または他の注文詳細を修正することを潜在的に可能にする。別の変形形態では、システムは、ユーザが、統一された入力フィールド内でｅｎｔｅｒを打ったことに基づいて、自動的に発注し、アクセサリを購入するためのウェブページの新しいタブ、購入された品物に関係するサービス、技術的サポートページ、または何らかの他の関係するウェブリソースに、ユーザを遷移させることができる。
【０２３８】
[00308]ユーザが、統一された入力フィールド内に第１の部分的入力文字列を入力したとき、ユーザは、結果をプレビューするために、１つまたは複数のタブ間のあちこちをクリックすることがある。次いで、ユーザは、統一された入力フィールドをもつタブに戻って、入力文字列を修正するまたはこれに追加することができる。システムは、以前に生成されたタブを削除し、新しいタブをポピュレートすることができる、またはシステムは、たとえば、他の以前に生成されたタブを除去しながら、ユーザが開いた、見た、操作した、またはクリックしたタブを保つことができる。このようにして、ユーザは、更新された入力文字列に基づいて、どのタブを保つべきか、およびシステムはどのタブを自由に削除または置き換えるべきかを選択することができる。
【０２３９】
[00309]システムは、どのユーザがタイプしているかに基づいて新しいタブに挿入するために、潜在的な合致するページを予測的に取り出してキャッシュすることができる。たとえば、ユーザが、統一された検索フィールド内で「Ａｐｐｌｅ」をタイプしている場合、システムは、３つの最も人気のあるＡｐｐｌｅ製品またはユーザが興味をもつ可能性が最も高い３つのＡｐｐｌｅ製品のページを取り出すことができる。次いで、ユーザが「Ａｐｐｌｅ  ｉＰ」をタイプすると、システムは、検索を、Ａｐｐｌｅ  ｉＰｏｄ、ｉＰｈｏｎｅ、およびｉＰａｄ（登録商標）などの部分的な文字列に合致する製品に絞ることができる。ＭａｃＢｏｏｋ  ＡｉｒまたはＡｐｐｌｅ  ＴＶなどの品物は統一された入力フィールド内の部分的な入力文字列に合致しないので、含まれない。プロセスは、キャッシュされたページを改良し続け、それによって時間を節約することができ、そのため、ページは、あるイベントがいつ発生するかまたは閾値がいつ満たされるかをユーザに提示する準備が整っている。たとえば、一変形形態では、システムが、ユーザがｅｎｔｅｒを押すよりも前に、ページを準備している、これを取り出している、およびこれをキャッシュしているにもかかわらず、システムは、ユーザが、新しいタブをポピュレートするために、統一された入力フィールド内でｅｎｔｅｒを押すのを待機することができる。このようにして、ユーザが、統一された検索フィールド内でｅｎｔｅｒを押すとき、システムは、新しいタブを非常に迅速に作成し、この新しいタブに、取り出されたページをポピュレートすることができる。追加のページが予測されていないまたは取り出されていない場合、それらのページのためのタブは正常にロードすることができるが、他のタブは、ユーザが閲覧する準備が整っている。
【０２４０】
[00310]一変形形態では、システムは、統一された入力フィールドを表示するタブから、統一された入力フィールドを介して提供された入力に応答して作成された異なるタブに、ユーザを即時に遷移させることができる。ほとんどのブラウザは、ユーザが、マウスに対して、タブをクリックする、またはタブ間でナビゲートするためにｃｔｒｌ−ｔａｂ、ｃｔｒｌ−ｓｈｉｆｔ−ｔａｂ、ｃｔｒｌ−ｐｇｕｐ、もしくはｃｔｒｌ−ｐｇｄｎなどのキーボードショートカットを押すことを可能にするが、統一された入力フィールドは、ユーザが、入力に応答してポピュレートされた新たに作成されたタブに自動的に切り換えるために、統一された入力フィールドを介して入力を提供することの最後に、ｅｎｔｅｒまたは何らかの他のキーを押すことを可能にすることができる。たとえば、ユーザが、統一された入力フィールド内でｅｎｔｅｒを打ったとき、システムは、Ａｍａｚｏｎ上でワンクリック購入ページのタブに切り換えることができる。システムは、ユーザが、統一された入力フィールド内でｅｎｔｅｒを押し、ならびにその新しいタブにユーザを切り換えたことに基づいて、Ａｍａｚｏｎにおいて購入が完了されるように、遷移アクションに購入も含むことができる。
【０２４１】
[00311]システムは、ユーザ入力に基づいて、異なるオプションまたは異なる宛先を提示することができる。たとえば、システムは、「ｅｎｔｅｒ」を１回押すと第１の新しいタブにユーザを遷移させ、「ｅｎｔｅｒ」を２回押すと第２の新しいタブにユーザを自動的に遷移させ、「ｅｎｔｅｒ」を３回押すと第３の新しいタブにユーザを自動的に遷移させ、以下同様である、メッセージまたは標識を提示することができる。統一された入力フィールドを介して提供される複数の異なるキーおよび／またはキー組み合わせは、統一された入力フィールド内で提供された入力に基づいてタブを管理またはナビゲートするための異なる行動をトリガすることができる。さらに、さまざまなアクションおよびそれらのアクションをトリガするキー組み合わせは、ユーザが統一された入力フィールド内に追加のテキストを入力する、または統一された入力フィールド内のテキストを修正するにつれて、変化することができる。
【０２４２】
[00312]図１６は、方法例を示す。方法例内のステップは、任意の順序で実行可能であり、追加のステップを含むまたは説明されるステップのうちのいくつかのすべてもしくは一部を除外する他の組み合わせまたは順列で実行可能である。システムは、第１のユーザインターフェース内で、ブラウザを介して処理された第１のウェブサイトに関連づけられた第１の入力フィールドを提示することができる（１６０２）。
【０２４３】
[00313]システムは、ユーザから第１の入力フィールドへの入力を分析して、ユーザが検索を実行することを要望するか購入を行うことを要望するかを決定し、決定をもたらすことができる（１６０４）。決定が、ユーザが購入を行うことを要望することを示し、入力以外にユーザからの他の任意の入力がない場合、システムは、入力とともに第２のウェブサイトに関連づけられた第２の入力フィールドを事前にポピュレートすることができる（１６０６）。システムは、ユーザが、自動遷移後の、入力に関連づけられた製品がユーザからワンクリックアクションを介して購入および配達のために処理可能である状態であるように、第２の入力フィールド内の入力を使用して第２のウェブサイトを前処理することができる（１６０８）。システムは、第１のウェブサイトおよびブラウザのうちの１つから第２のウェブサイトにユーザデータを送信することによって、第２のウェブサイトを前処理することができる。支払いデータは、ユーザのためのプロセスを単純化するために、ブラウザとサイトとの間で通信可能である。システムは、製品がワンクリックアクションを介して購入および配達のために処理可能である状態をもたらすために第２のウェブサイトのショッピングカートモデル内を自動的にナビゲートすることによって、第２のウェブサイトを前処理することができる。処理は、ユーザが購入を行うためにインターフェースと対話するとき、入力フィールドに関連づけられたエンティティが、品物の支払いを処理し、販売のために別個の販売業者と協調することを含むことができる。
【０２４４】
[00314]システムは、ブラウザ内のタブ内で第２のウェブサイトを提示することができる（１６１０）。システムは、タブに関連づけられたユーザに視覚的通知を提示することができ、そのタブをクリックすると、ユーザがワンクリックアクションを介して製品の購入および配達のために処理することができる状態である第２のウェブサイトをユーザに提示する。視覚的な通知は、ポップアップ、第１のウェブサイト上の標識、タブに関連づけられた、またはユーザインターフェース内の何らかの他のロケーション内の、ブラウザ固有の通知とすることができる。システムは、ブラウザ内の追加のタブ内で複数の追加のウェブサイトを提示することができ、統一された入力フィールドを介して、ブラウザに固有の確立されたキーボードショートカットおよびマウスクリックとは無関係に、それらのタブを通して操作またはナビゲートするために、機構を提供することができる。たとえば、システムは、ユーザが、ユーザからワンクリックアクションを介して購入および配達のために入力に関連づけられた製品が処理可能である自動遷移後の状態であるように、第３の入力フィールド内の入力を使用して第３のウェブサイトを前処理し、第３のウェブサイトをブラウザ内の第２のタブ内で提示することができる。
【０２４５】
[00315]図１７Ａは、入力フィールド１７０４とユーザ入力１７０８とをもつタブ１７０２を有するインターフェース１７００を示す。この入力フィールド１７０４は、ユーザ入力を検索として自動的に処理せず、いくつかの異なる機能を実行するために入力を処理することができるので、制限がない、または開ループである。ユーザが「ｉＰｈｏｎｅ  ５Ｓ」を入力すると仮定する。システムは、その入力を分析し、ユーザが購入を行うことを要望する高い可能性があることを決定する。次いで、システムは、Ａｍａｚｏｎ．ｃｏｍおよびＡｐｐｌｅ．ｃｏｍなどの１つまたは複数のウェブサイト上でその入力を前処理し、したがって、これらの代替ウェブサイトのうちの各々は、ユーザがそのウェブサイトにナビゲートし、「ｉＰｈｏｎｅ  ５Ｓ」を入力し、引き続きブラウジングし、もう１回のクリックが製品の購入および配達を引き起こす状態にナビゲートしたことの同等物である状態で位置決めされる。したがって、図１７Ｂでは、システムは、Ａｍａｚｏｎのためのタブ１７１０およびＡｐｐｌｅのためのタブ１７１２を提示することができる。ユーザは、「３２ＧＢ  シルバー」１７０８などのさらなるテキストを引き続きタイプすることができる。システムは、代替ウェブサイトの前処理を引き続き改良する。したがって、ユーザが完了した後、ユーザがＡｍａｚｏｎタブ１７１０をクリックした場合、そのタブは、次のクリックが、ユーザがその製品を買って配達することを可能にすることができるように、「ワンクリック」状態である前処理された検索を明らかにする。Ａｐｐｌｅのようなウェブサイトが類似した「ワンクリック」オプションをもたない場合、システムは、本質的にタブ１７１２に、ユーザが購入を行うためにもう１回のクリックをただ必要とする状態の準備が整ったショッピングカートを提示させるために、ショッピングカートモデルをナビゲートおよび前処理することができる。ブラウザまたはｏｎｅ−ｓｅａｒｃｈ．ｃｏｍアプリケーションは、ワンクリック購入能力をもたないウェブサイトの購入ページを通してバックグラウンドでナビゲートするために必要な、購入アカウントデータ、配達住所、パスワードなどを、代替ウェブサイトと通信するＡＰＩを介して提供することができる。ＡＰＩは、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍが品物のための支払いの処理を取り扱う場合、トランザクションを完了する必要なデータのみを通信する必要があることがある。このようにして、販売業者は、配達のためのＡＰＩを通してｏｎｅ−ｓｅａｒｃｈ．ｃｏｍと容易に通信することができる。
【０２４６】
[00316]タブの位置決めは、履歴、個人的な好み、意図の可能性などに基づくことができる。たとえば、ユーザが、一般的にはＡｍａｚｏｎ．ｃｏｍを通して品物を購入する場合、そのタブは、現在のタブ１７０２の隣に提示される１７１０。購入意図に対する検索意図の確率は同等であることがあり、したがってＧｏｏｇｌｅまたはＹａｈｏｏ！検索は、タブにおいて購入オプションの隣に提示されることがある。検索は、タブにおいて購入オプションの隣に提示されることがある。タブは、どれくらい深く前処理が進行したかに関するヒントも与えることがある。たとえば、１つのタブが「Ａｍａｚｏｎ検索」を示すことがあり、別のタブが「Ａｍａｚｏｎ  ワンクリック」を示すことがあり、Ａｍａｚｏｎ検索タブをクリックすることは、そのタブの「状態」が、通常のＡｍａｚｏｎ検索と同様にブラウジングのために品物のリストが返されるようにユーザ入力が前処理されていることであるが、その状態は、ユーザが購入および配達を完了するために単にもう１回クリックすることができる「ワンクリック」状態でないことを意味することをユーザに示す。前処理の深度は、どれくらい一義化が必要とされるかにも基づいて実行可能である。ユーザが十分なデータを提供しない場合、検索レベル状態のみが提供されることがある。品物から選定するために、２つの色などの２つのオプションのみがあり、ユーザが色を指定しなかった場合、システムは、タブ内で、各々が「ワンクリック」購入ボタンを有する２つの異なる品物を提示する場合があり、したがって、そのタブは依然としてワンクリック購入状態にあるが、２つの品物は、さらなるナビゲーションが必要でないようにページ上で提示される。システムは、購入のためにゴールド「ワンクリック」オプションおよびシルバー「ワンクリック」オプションを提示することができる。
【０２４７】
[00317]典型的なウェブ検索では、ユーザは、検索フィールドを選択するためにクリックし、テキストを入力し、結果ページがロードされるのを待機し、結果ページ内の所望のリンクをクリックして、最終的に、所望のリンクがロードされるのを待機した後に、それに到達する。ユーザが、継続し、購入を行うことを要望する場合、ユーザは、既存のアカウントでログインすることまたはウェブサイトで新しいアカウントを作成することのどちらかを行い、仮想ショッピングカート内に品物を置く、精算する、発送情報を提供するなどを行わなければならない。このプロセスは、多くのステップを必要とする。ユーザのためのショッピングカートを事前にポピュレートする統一された入力フィールドは、このプロセスを大きく単純化することができる。
【０２４８】
ブラウザ／エージェント販売業者サイトＡＰＩ間での情報交換
[00318]一態様では、本開示は、支払いプロセスを単純化するために図１７Ｂに示されているように、ブラウザと１つまたは複数の販売業者サイトとの間で情報が交換されるＡＰＩを有する新規なブラウザを包含する。そのようなブラウザは、数多くの入力フィールドへと支払い情報のすべてを入力することをユーザに求めることの複雑さおよび欠如に対処しようとすることに関する、以前の課題に対処する。いくつかのブラウザは、記憶された支払い情報がブラウザの側のフォームを埋めるために使用されるフォーム埋め込み機能を含む。しかしながら、これらのフォーム埋め込み特徴は、決して理解されず、依然としてあまりにも煩わしいものであった。販売業者サイトからサービスされるフォームは協調されず、ユーザは、依然として、フォームを通して入力され、次いで販売業者サイトに送り返されたデータのすべてを閲覧しなければならなかった。さらに、異なるサイトは、プロセスを混乱させるフィールドのすべてを埋めるための異なる構造を有した。必要とされるものは、買い入れを記憶された支払いデータとともに登録しなかったサイトのための支払いおよび精算プロセスを単純化するためのより包括的で協調された取り組みである。本明細書において開示されるブラウザＡＰＩは、支払いプロセスが、以前は達成不可能であった手段におけるその必須要素に本当に簡略化可能であるように、より包括的な手段でこの課題を解決する。たとえば、サイトとブラウザは、より具体的で戦略的な調節された手段で、次いで古いフォーム埋め込み手法で、さらに多くのデータを往復して交換することができる。ＡＰＩを介してさらに多くの情報を交換することができることは、ユーザにとって著しくより容易である、より効率的な手法を可能にする。
【０２４９】
[00319]ブラウザまたはウェブブラウザは、ワールドワイドウェブ上で情報リソースを取り出し、提示し、横断するためのソフトウェアアプリケーションである。情報リソースは、統一資源識別子（ＵＲＩ／ＵＲＬ）によって識別され、ウェブページ、画像、ビデオ、または他のコンテンツとすることができる。リソース中に存在するハイパーリンクは、ユーザが、関係リソースにブラウザをナビゲートすることを容易に可能にする。例示的なウェブブラウザは、Ｆｉｒｅｆｏｘ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ／Ｍｉｃｒｏｓｏｆｔ  Ｅｄｇｅ、Ｇｏｏｇｌｅ  Ｃｈｒｏｍｅ、Ｏｐｅｒａ、およびＳａｆａｒｉである。ウェブブラウザは、サーバ、デスクトップコンピュータ、ラップトップ、モバイルデバイス、およびソフトウェアを実行するように構成された他の任意のデバイス上で動作することができる。ウェブブラウザは、一般的には、ユーザインターフェースと、レイアウトエンジンと、レンダリングエンジンと、ＪａｖａＳｃｒｉｐｔインタープリタと、ユーザインターフェースバックエンドと、ネットワーク構成要素と、データ持続性構成要素とを含む。
【０２５０】
[00320]ウェブブラウザの主な目的は、情報リソースをユーザ（「取り出し」または「フェッチング」）にもたらし、ユーザが情報を見ることを可能にし（「表示」、「レンダリング」）、次いで、他の情報にアクセスする（「ナビゲーション」、「リンクをたどる」）ことである。
【０２５１】
[00321]プロセスは、ユーザがユニフォームリソースロケータ（ＵＲＬ）、たとえばｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／をブラウザに入力したときに始まる。ＵＲＬのプレフィックス、統一資源識別子すなわちＵＲＩは、ＵＲＬがどのように解釈されるかを決定する。最も一般に使用される種類のＵＲＬは、「ｈｔｔｐ：」で始まり、ハイパーテキスト転送プロトコル（ＨＴＴＰ）上で取り出されるようにリソースを識別する。
【０２５２】
[00322]ｈｔｔｐ、ｈｔｔｐｓ、ｆｉｌｅなどのケースでは、リソースが取り出されると、ウェブブラウザはそれを表示する。ＨＴＭＬおよび関連づけられたコンテンツ（画像ファイル、ＣＳＳなどのフォーマッティング情報）は、「レンダリング」として知られるプロセスである、マークアップからインタラクティブな文書に変換されるためにブラウザのレイアウトエンジンに渡される。ＨＴＭＬを除いて、ウェブブラウザは、一般に、ウェブページの一部とすることができる任意の種類のコンテンツを表示することができる。ほとんどのブラウザは、画像、オーディオ、ビデオ、およびＸＭＬファイルを表示し、多くの場合、ＦｌａｓｈアプリケーションおよびＪａｖａ（登録商標）アプレットをサポートするプラグインを有することができる。
【０２５３】
[00323]情報リソースは、他の情報リソースに対するハイパーリンクを含むことがある。各リンクは、進むことになるリソースのＵＲＩを含む。リンクがクリックされるとき、ブラウザは、リンクのターゲットＵＲＩによって示されるリソースにナビゲートし、再度コンテンツをユーザにもたらすプロセスが始まる。ブラウザは、本明細書において開示されるように、支払いデータ、ワンクリックパラメータ、または設定などのユーザデータを記憶することができる。Ａｎｄｒｏｉｄ  ＰａｙおよびＡｐｐｌｅ  Ｐａｙのような他の支払いサービスは、支払い機能のためにブラウザと通信することができる。たとえば、デバイス上のセキュアな要素は、Ａｐｐｌｅ  Ｐａｙのための支払いデータを記憶し、そのデータに対するアクセスを、サイト上での支払いのためにブラウザと協調させることができる。さらに、ブラウザ機能性は、購入プロセスを単純化するために、ＡＰＩを介して必要なデータを通信するように修正されることができる。
【０２５４】
[00324]したがって、この実施形態は、サイトが、通常の支払い処理構造に従って製品の購入を処理することができるように、ＡＰＩを通したｍｅｒｃｈａｎｔ．ｃｏｍサイトへの支払いデータの要求および送信を管理するために、ブラウザと販売業者（ｈｔｔｐ：／／ｗｗｗ．ｍｅｒｃｈａｎｔ．ｃｏｍなど）との間でのＡＰＩを通した対話を包含する。別個の支払いサービスが使用される場合、ＡＰＩは、組織化された手段で、支払いサービスによって支払いの管理を取り扱い、支払いデータをサイトに通信することができる。この点に関して、ブラウザ（または他の任意のエージェント）は、販売業者、買い手と、支払い方法または支払いアカウントとの間のデータの仲介通信を提供することができる。ブラウザは、支払い情報を記憶することができる、または支払い情報を記憶する別のローカルアプリケーションと通信することができる、またはＡｎｄｒｏｉｄ  ＰａｙもしくはＡｐｐｌｅ  Ｐａｙのような支払いサービスと通信することができる。たとえば、Ａｐｐｌｅ  Ｐａｙを用いると、データは、ブラウザＡＰＩを介した支払いのために要求が受信されたときにブラウザによってアクセスされるセキュアな要素内に記憶される。別のサーバがアクセスされ、処理のためにブラウザＡＰＩを通して販売業者サイトに渡される支払いトークンが生成される。ユーザがクレジットカードデータ、住所などを手動で入力することを求めない支払いプロセスを可能にするという全体的な目的を達成するためにＡＰＩを通して通信されるパラメータおよびデータの標準化された規格がある。プロセスは、サイトが支払いボタン（ＡＰＩを通してブラウザとインターフェースしないローカルに使用される支払いボタンとは機能が異なる）を受信または作成し、暗号化可能な、住所および支払いアカウントデータなどのユーザについての支払いデータを要求および受信することを可能にし、ユーザが、支払いデータのいずれかを更新し、次いで、受信された支払いデータを使用して支払いをローカルに処理することを可能にすることができる。ブラウザが支払い情報をサイトに渡すことができる多くの機構がある。たとえば、ブラウザは、クレジットカードを記憶することができる、および／またはＣｈｒｏｍｅを通してＡｎｄｒｏｉｄ  Ｐａｙと、もしくはＳａｆａｒｉを通してＡｐｐｌｅ  Ｐａｙと統合可能である。この点に関して、支払い処理のためにサイトに渡すために必要とされるデータのうちの１つまたは複数を提供するためにブラウザと通信する、Ａｎｄｒｏｉｄ  ＰａｙまたはＡｐｐｌｅ  Ｐａｙなどの別個のアプリケーションまたはソフトウェアがあることがある。別個のアプリケーションは、支払いを処理し、支払いが行われたことを、ＡＰＩを通してサイトに戻すように報告する場合もある。支払いに関連づけられた参加情報はすべて、提供可能である。
【０２５５】
[00325]一態様では、プロセスは、次のように進むことができる。コンピュータ可読記憶デバイスは、プロセッサによって遂行されるとき、プロセッサに、コンテンツを取り出すためのブラウザ動作を実行させ、そのコンテンツをユーザインターフェース内に提示させ、世界的なネットワーク上の情報リソースを横断させる、ブラウザ命令を記憶する。ブラウザ命令は、プロセッサによって遂行されるとき、命令が、プロセッサに、ユーザインターフェースを介してユーザから、購入に至ることができるサイトに関連づけられたオブジェクトとの対話を受信することを含むさらなる動作を実行させるように、修正および拡張される。オブジェクトは、サイトもしくはキオスク（kiosk）上のボタン、支払いを処理する必要性に至ることができるゲーム内のボタン、購入意図に至るバーチャルリアリティ環境内での任意の対話、または製品もしくはサービスに関連づけられた買うボタンであってよい。動作は、対話に基づいてアプリケーションプログラミングインターフェースを介して、購入に関連したユーザに関する支払いデータのためのサイトから要求を受信することと、アプリケーションプログラミングインターフェースを介してサイトに、支払いデータ（またはセキュリティ目的での支払いデータのトークン化されたバージョン）を送信することであって、支払いデータはサイト上で購入を処理するために使用可能である、送信することとを含む。一態様では、別のエージェント、検索エンジン、またはエンティティは、本明細書に述べられたように、支払いを処理し、サイトに戻すように報告する。
【０２５６】
[00326]別の実施形態は、オブジェクトとの支払い対話、または任意の支払い対話標識を受信し、支払い要求をブラウザ支払い要求ＡＰＩに送信し、支払いを処理するための支払いデータをブラウザＡＰＩから戻すように受信する販売業者の観点からのプロセスを包含する。
【０２５７】
ブラウザ支払い要求ＡＰＩを用いたキオスクの使用
[00327]本開示の別の態様は、ブラウザ支払い要求ＡＰＩとともにキオスクをどのように使用するかに対処する。キオスクは、ユーザが支払いを行うために販売業者または他のサービスプロバイダと対話し得るブラウザをもつ任意のデバイスであってよい。キオスクは、料金を支払う、食物を買う、デバイスを介してパントリー内での交換用紙タオルを注文するなどのために使用されてよい。多くのケースでは、これらのキオスクは公的であり、したがって、ブラウザ上に記憶されるまたはブラウザ支払い要求ＡＰＩを介して要求に応答するためにペアにされたデバイスを通して利用可能である支払い情報の単一のセットはない。
【０２５８】
[00328]課題は、任意の品物を購入するために使用可能である公的なキオスクに行った場合、キオスク上のブラウザは個人的なブラウザでないことである。それは、支払い情報を含まない。しかしながら、そのユーザは、ブラウザ支払い要求ＡＰＩをサポートし、したがって必要な支払い情報を記憶するまたはネットワークベース情報へのアクセスを可能にするブラウザを有するＡｎｄｒｏｉｄデバイス、ｉＰｈｏｎｅ、または他のモバイルアプリケーションを有することがある。以下は、機能が同じである（すなわち、ワンクリック、または簡略化された購入）ように、そのキオスクブラウザを個別化されたブラウザに一時的に変換することを可能にするための機構を提供する。キオスクおよびモバイルデバイスは、キオスクブラウザは、そのユーザのための一時的なプロキシとすることができるように、情報を交換することができる。Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、短距離通信、セルラー式、５Ｇ、または他の任意の手法もしくはプロトコル、ワイヤード手法すらも通して、キオスクブラウザは、モバイルデバイスブラウザにとって利用可能な支払いデータ（クレジットカードアカウント、Ａｎｄｒｏｉｄ  Ｐａｙ、Ｓａｍｓｕｎｇ  Ｐａｙ、Ａｐｐｌｅ  Ｐａｙ、Ｍｉｃｒｏｓｏｆｔ  Ｗａｌｌｅｔ、他の金融機関情報、デビットアカウント、ＰａｙＰａｌアカウントなど）にセキュアにアクセスすることができる。
【０２５９】
[00329]いくつかのケースでは、デバイスは、通常のワイヤレスなやり方でＡｐｐｌｅ  ＰａｙまたはＡｎｄｒｏｉｄ  ｐａｙを使用する。本開示は、支払いを行うための標準化された手法である支払い要求ＡＰＩインフラストラクチャを活用する新しい手法を可能にする。したがって、多くの販売業者は、支払い要求ＡＰＩを使用する方向に動いているが、キオスクタイプのデバイスも、同じ支払い機構を利用することができる。
【０２６０】
[00330]ラップトップ上でＡｐｐｌｅ  Ｐａｙを使用するとき、Ｓａｆａｒｉブラウザは、ＡＰＩ（所有権を主張できるＡｐｐｌｅ支払い要求ＡＰＩ）を通して販売業者サイトから支払い要求を受信し、一態様では、ユーザは、ラップトップ上ではなくｉＰｈｏｎｅ上で指紋確認を介して購入を確認する。ラップトップとｉＰｈｏｎｅは、トランザクションを達成するためにワイヤレスで通信する。提案される手法は、いくつかの点で異なる。このケースにおけるキオスク（またはブラウザを有する任意のデバイス）は、公的なキオスクであるので、第１のインスタンス内では、ユーザのための支払い情報をもたない。ブラウザ支払い要求ＡＰＩは、使用されているブラウザは、公的なブラウザまたは支払い情報のないブラウザであるという通知を含むように修正可能である。したがって、ユーザが、パーキングメータキオスクを支払い始めており、「支払う」ボタンと対話する場合、バックエンドの販売業者アプリケーションは、それが利用可能な支払いオプションであるかどうかを確かめるためにＡＰＩを通して支払い要求を送ることがある。キオスクは、ユーザのモバイルデバイスが、ユーザ支払い情報を含むブラウザを有しているかどうか、および／またはその情報を接続および利用する許可があるかどうかを確かめるために、ワイヤレスで（またはワイヤード接続を使用して）問い合わせることができる。そうである場合、キオスクとのユーザ経験は、ブラウザＡＰＩを使用する通常の購入経験（指紋、ＣＶＣコードエントリ、配達住所または支払いアカウントの確認などを通しての確認）と同じまたは非常に類似していることができる。キオスクブラウザＡＰＩ間の通信は、キオスクブラウザとユーザのモバイルデバイスブラウザとの間の接続を通して協調可能である。別個のＡＰＩは、キオスクブラウザとモバイルデバイスブラウザとの間の通信、要求、応答などに使用可能である。支払い情報を販売業者サイトに渡すのに適切な時間が来たとき、データは、モバイルブラウザから販売業者サイトに対するキオスクブラウザに渡され得る。データは、セキュリティのための任意の様式でトークン化または暗号化可能である。次いで、販売業者サイトは、ちょうど支払い要求ＡＰＩを通して通常のブラウザからデータを受信するように、支払いデータを受信する。キオスクブラウザは、支払いデータを記憶せず、それを販売業者に通過させるのみである。
【０２６１】
[00331]一態様では、キオスクブラウザがユーザのための支払い情報を実際に記憶しない状況においてキオスクブラウザがブラウザＡＰＩを介して販売業者と適切に通信することを可能にするために、パラメータが設定されてもよいし、キオスクブラウザが応答することを可能にするためにダミー情報が提供されてもよい。たとえば、販売業者要求が、販売業者がＶＩＳＡ支払いおよびＭＡＳＴＥＲＣＡＲＤ支払いを受け入れることを示し、モバイルデバイスユーザが、モバイルデバイスブラウザ内に記憶されたＶＩＳＡアカウントを有する場合、モバイルデバイスとキオスクとの間の通信は、キオスクブラウザが、（実際には、キオスクがＶＩＳＡアカウント番号を記憶しないことがあるが）ＶＩＳＡが支払いに使用されるという販売業者要求に応答するのに十分な情報を有することを可能にすることができる。任意の量またはタイプのデータが、キオスクブラウザがユーザの個人情報のセキュリティを維持しながらブラウザＡＰＩを介して販売業者と通信するのに成功することを可能にするために通信され得る。たとえば、１つのシナリオでは、ダミー情報は、キオスクブラウザが、支払いを処理するのに必要なデータを有すると信じるようにキオスクブラウザ内にデータ（ダミークレジットカード番号、ユーザ名、住所などのうちの１つまたは複数）をポピュレートすることがある。次いで、支払い情報を実際に提供することが必要とされるとき、モバイルデバイスは、トークンを送信してもよいし、支払いを処理するために情報を販売業者に転送することができることができるキオスクに必要な実際の情報を送信してもよい。別の態様では、ブラウザＡＰＩは、キオスクブラウザがモバイルデバイス（または他のデバイス）と通信しており、キオスクブラウザは実際のデータをもたないが、モバイルデバイスは実際のデータをもっており、ユーザはＶＩＳＡアカウントを有することを示すキオスクパラメータが、キオスクブラウザ内で設定され得るように、修正されることがある。したがって、キオスクブラウザは、支払いプロセス内でデータを交換するプロセスを続行することがある。たとえば、キオスクブラウザが、ＶＩＳＡは、支払いを行うために使用可能であり、料金の総額および発送コストを受信することができ、その情報をモバイルデバイスブラウザに転送し、最終的な支払いおよび／または住所または他の任意の情報を受信して、プロセス内の適切な時間に販売業者サイトに渡すことができることを確認することがある。
【０２６２】
[00332]キオスクが、ユーザに関連づけられ得る複数のモバイルデバイスを検出することがある（各々がデバイスをもつ３人の異なる人々は、ユーザが支払いを処理している間、キオスクの十分近くにいることがある）。したがって、一義化技法は、どのデバイス（どのモバイルブラウザ）が使用するべきかを確認するために必要とされることがある。キオスク上での指紋確認、ＣＶＣコード、ダイアログ、スピーカ検証などのセキュリティの余分な層が、実施されることを必要とすることがある。確認は、「ＴｏｍまたはＭａｒｙですか」または「お客様のＣＶＣコードは何ですか？」と同じくらい単純であってよい。ユーザは、モバイルデバイス上で指紋確認を提供することを必要とすることがある（「お使いのｉＰｈｏｎｅ上での指紋確認を通して、こちらがＭａｒｙであることを確認します」）。任意のそのようなセキュリティ対策は、本開示の一部として企図されている。
【０２６３】
[00333]セキュリティ対策は適切であると仮定すると、開示されるプロセスは、モバイルデバイスは、ユーザのための支払い情報を、そのブラウザを通してキオスクブラウザに渡し、次いで、キオスクブラウザは、処理のために支払い情報を販売業者に通過させる。支払い情報は、モバイルブラウザに記憶可能であり、または別のエンティティからモバイルブラウザによってアクセス可能である。結果は、ユーザがキオスクにおいて同じまたは類似の購入経験を有することである。クレジットカードは、スワイプまたは使用される必要はない。キオスクブラウザは、ユーザがユーザのための簡略化された購入トランザクションを可能にするためのエージェントまたはプロキシブラウザとして機能することができる。支払いプロセスは、公的なキオスクにおいてすら、なじみの深いブラウザ支払い要求ＡＰＩプロセスである。
【０２６４】
[00334]モバイルデバイスとキオスクとの間の交換は、要求、応答、データの通信などが購入トランザクションに関連して発生することができるＡＰＩまたは他の任意の手段を通してとすることができる。キオスクブラウザは、一態様では、その人の支払い情報、配達情報、またはユーザについての他の任意の情報を記憶しない。実際、１つの手法は、キオスクブラウザが支払い情報のトークン化されたバージョンを見たことすらないように、セル接続または他の接続であるが、モバイルデバイスから販売業者へ支払い情報の別個の配信を可能にすることができる。別の態様では、キオスクは、ユーザについてのデータを販売業者サイトに通信することができ、販売業者サイトは、ユーザモバイルデバイスに対するブラウザＡＰＩ要求を直接的に実行し、その通信チャネルを通して支払いデータを通信することができる。
【０２６５】
[00335]一態様では、キオスクにおいて行われた購入のための支払い対話は、モバイルデバイス上で実際に発生することができる。たとえば、ユーザは、キオスク上の「支払う」オブジェクトをクリックするが、次いで、支払いインターフェースを閲覧し対話するためにモバイルデバイスに遷移されることがある。インターフェースの分割、データの通信などが、ユーザが任意の製品またはサービスの支払いを達成する簡略化された対話を達成するために、モバイルデバイス、キオスク、および／または他のデバイスの間で発生することがある。
【０２６６】
[00336]この代替プロセスは、次のように進み得る。
【０２６７】
[00337]（１）モバイルデバイスをもつユーザは、ブラウザをもつキオスクに近づく
【０２６８】
[00338]（２）ユーザがキオスクとの対話を開始する前または開始すると、ワイヤレス通信が、「Ｍａｒｙ、Ｋｉｏｓｋ＃３との購入のための支払い情報の通信を許可してください」などの事前許可オブジェクトがモバイルデバイス上で（またはキオスク上で）提示されるように、モバイルデバイスとキオスクとの間で確立される。オブジェクトとの単純な許可対話、指紋、コード、顔認識、または他の任意の手法を通して、許可が提供される。
【０２６９】
[00339]（３）一態様では、支払い情報（クレジットカード、住所、有効期限、名前など）が、適切なメモリに情報がポピュレートされるように、キオスクブラウザに通信される。ワンタイム支払いトークンも、モバイルデバイスからキオスクに送信されることがある。
【０２７０】
[00340]（４）Ｍａｒｙは、キオスクを使用して、製品をブラウジングし、決定を行い、最終的に「買う」オブジェクトと対話する。
【０２７１】
[00341]（５）販売業者サイトは、対話を受信し、ブラウザＡＰＩを通してキオスクブラウザへの支払い要求を開始し、Ｍａｒｙは、標準的な手段で購入を確認するためにキオスクブラウザと対話する。
【０２７２】
[00342]（６）キオスクブラウザは、最終的な確認に続いて、そのメモリからＭａｒｙの支払い情報を削除し、削除を確認することができる。
【０２７３】
[00343]（３ａ）別の態様では、支払い情報は、Ｍａｒｙのモバイルデバイス上で維持される。
【０２７４】
[00344]（４ａ）Ｍａｒｙは、キオスクを使用して、製品をブラウジングし、決定を行い、最終的に「買う」オブジェクトと対話する。
【０２７５】
[00345]（５ａ）販売業者サイトは、対話を受信し、ブラウザＡＰＩを通してキオスクブラウザへの支払い要求を開始する。
【０２７６】
[00346]（６ａ）キオスクブラウザは、モバイルブラウザから支払い情報を受信するために、モバイルブラウザと通信する。支払い情報は、キオスクブラウザによって受信されＡＰＩを通して販売業者サイトに渡されるワンタイム使用トークンとすることができる。キオスクブラウザは、ユーザのモバイルブラウザがラップトップ上で示されたように機能し、Ａｐｐｌｅ  Ｐａｙ支払いを確認するためにユーザのｉＰｈｏｎｅと通信することがある。
【０２７７】
[00347]（７ａ）Ｍａｒｙは、標準的な手段で購入を確認するために、キオスクブラウザと対話する。
【０２７８】
[00348]必要なデータ、通信、要求および応答、ならびに確認はすべて、可能な限り少ない対話で支払い情報とのユーザのモバイルデバイスのリンクを可能にするためにさまざまなデバイスとキオスクデバイスとの間で発生することができ、したがって、ユーザは、自身のモバイルデバイス、デスクトップデバイス、タブレット、またはラップトップデバイス上でブラウザを使用するような様式でキオスクブラウザを使用することが可能にされる。最終的な目的は、キオスクを介して、または購入プロセスを管理するためにブラウザＡＰＩを使用するが、特定のユーザを記憶しないまたはこれについて知らない任意のデバイスを用いて、同じ快適な購入経験をユーザに与えることである。
【０２７９】
ピアツーピアブラウザＡＰＩアプリケーション
[00349]別の態様では、ブラウザＡＰＩは、ピアツーピア支払いに利用される場合がある。このシナリオでは、「販売業者」サイトは、単に、支払いデータの要求を開始するピアサイトである場合がある。各ユーザがたとえばモバイルデバイスまたは任意の種類のデバイスを有するピアツーピアシナリオでは、各デバイスが、ブラウザＡＰＩを通してデータを通信するように構成されたブラウザを有することが仮定される。サービスは、販売業者が一般的に本明細書において開示されるように動作する特定の機能を実行するように動作する場合がある。たとえば、第１のデバイスが、コンテキストピアツーピアコンテキストにおいてアプリケーションを介して第２のデバイスと通信する間、第１のピアが第２のピアに２０ドルを送信するための命令が行われる場合、サービスは、第１のピアとのブラウザＡＰＩを通しての必要な支払い要求ならびに第２のピアとのブラウザＡＰＩを通しての支払い要求を生成する場合がある。このシナリオでは、ブラウザＡＰＩは、第２のピアが支払いを行っておらず、支払いを受信しているように修正される。この点に関して、ブラウザＡＰＩは、金銭がそのアカウントに支払われ得るように、第２のピアのためのアカウントデータを取り出すように修正される。これは、一般に同じ手段で処理され得る返金のために発生する類似のプロセスである。この手法は、ユーザへの返金にも使用可能である。たとえば、ユーザは、ブラウザＡＰＩを介して、トークン化された支払いデータパケットを受信する場合がある。ブラウザＡＰＩを通して受信すると、デバイスは、そのトークンを、アカウントへの返金を受信するために支払い処理システムに通信することができる。
【０２８０】
[00350]したがって、ピアツーピアコンテキストでは、方法は、第１のピアと第２のピアとの間のピアツーピア通信を可能にすることと、金銭などの利益を第１のピアから第２のピアに転送したいという要望の標識を受信することとを含むことができるが、利益は、ポイント、メディア、または価値のある任意の品物であってよい。方法は、支払いを達成するために支払いデータおよび／または他のデータを取り出すのに必要な情報とともに、本明細書において開示されるように、ブラウザＡＰＩを通して第１のピアへの第１の支払い要求を開始することを含む。サービス。料金、第１のピアの支払いアカウント。クレジット要求は、ブラウザＡＰＩを通して第２のピアにサブミットされ得る。本明細書において開示される支払い要求ＡＰＩと同様に、情報の交換は、サービスがクレジットとクレジットを受信するために第２のピアによって利用可能なアカウントタイプを提供するために利用可能である、利用可能な支払い手法を調和させ得る。次いで、サービスは、ブラウザＡＰＩを介して受信されたデータに基づいて第１のピアから額を請求し、第２のピアから受信されたアカウントデータに基づいて第２のピアのクレジットアカウントを提供し得る。一態様では、クレジット受信トークンであるので支払いトークンとは異なるように構成されるワンタイム使用トークンを提供するための第２のピア。サービスは、第２のピアからの支払い受信トークンを利用し、支払いデータを一度も実際に閲覧することなく第２のピアのアカウントにワンタイム支払いを提供し得る。暗号通貨、または他の支払い手法は、本当に、適切なキーまたはトークンまたは支払いデータがそれぞれのＡＰＩを介して交換され、異なるデバイス上のブラウザ間で管理され得るように、サービスに介入することのないピアツーピアである場合もある。さらに、ピアツーピア通信における売り手が支払いならびに品物を配達するための配達情報を受信することができるように、製品の購入者のブラウザＡＰＩを介して住所情報も通信可能である場合、製品のピアツーピア購入および配達も、同様に提供される場合がある。ピアツーピアコンテキストにおいて通信されることが望ましい他の任意のデータまたは情報は、通信、販売、送金などへのピアツーピアが可能にされるように修正されたブラウザＡＰＩにおいて実施され得る。別の態様では、ＡＰＩは、サービスにおいて支払いを受信するために使用可能であり、受信者デビットカードは、ピアツーピア受信者への支払いを信用するために使用される場合がある。
【０２８１】
登録目的でのＡＰＩの利用
[00351]ブラウザまたは他のエージェント（ａｍａｚｏｎ．ｃｏｍなど）は、住所、名前、クレジットカードなどを記憶することができる。支払いに使用される以外に、ＡＰＩは、他の目的で他の任意のサイトから呼び出される場合もある。たとえば、ユーザが会議のために登録している場合、登録ウェブサイトは、単にユーザ名および電子メールアドレスを求める、またはどのような情報の組み合わせが登録に必要とされても、エージェント（ブラウザ、サービス、ａｍａｚｏｎ．ｃｏｍ、または情報を記憶し、ＡＰＩを介して対話する他の任意のエンティティ）に対するＡＰＩ要求を生成する。１つまたは複数の情報を要求する任意のサイト上の任意の入力フィールドは、その情報のためにＡＰＩを通して要求をサブミットする場合がある。通常の支払い要求ＡＰＩは、そのサイトに対してどの支払いタイプが承認されるか（ＶＩＳＡ、Ｍａｓｔｅｒｃａｒｄなど）のような情報を含むが、ＡＰＩは、名前のみ、または名前および住所、または名前および電子メールアドレスなどを単純に求めるように修正されてよい。
【０２８２】
[00352]したがって、ブラウザへのＡＰＩ呼び出しはデータを埋めるために行われ得るので、ＡＰＩの使用を拡張することによって、個別の情報すら要求する任意の入力フィールドを有する任意のウェブサイトまたはアプリケーションを利用する人は、その情報を手動で入力する必要がないことがある。したがって、支払いプロセスを超えたまたはこれとは完全に無関係な使用は、情報フィールドＡＰＩを利用して情報を満たし得る。この点に関して、ブラウザは、支払いデータまたは支払い関連データ、好み、食物制限、部屋の要件、ロケーションベースの情報、誕生日、または任意のサイトの入力フィールドに有用であり得る任意の情報などの他の情報を超えて記憶する場合もある。任意のそのような情報は、ブラウザＡＰＩを通して受信可能である。これは、たとえば、会議のために登録するまたはウェブサイトもしくはコンテンツへのアクセスを取得するために電子メールアドレスを提供する、ホテルの部屋を予約する、クラスを登録する、ホワイトペーパーを要求することなどを行う人々に、ウェブにわたって標準化されたプロセスを提供することもできる。
【０２８３】
支払いデータを交換するためにオブジェクトを利用した販売業者およびブラウザ対話
[00353]別の態様では、本開示は、図１７Ｃに示すように、ブラウザが、ユーザインターフェースを介して、ユーザによる、サイトに関連づけられたオブジェクトとの対話を受信する（１７２０）ことであって、その対話は、購入を行うためのユーザ意図を示す、受信する（１７２０）ことと、対話に基づいて、アプリケーションプログラミングインターフェースを介して、購入に関連して支払いデータのための要求をサイトから受信する（１７２２）ことと、アプリケーションプログラミングインターフェースを介して、サイトに支払いデータを送信する（１７２４）ことであって、支払いデータは、支払いを処理するまたは購入に関連づけられた製品を配達するために使用可能である、送信する（１７２４）こととを包含する。
【０２８４】
[00354]プロセスは、より詳細には、次のように実行可能である。ユーザがオブジェクトと対話した後、サイトは、ブラウザとサイトとの間のブラウザ支払い要求ＡＰＩを介した支払い要求のために、ＪａｖａＳｃｒｉｐｔ  ＡＰＩ呼び出しを行うことができる。ＡＰＩ要求は、サイトの許容できる形式の支払い（Ｖｉｓａ、Ｍａｓｔｅｒｃａｒｄ、ビットコインなど）、請求される額、どの通貨が予想されるか、購入のコンテキストに応じた他のデータなどのデータを含むことができる。ＡＰＩ要求は、総額、通貨、どのくらいの額が計算されるか、税金、割り引き、発送コストなどのトランザクションについての詳細も含むことができる。次いで、ブラウザは、記憶されたクレジットカード情報、ユーザのためのアルトコインウォレット、Ａｐｐｌｅ  Ｐａｙ、Ａｎｄｒｏｉｄ  Ｐａｙ、ＰａｙＰａｌ、または他の任意のタイプの支払いサービスへのアクセスを通して、許容できる支払いと利用可能な支払いとの間の合致を決定することができる。システムは、現在の情報と、発送先住所、適切なデータを追加する、またはトランザクションに対する必要なデータのいずれかを変更する機会をユーザに提示する。システムは、変更されたデータを受信および更新する。オプションがユーザに提示される場合、ユーザは、トランザクションを処理するためにどの支払いオプションを使用するべきかを選択することができる。
【０２８５】
[00355]次に、ユーザは、ユーザが使用している支払いアカウントのタイプに応じてトランザクションを許可することができる。発送先住所は、発送が請求する総額に含むように交換または使用されてよい。インターフェースは、支払い方法、支払い額、発送先住所などのうちの１つまたは複数を確認するために、ユーザに提示可能である。支払い方法は、下４桁が確認のために提示されることがある記憶されたクレジットカードによるものであってよい。それが使用される場合、クレジットカード情報（カード番号、有効期限、名前、ＣＶＣ）が、サイトの支払いプロセスシステムを使用した処理のために、ＡＰＩを通してサイトに送信される。これは、暗号化された送信、または生成されたワンタイム使用トークンなどの、セキュリティを維持するための何らかのセキュアな機構とすることができる。ローカルな支払いが、たとえばＧｏｏｇｌｅ  Ｗａｌｌｅｔ、Ａｎｄｒｏｉｄ  Ｐａｙ、またはＡｐｐｌｅ  Ｐａｙタイプのサービスを通して選定される場合、選定されたサービスは、支払いを処理することができ、ＡＰＩを通した報告がサイトに提供可能である。電子メールアドレス、住所、支払人の電話、ソーシャルメディアデータ、ソーシャルメディア内の連絡先などの、ユーザについての他の情報は、販売業者にも送出可能である。次いで、販売業者は、買い手との関係を継続することができる。
【０２８６】
[00356]販売業者観点から、方法は、一般に、次のように、図１７Ｄに示されるように進むことができる。方法は、サイト（販売業者）とブラウザとの間でデータを通信する（１７３０）ことを含む。方法は、ブラウザのユーザインターフェースを介して提示するために、ユーザが対話することができるオブジェクトを送信する（１７３２）ことと、ユーザによる、サイトに関連づけられたオブジェクトとの対話を受信する（１７３４）ことであって、この対話は、購入を行うためのユーザ意図を示す、受信する（１７３４）ことと、対話に基づいて、サイトとブラウザとの間のアプリケーションプログラミングインターフェースを介して、購入に関連した支払いデータの要求をサイトから送信する（１７３６）ことと、サイトにおいて、アプリケーションプログラミングインターフェースを介して、支払いデータを受信する（１７３８）ことであって、支払いデータは、支払いを確認する、または製品の支払いを処理するもしくは購入に関連づけられた製品を配達するために使用可能である、受信する（１７３８）こととを含む。上記で述べられたように、支払い処理は、どのサービスをユーザがサインアップしたのかまたはユーザの好みに応じて、ＡＰＩのどちらの側でも発生することができる。サイトが製品の支払いを処理するとき、支払いデータは、ワンタイム使用トークンなどのユーザ支払いアカウントデータを少なくとも含むことができる。方法は、サイトが、アプリケーションプログラミングインターフェースを介してブラウザから受信された支払いアカウントデータに基づいて製品の支払いを処理することをさらに含むことができる。支払いサービスが製品の支払いを処理するとき、支払いデータは、サイトがユーザに製品を配達することができるように、支払いサービスによって製品の支払いが発生したという確認を含むことができる。あるいは、アルトコイン手法が選択される場合、ＡＰＩプロトコルは、暗号化されたやり方で、情報または個人的なキー、住所、量、通貨とアルトコイン値との間の変換データ、およびアルトコインウォレットまたは支払いサービスが販売業者サイトに対するアルトコイン支払いを行うことを可能にし、支払いの成功を報告するために必要な他の任意のデータを交換するための特徴を含むことができる。この点に関して、ＡＰＩプロトコルは、ユーザが、ＡＰＩのブラウザ側で（ブラウザもしくはブラウザに関連づけられたもしくはブラウザと通信する支払いサービス、またはアルトコインシステムを通して）またはＡＰＩの販売業者側で、Ｖｉｓａ、Ｍａｓｔｅｒｃａｒｄ、デビットカード、ＰａｙＰａｌなどのような支払いシステムのための販売業者の標準的な支払い処理構造を通して、発生する支払いを含むさまざまな支払いの方法を選択することができるように構造化される。したがって、１つのユーザインターフェースでは、ユーザが購入を行うことに近づいているとき、ユーザは、「Ｖｉｓａ＊＊＊＊＊＊＊＊１２３４」または「Ａｎｄｒｏｉｄ−Ｐａｙ」などの支払いオプションを見ることができる。Ｖｉｓａ支払い方法を選定することは、販売業者とブラウザとの間のバックエンド処理に、Ｖｉｓａ支払い情報、アカウント番号、セキュリティコード、ユーザ名、��所などを販売業者サイトに送信させ、そのため、販売業者は、支払いを処理することができる。Ａｎｄｒｏｉｄ  Ｐａｙを選定することは、購入量、税金、発送、および／またはＡｎｄｒｏｉｄ  Ｐａｙサービスが、販売業者が製品を配達することができるように、支払いを処理し、完了された支払いの確認を戻すように報告することができるようにＡＰＩを通して送信されることになる他の任意の必要なデータという結果になる。
【０２８７】
[00357]上記の手法は、ドロップダウンメニューまたはドロップアップメニューにも適用可能である。適切なＡＰＩを用いると、ドロップダウン／アップメニューオプションから購入を行う効率が増加可能である。たとえば、帽子のサイズ、靴のサイズ、シャツのサイズ、ズボンのサイズなどのユーザの情報が記憶可能である。色、スタイルなどに関するユーザの好みは記憶可能であり、そのような情報はまた、ソーシャルメディアサイトまたは連絡先情報を介してアクセス可能である。このデータは、ドロップダウンメニュー内でリストするために、オートコンプリートを助けるまたは製品を選択するために使用可能である。そのような情報は、そのようなユーザデータを通して埋め込み可能なパラメータをもつ製品を販売する販売業者と、ブラウザＡＰＩを介して通信可能である。ユーザが「緑色の野球帽」をタイプし始めた場合、ドロップダウンメニュー項目は、「緑色の野球帽７  ８／５インチ、Ｖｉｓａで今すぐ買う、１１ドル、火曜日にＷａｌｍａｒｔによって配達される」と述べることができる。ユーザが単語をタイプすると、販売業者サイトにおける製品データベースに対する相関は、販売業者が製品情報を交換することまたは支払い要求ＡＰＩを通して支払い要求の要求を行うことに至ることができる。ユーザの住所は、ドロップダウン／アップメニューが、料金、支払いオプション、配達情報、製品の説明、サイズ情報、色またはスタイルなどに関する個人的なユーザの好みのうちの１つまたは複数を含むことができるように、発送コスト、税金などを迅速に決定するために利用可能である。ユーザは単に、そのオプションを、（販売業者の能力、ユーザ支払いアカウントなどに応じて、ＡＰＩのどちらの側でも）支払いを行い、製品を配達させるためにクリックする。２つ以上の支払いオプションが利用可能である（Ｖｉｓａ、Ａｎｄｒｏｉｄ  Ｐａｙ、ビットコイン）である場合、ドロップダウンメニュー内の項目は、おそらく、おそらく左から右に行くように選ぶために複数のサブオプションを有することができる。これは、ユーザがドロップダウンして行を選択し、次いでカーソルがＡｎｄｒｏｉｄ  Ｐａｙオプションの上にくるまで右または左にスライドし得る、より動的なドロップダウン／アップメニューである。カーソルを放すと、システムに、引き続きＡＰＩを介して情報を交換させ、Ａｎｄｒｏｉｄ  Ｐａｙオプションを通して支払いを処理させ、その支払いを販売業者に報告させ得る。メニューオプションは、ピックアップロケーション（Ｄｕｎｋｉｒｋ内のＷａｌｍａｒｔにおけるピックアップのため）などの、製品のための任意の数の異なる情報を報告し得る。現在のドロップダウンメニューは、Ａｍａｚｏｎ．ｃｏｍまたはＹａｈｏｏ．ｃｏｍ上で品物を検索することに似た何らかのオプションを提供するが、ブラウザと販売業者サイトとの間でのブラウザＡＰＩの使用を通してドロップダウン／アップ選択肢を調節することによって達成可能である購入の簡単さは提供しない。ユーザがインターフェースすることができるオブジェクトは、単にドロップダウンメニュー上のみならず、ユーザインターフェース上の任意のロケーションにおいて提示可能である。
【０２８８】
[00358]この手法の別の利益は、ユーザが製品情報を検索フィールドへとタイプしているとき、ユーザは、ドロップダウン／アップ結果を閲覧し、ユーザが進む範囲を絞ることができる。たとえば、ユーザが「野球帽」をタイプする場合、ドロップダウン／アップ項目は、「Ｗ」ａｌｍａｒｔまたは「Ｃ」ｏｓｃｏから販売される「Ｇ」緑色の野球帽などの項目を含むことができる。ユーザは、ドロップダウンメニューからのヒントを利用して、それを緑色にしてＣｏｓｃｏからのものにし得る「野球帽Ｇ  Ｃ」を引き続きタイプする場合がある。おそらく、「１１ドルまたは２０ドル」という２つの価格が示される場合があり、ユーザは、引き続き「１１」を入力フィールドへとタイプする。タイピングおよびドロップダウン／アップメニュー項目からのフィードバックの動的な交換はまた、いくつかの異なるドロップダウン／アップメニュー項目のうちのどれとユーザが対話しているかを示し、検索およびユーザが何を探しているかに関する結果に引き続き焦点を合わせる場合がある。このプロセス全体を通じて、購入意図は可能性があり、支払いデータおよびオプションの交換が提示され、ユーザによって選定可能であることが、迅速に仮定可能である。たとえば、ドロップダウンメニュー項目は、「緑色の野球帽、１１ドル、「Ａ」ｎｄｒｏｉｄ  Ｐａｙ、「Ｖ」ｉｓａまたは「Ｂ」ビットコイン」を示すことがあり、ユーザは、支払い方法としてＶｉｓａの選択肢を示す「野球帽Ｇ  Ｃ  Ｖ」を引き続きタイプすることがある。写真は、写真をクリックし、最終的にユーザが品物、その色、サイズなど、支払い機構を選定し、支払いを確認することができるように、入力フィールドを通して情報を提供し続ける機会を含めて、このプロセスを通して動的に提示可能である。一例では、メニュー項目は、支払いオプション、サイズ、色、販売業者、配達住所などを選定するように、ユーザに項目内の異なるオブジェクトをクリックさせるために、現在のメニュー項目よりも動的である場合がある。ユーザが、どのドロップダウン／アップ項目をユーザが焦点を合わせることを望むかを絞り込むにつれて、プロセスが非常に迅速で単純になるように、購入を完了するためのより多くの情報が提供されてよい。メニュー項目は、短く単純で始まってよいが、ユーザがより多くタイプするまたはメニュー項目と対話するにつれて、ＡＰＩとの対話を通して動的なやり方で購入のための品物の迅速な確定に至り得る新しいデータまたはオブジェクトが提示され得る。たとえば、ユーザは、最初は、「ｉＰｈｏｎｅ  ８、Ｂｏｂのオーディオビデオから」を選定することがあるが、次いで、販売業者は、ＡＰＩを通してＶｉｓａおよびＡｎｄｒｏｉｄ  Ｐａｙを取り扱うことができることを通信することができる。ユーザが、利用可能であるこれらの支払いオプションも有する場合、メニュー項目は、（いずれにせよ、ユーザは既にキーボードのところでタイプしているので）選択肢を表すためにユーザが入力フィールド内で「ｖ」または「ａ」をクリックするまたはあるいはタイプし続け得る２つの選択可能なオブジェクトを追加することができる。システムは、品物、量、配達住所、支払いオプションなどを確認するために対話した後で、��ＰＩのどちらかの側で、本明細書において開示されるように支払いを管理し、配達を行うように販売業者に指示することができる。
【０２８９】
[00359]プロセスは、ブラウザＡＰＩを通して、支払いデータ、ワンクリックパラメータまたは設定、他の任意のデータの交換、ユーザによって選定される様式で支払いを処理することを可能にする。販売業者は、品物を配達する。本明細書において開示されるドロップダウン／アップメニュー概念は、ブラウザ支払い要求ＡＰＩとの異なる手段で機能するが、ユーザのためのより効率的な購入プロセスの類似の結果を達成する。本開示は、販売業者とのＡＰＩを通してプロセス全体を通じて対話するブラウザの側からの対話と、ブラウザとのＡＰＩを介して製品のデータベースを管理し、対話して情報、要求などを交換する販売業者サイトからの処理の両方を包含する。
【０２９０】
[00360]以下の検討は、購入プロセスを単純化するためにユーザのための支払いフィールドをポピュレートする目的で、ブラウザ、サイト、エージェント、または他の記憶ロケーションから販売業者サイトに支払い関係データを通信するためのＡＰＩまたは他のプロトコルの使用に引き続き関係する。一態様では、本開示は、次に、ＡＰＩを使用して検索エンジン、ソーシャルメディアサイト、または任意のサイトから販売業者サイトにユーザを遷移させることに関係する。別の態様では、販売業者サイトは、モバイルデバイス上では特に煩わしい、ユーザがデータフィールドを埋める必要性をなくすまたは減少させるように、支払い情報を自動的にポピュレートするために支払いデータを取得するためにＡＰＩを介してブラウザ／エージェント／エンティティと（どのようにユーザがサイトにナビゲートするかとは無関係に）対話することができる。
【０２９１】
[00361]一態様では、統一された入力フィールドに提供された入力を処理する分類器によって決定された意図に基づいてオンラインベンダーのウェブサイト内でショッピングカートを事前にポピュレートする、システム、方法、およびコンピュータ可読記憶デバイスが開示される。ユーザ意図は、任意の様式で分類または決定可能である。ユーザは、Ｃｈｒｏｍｅ、Ｆｉｒｅｆｏｘ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ、Ｓａｍｓｕｎｇ  Ｉｎｔｅｒｎｅｔ、Ｍｉｃｒｏｓｏｆｔ  Ｅｄｇｅ、Ｓａｆａｒｉ、またはＯｐｅｒａなどのブラウザに登録および／またはログイン可能であり、したがって、ユーザの購入クレジット／デビットカードもしくは他のアカウントおよび配達住所、ならびに／または他のデータがユーザプロファイル内に記憶される。次いで、ユーザが、登録されたウェブサイト上で見出されないことがある製品を有し得る宛先ウェブサイトを通して購入を行うことを要望する場合、ブラウザ（またはネットワーク内で処理するシステム）は、システムが、ユーザが登録していないショッピングカートベースモデルウェブサイトをユーザのための「ワンクリック」購入経験へと変換することができるように、ブラウザとウェブサイトとの間の（ＡＰＩを介して）交渉を取り扱うことができる。たとえば、システムは（Ｇｏｏｇｌｅ  Ｗａｌｌｅｔ、Ａｐｐｌｅ  Ｐａｙ、Ａｎｄｒｏｉｄ  Ｐａｙ、またはＰａｙＰａｌなどのようなサービスを通して）、配達を取り扱うために、品物の支払いを取り扱い、販売業者サイトと通信することができる。もちろん、このシナリオでは、プロセスは、検索エンジンからではなく、単にユーザが品物の購入を行う位置にいる販売業者サイト内の状態から、開始することができる。その状態では、販売業者サイトは、ブラウザ、エージェント、または検索エンティティとのＡＰＩを介して、必要な支払いフィールドをポピュレートするために支払いデータを取り出し、簡略化された購入経験をユーザとのインターフェースを介して提示するために通信し得る。ＡＰＩを通して販売業者サイトに通信される支払いデータ（アカウントデータ、配達データ、日付、配達オプション、好みなどのうちの１つまたは複数）を用いて、販売業者サイトは、通常の支払いシステムを使用してユーザの支払いアカウントから支払いを処理することができる。
【０２９２】
[00362]ブラウザ設定において、ブラウザがナビゲートし、名前、住所、クレジットカード情報などを自動的に入力するためにウェブサイトの購入、登録、またはショッピングカートプロセスにおいて入力を提供することを許可することなどの、適切な認可が適切であると仮定すると、システムは、ユーザが登録されていないウェブサイトにおいてユーザに代わって登録することすら含めて、ショッピングカートを自動的にポピュレートすることができる。これは、遷移においてアクセスされることを必要とするブラウザ内での設定に基づいて、ワンクリック購入状態において、たとえばソーシャルネットワーキングサイトから宛先販売業者サイトに遷移することの一部として発生することができる。ユーザは、特定のトースターモデルの購入を行いたいという要望としてシステムおよび分類器がカテゴリ化する「ａｃｍｅトースター４．５を買う」などの統一された入力フィールド内で入力を提供する。システムは、価格設定、発送、国などのさまざまな基準に基づいて、そのトースターモデルを提供する販売業者ウェブサイトを決定する。ユーザは、販売のためにトースターを提供する販売業者ウェブサイトにおいて、一度も登録または購入を行っていない。したがって、ユーザが、その販売業者ウェブサイトからトースターを買う場合、ユーザは、トースターを仮想ショッピングカート内に置き、次いで、品物を発送させるために住所、クレジット／デビットカード情報、ユーザ名、パスワードなどの個人情報を入力しなければならない。
【０２９３】
[00363]システムは、一態様では、統一された入力フィールドを介して提供される入力に基づいて販売業者サイトを識別することができる、または販売業者サイトに到達するために検索とは無関係に販売業者サイトから直接的にプロセスを開始することができる。次いで、システムは、通常ならユーザがショッピングカート内に品物を置くためにクリックするであろう販売業者ウェブサイト内の状態にナビゲートすることができる。しかしながら、このケースでは、システムは、品物がショッピングカート内に置かれ得る販売業者ウェブサイトにナビゲートし、ユーザがこの販売業者ウェブサイトに登録されていないと決定する。次いで、システムは、システムおよび／またはブラウザにとって利用可能なユーザデータを使用してユーザに代わって新しいアカウントを作成するために、新規ユーザ登録ページ、またはＡＰＩなどを介して、販売業者ウェブサイトと自動的に通信することができる。したがって、システムは、ワンクリックを介して購入するためにボタン内での確認をただユーザに提示することができる。確認は、新しいアカウントを作成する許可と次いで新しいアカウントを使用して発注する許可の二重確認とすることができる。ユーザは、新しい登録を自動的に許可することができ、新しいプロフィール登録を支配する設定または好みを確立することができる。次いで、システムは、登録を完了し、さらなるユーザ入力の必要なしに品物を購入および発送させるために、ブラウザまたは何らかの他のロケーションから取り出される必要なデータをすべて入力することができる。この手法は、統一された入力フィールドを通した入力を介して、非ワンクリック購入ウェブサイトをワンクリック購入ウェブサイトにすることができる。システムは、登録された支払い情報を使用して、支払いも処理し、注文を埋めるために販売業者サイトと協調することもできる。支払いおよび／または配達データを自動的に提供するためにＡＰＩを通して支払いデータを取得するプロセスは、ＡＰＩを通して販売業者サイトとブラウザとの間で単純に発生することもできる。販売業者サイトは、ユーザが購入を行うことがある適切な状態において、購入プロセスを単純化するためにブラウザまたはエージェントによって記憶されるように提供可能である支払いデータのために、ＡＰＩを通して要求をサブミットすることができる。データはまた、支払いアカウント情報を保護するためにトークン化されたプロセスを介して、ブラウザから販売業者サイトに提供可能である。ユーザが閲覧するインターフェースは、販売業者情報の組み合わせ（製品の写真、レビュー、他の日付）ならびにＡＰＩを介してグラフィカルインターフェースに提供される「今すぐ買う」または「ｇｏｏｇｌｅを通して買う」または「Ａｎｄｒｏｉｄ  Ｐａｙ」タイプのボタンとすることができる。
【０２９４】
[00364]一態様では、システムは、ユーザデバイス上で支払い要求ＡＰＩを使用するためにどのような情報が必要であっても記憶する。たとえば、ユーザがデビットカードまたはクレジットカードを支払い機構に追加するとき、アカウント情報が暗号化され、ネットワークサーバに送られる。次いで、サーバは、情報を検証するためにユーザバンクとリンクする。バンクは、サーバに戻すように送信されてユーザデバイス内のセキュアな要素の上に記憶される暗号化されたデバイスアカウント番号を作成することができる。このセキュアな要素は、デバイス上の短距離通信（ＮＦＣ）チップ内に埋め込まれ得る。この番号は、ユーザデバイスならびにそれに関連づけられたクレジットカードおよびデビットカード（または暗号通貨または他の形式の支払い）にとって完全に一意である。
【０２９５】
[00365]ユーザがブラウザＡＰＩを通して購入を行うとき、セキュアな要素（セキュリティチップである）は、一意のコードを作成し、それを、カード番号の代わりにデバイスアカウント番号とともに支払い端末に送る。カード情報は、一態様では、ユーザデバイス上またはサーバ内に記憶されず、クラウドプロバイダにバックアップされないことがある。一意のコードは、支払いを処理するためにブラウザＡＰＩを通して販売業者サイトに送信される。したがって、この態様によれば、ユーザデバイス上に記憶された情報は、具体的には、支払いアカウント番号でないことがあり、ユーザの支払いアカウント番号に関連づけられた特定のアカウント番号である。最終結果は、支払いのためにデバイスがアカウント番号を販売業者サイトに送信した場合と同じである。いくつかのサービスプロバイダでは、デバイスアカウント番号は、支払いに使用されるクレジットカードまたはデビットカードを識別するために使用される。
【０２９６】
[00366]図１７Ｅは、支払い要求ＡＰＩとともに使用するためのトークン化プロセス１７４０を示す。トークン化されたプロセスを使用するとき、販売業者１７４４は、ブラウザＡＰＩから受信されたトークンを処理することを可能にするために、いくつかの情報を必要とすることがある。販売業者は、支払いプロセスに関連づけられた販売業者を表す一意の識別子を必要とすることがある。販売業者は、支払いデータをセキュアに転送するために使用される支払い処理証明書を必要とすることがある。ネットワークサーバ１７５０は、支払い処理証明書公開鍵を使用して、支払いデータを暗号化することができる。販売業者は、支払いまたはトークン情報を処理するとき、秘密鍵を使用してデータを復号することがある。販売業者識別証明書またはトランスポート層セキュリティ証明書は、ネットワークサーバとの販売業者セッションを認証するために使用可能である。このプロセスは、次に、より詳細に示される。
【０２９７】
[00367]図１７Ｅに示されるように、販売業者またはアプリケーション１７４４は、ユーザがサイトを通してナビゲートするとき、ユーザまたは買い物をする人１７４２と対話する１７５４。ユーザが購入を行うことを決定すると、ユーザは、買うボタンをクリックし、開始する支払いプロセスを許可することがある。これは、支払いを許可する１７５６ために、指紋などのタッチＩＤも含むことができる。そのような能力は、Ｘｃｏｄｅ内で可能にされ得る。上記で述べられたように、販売業者１７４４は、一態様では、販売業者ＩＤを登録し、支払い処理証明書を作成しており、支払い処理証明書は、販売業者サーバに支払いデータをセキュアに送るために使用される暗号鍵である。買うボタンのクリックおよび支払いを処理するために指紋許可を提供することは、単一のステップを伴うことができる、または複数のステップを伴うことができる。
【０２９８】
[00368]支払いを開始するために、販売業者アプリケーションは、販売業者１７４４とブラウザ１７４６との間の支払い要求ＡＰＩにサブミットするために支払い要求を作成する。この要求は、購入されたサービスおよびグッズの小計、ならびに税金、発送、または割り引きのための追加の料金を含むことができる。販売業者は、この要求を支払い許可ビューコントローラに渡すことができ、支払い許可ビューコントローラは、ユーザに要求を表示し、発送先住所または請求先住所などの必要とされる情報を促す。委譲（delegate）は、ユーザがビューコントローラと対話するにつれて要求を更新するために呼び出され得る１７５４。これは、サイズ情報、色の好み、誕生日情報のようなソーシャルメディアデータ、または購入に関係することができる他の任意の情報の要求も含むことができる。
【０２９９】
[00369]ユーザが支払いを許可する１７５６とすぐに、支払い情報は、許可されていないサードパーティがそれにアクセスすることを防止するために暗号化可能である。一態様では、支払い要求は、ユーザのデバイス１７４６上の専用チップであるセキュアな要素（販売業者サイトにおける短距離通信をもつＡｐｐｌｅ  Ｐａｙを可能にするためにｉＰｈｏｎｅ上で使用されるセキュアな要素など）に送られ得る。セキュアな要素は、支払いデータを、指定されたカードおよび販売業者に追加し、暗号化された支払いトークンを作成する１７５８。次いで、セキュアな要素は、このトークンをネットワークサーバ１７５０に渡し１７６０、サーバは、販売業者支払い処理証明書を使用してトークンを再暗号化する１７６２。サーバ１７５０は、再暗号化されたトークンをユーザデバイス１７４６に戻すように送信する１７６２。再暗号化されたトークンは、販売業者サイト１７４４に送信されるように準備された第２のトークンを表す。ブラウザＡＰＩを通して、ユーザデバイス１７４６は、処理のために、暗号化されたトークンおよび／または支払いデータを販売業者サイトに戻すように送る１７６４。靴のサイズ、シャツのサイズ、ズボンのサイズ、色の好み、スタイルの好みなどの、要求された他のデータも、ＡＰＩを通してサイトに戻すように送信可能である。ＡＰＩへの複数の異なる呼び出しが、プロセス内の異なる段階で行われ得る。たとえば、支払い要求が行われる前のいくつかのステップ、販売業者サイトは、ユーザがシャツのサイズに関して「Ｘ」または「ＸＬ」または「Ｍ」をクリックする必要がないように、サイズ情報を望むことがある。そのうえ、人体に関する身体モデルが生成されている。ユーザのためのデータは、ブラウザにおける身体形状モデル内に記憶可能である、またはブラウザによってアクセス可能である。使用がオンラインで衣服を探している場合、身体モデルについてのデータが、ブラウザＡＰＩを介して取り出され、その個人のために衣服の提示を調整することができるサイトに送信されることがある。データは、ユーザがサイトと対話するとき、サイトが、あなたのためですか、ご姉妹のためですか、それとも奥様のためですかと言うことができ、衣服が適切な人に合わせて調節され得るように彼女らの身体モデルデータが送信されることがあるように、他人に関するデータも含むことがある。その場合、衣料品のビューは、その身体モデルのために修正されることがある。
【０３００】
[00370]次いで、販売業者サイト１７４４は、支払いプロセスの一部として、商業サーバ１７４８にデータを通信する、暗号化されたトークンおよび支払いデータとともにＲＥＳＴサービス（支払いを処理するために当業者によって知られている）または他の類似のサービスを呼び出す１７６６。サーバ１７４８は、注文するためにカートをサブミットし１７６８、支払いゲートウェイ１７５２に支払いを許可する１７７０。「ｏｋ」信号１７７２は、販売業者サイト１７４４に返品支払いステータスを通信する１７７４商業サーバ１７４８に戻すように送信される。支払いは、処理および確認されており、販売業者サイト１７４４に支払い用紙を却下させ１７７６、ユーザに注文確認を表示させる１７７８。
【０３０１】
[00371]一態様では、支払いトークンは、一度もアクセスされてもいないし、支払いデータおよびトークンを暗号化するために使用されるネットワークサーバ１７５０上に記憶されてもいない。サーバは、販売業者証明書を使用してトークンを単純に再暗号化する。このプロセスは、販売業者に、販売業者アプリケーションの一部として支払い処理証明書を分散させる必要なしに、支払い情報をセキュアに暗号化させる。
【０３０２】
[00372]多くのケースでは、販売業者サイトは、支払いを復号および処理するために、暗号化された支払いトークンをサードパーティ支払いソリューションプロバイダ１７４８に渡す。しかしながら、販売業者が既存の支払いインフラストラクチャを有する場合、販売業者は、自身のサーバ上で支払いを復号および処理することができる。支払い情報を読み、検証し、処理することは、ＳＨＡ−１ハッシュを計算すること、ＰＫＣＳ  ＃７署名を読み取り検査すること、および楕円曲線Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換を実行することなどの１つまたは複数の暗号化ステップを伴うことができる。上記の手法は、ブラウザ支払い要求ＡＰＩとともに使用するための例示的なトークン化プロセスを表すことが留意される。支払いトークンオブジェクトは、トランザクションＩＤ、金額、製品についてのデータ、支払いネットワークについての情報、暗号化された支払いデータを含むことができる署名およびヘッダなどの支払いトークンデータ、ならびに量、カード所有者名、ＣＶＶコード、有効期限、支払いアカウント番号、支払い処理データ、および住所、ユーザの他の好み、暗号通貨データなどのようなデータを含むことができる。もちろん、プロセスにセキュリティの層を追加することができる、トークン化のための他のプロセスも企図されている。
【０３０３】
[00373]別の態様では、ブラウザは、ラップトップコンピュータなどの第１のユーザデバイス上で動作可能であってよく、支払いデータは、モバイルデバイスまたは携帯電話などの第２のユーザデバイス上に記憶されてよい。第１のユーザデバイスおよび第２のユーザデバイスは、Ｂｌｕｅｔｏｏｔｈプロトコルなどのプロトコルを通してワイヤレスで通信することができる。いくつかのシナリオでは、第２のデバイスは指紋識別オプションを持っているが、第１のデバイスは指紋識別オプションをもたないことがある。このシナリオでは、ユーザが、第１のデバイスを介して、ブラウザ支払い要求アプリケーションプログラミングインターフェースを利用するように構成されたブラウザと対話する間、第１のデバイスは、支払いプロセスの一部として、ユーザがタッチ識別を介して支払いを許可することができるように、第２のデバイスとの通信を確立し、第２のデバイスは、支払いトークンを生成し、第２のデバイスから第１のデバイスに、および支払い処理のためにブラウザ支払い要求アプリケーションプログラミングインターフェースを通して販売業者サイトに渡される第２の支払いトークンを受信するためにネットワークサーバと通信するために利用可能である。他のシナリオでは、第１のデバイスは指紋認識機構を含み、したがって、単一のデバイスのみが、購入の許可を確認するために必要とされる。ブラウザは、サイトまたはアプリケーションを閲覧およびナビゲートするために使用される任意のユーザインターフェースとすることができる。ブラウザＡＰＩは、ＡＰＩを通して販売業者に支払いデータを戻すように渡すこととは別個に支払いプロセスが発生し得るように、製品、販売業者、暗号化された通信のための鍵、または他の任意の情報についてのデータのうちの１つまたは複数を受信することもある。たとえば、セキュリティ目的で、支払い情報は、ユーザのための支払いデータがサイトに提供されないように支払いを取り扱うことができる別個の支払いプロセッサに通信されることがある。しかしながら、販売業者は、依然として製品を配達しなければならず、そのため、ブラウザＡＰＩは、別個の支払いプロセッサに支払いを処理させるが、製品を配達するためにユーザ名および住所配達情報をサイトに渡すことがある。
【０３０４】
[00374]ブラウザまたはアプリケーション観点からの処理に関するさらに別の態様では、例示的な方法は、グラフィカルユーザインターフェース上で、プレゼンテーションを提示することであって、このプレゼンテーションはネットワーク上でサイトから受信される、提示することと、ユーザインターフェースを介してユーザから、プレゼンテーションとの対話を受信することと、ブラウザと販売業者サイトとの間のブラウザアプリケーションプログラミングインターフェースを介して、ユーザのための支払いアカウントデータのための要求をサイトから受信することと、アプリケーションプログラミングインターフェースを介してサイトに、支払いアカウントデータ、または他のデータを送信することであって、支払いアカウントデータは、サイト上での支払い処理のために支払いフィールドにポピュレートするために使用可能である、送信することとを含む。データは、支払いに１回使用可能であり、アカウント情報のプライバシーを維持するトークンとすることができる。支払いアカウントデータは単に、支払いを処理するために販売業者サイトによって使用されることがあり、そうでなければユーザ入力によって手動でポピュレートされるであろうフィールドに文字通りポピュレートされることがある。たとえば、支払いデータが、トークン化されたセキュアな様式で受信された場合、データは、事前に設定されたフォームフィールドを埋めるために文字通り使用されるのではなく、単に支払いを処理するために使用されることがある。プレゼンテーションは、購入のための製品およびサービスのうちの１つを含むことができる。方法は、サイトがユーザのための支払いアカウントデータを使用して品物またはサービスの支払いを処理することを含むことができる。グラフィカルユーザインターフェースは、ブラウザまたはアプリケーションに関連づけ可能である。一態様では、サイト（販売業者サイト）と、ユーザに関する支払いアカウントデータを記憶することができるブラウザとの間で、データを通信するＡＰＩ。この態様は、ユーザの支払い／配達データを記憶し、そのデータを、販売業者サイト上にいるユーザのためのワンクリック購入経験を作成するのに必要なフィールド（または同等のタイプのプロセス）にポピュレートするためにＡＰＩを介して販売業者サイトと通信するブラウザの観点からのプロセスを包含する。
【０３０５】
[00375]ＡＰＩは、購入のために衣服を提示する際に使用するために、身体タイプ、サイズ、または身体モデルをユーザに要求するためにも使用可能である。別の態様では、販売業者サイトは、サイトをナビゲートするために使用されているブラウザを通してブラウザＡＰＩが利用可能であるかどうかを決定することがある。そうである場合は、ブラウザＡＰＩ要求は継続することができ、そうでない場合は、サイトが、支払いおよび住所情報のための標準的な入力フィールド手法を続行する。
【０３０６】
[00376]方法は、ユーザからの確認に基づいて、サイトが、ＡＰＩを通して受信された支払いアカウントデータを利用して、ユーザがサイト上の支払いフィールドを埋めることを必要とすることなく品物またはサービスの購入を処理することを可能にするように構成された買うオプションを含むようにプレゼンテーションを更新することをさらに含むことができる。ブラウザまたはＡＰＩを介して通信する他のエージェントは、サイトのグラフィックと統合するために、「今すぐ支払う」タイプのボタンのためのグラフィックも提供することができる。支払いアカウントデータは、ユーザのための住所データ、支払いアカウント番号、有効期限、セキュリティコード、カード所有者名、およびユーザのための発送指示のうちの１つまたは複数をさらに含むことができる。
【０３０７】
[00377]ＡＰＩを通した要求は、サイトのためにサポートされる支払い方法、購入の総額値、購入のために表示され得る品物、発送オプション、支払い修飾子、ユーザの電子メールアドレスの要求、ユーザの電話番号の要求、および情報を更新する要求のうちの１つまたは複数をさらに含むことができる。ブラウザに類似したまたはこれとは別個のユーザエージェントは、アプリケーションプログラミングインターフェースとサイトとの間で支払いアカウントデータを通信することができる。
【０３０８】
[00378]別の態様では、方法は、サイトの観点からの概念を含む。このコンテキストにおける方法は、グラフィカルユーザインターフェース上で閲覧するために、プレゼンテーションを送信することであって、このプレゼンテーションは、ネットワーク上のサイトからグラフィカルユーザインターフェースを有するデバイスに送信される、送信することと、ネットワークを介してユーザから、プレゼンテーションとの対話を受信することと、ユーザの支払いアカウントデータの要求をアプリケーションプログラミングインターフェースに送信することとを含む。方法は、サイトにおいてアプリケーションプログラミングインターフェースを介して、支払いアカウントデータを受信することと、ポピュレートされた支払いデータフィールドをもたらすために、ユーザのための支払いアカウントデータを支払いプロセスに関連づけられた支払いデータフィールドにポピュレートすることとを含む。支払いデータは、ユーザのアカウント情報を明らかにしないセキュアな手段で支払いを処理するためにトークン化されたフォーマットであってもよい。部分的なアカウント情報（すなわち、アカウント番号の下４桁）が、どのアカウントを使用するべきかを確認するために、ユーザインターフェース上での提示のために送信されることがある。サイトは、ユーザのための支払いアカウントデータを使用して品物またはサービスの支払いを処理することができる。ＡＰＩは、ブラウザとサイトとの間でデータを協調させることができ、ブラウザは、ユーザのための支払いアカウントデータを記憶する。プレゼンテーションに関連づけられた品物またはサービスの購入を行うためにユーザから確認を受信すると、方法は、ポピュレートされた支払いデータフィールドを使用して製品の支払いを処理することを含むことができる。
【０３０９】
[00379]方法は、支払いアカウントデータを受信すると、ユーザからの確認に基づいて、サイトが支払いアカウントデータを利用して、ユーザがサイト上の支払いデータフィールドを手動で埋める必要なしに製品またはサービスの購入を処理することを可能にするように構成された買うオプションを含むようにプレゼンテーションを更新することをさらに含むことができる。支払いアカウントデータは、ユーザのための住所データ、支払いアカウント番号、有効期限、セキュリティコード、カード所有者名、およびユーザのための発送指示のうちの１つまたは複数をさらに含むことができる。要求は、サイトのためにサポートされる支払い方法、購入の総量値、購入のために表示され得る品物、発送オプション、支払い修飾子、ユーザの電子メールアドレスの要求、ユーザの電話番号の要求、および情報を更新する要求、のうちの１つまたは複数をさらに含むことができる。ユーザエージェントも、アプリケーションプログラミングインターフェースとサイトとの間で支払いアカウントデータを通信することができる。別の態様では、方法は、グラフィカルユーザインターフェース上で、プレゼンテーションを提示することであって、このプレゼンテーションは、ネットワーク上でサイトから受信される、提示することと、ユーザインターフェースを介してユーザから、プレゼンテーションとの対話を受信することと、アプリケーションプログラミングインターフェースを介して、ユーザのための支払いアカウントデータの要求をサイトから受信することと、プレゼンテーションに関連づけられた支払いフィールドに支払いアカウントデータを自動でポピュレートすること（または、支払い処理のために必要に応じて単にデータを使用すること）と、アプリケーションプログラミングインターフェースを介してサイトに支払いアカウントデータを送信することであって、サイトは、ユーザのための支払いアカウントデータに基づいて支払いを処理することができる、送信することとを含む。方法は、支払いフィールドが自動でポピュレートされた後にユーザからの購入の確認を受信することも含むことができる。
【０３１０】
[00380]システムは、ブラウザ内のバックグラウンドタブまたは新規ウィンドウ内などで、新規登録ページを静かに処理することができる、または登録ページを全くユーザに提示することなく新規登録プロセスについて販売業者ウェブサイトと交渉することができる。システムは、統一された入力フィールドを介して入力を提供した後でｅｎｔｅｒを押すことなどによって、ユーザが購入を要求した後、統一された入力フィールドを含む同じページ上で進捗バーを提示することができる。進捗バーは、新規アカウントを作成すること、発送先データを入力すること、販売業者ウェブサイトのカートに品物を追加する、および発注することの進捗をユーザに示すことができる。
【０３１１】
[00381]ユーザは、個人情報が新規登録に使用されるデフォルトの好みを確立することができる。ユーザは、販売業者ウェブサイトに遭遇することに先立って、または統一された入力フィールドに遭遇することにすら先立って、これらのデフォルトの好みを確立することができる。あるいは、登録が必要とされる第１のインスタンスにおいて、システムは、そのような設定を確立するおよび／または追加の情報を提供するようにユーザに促すことができる。
【０３１２】
[00382]システムは、ユーザが既にアカウントをもっているまたはユーザが既に登録されている販売業者ウェブサイトを好むことができる。たとえば、販売業者Ｘと販売業者Ｙの両方が、販売のために同じ品物を提供する場合、システムは、ユーザが既にアカウントをもっている、これらの２つの販売業者のうちの１つを使用することを選定することができる。システムは、これを、ブラウザ履歴、ブラウザに利用可能なプロフィールデータ、ブラウザタイプ、またはブラウザによってもしくはユーザに関連づけられた他のブラウザによって記憶されたクッキーを調べることによって、決定することができる。システムは、発送時間の違いまたは価格の差などに基づいて、ユーザが登録されていない販売業者をいつ使用するべきかをインテリジェントに決定することができる。たとえば、ユーザが登録されていない販売業者が、ユーザが登録されている販売業者よりも少なくとも２５％低い価格で所望の品物を提供した場合、システムは、新規アカウントを作成することができる。ユーザが、システムに、自分に代わってユーザアカウントを作成させることを要望しない場合、ユーザは、自分がアカウントを既に持っているところで、またはゲストアカウントを可能にする販売業者ウェブサイトで、購入を行うようにシステムに指示することができる。
【０３１３】
[00383]しかしながら、システムは、分類器およびユーザプロファイルデータを使用して、ユーザが選択する可能性が最も高い販売業者を識別し、一義化のために、それらの販売業者をユーザに提示することができる。システムは、ＪａｖａＳｃｒｉｐｔポップアップなどによって、販売業者、発送時間、ならびに発送および税金を含む総価格を示す表をユーザに提示することができる。ユーザは、表から所望の販売業者を単にクリックすることができ、システムは、必要な場合はその販売業者にユーザを自動的に登録し、その販売業者に関する注文を処理することができる。ユーザは、販売業者を識別するためにワンクリックを行うだけでよく、システムは、ステップの残りを取り扱い、それによって、統一された入力フィールドを介して非ワンクリックウェブサイトへとワンクリックインターフェースを提供する。
【０３１４】
[00384]図１７Ｆは、支払いデータを通信するためにブラウザＡＰＩを使用する別の態様１７８２を示す。ユーザがウェブサイトを通してナビゲートし、精算プロセスを開始した１７８７後、ウェブページは、一般的にはユーザが「買う」ボタンをクリックしたときに開始される支払い要求を作成するべきである。この支払い要求は、方法データと、詳細と、オプションとを含むことができる。方法データは、支払い方法識別子を含む、必要とされる支払い方法データと、必要とされるトランザクション情報と、返されるべき発送先情報または連絡先情報などの任意選択の情報とを含むことができる。一態様では、支払い額は負であることがあり、支払い要求ＡＰＩは、返品または割り引きを処理するために使用可能であることがある。もちろん、この態様では、金銭は、販売業者サイトから、ブラウザＡＰＩを通って、ユーザのデジタルウォレットまたは支払いアカウントに流れる。この態様ではまた、ユーザが、ブラウザからまたはサイトから支払い要求を開始する場合、プロセスは本質的に、逆転されることがあり、発送先情報、割り引き、必要な他の任意のデータが、返金が処理されることを可能にするために利用可能である場合、このプロセスの任意の態様は、本質的に逆転されることがある。トークンは、返品またはピアツーピア支払いを処理するためのアカウント情報およびデータとともに、ブラウザ側または販売業者側のどちらかで使用および生成されることがある。返品発送情報、特別料金、またはユーザが品物を返し、返金を受け取ることを可能にするために必要な他の任意のデータは、ユーザが販売業者サイトにおいて購入を行うときに発生するのと同様に、ブラウザＡＰＩを通して交換可能である。
【０３１５】
[00385]図１７Ｆを続けると、支払い要求１７８８は、支払いを処理するためのインターフェースとして使用するためのダイアログ１７８９を示す、「示す」機能を開始することができる。Ｍｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔウォレットなどのユーザのウォレット１７８６、暗号ウォレット、ブラウザまたは他のロケーションに記憶された支払い情報などは、ユーザインターフェースの一部としてブランディングまたは利用可能である。この例では、ユーザは、インターフェースを通して発送先住所１７９１を選定する。図１７Ｇは、ユーザの名前、発送先住所、発送オプション、および受け取り用電子メールアドレスなどの情報をもつインターフェース１７８１を示す。発送先情報は、ウォレット１７８６からブラウザ１７８５に返され、次いで、ウェブページ１７８４に渡され、したがって、ウェブページは、ウェブサーバ１７８３に発送コスト１７９３を要求することができ、ウェブサーバ１７８３は販売業者１７８４に発送コストを返し、次いで、販売業者１７８４は、ブラウザ１７８５およびウォレット１７８６に渡される価格１７９４を更新することができる。支払い応答１７９５は、ブラウザ１７８５に対してウォレットのために生成され、ブラウザ１７８５は、ブラウザＡＰＩを通して、購入を行う１７９６販売業者１７８４に支払い応答を渡す。成功または失敗信号１７９７が販売業者に提供され、次いで、販売業者は、ブラウザ１７８５に知らせることによってプロセスを完了する１７９８ことができ、その時点で、購入は完了される１７９９。図１７Ｆは、トークン化プロセスについて具体的に言及していないが、さまざまな暗号化技術も、ブラウザＡＰＩを通して渡される支払い要求または支払い応答が、支払い、支払いの配信、およびユーザ情報の更新などのうちの１つまたは複数を処理するために必要とされるさまざまな情報を暗号化するワンタイム使用トークンであり得るように、データを暗号化するまたはデータをトークン化するために使用可能である。
【０３１６】
[00386]図１７Ｈは、それにとって一意であるいくつかの特徴を有するインターフェース１７７１を示す。１つの一意の特徴は、タッチセンシティブスクリーン１７７９内に買うボタンがないことである。指紋ＩＤを用いてセキュアな購入経験を提供する標準的な手段は、購入を完了するためにいくつかの対話を必要とすることである。第１の対話は、ユーザインターフェース１７７９上の買うボタンをクリックし、続いて指紋確認を介してユーザＩＤをクリックすることである。これは２回のクリックを伴うので、指紋ＩＤを含むシステムのために認証された機構は、以下のものであってよい。ユーザが、購入が行われ得る状態に近づきつつあるようにサイトを通してナビゲートしている間、サイトは、ブラウザ支払い要求インターフェースを通して、購入に関連づけられた予備情報の要求を提供することができる。予備情報は、買い手の町または都市ならびに買い手の名前を含むことがある。予備情報は、支払いアカウント情報を含むことがある。いくつかの情報が、プライバシーを維持するために、一部は暗号化または配信されることがある。１つのシナリオでは、適切なユーザが識別されたことを確認するのに十分な情報ならびに適切な町をユーザに提供するために、十分な量の情報が通信される１７７３。発送のタイプも表示可能である１７７３。予備情報の通信とともに、ユーザが買うボタンをクリックする前に、請求される総額が計算され、ユーザに提示可能である。ブラウザ支払い要求ＡＰＩは、ブラウザまたはユーザインターフェースを介して、ユーザインターフェースの状態に到達するために必要とされる基本データを受信するために適切な通信チャネルである。ブラウザが情報のためのブラウザＡＰＩに対して支払い要求呼び出しをいつサブミットするかのためのトリガは、サイト上でのナビゲーションの状態であることがある。したがって、ユーザが買うボタンをクリックしたことに基づいて支払い要求をトリガするよりもむしろ、サイトは、ユーザがショッピングカート内に品物を置いたことを認識することがあり、ユーザが、ショッピングカート、どの対話が買う対話の前に発生するであろうかを明らかにする機能ボタンをクリックしたとき、システムは、買うボタンがインターフェース上で押されることを必要としないように、支払い要求をサブミットすることがある。以下のパラメータのうちの１つまたは複数は、支払い要求または潜在的な購入に関連づけられた１つもしくは複数の情報のためのブラウザＡＰＩへの呼び出しをいつ開始するべきかを決定するために分析に含まれてよい。機械学習ツールまたはユーザ習慣についての情報、ユーザの以前の対話およびユーザの買う習慣の分析、ウェブサイトの構成、時刻、潜在的に購入され得る製品のタイプ、友人および家族の誕生日などのソーシャルメディア情報、ユーザがサイトをナビゲートしているところのロケーション、デスクトップ、ラップトップ、または携帯電話などのユーザが使用しているデバイスのタイプなど。このデータのうちのいずれか１つまたは複数は、ユーザが買うボタンをクリックしたこととは別個の、ブラウザＡＰＩへの呼び出しをいつ開始するべきかを決定するために分析され得る。述べられたように、ユーザが買うボ��ンをクリックしたことではなくナビゲーションの状態に基づいて呼び出しを開始することによって、対話は、購入を行うためであるように除去可能である。ユーザは、少なくとも、買うボタンをクリックすることと、指紋読み取り装置を押すことの一方を行う必要はない。
【０３１７】
[00387]インターフェース１７７９内には、提示された情報をユーザが変更するためのオプションも示されている。一般的には、ユーザは、一番遅い（ground）発送を選定することなどの、ユーザが何度も使用する特定のパターンを有する。したがって、多くのシナリオでは、ユーザが指紋を用いて今すぐ買う１７７５ことができることを示す、ユーザインターフェース内で提供される情報は、ユーザが、単一のタッチが購入する意図を示すだけでなく指紋許可も提供する単一のタッチ購入経験を本当に有することを可能にする。もちろん、指紋許可は、タッチセンシティブスクリーン１７７９がそのように構成された場合、タッチセンシティブスクリーン１７７９上でも提供されることがある。指紋ボタン１７７７の使用はブラウザの外部にあるので、デバイス１７７１は、ユーザが購入する意図ならびに指紋許可を提供したことを示すタッチをサイトに通信することがある。この時点では、システムは、支払いを処理するために暗号化されたトークンおよび支払いデータをサイトに返すために必要なさまざまなトークンまたは暗号化されたデータを作成するために進むことがある。
【０３１８】
[00388]システムが、指紋センサのないラップトップおよび指紋センサを有する協調されたモバイルデバイスなどのデバイスを含むことを望むことがある場合、その構成は、提供され図１７Ｈに示される予備情報が、ラップトップ上のブラウザが、購入を行うためにユーザが単にモバイルデバイス上で指紋識別を提供することができることを通知１７７５内でユーザに指示することを可能にすることができるように、適切な情報がモバイルデバイスから、ワイヤレスインターフェースを通して、ラップトップまたは他のデバイスに、次いでサイトに提供可能であるように、サイトに通信されることがある。このシナリオにおいて削除されるステップは、デバイス上のブラウザ内で今すぐ買うボタンをクリックするためのユーザの要件である。したがって、インターフェース１７７９は、ユーザが、指紋許可に単一のデバイスを必要とするか、それとも複数のデバイスを必要とするかに応じて、動的とすることができる。動的な買うボタンは、検出されたブラウザタイプまたはユーザ支払いアカウントタイプに基づいて提示可能である。単一のデバイスが使用される場合、通知１７７５は単に、購入を行うために指紋センサ１７７７上に指紋を提供するようにユーザに指示することができる。複数のデバイスが使用される場合、通知１７７５は、第２のデバイス上で指紋認証を単に提供するようにユーザに指示することができる。表示も、情報を協調させ、第２のデバイス上で指紋識別ボタンに触れることによって、ユーザが、第１のデバイス上に示されるシルクハットを購入していることを確認するために、第２のデバイス上で提供可能である。販売業者サイトと、第１のデバイスと、第２のデバイスとの間で、この協調を提供することによって、支払いプロセスは、１つの対話をなくすことができる。このプロセスは、購入を、本当のワンクリック購入経験にすることができる。
【０３１９】
[00389]以下の例は、上記で作成されたポイントを示す。ユーザが、ナビゲートしており、サイトから購入のためにいくつかの品物を選択しており、それらの品物をショッピングカート内に置いていると仮定する。３つの品物がショッピングカート内に置かれており、ユーザは今精算することを要望すると仮定する。ユーザは、「ショッピングカートを閲覧する」ボタンをクリックする。そのボタンは、システムにブラウザＡＰＩへの呼び出しを開始させることができ、ブラウザＡＰＩは、ユーザが、ショッピングカート内の３つの品物、ｖｉｓａなどの支払いアカウントの識別、発送先住所および発送方法の識別、ならびに購入のための指紋許可を単純に提供する命令が提示されるように、１つまたは複数の情報を取り出すことができる。実際に、この段階では、買うボタンの必要性はない。もちろん、オプションは、ユーザが情報を編集するまたは支払いアカウントを変更するなどのために提示可能である。機械学習または他のインテリジェンスは、どの支払いアカウントをユーザが使用する可能性が高いか優先順位を付けるために利用可能である。たとえば、ビジネス用クレジットカードが、ユーザが購入を行っているロケーション、購入の種類、時刻などの１つまたは複数の要因に基づいて提示されることがある。
【０３２０】
[00390]機械学習アルゴリズムは、口頭でのダイアログインターフェースなどの他のタイプのインターフェースにも適用可能である。スピーチ関係モデルは、過去において、一般にダイアログ管理に関して開発されてきた。本明細書において開示される追加の概念は、機械学習を利用して、任意の種類のユーザインターフェースの一部として支払いプロセスを動的に修正するまたはこれを提示する。支払いプロセスは、口頭でのダイアログ、グラフィカル、マルチモデル、短距離通信、モバイルベース、デスクトップベースなどであってよい。たとえば、テキスト構成要素と口頭構成要素を含むメッセンジャーアプリケーションでは、テキストまたはメッセージとして提示されるものと口頭または視覚的であるもののバランスは、機械学習モデルによって選択または決定可能である。口頭でのダイアログは、どのタイプの対話がユーザにとってより簡単で、摩擦がより少ないかだけでなく、どれが変換および支払いプロセスの完了を増加させ得るかにも基づいて、何を言うべきか、それをどのように言うのか、どの音声を使用するべきか（男性、女性、アクセントなど）、ある音声から別の音声に切り換えるかどうかなどを選択してよい。加えて、音声は、ＡｐｐｌｅまたはＧｏｏｇｌｅからなどの特定の支払いサービスに関連づけられてよい。ダイアログ、ボリューム、トーン、アクセント、支払いサービス、提示されるオプションの選択肢は、履歴データ、機械学習データ、および購入の履歴、ユーザの好みなどの他のデータに基づくことができる。そのような手法を利用すると、購入プロセスに関する個々のユーザ経験を高めるように、支払いプロセスが人によって異なることを可能にすることができる。もはや、誰も、入力フィールドの同じセットまたは同じＰａｙＰａｌボタンが提示されない。購入を行うことを確定し、購入を許可するまさにその瞬間は、個人に合わせて調節可能である。その個別化された手法はまた、ユーザが一貫した経験を有するように、さまざまなプラットフォームおよびサイトで提供可能である。ブラウザＡＰＩは、どのようにユーザが履歴的に精算を経験したかに関連づけられた何らかのデータをサイトに渡すことができる、または、プロセスを改善するようにサイトに指示するために、ユーザパラメータ、または他の任意のデータを渡すことができる。たとえば、通常グラフィカルユーザインターフェース経験では、あるユーザが、買うボタンが提示されるときに、「Ｍａｒｙ、弊社のサイトを訪問していただきありがとうございます。Ａｐｐｌｅ  Ｐａｙをお使いいただくように設定しました」などの耳に聞こえるコメントが行われた場合、購入を最終決定することの３０％増加した可能性を有することがある。ダイアログが、人々にプロセスを進ませ、より快適にするために、グラフィカル経験に追加されることがある。チュートリアル、グラフィックス、ビデオ、チャット機会などはすべて、支払い経験の一部とし、各ユーザに対して動的なやり方で提示されるように管理されることがある。
【０３２１】
マルチサイトサイトショッピングカート
[00391]上記でショッピングカートを参照することは、図１７Ｉに示されるように、本開示の別の態様を提起する。システム１７０１の構成およびこの図は、ショッピングのために複数のサイト１７０３、１７０５、１７０７にナビゲートするユーザを表す。最初に、ユーザが、Ａｍａｚｏｎ．ｃｏｍなどの単一のサイトにおいてショッピングしており、いくつかの品物をショッピングカート内に置く場合、ユーザは、そのショッピングカートを閲覧し、カート内の複数の品物をワンクリックで購入することができることに留意されたい。しかしながら、ブラウザＡＰＩを使用してですら、ユーザが購入を行うために複数の異なるサイトにナビゲートする場合、ユーザは、３つの品物を購入するために複数のワンクリック購入を行わなければならない。たとえば、ユーザがサイト１（１７０３）から第１の品物を買い、サイト２（１７０５）から第２の品物を買い、サイト３（１７０７）から第３の品物を買う場合、ユーザは、これらのサイトの別個の性質のために、購入するために３回のクリックを行わなければならないであろう。以下は、複数のサイトにわたって購入を行うときにいくつかのクリックをなくす手法である。本開示の一態様は、ブラウザＡＰＩを使用して、ショッピングカート内に置かれた品物を記憶することである。別の態様は、異なるモードを介して行われた購入のための単一の精算のように、検索エンジンまたは検索エンティティを用いて汎用ショッピングカートにわたってデータを記憶することを伴う（ウェブ検索からのある品物と、カートを別の品物で満たすためにダイアログシステムを用いた口頭でのダイアログからの別の品物とで満たされたショッピングカートなど）。検索エンティティまたは汎用カートからの精算を管理するエンティティは、精算を管理するための代金を販売業者に請求することができる。たとえば、複数の販売業者が汎用カート内に製品を有する場合、精算を管理するエンティティは、支払いプロセスを管理するための料金の一部分を各販売業者に請求することができる。検索エンティティのケースでは、検索エンティティは、販売業者に広告の代金を請求しないことがあり、汎用ショッピングカートを通して行われた購入の代金のみを請求することがある。
【０３２２】
[00392]たとえば、ユーザがサイト１におり、仮想ショッピングカート内にトースターを置くと仮定する。オプションが、ブラウザショッピングカート内にトースターを置くために、ユーザに提示されることがある。これは、そのサイトにあるままである通常のショッピングカートからのユーザとの対話のための別個のボタンであってよいし、ショッピングカート内に品物を置くための標準的なサイトボタンと統合されることもある。そうである場合、システムは、ユーザがサイト１から遷移したとき、トースターがブラウザショッピングカート内に置かれていることをユーザに通知することがある。いずれにしても、ブラウザ１７１１は、ブラウザＡＰＩ１７０９を通して、トースターに関連づけられたすべての必要な情報を受信する。情報は、ユーザが購入を行う前にショッピングカートを放棄した場合、ブラウザＡＰＩを通して渡されることがあり、そのプロセスは、ユーザ設定を介して修正されてもよい。この点に関して、ブラウザショッピングカートは、複数のサイトへのナビゲーションにわたって永続的になる。次に、同様に、ユーザがサイト２にナビゲートし、仮想ショッピングカート内に料理本を置くと仮定する。その情報は、ブラウザＡＰＩ１７０９を通して通信され、サイト２のショッピングカート内に記憶される。ユーザはまだ料理本を買わないと仮定する。次に、ユーザがサイト３上におり、鉛筆を仮想ショッピングカートに追加すると仮定する。この時点で、ユーザが「ショッピングカートを閲覧する」ボタンをクリックすると仮定する。このシナリオでは、その対話は、サイト１のショッピングカート内のトースターおよびサイト２のショッピングカート内の料理本を取り出し、ユーザがサイト３にいる間、ショッピングカート内の鉛筆とともにそれらの品物を提示することができるブラウザＡＰＩ１７０９への呼び出しをトリガすることができる。ユーザが３つの品物すべてを一度に購入することを可能にする買うボタンが、提示可能である。諒解され得るように、このプロセスは、異なるサイトにわたって複数の品物を購入する従来の手段から、少なくとも２回のクリックをなくした。ユーザが支払いを確認すると、各それぞれのサイトは、支払い全体のうちの各サイトの割り当て分が支払われる。ブラウザまたは他のエンティティは、たとえば、それぞれの品物、発送コスト、税金などに対して、第１のサイトは３０ドルが支払われ、第２のサイトは５０ドルが支払われ、第３のサイトは２５ドルが支払われる、１０５ドルの支払いを処理することができる。指紋対話は品物をすべて購入することができるという、インターフェース上での通知などの、本明細書において開示される、購入を管理するためのいかなる手法も利用可能である。オプションは、２つの異なるロケーションに発送されることになる異なる品物などに対して提示可能である。機械学習、履歴情報、または他の分析およびアルゴリズムは、対話の数を減少させるまたはユーザのためのプロセスを単純化するために、住所、支払いアカウント、発送オプションなどを予測するために利用可能である。検索エンジン、検索エンティティ、または他のサービスなどの、ＡＰＩまたは他の手段を介したネットワークサービスは、マルチサ��トショッピングカート経験のための機能も提供することができる。たとえば、ネットワークサービスは、類似のまたは異なるインターフェースモダリティを使用して、第１のデバイスによってアクセスされる１つのサイトからの品物と、第２のデバイスによってアクセスされる第２のサイトからの第２の品物をショッピングカート内に記憶し、次いで、カート内のすべての品物のための支払いを一度に処理することができる。サイトは、サービスに登録することができ、特許請求の範囲は、サービス、ブラウザ、ショッピングカートモデル、および販売業者処理に出され得る。支払いを処理する目的でブラウザＡＰＩを利用することによって、システムは、ユーザがショッピングカート拡張機能にログインするまたは別個のショッピングカート拡張機能に支払いおよび住所情報を提供する必要性を軽減することができる。本明細書において開示される汎用ショッピングカートは、ブラウザＡＰＩを利用して、ユーザが支払い情報および住所情報をさらに別のエンティティに与える必要性をなくすことができる。検索エンティティのようなエンティティが支払い／住所データを記憶するとき、そのエンティティは、支払いプロセスを提供し、ショッピングカート内の品物に支払いを適用することができる。
【０３２３】
[00393]ブラウザＡＰＩおよび任意のそれぞれの販売業者との通信は、ユーザが利用する支払いのタイプに関連して販売業者に対する能力のある支払いプロセスを調和させることが留意される。本開示は、複数のサイトにまたがる永続的なショッピングカートは、ユーザ能力に関して、サイトにまたがる異なる支払い能力という結果になり得ることを認識する。これらの違いのすべては、ブラウザにおいてにせよ、他のサービスまたはエンティティと協調するにせよ、このプロセス内で解消される。言い換えれば、サイト１はＶｉｓａのみを受け付けてよく、サイト２はＭａｓｔｅｒＣａｒｄのみを受け付けてもよい。サイトモード３は、Ａｐｐｌｅ  Ｐａｙを受け付けてよい。このケースでは、ユーザは、記憶されたＶｉｓａカード、記憶されたＭａｓｔｅｒＣａｒｄ、ならびにＡｐｐｌｅ  Ｐａｙアカウントを有すると仮定する。複合ショッピングカートは、エンティティがユーザの利用可能な支払い機構のすべてを協調させ、単一のクリック対話がサイト１に対してｖｉｓａ支払いを行わせ、サイト２からＭａｓｔｅｒＣａｒｄ支払いを行わせ、サイト３に対してＡｐｐｌｅ  Ｐａｙ支払いを行わせるように、それらの支払い機構を適切なそれぞれのサイトに割り当てたという確認を、ユーザに提示することができる。各それぞれのプロセスは、ブラウザＡＰＩ、検索エンティティ、または他のネットワークベースのサービスを利用して、それぞれの支払い、必要な場合はトークンの生成などを達成することができる。割り引きは、それぞれの購入、クーポン、返金などに対して組み入れ可能である。他の機構も、少額のサービス料金に関して、Ｖｉｓａカードまたはユーザによって提供される他の任意の単一支払い機構に請求し、他のそれぞれの販売業者に対して他の支払いを処理するサービスによって提供される場合がある。一態様では、単一のトークン化された支払いは、異なるサイトの間でのすべてのそれぞれの支払いを取り扱うために支払いプロセッサに送信可能である。
【０３２４】
[00394]図１７Ｉは、ブラウザＡＰＩを使用して異なるサイトにまたがる永続的なショッピングカートを提供するために利用可能である、ありとあらゆるタイプの通信、要求、呼び出し、応答などを表す。いくつかのケースでは、ブラウザまたはブラウザが機能しているデバイスは、情報を記憶し、情報を取り出し、データを分析し、暗号化された支払いデータまたはトークン化データを取り出すなどのために、サーバ１７１３と通信することがある。サーバ１７１３はまた、プロセスの一部として、ショッピングカート品物が記憶されるサイトのいずれかと直接的に通信することがある。支払いデータ、他の任意のデータ、または通信は、サーバ１７１３とそれぞれのサイトとの間で発生することができる。ショッピングカートデータは、単回使用のために暗号化またはトークン化可能であり、または場合によってはセキュリティ対策を備えることができる。本開示のこの態様は、元のブラウザＡＰＩの強化された利用を表し、これは、ショッピングのためにナビゲートされる複数のサイトにまたがって永続的なショッピングカートが維持されることを可能にする。
【０３２５】
[00395]別の態様では、ＡＰＩ１７０９を利用し、同じ様式で機能するネットワークベースのサービスを単に表すブラウザ１７１１。ショッピングカート内に置かれた製品のデータは、プロセスの任意の数の異なる段階におけるＡＰＩ呼び出しを通して通信可能である。たとえば、販売業者サイトは、ＡＰＩを通してショッピングカート情報をいつ転送するべきかに関する異なるシナリオをセットアップすることができる。ショッピングカート内に品物を置くとすぐに、または買うボタンをクリックするとすぐに転送されるべき情報。いくつかのシナリオでは、必ずしも「ショッピングカート」があるとは限らず、購入されているプロセス内の製品に関連づけられたデータがあるにすぎないことがある。たとえば、誰かが「Ａｐｐｌｅ  Ｐａｙ」ボタンをクリックした時間と、購入を確認するためにその誰かが指紋を提供する時間との間、データが、記憶およびその後のアクセスのために、ＡＰＩに提供されることがある。サービスは、ユーザがその製品を後で購入した場合、販売業者にある額を請求することがあるが、これは、それが、永続的なショッピングカート内でもたらされ、したがって、注意が戻されたからである。
【０３２６】
[00396]現在、たとえば、ソーシャルメディアに関する多くの広告は、他のウェブサイトナビゲーションに基づいてユーザのニュースフィード内でユーザに広告を提示することを伴う。ユーザが、トースターに関してブラウジングするが、一度もトースターをショッピングカートに入れることや購入を行うモードに近づくことすらしないことがある。次いで、そのトースターに関する広告が、変換という結果になることができるニュースフィード上に後で提示される。本開示の別の態様は、そのような品物を本明細書において開示されるショッピングカートに追加することである。したがって、ユーザがトースターを検索した、ショッピングカート上に置くことすら一度もしない場合、そのトースターをソーシャルネットワーキングページ上で後で広告するよりもむしろ、一態様は、ユーザが後でショッピングカート内の別の品物の購入を行っているときに、トースターを見て、他の品物ならびにトースターを購入するためにワンクリックを行うことができるように、そのトースターをショッピングカート内に置くことを伴うことができる。トースターは他の品物とともに購入されるべきであることを確認するためにユーザ対話があることもある。オプションが、ショッピングカートからトースターを削除するまたは後での購入のためにトースターを保持するために、提示可能である。したがって、ショッピングカートは、品物が全体として購入可能であり、したがってプロセスを単純化する、より動的な環境になる。別の態様では、トースターに関するソーシャルメディアサイト上での投稿は、対話するとき、販売業者サイトではなく、マルチサイトショッピングカートからの他の品物とともに、その品物がその中に含まれたショッピングカートに、ユーザを遷移させることができる。言い換えれば、広告または投稿上の選択可能なオブジェクトは、広告された品物ならびにユーザがショッピングカート内に置いた他の品物を含めるために、マルチサイトショッピングカートへの遷移を引き起こすことがある。
【０３２７】
[00397]別の態様は、アカウントを集約することを伴う。たとえば、いくつかのカップルがａｍａｚｏｎ．ｃｏｍアカウントを共有しており、したがって、どちらかの人によって行われた購入は、購入履歴内で見られ得る。品物がショッピングカート内に記憶されている場合、各個人は、もう１人によって記憶された品物を見ることができる。このケースで適用することができる別の原理は、任意の数の要因に基づいてショッピングカートを結合することであろう。たとえば、本開示以前では、夫が販売業者サイト番号１上でショッピングカート内に品物を買い、妻が販売業者サイト番号２で買い物をし、ショッピングカート内に第２の品物を置いた場合、これらの２つの品物を永続的なショッピングカートにまとめる機構はなかった。したがって、コンピュータにリンクすることによってであろうと、アカウントにリンクすることによってであろうと、使用される支払いアカウントに基づいてであろうと、ユーザの好みなどの他の任意の数の要因に基づいてであろうと、個人は、別個のショッピングカート品物を集合ショッピングカートにまとめることができる。したがって、ユーザ店舗をリンクさせ、複数のサイトにまたがって品物を置くと、彼らは２人とも、集約ショッピングカートを閲覧することができ、それらの品物の購入を行うことができる。さらに、ユーザは、子供が品物を追加することができるが、親だけが購入を行うことができるなどの、異なる認可を有してよい。
【０３２８】
[00398]図１７Ｊは、図１７Ｉに開示されているシステムの方法態様を示す。方法は、ブラウザショッピングカートＡＰＩまたは第１のデバイスを介して、第１のサイトから第１のショッピングカート情報パッケージを受信すること（１７１５）と、ブラウザＡＰＩを介して、または第２のデバイスを介して、第２のサイトから第２のショッピングカート情報パッケージを受信すること（１７１７）とを含む。方法は、ユーザがショッピングカートの閲覧を要求すると、ブラウザＡＰＩを介してサイト（ユーザがサイトにナビゲートしている場合）またはブラウザインターフェース（ユーザがショッピングカートを要求するブラウザにいる場合）に第１のショッピングカート情報パッケージおよび第２のショッピングカート情報パッケージを通信すること（１７１９）と、ショッピングカート内の品物を購入したいという要望の標識を受信すること（１７２１）とを含む。ショッピングカート情報パッケージは、ショッピングカート内にある品物をそれぞれのサイトから識別するために必要な情報、サイトの識別情報、および／またはその品物の発送先住所、その品物に関連づけられた支払いアカウント、それが贈り物であるかどうか、ギフト包装されるべきであるかどうか、発送指示などの、ユーザによって選択された他の任意のパラメータの識別情報を含むことができる。含まれ、ＡＰＩを介して通信可能な他の品物は、ビデオ、画像、コメント、比較、レビュー、および／または任意のそのような情報へのリンクとすることができる。画像、ビデオ、または他のブランディング材料を提供するために必要なプロトコルは、永続的なショッピングカートを提供する修正されたブラウザＡＰＩ内に含まれ得る。ユーザが任意のそれぞれのサイトにおいてナビゲートしている間、ユーザは、そのような選択および決定を行うことができ、その情報は、記憶および後での取り出しのためにブラウザＡＰＩを介してブラウザに通信可能であるショッピングカート情報パッケージの一部である。異なるデバイスは、異なるモダリティを通して異なるサイトにアクセスするためにも使用可能であり、各サイトからの製品は丁寧に、１つまたは複数のサイトからの複数の製品の単一購入プロセスのためにショッピングカート内に含まれ得る。
【０３２９】
[00399]概念は、ユーザがローカルショッピングカート閲覧を要望するのかマルチサイトショッピングカート閲覧を要望するのかを決定することも包含する。ユーザは、第１のデバイスの使用を介して、ローカルサイトショッピングカートにいくつかの品物を入れるサイト上にいることがある。オプションまたはオブジェクトが、ブラウザＡＰＩショッピングカート内に記憶された他の製品を追加するために、ローカルショッピングカートを閲覧することの一部として提示されることがある。このオプションは、ユーザの習慣、含まれるブラウザ製品の全体的なコストと比較したローカルカート内の製品のコスト、ソーシャルメディアデータなどに基づいて動的であってよい。ローカルサイトは、ユーザがショッピングカートを閲覧することに進んだとき、他の品物がブラウザショッピングカート内で待機しているまたは記憶されているかどうかを決定するために、ＡＰＩを通して（ブラウザまたはネットワークベースのエンティティへの）呼び出しを開始することができる。そうである場合、サイトは、ユーザがすべての品物をまとめて購入することを可能にするために、ショッピングカートに「ブラウザ製品を追加する」などの選択可能なオブジェクトを提示することができる。品物についての短い情報も提供されてよい。たとえば、ユーザがブラウザショッピングカート内にトースターおよび歯ブラシを有している場合、販売業者は、ようにユーザに求める「トースターおよび歯ブラシをこのカートに追加する」オブジェクトを提供してもよいし、買うボタンが、ローカルサイトで品物を購入することは他のブラウザショッピングカート製品の購入を処理する結果にもなることを示すように修正されてもよい。このケースでは、２つの買うボタンが、１つはローカルサイト製品だけを買うために、もう１つはブラウザに記憶された製品に加えてローカルサイトのワンクリック購入のために、提示されてもよい。購入は、ＡＰＩの支払い要求タイプを通して発生することがあり、または検索エンティティもしくは他のエンティティを用いて記憶された支払い関係情報を使用して検索エンティティを介して管理されることがある。
【０３３０】
[00400]一態様では、ユーザが、ブラウザＡＰＩを介してブラウザから、またはネットワークサービスから、ショッピングカートを取り出すことがある。ユーザが、ブラウザに記憶されたまたはブラウザを介してアクセス可能な支払い情報を有するので、ブラウザは、ショッピングカートを閲覧するために、対話型ボタンを介する、またはドロップダウンメニューを介する、オプションを含むことがある。品物を記憶していることをユーザに思い出させるために、ショッピングカート内に品物があるときのみ、動的オブジェクトが提示されることがある。言い換えれば、ショッピングカート内に品物があるときのみ、ブラウザの上部インターフェース上に、「ショッピングカートを閲覧する」オプションが提示可能である。ユーザがそのオブジェクトをクリックしたとき、ショッピングカートは、発送先住所、支払いアカウントなどを選定するために利用可能なオプションのすべてが提示可能である。図１７Ｋは、永続的なブラウザベースのショッピングカートインターフェース１７２１を示す。ブラウザは支払い情報へのアクセスを有するので、ユーザは、ブラウザからすぐに購入を行うことができる。ショッピングカートへのアクセスは、ソーシャルメディア投稿もしくはメニュー、またはユーザがナビゲートするもしくは時間を費やす任意のロケーションを通じても、提供可能である。たとえば、ユーザがショッピングカート内に品物を有する場合、その情報は、ＡＰＩを通してＦａｃｅｂｏｏｋなどのソーシャルメディアネットワークに通信されることがあり、投稿が、最終的な購入を行うためにショッピングカートにアクセスするためにユーザが対話することができるオブジェクトを提供する、ユーザのニュースフィード上で生成されることがある。そのようなオブジェクトは、任意のソーシャルメディアサイト上で提示可能であり、どのようにユーザがそのサイトと対話するか、ならびにＦａｃｅｂｏｏｋメッセンジャー、テキスト送信などの任意の補助サービスに従って構成されるであろう。トリガは、そのような投稿または通知が、間もなく訪れる誕生日に対して品物がショッピングカート内にある時間の長さ、またはそのような通知をユーザに対してトリガするために利用可能な要因の他の任意の組み合わせなどのある環境下で提供されるように、プロセスへと組み込まれ得る。口頭でのダイアログシステムも利用可能である。
【０３３１】
[00401]任意のそれぞれのサイトからブラウザへの送信のタイミングも、動的とすることができる。たとえば、サイト１にいるユーザがショッピングカート内にいくつかの品物を置き、次いで、それらの品物を購入したにすぎない場合、それらの品物のためにブラウザＡＰＩを通してブラウザに情報のパッケージを通信する必要がないことがある。しかしながら、ユーザがショッピングカート内にいくつかの品物を置いたが、次いで、ショッピングカートを放棄するすなわち購入を完了せず、サイトから遷移する場合、情報パッケージは、それらの品物が汎用ショッピングカート内で維持されるように通信可能である。ユーザの好みは、これが自動的に発生することを防止するため、またはデータパッケージの転送を確認するために対話を必要とするために実施されてよい。１つの観点では、この手法は、ブラウザ支払い要求ＡＰＩを通して利用可能になるように１つまたは２つのクリック購入オプションすら用いて放棄されたショッピングカートの課題をある程度解決することができる。この手法は、放棄されたショッピングカートが完全には放棄されないことがあるがユーザはそれらの品物をもつカートを後で再度閲覧することがあるようにより永続的なショッピングカート経験を維持するためのブラウザＡＰＩまたは検索エンティティなどのネットワークサービスの、ユーザが第２または第３の閲覧で品物の購入を行う確率を増加させることができる簡略化された購入プロセスを用いたショッピングカート内での使用を強化する。本開示は、ユーザがブラウザの永続的なショッピングカートを管理するための他の任意のオブジェクトまたは操作機会も含む。たとえば、ショッピングカートから品物を削除し、品物をショッピングカートに追加し、特定の時間の期間にわたってショッピングカートの品物を維持し、２週間などの時間の期間の後でショッピングカートの品物を取り下げるなどのためにユーザが対話することができる、提示される任意のオブジェクト。
【０３３２】
[00402]図１７Ｋは、永続的なショッピングカート内のさまざまな品物を示す。ｓｉｔｅ１．ｃｏｍからのトースターは１７２３に示されており、ｓｉｔｅ２．ｃｏｍからの遠隔制御車は１７２５に、ｓｉｔｅ３．ｃｏｍからのタオルは１７２７に示されている。これらのサイトは、異なるデバイスを通してもアクセス可能である。「ショッピングを続ける」オブジェクト１７２９も示されており、今すぐ支払うボタン１７３１も示されている。ここでも、この手法の利点は、１回の今すぐ支払うｅｎｔｅｒアクション１７３１を介して、システムが、（１）ｓｉｔｅ１．ｃｏｍへのＶｉｓａカードを使用した支払い（ブラウザＡＰＩを通してｓｉｔｅ１．ｃｏｍにトークンまたは必要な支払い情報、ならびに他の情報を送信することなどによって）、（２）遠隔制御車のためのｓｉｔｅ２．ｃｏｍへのＭａｓｔｅｒＣａｒｄを使用した支払い、および（３）タオルのためのＡｐｐｌｅ  ｐａｙを使用したｓｉｔｅ３．ｃｏｍへの支払いを実行する。もちろん、総額が、購入のすべて、ならびに購入を削除する、品物の数を変更するなどのための他のオプションに関して示され得る。そのような個々の操作が行われる場合、ブラウザショッピングカートＡＰＩは、品物の数、または発送先住所もしくは発送指示の変更に基づいて請求される総額を更新するために、それぞれのサイトと通信することができる。したがって、インターフェース１７２１は、ユーザが各個々の注文に対する適切な変更および調整を行うことを可能にするために任意のそのようなオブジェクトを含むことができ、その時点で、ユーザが支払うとき、さまざまな支払い機構のすべてが実施可能である。通常、販売業者サイトは、支払いデータのためのブラウザＡＰＩを通して呼び出しを開始する。ショッピングカートモデルを通して行われる後での購入の下で、ブラウザは、ユーザが品物のうちの１つを購入したことを販売業者サイトに知らせる、販売業者サイトへの呼び出しを開始することがある。呼び出しは、サイト上での品物に対するユーザの以前の検索を参照し、送信および処理されることになる支払いデータのためのＡＰＩを介して必要な通信を開始するために、識別情報を含むことがある。一態様では、別個のローカルまたはインターネットベースのサービスは、ユーザからの１つの統一された支払いを提供することがあり、次いで、サービスは、各購入についての情報に基づいて、各個々のベンダーまたは販売業者に対する支払いを行うことがある。
【０３３３】
[00403]別の態様では、ユーザは、サイト１から永続的なショッピングカート１７２１内に第１のトースター１７２３を置き、次いで、サイト２から異なるトースターを見つけることができる。ショッピングカート内に置かれている両方のトースターは、類似の品物がカート内に置かれており、ユーザが比較分析を要望することがあることをシステムに識別させることがある。この点に関して、ユーザが、両方のトースターをもつ永続的なショッピングカートを取り出すとき、ショッピングカートは、まさにその２つの品物間での何らかの比較可能な情報を提示することができる。これは、ユーザとの対話のこの状態において、ユーザは、次いで、品物のうちの１つを単に選び、ショッピングカートから選択されていない品物を削除し、購入プロセスを続行することができるので、そのような比較を提供するために、非常に簡単なロケーションである。さらに、永続的なブラウザショッピングカートから、リンクが、各それぞれのサイトにおける「ショッピングを続ける」に対するオプションのために提供可能である。このプロセスは、複数のサイトにまたがるショッピング経験をなくし、単純化することができる。
【０３３４】
[00404]サービスはまた、ショッピングカート内のさまざまな品物の分析を提供し、それに応じて提案またはアップグレードを提供することがある。たとえば、ユーザが、あるサイトから皿を、別のサイトからグラスを、またはあるサイトからスーツを、別のサイトからネクタイを買う場合、システムは、この協調されたショッピングカート内の品物を分析し、代替品物または互いにより良く合致する品物、アップグレード、代替色などのための提案および広告を提供することがある。
【０３３５】
[00405]ブラウザはまた、品物を返すことを選択することまたはその発送進捗をたどることなどの、後での取り出しおよび処理のために購入された品物の履歴を記憶することがある。この点に関して、購入が行われた後、情報が、ブラウザＡＰＩを通して通信され、ブラウザから、または本明細書において開示される、サイト上のオブジェクト、ソーシャルメディアインターフェース、アプリなどを介して、後での取り出しのために記憶されることがある。
【０３３６】
[00406]別の態様は、ショッピングカート内に置かれた製品を越えて他の製品検索とショッピングカートを統合することを含む。たとえば、ユーザが、デスクトップコンピュータ上でＡｍａｚｏｎ．ｃｏｍに、または音声ベースのデバイスを介してｔａｒｇｅｔ．ｃｏｍにナビゲートし、トースターを見るまたは注文するが、ショッピングカート内にトースターを置かず、何らかのレベルで、買われ得るトースターについてのデータを閲覧するだけである（トースターをショッピングカートに入れることを含んでよい）場合、存在する１つの現在のプロセスは、そのトースターを売り物とするニュースフィード内にＡｍａｚｏｎ広告を提示することである。この広告は、ユーザが、品物を購入する別の機会を有することを可能にする。本シナリオでは、この概念は、製品との任意のユーザ対話は、それが物理的にオンラインであるにせよ、仮想的にオンラインであるにせよ、バーチャルリアリティ環境内などにあるにせよ、その品物のためのショッピングカートエントリをシステムに生成させることがあるように拡張される。サービスは、どの製品をユーザがサービスまたは閲覧されたかについての情報を取り出し、ユーザが買うのを好む可能性の最も高い製品を生成することがある。次いで、ユーザがマルチサイトショッピングカートを閲覧するとき、その品物は、リストされ、個々に、または他の品物と集約された手段のどちらかで、ワンクリックで容易に買われることがある。そのような品物が一度もユーザによってショッピングカートに入れられなかったので、ユーザが購入のためにショッピングカート内に品物を明示的に置くためにクリックすることができる選択可能なオブジェクトなどの追加の対話が、提示されることがある。別の態様では、品物は、ショッピングカート内の買うボタンをクリックすると、その品物ならびにショッピングカート内の他の任意の品物の購入を行わせるように事前構成された状態で、ショッピングカート内に置かれることがある。閾値は、そのような品物がショッピングカート内に置かれるときのために設定されることがある。たとえば、機械学習は、どれくらい深くユーザが品物を検索し調べたか、どれくらい多くの時間をユーザが品物に費やしたか、どれくらい多くのレビューをユーザが読んだか、ユーザが品物を他の類似の品物と比較したかどうかなどのパラメータを決定するために、利用されることがある。このシナリオでは、その閾値が満たされると、次いで、システムは、その品物を売り物とする、ユーザのショッピングカートのためのエントリを作成するであろう。別のシナリオでは、２つの類似の品物が検索された場合、システムは、ショッピングカート内で比較データとともに両方の品物を提示し、これは、ユーザが比較情報をレビューし、選択された品物をクリックすることを可能にし、したがって、次のクリックまたは次の対話は文字通り、ショッピングカート内の他の任意の品物を伴う選択された品物の購入であってよい。
【０３３７】
[00407]本明細書において開示されるショッピングカートは、特徴を利用するために拡張機能がログインまたはクリックされることを必要としないように、ウェブサイト内で統合可能である。支払いデータまたは住所の別個の登録は、ショッピングカート拡張機能内で発生することを必要としない。汎用ショッピングカートは、カートをアクティブ化するために、ブラウザインターフェース上で選択可能なオブジェクトなしで動作することができる。サイトは、たとえば、品物が異なるデバイスにまたがって、ならびに異なる販売業者および相違デバイスにまたがって、汎用カート内に置かれ得るように汎用ショッピングカートモデルを協調させることを可能にするために、検索エンジンに登録することがある。ショッピングは、デバイスから、アシスタントアプリケーション内で、音声ベースのデバイスを介して、ブラウザを介して、車両ベースのデバイス、腕時計などを介して、発生することができる。汎用カートは、販売業者との対話のこれらのさまざまなモードにまたがり、ネットワークベースのシステムによって協調可能である。次いで、検索エンティティが、記憶された支払いデータを使用して同じ汎用カート内の１つまたは複数の販売業者に対する複数の品物の支払いを処理することができる。これは、本明細書において開示されるブラウザＡＰＩまたは検索エンティティによって管理されるＡＰＩもしくは他の技術を通してなされ得る。品物が、第１のデバイス上でのウェブ検索からショッピングカート内に置かれ、これに続いて、別の品物が、第２のデバイスを介して音声ダイアログからカート内に置かれ得る。ユーザは、ブラウザＡＰＩを使用する統一された購入プロセスまたは検索エンティティに記憶されたデータが複数の品物を購入するために適用される検索エンティティベースのプロセスを通して、両方の品物のために１回精算することができる。各販売業者は、支払われ、次いで、それぞれの品物を発送することができる。検索エンティティは、販売業者に、購入時に汎用ショッピングカートを使用する代金を請求することができる。
【０３３８】
[00408]汎用ショッピングカートに関係する他の概念は、ユーザショッピング経験を修正することができる、サイト検索またはプレゼンテーションを改善するための、ショッピングカートからウェブサイトにデータ、すなわち、カート内の品物、人口統計学的データを提供することを含む。たとえば、サイト２が、サイト１からのトースターが汎用ショッピングカート内にあることを知っている場合、ナビゲーション結果または検索結果またはサイト２においてユーザに提示される品物は、ユーザ経験を改善するように修正可能である。次に、ここでも、ＡＰＩの使用は双方向とすることができることに留意する。たとえば、ユーザがショッピングカート内の品物を買い、情報のパッケージが、ブラウザＡＰＩからトランザクション全体を開始するために、オブジェクト、トークン、支払い情報、住所情報、登録情報、ログイン情報、製品情報、サイズデータなどのうちの１つまたは複数とともに、ＡＰＩを通してウェブサイトに渡される。これは、ウェブサイトを離れたが品物をショッピングカート内に置いている場合に起こるであろうことである。
【０３３９】
[00409]方法は、ユーザナビゲーションに基づいて第１のサイトから購入可能である第１の品物を識別することを含むことができるが、この第１の品物は購入されない。これは、サイトの通常の標準的なナビゲーション内でなされ得る。方法は、第１の品物に関連づけられたデータの遷移（ＡＰＩ上で、ブラウザに対する、拡張機能、またはネットワークサービスに対するものとすることができる）を受信することを含む。たとえば、Ｗ３ＣブラウザＡＰＩは、製品の詳細または税金および発送の内訳を提供するための任意選択の特徴であるＰａｙｍｅｎｔＤｅｔａｉｌｓＢａｓｅディクショナリの一部である「ｄｉｓｐｌａｙＩｔｅｍｓ」メンバーおよび／または「ａｄｄｉｔｉｏｎａｌＤｉｓｐｌａｙＩｔｅｍｓ」を含む。ブラウザＡＰＩは、サイトが後での取り出しのためにナビゲーションプロセス中の任意の時間に製品詳細をショッピングカートに渡し得るように修正され得る。製品についてのデータを送信するトリガは、初期検索と完了された購入との間の任意の数のナビゲーション状態または段階においてであってよい。たとえば、ユーザが、ブラウザＡＰＩインターフェースが提示されているが、トランザクションを完了しない場合、サイトは、記憶および後での取り出しのために製品データをブラウザに渡すことができる。次いで、ユーザは、同じデバイスを介して、または音声ベースのユーザインターフェースもしくは他のタイプのユーザインターフェースをもつデバイスも含むことができる完全に別個のデバイスを介して、第２のサイトにナビゲートすると仮定する。方法は、ユーザナビゲーションに基づいて第２のサイトから購入可能な第２の品物を識別することであって、この第２の品物はショッピングカート内に置かれる、識別することと、ショッピングカートに第１の品物についての情報を送信することと、第１の品物および第２の品物を買うために購入オブジェクトとのユーザ対話を介して確認を受信することと、品物の購入を処理するために第１のサイトに購入情報を通信することと、第２の品物の購入を処理するために第２のサイトに支払いデータを通信することとを含む。通信は、第１の製品の第１のサイトにおいて購入を開始するための、ブラウザＡＰＩと情報との間の通信を含むことができる。たとえば、ブラウザＡＰＩは、第１のサイトを、ユーザが、第１の品物を購入し、購入ボタンをクリックする点にナビゲートしたかのような状態にするために、第１のサイトにデータを送信することがある。通常、その対話は、第１のサイトに、支払い情報のために、ブラウザに対するブラウザＡＰＩを通して支払い要求を開始させるであろう。しかしながら、上記のシナリオでは、ユーザは、第１の品物についての情報がショッピングカート内に保有されている第１のサイトを離れている。したがって、第１の品物の購入を容易にするために、改善は、ＡＰＩを通して第１のサイトに情報を送信することを通して製品の購入を開始するためにブラウザＡＰＩの使用を拡張することを含む。この態様では、第１のサイトが、次いで、支払いデータ、住所データなどを取り出し、通常のやり方で製品の購入および配達を完了するために、ブラウザＡＰＩに対する支払い要求を開始する。これを発生させ��ために、追加の通信が交換されることを必要とすることがある。第１のサイトに送られる情報のパッケージは、ユーザが第１の品物にナビゲートし、「買う」ボタンを打ったと錯覚するようにすることができる。情報は、販売業者サイトに、製品の支払いを処理するための支払い情報を戻すように求めるためにブラウザへの支払い要求ＡＰＩ要求を開始させることができる。情報のパッケージは、ユーザがショッピングカートを開いたときに送られることがある。タイミングに関して、ユーザが、第１のサイトからの第１の品物および第２のサイトからの第２の品物を有する状態で「買う」ボタンをクリックしたとき、両方のサイトは、基本的に、ユーザが、購入を処理するための買うボタンとともにそれぞれの品物を閲覧する点にナビゲートしたかのような状態を有する。しかしながら、ショッピングカートの買うボタンは、ユーザが買うボタンを打ったとき、両方のサイトが、単一のクリックに基づいて支払いを処理するためにブラウザＡＰＩを通して支払い要求を送るように、これらの２つの異なる状態にリンク可能である。ショッピングカート用プラグインは、支払いを処理するために必要な他の任意の対話情報を一義化または提示することができる。たとえば、１つのウェブサイトがＡｐｐｌｅ  Ｐａｙを必要とする場合、ショッピングカートは、単に支払いのためにユーザの指紋を求めることができるが、それが１つの特定の製品購入のためのものであることを識別する必要はない。
【０３４０】
[00410]別の態様では、ショッピングカートと協調するブラウザは、第１のサイトが製品の購入および配達を最終決定することができるように、ユーザに関する支払い能力、支払いトークン、支払いデータ、住所データ、製品データ、価格などを含むデータのパッケージを送ることができる。この手法は、ブラウザＡＰＩ概念の能力の拡大を表す。一態様では、第１のサイトにおけるユーザの初期ナビゲーション、第１のサイトの品物の購入の欠如に基づいて、第１のサイトは、トランザクションＩＤを生成することができ、このトランザクションＩＤは、ＡＰＩを通してショッピングカート管理システムに送信される（ショッピングカート管理システムは、ブラウザまたはサードパーティネットワークベースのサービスのためのプラグインまたは拡張機能とすることができる）。このトランザクションＩＤは、後で、品物を覚えておき、ユーザのために品物の購入を処理するために、過去の第１のサイトへの後戻りで、支払いデータ、住所データ、およびワンタイム使用トークンなどの他の任意のデータとともに使用可能である。
【０３４１】
[00411]他の態様は、Ｓｔａｐｌｅｓにおいて椅子に座っていることのような、製品のための電話機のロケーションを追跡することと、興味を示す製品に関する閾値対話を得ると、永続的なショッピングカート内の製品についての詳細を提供することとを含む。ウェブをサーフィンするとき、製品のレビューを読むこと、またはある量の時間を製品ページに費やすことのような、その閾値に当たると、ユーザが別のサイトにいるときでも、ショッピングカート内にその品物を置くために、製品ＩＤ、販売業者ＩＤ、タイミング、個人情報、コスト、割り引きなどを含む情報がサービスにフォワーディング可能である。
【０３４２】
[00412]汎用ショッピングカート内に置かれた複数の品物を管理するために使用可能である、本明細書において開示されるネットワークデバイスは、ユーザによって使用されるさまざまなデバイスにまたがって汎用ショッピングカートを協調させることができる。たとえば、検索エンティティは、モバイルデバイス上での第１のブラウザ検索からショッピングカートへと入れられた第１の製品を識別し、次いで、ショッピングカートに入れられる第２の製品を識別するために第２のデバイス上で音声指示を使用するユーザを識別することができる。次いで、ユーザは、どちらのデバイス上でも、または任意の時間に、両方の製品を購入することができる。システムは、音声識別を通して、または同じユーザショッピングカートの一部であるように品物を接続する他の手段を通して、ユーザを識別することができる。音声ベースのデバイスは、特定の支払いアカウントに既に関連づけられていてもよいし、音声識別に基づいて異なる支払いアカウントに調整されてもよい。たとえば、自宅にいるユーザが、デスクトップコンピュータから第１の製品を汎用ショッピングカートに入れ、次いで、友人の家に行くことがある。ソーシャルネットワーキングデータまたはスピーチ／音声識別を通して、ユーザは、友人の家で音声ベースのデバイスに話しかけることができ、このことは、「これはＭａｒｙ  Ｓｍｉｔｈですか？」と尋ねることによって識別を確認することができ、その時点で、ユーザは、音声コマンドを介して別の品物をショッピングカートに追加し、すべての品物の購入を行うことができる。ソーシャルメディアデータまたは好みは、購入のために友人の音声ベースのデバイスを潜在的に使用することにＭａｒｙを接続することができる。別個のバイオメトリック確認は、これらのシナリオでは、購入が、適切な人間からであることを確認するためにも提供されることがある。一例では、Ｍａｒｙが友人の家に行ったとき、音声ベースのデバイスまたは他のデバイスは、Ｍａｒｙの携帯電話を通してＭａｒｙを識別することができる。ジオロケーションデータも、Ｍａｒｙのロケーションに基づいて提供可能である。このデータに基づいて、検索エンティティを通して音声ベースのデバイスは、Ｍａｒｙが音声ベースのデバイスを通して友人の自宅でショッピング要求を行うことがあると潜在的に予想するように構成可能である。スピーチ認識モデル、話者識別モデル、または発生することを必要とすることがある他の任意のスピーチ関係の事前構成が、ネットワークベースで開始可能またはローカルの音声ベースのデバイスに転送可能、あるいは両方が可能である。したがって、Ｍａｒｙが音声ベースのデバイスに、「紙タオルを私のショッピングカートに追加してちょうだい」と言ったとき、システムは、Ｍａｒｙの音声を認識し、調節されたスピーチ認識モデルを使用してスピーチを解釈し、「オーケー、Ｍａｒｙ、紙タオルが、ショッピングカートに入っていて、塩と胡椒入れが昨日追加されました。精算しますか？」で応答することができる。次いで、Ｍａｒｙは、友人の音声ベースのインターフェースデバイスからショッピングカート内のすべての品物に対する単一の購入トランザクションを行うことができる。購入を確認するために、システムは、ネットワークシステムを介して協調可能である指紋認証を提供するようにＭａｒｙに求めることがある。これは、ＮＦＣ支払い経験に類似していてもよい。音声ベースのデバイスは、ＮＦＣ能力を有することがあり、購入を確認するために、Ｍａｒｙは単に、自分の電話機を音声ベースのデバイスに移動させ、すべての品物の購入を完了するために指紋を提供することがある。音声ベースのデバイスに提供されるデータは、Ａｐｐｌｅ  ＰａｙまたはＧｏｏｇｌｅ  Ｐａｙが使用されるときに、小売業者のところにあるＮＦＣデバイスにおいて提供されるものに類似している。ユーザは、自分のデバイスを音声ベースのデバイスの近くに移動させ、指紋または顔認識を求める支払いインターフェースがポップアップするであろう。このようにして、ユーザは、友人の家でまたは自宅ロケーションからは異なるロケーションにあるデバイスにおいて、しかし同じ単純なインターフェースを使用して、容易にショッピングを完了するまたはショッピングを開始することがある。ネットワークシステム（支払いプロセスを管理する検索エンティティなど）へのおよびこれからの必要な通信のすべては、Ｍａｒｙが品物を注文し、それをショッピングカート内に含ませ、精算することを可能にするために、音声ベースのデバイスとシステムとの間で発生することができる。
【０３４３】
[00413]Ｍａｒｙが電話機を持っていない場合、音声対応デバイスが、Ｍａｒｙがデバイスで「登録する」ために使用することがある指紋読み取り装置もその上に有することがある。顔認識または他の任意の機構も使用されることがある。デバイスにおいて識別されると、顔認識または他の任意の機構は、汎用ショッピングカートの目的で、それが自分のデバイスであったかのようになることができる。デバイスは、類似の目的で、レストランにおいて、店舗において、または任意のロケーションにおいて位置決め可能である。複数の人々が友人の家にいる場合、グループのうちの任意の人々が、人々がその場所に住んでいなくても、デバイスに話し、デバイスをプロファイル、汎用ショッピングカートなどに調整させることができるように、複数のプロファイルが、そのロケーションにある音声対応デバイスに追加可能である。デバイスは、その人間がそのロケーションにいるという知識に基づいて、事前構成されたデータを持たないこともある。システムは単に、ユーザが音声ベースのデバイスに話すとき、音声によってユーザを識別することがある。
【０３４４】
[00414]本明細書において開示される概念は、物理的な商店街にも機能することができる。人々は、２つのことをすることができる。１つのケースでは、ユーザは単に、ショッピングをし、物理的なショッピングバッグに品物を入れる。ユーザは、個々の店舗で精算せず、店舗から店舗へと行くだけである。すべての店舗に対する１つの精算は、１つの支払いとともにすべての品物に使用されることがある。精算は、出口のところであってもよいし、電話であってもよいし、バーコード読み取り装置、または単一のクリックがすべての支払いを処理することができるように製品を組み合わせることができることができる製品の他の識別子を介してであってもよい。
【０３４５】
[00415]また、ユーザは、物理的店舗に行き、購入のために品物を精査することがある。ユーザは、電話機にコード読み取り装置を有することがあり、好きな製品を見たとき、コードをスキャンしてもよいし、コードは、短距離通信または何らかの他のワイヤレスプロトコルを通して自動的に識別されてもよい。次いで、ユーザは、実際には、品物を携行しないことがある。ユーザが店舗のすべてに行き、たとえば４つの品物を４つの異なる店舗で見ると、ユーザは、次いで、モバイルデバイス上のショッピングカートを引き上げ、ショッピングカート内に置かれたそれらの品物をすべて見ることができる。次いで、ユーザはワンクリック購入することができる、支払いはすべて、それぞれの店舗に対して処理される。品物は、購入された品物を運び、それを商店街の東出口にいるＪｏｈｎに配達するための商店街内の各店舗における係員への通知のような、ユーザが店舗を離れるとき、ある出口でユーザに対して持ってこられてもよいし、自宅にいるユーザに配達されてもよく、そのため、ユーザは、ただ出ることができる。システムは、買い手のモバイルデバイスの移動を追跡し、単に商店街内で買い手を見つけるだけでもよい。コードが、適切なユーザが購入製品を受け取っていることを確認するために係員によって使用されることがある。ショッピングカートは、オプションまたはコードまたは他のデータを提供することができる。どれくらい長く待たなければならないかに関するタイミング予想が、ユーザに提供可能である。おそらく、ユーザは、自動車へと歩き始めたときに電話で品物を買うことがあり、どの入口にユーザが入るかに関するジオフェンシング情報を提供することができるモバイルデバイスの追跡が与えられると、ユーザが購入した品物は、ユーザが出口に着いたとき、そこでユーザを待っていることができる。係員は、識別されたロッカー、ユーザの電話機のロケーション情報に基づいたユーザ、またはユーザが単に品物を自宅に持っていくことができるように出口にあるロケーションに、品物を配達することができる。これは、ユーザが、商店街を歩き回るときに購入した品物をすべて持ち歩く必要がない経験を改善する。製品をすべて配達する予想タイミングが提供されることがある。ユーザが、ショッピングカート上の「買う」をクリックする場合があり、システムは、すべての製品がユーザに配達されるとき、１０分の時間を予測することがある。そのことが、人々が買う品物の数を増加させることもある。単一のショッピングカートから、ブラウザ支払い要求ＡＰＩが使用可能であり、プラグインが、異なる店舗に対する支払いをすべて管理することがある。ユーザは、各店舗においてＡｐｐｌｅ  Ｐａｙまたは他の支払い機構を使用することもあり、システムはユーザが出るとき、ユーザが、ユーザが出ようとしており、配達を必要としていることを示すことができるように、単に、購入された品物を「ショッピングカート」へと組み合わせることがある。次いで、品物が収集され、ユーザに配達可能である。１人または複数の係員が、アプリを介して、どの品物を入手するべきか、どの店舗から、購入者の識別情報に関する命令を受信することができ、容易にすべての品物を収集して購入者に持っていくことができる。
【０３４６】
[00416]別の態様では、システムは、さまざまなウェブサイト上で精査されたさまざまな製品を記憶することができる。次いで、ユーザが、製品をショッピングカートへと入力すると、他のサイトからこれらの他の品物のうちの１つまたは複数をショッピングカートにポピュレートするオプションが、提示可能である。システムは、このオプションを戦略的に提示することができる。たとえば、ユーザが、異なるウェブサイト上でトースター内の歯ブラシを精査したが、今、ショッピングカート内に異なるトースターを置く場合、システムは、比較可能な情報とともに提示された他のトースターを見たいかのみを尋ねることがある。ユーザが、最近精査したある数の品物を有する場合、システムは、カートに追加された直近の３つの品物、またはレビューに最も多く時間を費やした品物、または最も高価な品物、またはユーザが所望し得る他の任意の特徴を見たいかどうかを尋ねることがある。この手法は、ユーザが、品物のグループのワンクリック購入のために、どの品物が汎用ショッピングカートに追加されたかを制御することを可能にする。人工知能および／または機械学習手法も、ショッピングカートが、ユーザが実際に購入する閾値確率を有する品物のみがポピュレートされ得るように、ユーザショッピングおよびユーザの買い物習慣に関するナビゲーション履歴を特徴づけるために利用可能である。上記で述べられたように、ショッピングカートは、複数のユーザに関連することもできる。したがって、家族、友人、支払いアカウント、ブラウザ使用状況、または他の任意のグルーピングによる複数のユーザグループが、たとえば、親がショッピングカートを開いた場合、子供によって閲覧された品物が、購入するべきかどうかを決定するためにショッピングカートに追加可能であるように、協調可能である。そのようなショッピングカートはまた、任意のそれぞれのサイトにおいて継続されるショッピングのための出発点とすることができる。たとえば、ショッピングカートが、３つの異なるサイトからの３つの品物を含み、第２のサイトからの第２の品物がトースターではあるが、あまり良くないトースターである場合、選択可能なオブジェクトが、そのサイトにおいて類似の製品に関してショッピングを続けるために提示可能である。オブジェクトは、ショッピングカート内の製品に関連づけられた検索結果をもつが、継続される精査のために比較可能な製品を示す、第２のサイト内のディープリンクにユーザを遷移させるように構成可能である。そのようなシナリオでは、永続的な状態は、ユーザが、継続されるショッピングのために第２のサイトに遷移すると、ユーザが、別個のトースターを選定した場合、ユーザが、品物のグループの再度の単一クリック購入のために、初期トースターを置き換える別個のトースターをもつショッピングカートに戻るように遷移することがあるように、維持されることがある。
【０３４７】
[00417]本明細書において開示される手法の１つの利益は、ブラウザＡＰＩが支払い情報のために利用されるので、ユーザが、ショッピングカートプラグインまたはサービスに支払い情報または住所情報を登録する必要がないことである。しかしながら、ユーザが、ショッピングカートプラグインまたは拡張機能に支払い情報、住所情報、または他の任意の情報を登録する場合、他の機能のうちのいくつかも、適用されることがある。
【０３４８】
[00418]別の態様は、ＡＰＩを利用して、異なる手段でクロスサイトショッピングカートを埋めることに適用される。この別の態様は、ユーザがどのようにして、記憶、集約、プレゼンテーション、および支払い／配達処理のためにＡＰＩまたは他の機構を通してサイトからブラウザまたは他のロケーションに送信された製品情報を有することができるかに関する。サイトは、どの製品をＡＰＩに送信するべきかの決定のために、サイト上でのユーザの検索およびナビゲーションを監視するために、プログラミングをサイトに追加させることができる。たとえば、ユーザが、トースターを見ること、レビューを読むこと、写真を見ることなどに、２０秒を費やした場合、システムは、ブラウザまたは他の場所を用いた記憶のためにＡＰＩを通して製品データを送るのに十分な興味があると決定することができる。ＡＰＩは、たとえば、「ｓｅｎｄｐｒｏｄｕｃｔｄａｔａ（製品、ＵＰＣ、サイズ、時間、色、サイズ、価格、税金、トークン、格付け、他）」のような構文を有することができる。このデータおよび他の任意のデータは、ＡＰＩを通して送信され、購入を行うための後での使用のために記憶可能である。データを送るためのトリガは、自動的であってもよいし、手動であってもよい（ユーザが、データを送るためにオブジェクトをクリックすることなど）。ユーザがサイトにナビゲートすると、サイトは、ＡＰＩが製品情報に利用可能かどうかを決定するためにＡＰＩ要求を送ることができる。そうである場合、サイトは、ＡＰＩを利用して、ユーザが検索する製品に関する製品データを送ることができる。ユーザが、後でサイト上で製品を購入する場合、製品は、ブラウザ製品記憶から除去可能である。データは、ユーザが後で製品を購入することを要望する可能性の評価を含むことができる。この情報のすべては、ＡＰＩを通して記憶ロケーションに送信される。
【０３４９】
[00419]ユーザは、次いで、他のサイトにもナビゲートして、製品をサーフィンすることができる。閾値が満たされると、複数の製品が、記憶のためにブラウザに送信可能である。購入のユーザ可能性などの、製品に関連づけられたデータも送出可能である。ユーザがウェブをサーフィンすると、製品が収集され、ＡＰＩを通して渡され、記憶される。ユーザは、６０秒以上閲覧する、または家族の誕生日の前の２週間に調査されたすべての製品、または１０ドルの価格を上回るすべての製品、もしくは製品がサイトショッピングカート内に置かれた（そしてまた、ブラウザショッピングカートに送信されるべきである）などのナビゲーション内のある段階にある、などの製品データを送信させる環境に関するパラメータを設定することができる。ユーザは、次いで、ｓｉｔｅ３．ｃｏｍにおいて、システムが、買うボタンインターフェース内に、ユーザが検索した第１のサイトおよび第２のサイトからの品物を含む、またはそうすることができるなど、ブラウザＡＰＩインターフェースを使用して購入を行う時点に到達したとき、異なるサイトにまたがって品物をブラウジングすることができる。図１７Ｋを参照されたい。重要な点は、ここでのインターフェースは、ブラウザ支払い要求ＡＰＩインターフェースであり、通常の支払いインターフェースは（そうであってもよいが）必要ではないことである。インターフェースは、他のオプションも含むことができる。たとえば、ユーザが、ｓｉｔｅ３．ｃｏｍにおいて、そのサイトから品物を購入しているとき、支払いインターフェースは、「ブラウザショッピングカートから他の２つの品物を追加する」または「今日検索した品物を追加する」または「今週検索した品物を追加する」ために選択可能なオプションを含むことができる。ユーザは、次いで、それらの品物をショッピングカートに追加させることができ、ワンクリックは、各品物の個々の購入および配達を管理することができる。異なる配達住所、挨拶、または他の任意のデータの一義化は、検索または支払いプロセスの任意の段階で収集され得る。ドロップダウンメニューは、ユーザが購入モードであるとき、さまざまな品物が、集約グループとして支払いのためにまとめて収集可能であるように含まれ得る。ショッピングカートはまた、いかなるサイトとも関係なく、ブラウザ内で直接的に閲覧されることもある。購入を報奨金で奨励するための比較、割り引き、オプションが、品物の集約グループ内で提供可能である。ブラウザまたは他のサービスが、個々のサイトに対する支払いのすべてを管理する。支払い要求ＡＰＩの構文は、本明細書において開示される機能を達成するために調整されることがある。
【０３５０】
[00420]利益は、ブラウザ支払い要求ＡＰＩインターフェースが、ユーザが任意のサイト上で購入を行い、ブラウザ支払い要求ＡＰＩが購入のためにアクセスされるとき、自動的にまたは手動で、ショッピングカート内の他の品物が、ユーザが支払いプロセスを通して入手するためにワンクリックまたはクリックのシリーズで複数の製品を購入することができるようにインターフェースに追加可能であるように、修正可能であることである。閾値は、転送のために満たされ得る。サイトは、ブラウザショッピングカートに追加するためにユーザがクリックすることができる閾値が満たされたときに動的に提示される、プラスボタン、買うボタン、または他のオブジェクトを提供することができる。次いで、ユーザは、次の品物に移動することができる。この概念は、サイトの観点から両方とも適用される（サイトが製品の購入を処理することができるように、ナビゲーションを監視する、ブラウザショッピングカートＡＰＩに製品データを送信することを決定する、および別のサイトからブラウザ支払い要求ＡＰＩインターフェース上での製品の購入についてのデータを受信する。これは、もちろん、ユーザが一度も第１のサイト上で製品にナビゲートしたことがなく、第１のサイト上で、そこで購入を行うことを望んだことがないと示した場合でもである。購入が、支払いインターフェース上で示される製品のグループの一部として別のサイトで行われるとき、ブラウザは、第１のサイトへ戻っての、購入が行われたという通知を管理することができ、ブラウザショッピングカートＡＰＩおよび／またはブラウザ支払い要求ＡＰＩを通して、製品、支払いアカウント、単回使用トークン、住所配達情報、製品識別などについてのデータを送信することができる。データのパッケージは、サイトが支払いを処理し、製品を配達することができるように、以前に検索されブラウザに通信された製品を第１のサイトが識別することを可能にするためのデータのすべて、支払いトークンまたは他の支払いデータ、住所情報などとともに、第１のサイトに送信可能である。サイトは、製品ブラウザＡＰＩが利用可能であるかどうかに基づいて調整することもできる。たとえば、製品ブラウザＡＰＩが利用可能である場合、ボタンが、閲覧されている品物をショッピングカートに追加するために提示可能である。サイトは、メッセンジャーアプリ、通信アプリケーション、ビデオアプリケーションなども含むことができる。そのため、製品が提示されている任意のコンテキストでは、サイトまたはアプリケーションは、ユーザのショッピングカート内での記憶のために製品ＡＰＩにデータを送信する能力を提供する。
【０３５１】
[00421]さらに別の態様では、ユーザがサイトにナビゲートすると、サイトは、ブラウザまたはネットワークベースのサービスに関連づけられたユーザ情報ＡＰＩにアクセスすることができる。ブラウザまたは他の任意のサービスは、ユーザの帽子のサイズ、シャツのサイズ、ズボンのサイズ、ショーのサイズ、色の好み、スタイルの好み、購入履歴、友人および家族の情報などのソーシャルメディア情報、サイズ、好みなどのような情報を記憶することができる。ユーザが検索を始めると、サイトは、そのようなデータを、ＡＰＩを介して受信することができる。このデータに基づいて、サイトは、そのプレゼンテーションをナビゲーションオブジェクトのユーザおよびインターフェースに合わせて調整することができる。たとえば、ユーザが中くらいであることをＡＰＩがサイトに知らせる場合、ユーザは、Ｓ、Ｍ、またはＬのシャツを選定するためにオプションが提示されることを必要としないことがある。色またはスタイルの好みは、ユーザがサイトを検索するとき、ユーザのために調節可能である。ユーザがそれぞれのサイトにナビゲートするとすぐに、サイトは、個人化パラメータを求める、ブラウザへの呼び出しをすることができ、ブラウザは、サイトがブラウジング経験を調節するために使用することができる、ユーザおよび／または他のユーザのための個人データで応答することができる。ユーザは、サイト上のボタン、メニュー、項目の自動送信などのパラメータを設定することができる。
【０３５２】
[00422]実際、ユーザがサーフィンし始めると、インターフェースが、何にユーザが興味を抱いているかを尋ねるために提示可能である。自然言語またはテキストインターフェースは、「私は、妻の誕生日のためにショッピングをしています」などのデータをユーザから受信することができる。システムが、家族／友人のサイズを含むユーザのためのソーシャルメディアデータを知っていると、ユーザは、たとえば妻の誕生日のためのコートを求めて、より効率的にショッピングすることができる。妻に関連づけられた色およびスタイルの選択肢は、提示されるオプションを改善することができる。サイズ情報は、ユーザがサイズを選定することを必要としないように事前構成可能である。任意のパラメータ、ソーシャルメディアデータ、サイズ、好み、スタイル、購入履歴などが、ユーザがナビゲートするにつれてサイトのためのナビゲーション特徴を変更するために使用可能である。シャツ、ズボン、または靴などに関するサイズ選択肢の必要性は、もはやない。そのようなデータは、そのユーザのナビゲーションのためにサイトを再構成するために、ＡＰＩを通してサイトに送信可能である。サイトは、製品／サービスのより効果的なプレゼンテーションを助けることができる、ユーザについての他のデータを受信することができる。サイトが、ユーザが、母親のための本を求めてショッピングしていることを知っている場合、そのことは、より焦点が当てられた製品のプレゼンテーションを確実に助けることができる。
【０３５３】
[00423]さらに、検索される製品は、自動的にまたは手動で、誕生日、またはクリスマス、または母の日など、分類されることがある。分類のためのオプションは、ソーシャルメディアデータ、製品特性、またはメニュー選択に基づいて、サイト上で提示可能である。したがって、ユーザは、異なるサイトをブラウジングし、３つの品物を母の誕生日の品物として、２つの品物を自分の購入品として分類させることがある。ユーザが、ブラウザＡＰＩインターフェースを用いて品物を買っているとき、オプションは、購入のために、母の誕生日の品物を追加する、個人的な品物を追加する、またはすべての品物を追加することがある。品物は、玩具、またはキッチン用品、または浴室用品、またはオフィス用品としてグループ化されることがある。任意の数の手段が、分類された品物のグループをショッピングカートへと追加するために提供可能である。カート内の品物はすべて、手動手段または自動的な手段に基づいてグループ化または編成可能である。したがって、一緒に購入することを望む品物は、より合理化されることがある。
【０３５４】
[00424]いかなる時点においても、一義化ダイアログは、ナビゲーションを改善するためにユーザからの情報に焦点を当てる助けとなることができる。たとえば、ユーザがサイトにナビゲートすると、システムが、「ご自分のためにショッピングされますか、それとも奥様の誕生日のためにショッピングされますか？」と尋ねることがある。ショッピングに何を求めているかについての何らかのデータがあれば、システムは、サイトがユーザのために経験を修正することができるように、ＡＰＩを介してウェブサイトに、個人化された情報、住所情報などを送信することができる。たとえば、「Ｓ」、「Ｍ」、または「Ｌ」のようなサイズボタンではなく、システムは、「Ｍａｒｙ」、「母」、「Ｎａｎｃｙ」、「Ｔｉｍ」を提示することができる。兄弟のＴｉｍのためのサイズを選ぶ必要があるだけである。ドロップダウンメニューは、ユーザがその人のためにショッピングしているさまざまな人々を含むことがあり、そのため、ユーザは、その人を選ぶだけである。名前、サイズ、好みなどのすべては、処理するために、サイトに、１人または複数の人々のために送出可能である。システムが、Ｔｉｍは赤色のシャツを好むことを知っている場合、システムはまた、青色のシャツは最良の選択肢でないことがあることを買い手に提案することがある。
【０３５５】
[00425]いつサイトがＡＰＩを通して製品データを送信するかに関するイベントをトリガすることは、製品に関して費やされた時間、読まれたレビュー、ショッピングカート内に品物を置くこと、製品をレビューすること、ショッピングカート内の他の品物などのサイトに送信されたデータと結合されたこれらの種類のナビゲーションデータの組み合わせ、ユーザについての要約された情報、ユーザのサイズ、色の好みなどとすることができる。ユーザが、個人化されたデータが送られることを許可した場合、割り引きは、ユーザに提供可能である。サイトの観点から、サイトが、受信されたデータに基づいてインターフェースおよび選択可能なオプションを提示するように、サイトは、ユーザナビゲーションを受信し、サイズ情報、スタイルの好み、購入履歴、ソーシャルメディアデータ、休暇データなどの、ユーザのために個人化されたデータを、ＡＰＩを介して受信する。それらの好みは、汎用ショッピングカート内に置くために製品データをＡＰＩにいつ渡すかを決定するアルゴリズムを駆動することもできる。トリガアルゴリズムは、誕生日が近づいていることに基づいて製品のための３０秒時間フレームが２０秒に減少可能であることなど、サイトに送信されたデータに基づいて調整可能である。
【０３５６】
[00426]ソーシャルネットワーク内の人々のためのサイズ情報は、ソーシャルメディアデータにも基づいて渡され得る。たとえば、友人のサイズ情報は、友人の誕生日が近づいている場合に渡され得る。システムはまた、あなたが、衣服のために友人のサイズを選定することができるが、サイズが何であるかを知らないように、そのサイズ情報をトークン化することができる。あなたは、ブラウザ記憶から、トークン化された様式またはセキュアな様式でデータを共有することができる。
【０３５７】
[00427]図１７Ｌは、例示的な方法実施形態を示す。この開示の一態様は、マルチサイト汎用ショッピングカートに適用され、特に、Ｗ３Ｃによって実施されるブラウザ支払い要求アプリケーションプログラミングインターフェースの修正バージョンを使用して適用可能である解決策を提示する。ユーザは、異なるデバイスにまたがって、異なるモダリティを使用して、異なるロケーション内で、複数のサイトにアクセスすることができる。一態様では、方法、システム、またはコンピュータ可読記憶デバイスは、ブラウザの観点から動作する。方法は、ブラウザに関連づけられたブラウザショッピングカートアプリケーションプログラミングインターフェースを介して、ブラウザを使用して第１のサイト上でナビゲートするユーザによって閲覧される第１の製品に関連づけられた第１のデータを受信することであって、ユーザは、第１のサイト上で製品を購入しなかった、受信すること（１７３３）を含む。第１のデータは、ブラウザまたは検索エンティティなどのネットワークサービスにとってアクセス可能であるように記憶される。この記憶は、ブラウザと一緒であってもよいし、ユーザデバイス上であってもよいし、検索エンティティまたは他の支払いエンティティによってホストされるネットワークデバイス上であってもよい。方法は、第２の製品の購入を管理するためにユーザにブラウザ支払いインターフェースを提示することであって、このブラウザ支払いインターフェースは、ユーザのための支払いデータがブラウザ支払い要求アプリケーションプログラミングインターフェースを通してブラウザから第２のサイトに渡されるブラウザ支払い要求アプリケーションプログラミングインターフェースに関連づけられる、提示する（１７３５）ことを含む。支払い要求ＡＰＩの一部として、ユーザが支払いを達成するために対話することができるインターフェースがユーザに提示される。このインターフェースは、複数の品物が「ワンクリック」で購入されることを可能にするために、追加のショッピングカート品物で増大される（インターフェースは通常、少数であるが、複数のフィールドがユーザによって手動で埋められなければならない通常の支払いプロセスよりもはるかに少ない、クリックを必要とする）。方法は、第１の製品についての情報をブラウザ支払いインターフェース上で提示し、ブラウザ支払いインターフェースとのユーザ対話に基づいて第１の製品と第２の製品の両方の支払いを処理する（１７３７）ことをさらに含む。第１の製品と第２の製品の両方の支払いの処理は、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介するブラウザと第１のサイトとの間の第１の通信およびブラウザ支払い要求アプリケーションプログラミングインターフェースを介するブラウザと第２のサイトとの間の第２の通信を使用して、発生することができる。違いは、第２のサイトが第２の製品の支払いプロセスのためにブラウザと既に通信していることである。しかしながら、ユーザは第１のサイトから離れてナビゲートしており、そのため、第１のサイトへの戻るような通信は、製品を識別し、ならびに以前に検索された製品を第１のサイトに「思い出させる」ために第１のサイトに支払��および／または配達データを提供しなければならない。第１の製品と第２の製品の両方の支払いを処理することは、さらに、ブラウザアプリケーションプログラミングインターフェースを通して、第１のサイトが第１の製品の第１の購入を処理することを可能にするデータのパッケージを送信することを含むことができる。データのパッケージは、第１のサイトが、第１の製品のための支払いを処理し、第１のサイトが製品を配達するためにユーザに関連づけられた情報に対処するために支払いデータを含むことができる。方法は、ブラウザ支払いインターフェースを介して１つの製品を購入するために使用されるオブジェクト対話の同じセットを利用して第１の製品と第２の製品の両方の購入のユーザから確認を受信する（１７３９）ことも含むことができる。言い換えれば、ユーザは既に、第２の製品のための支払いを処理するためにブラウザインターフェース内にいるので、方法は、同じ「ワンクリック」およびおそらく１つの指紋認識もしくはＣＶＣコードエントリを利用して、またはいかなるより少数のステップが第２の製品の購入に利用されても、第１の製品のための支払いも処理することを含むことができる。述べられたように、汎用ショッピングカートは、ブラウザＡＰＩとは別個であり、ネットワークエンティティまたは検索エンティティによって完全に管理されてもよい。カートおよび購入を管理するために、ＡＰＩとネットワークエンティティとの間に協調があってもよい。
【０３５８】
[00428]第１の製品および第２の製品のための支払いを処理することは、第１のサイトからの第１の製品の購入および配達を完了するためにブラウザ支払い要求アプリケーションプログラミングインターフェースを介して第１のサイトに第１の情報を通信することと、第２のサイトからの第２の製品の購入および配達を完了するためにブラウザ支払い要求アプリケーションプログラミングインターフェースを介して第２のサイトに第２の情報を通信することとを含むことができる。ブラウザを使用して第１のサイト上でナビゲートするユーザによって閲覧される第１の製品に関連づけられた第１のデータを受信することはさらに、第１の製品に関連づけられた閾値ユーザ対話に基づいて第１のデータを受信することを含むことができる。たとえば、ユーザは、第１の製品をショッピングカート内に入れる、またはボタンをクリックする、または購入関心がある可能性があることを示すある時間の期間にわたって製品を閲覧することを必要とすることがある。別の態様では、検索エンティティは、購入のために支払い証明書ならびに住所および／または他の情報を記憶し、汎用ショッピングカートのための支払いプロセスを管理することができる。
【０３５９】
[00429]第１のサイトの観点からの方法が図１７Ｍに示され、第１のサイトから、ブラウザに関連づけられたブラウザショッピングカートアプリケーションプログラミングインターフェースを介して、ブラウザを使用して第１のサイト上でナビゲートするユーザによって閲覧された第１の製品に関連づけられた第１のデータを送信することであって、ユーザは第１のサイト上で製品を購入せず、ブラウザは、第１のデータがブラウザにとってアクセス可能であるように第１のデータを記憶することを管理することができる、送信する（１７４１）ことと、ユーザが第１のサイトから離れて第２のサイトにナビゲートした後、第１の製品のための支払いを処理するためにブラウザ支払い要求アプリケーションプログラミングインターフェースからデータのパッケージを受信することであって、データのパッケージは、第１の製品を識別し、第１の製品のための支払いを処理するためにユーザに関連づけられた支払いデータを含むことができ、ユーザは、ブラウザアプリケーションプログラミングインターフェースを使用して第２のサイト上で第２の製品の購入を管理することの一部として提示されたブラウザ支払いインターフェースとの対話を介して第１の製品のための支払いを確認した、受信する（１７４３）こととを含むことができる。
【０３６０】
[00430]第１のサイトにおいて受信されるデータのパッケージはさらに、第１の製品の配達のためにユーザのための住所情報を含むことができる。方法は、支払い方法を識別し、ショッピングカートを通信するために第１のサイトと第２のサイトの両方から必要とされる任意の通信と、ブラウザの支払い能力、製品データ、第１のサイト上でのユーザの検索に関連づけられたセッションデータ、ユーザデータ、支払いデータ、配達データ、サイズデータ、または第１の製品のための支払いを処理することもしくは異なるサイトからの複数の製品が単一のショッピングカートを介して購入可能であるように第１の製品および第２の製品をブラウザ支払い要求ＡＰＩに関連づけられたブラウザ支払いインターフェースへと集約することに関連づけられた他の任意のデータとを含むことができる。本明細書において参照される、ショッピングカートを処理するためのいかなる概念も、包含される実施形態に応じて第１のサイトまたは第２のサイトの観点から適用することができる。
【０３６１】
[00431]別の態様では、ユーザは、ブラウザショッピングカート内にいくつかの品物を有し、品物を購入し、それらを配達させたいと決定することがある。しかしながら、ユーザは、ブラウザＡＰＩ支払いインターフェースを開始するためにサイト上の製品にナビゲートし、サイト上で品物の購入を行わなければならないことを望まないことがある。この場合、システムは、ブラウザ上での通知を提供することができ、または動的オブジェクトが提示されることがあり、またはユーザがブラウザからショッピングカート品物とともに支払いインターフェースが提示されることを可能にするメニュー項目が提示されることがある。ユーザは、ブラウザタイプ、支払い要求ＡＰＩタイプ、またはユーザアカウントタイプに関連づけられた、動的に修正された買うボタンが提示可能である。次いで、ユーザは、必要とされるオブジェクトとの対話を介して、それらの品物を購入することができる。この場合、ユーザはサイト上にいないので、たとえば、ショッピングカート内に第１のサイトからの第１の品物および第２のサイトからの第２の品物がある場合、ブラウザＡＰＩは、サイトが標準的な支払い要求ＡＰＩによる支払い要求を開始していなかった場合でも製品の支払いおよび配達を処理するために、それぞれのサイトに製品ＩＤ、支払いの詳細、住所の詳細などを送信する。Ａｐｐｌｅ  Ｐａｙなどの支払いサービスが使用される場合、それらは、購入を処理するためにそれぞれのサイトによって必要とされる標準的なデータ（カードタイプ、受信されるトークン、行われた購入の確認など）がＡＰＩを介して受信可能であり、製品の配達が達成可能であるように、適切に処理可能である。ショッピングカートはまた、ユーザが、ソーシャルメディアサイト（Ｆａｃｅｂｏｏｋは、ショッピングカート内に品物があることを示す選択可能なオブジェクトを有することがある）、テキスト送信アプリケーション、電子メールアプリケーション、カレンダーアプリケーションなどの上で、サーフィンする場合はどこでも、利用可能にされるであろう。
【０３６２】
[00432]別の態様では、あるサイトがＡｐｐｌｅ  Ｐａｙを使用し、別のサイトがＶＩＳＡを必要とし、第３のサイトがＡｎｄｒｏｉｄ  Ｐａｙを使用するとき、サイトからの３つの品物をもつユーザのショッピングカートは、いくつかの異なる対話（指紋対ＣＶＣコードなど）を利用して、支払いを最終決定することがある。そのような対話に違いがある場合、インターフェースは、１つのオブジェクト上のワンクリックが、「Ａｐｐｌｅ  ＰａｙおよびＡｎｄｒｏｉｄ  Ｐａｙで支払う」または「Ａｐｐｌｅ  ＰａｙおよびＶＩＳＡで支払う」を示すことができるように、要件を集約することができる。次いで、インターフェースが、指紋を、次いでＣＶＣコードを要求することがある。さまざまな対話の集約および編成は、異なる支払い機構を用いて１つのショッピングカート内で購入を行うプロセスを単純化することができる。
【０３６３】
[00433]別の態様は、ＡＰＩの異なるバージョン間でどのようにして協調させるかに関する。たとえば、ユーザが、所有権を主張できるブラウザＡＰＩを利用するＡｐｐｌｅ  Ｐａｙを使用して購入を行っている場合、システムは、業界標準であるＷ３Ｃブラウザ支払い要求ＡＰＩに関連して記憶されたショッピングカート品物についてのデータにアクセスすることがある。一般的なプロトコルが使用されるにせよ、異なるＡＰＩ間でのパラメータの何らかの翻訳が使用されるにせよ、１つの手法は、集約されたショッピングカートが、ブラウザＡＰＩの２つの異なるバージョンもしくはブラウザショッピングカートＡＰＩの２つのバージョン、または２つの異なる購入インターフェースにまたがるときでも、複数の品物がショッピングカート内で購入されるように、１つの買うボタンまたは集約された対話のセットとともに、１つの単一ショッピングカートを提示することである。一例では、ユーザがＡｐｐｌｅ  Ｐａｙインターフェース内におり、買うボタンをクリックし、指紋を用いた３つの品物の購入を確認し、３つの品物のうちの１つはＡｐｐｌｅ  Ｐａｙの品物であり、３つの品物のうちの２つは、異なるコンテキストから組み込まれるが、１つの品物に対してはＡｎｄｒｏｉｄ  Ｐａｙを、別の品物に対してはＶＩＳＡ支払いを必要とし、各々は異なるサイトからであると仮定する。ローカルデバイスおよび／またはサーバは、購入の確認が、通常のやり方でＡｐｐｌｅ  Ｐａｙ購入を処理するために利用されるが、次いで、Ａｎｄｒｏｉｄ  Ｐａｙを介する第２の品物の購入が達成され、ＶＩＳＡを介する第３の品物の購入が協調されるようにそれぞれのサイトと通信するプロセスを実行するようにＷ３Ｃ  ＡＰＩに命令を提供することができるように、Ａｐｐｌｅ  Ｐａｙプロセス（Ｓａｆａｒｉ内）とＷ３ＣブラウザＡＰＩ（たとえば、ＣｈｒｏｍｅまたはＭｏｚｉｌｌａまたはＭｉｃｒｏｓｏｆｔ  Ｅｄｇｅ上など）との間で情報の通信を協調させることができる。したがって、この態様は、複数のサイトおよびブラウザ支払い要求ＡＰＩの複数のバージョンにまたがる複数の品物を含む単一のショッピングカートが複数の品物をまとめて購入するために使用されるとき、シーンの背後でさまざまなサイトからの購入が達成されることを可能にする目的で、２つの異なるＡＰＩ（ブラウザ）との間の協調および交換される情報のすべてを包含する。この態様は、ブラウザＡＰＩ支払いインターフェースの一部としてショッピングカート内の品物のワンクリック購入を達成するために、ブラウザ間ならびにブラウザ、異なるサイト、サービス、および／または支払いプロセッサのうちの１つまたは複数の間での通信、応答、確認、セキュリティ関係通信、命令などをすべて包含するが、ショッピングカート内の品物の含有は、異なるサイトおよび支払いの処理の通知が複数の製品のための単一の支払いプロセスに基づいて実行可能であるように、ブラウザ支払いＡＰＩの異なるバージョンまたは異なるブラウザにまたがる。したがって、Ｓａｆａｒｉは、支払いインターフェースを管理するが、ショッピングカート品物を受信し、次いで、ショッピングカート内のそれぞれのＣｈｒｏｍｅ品物の購入をＣｈｒｏｍｅに通知��るためにＣｈｒｏｍｅと通信することがある。次いで、Ｓａｆａｒｉは、サイトからの製品購入のその支払いを管理することができ、Ｃｈｒｏｍｅは、そのサイトから購入された製品のその支払いを管理することができる。さらに、ショッピングカートは、他の非ブラウザＡＰＩインターフェースと統合可能である。たとえば、ＰａｙＰａｌインターフェース、またはＡｍａｚｏｎ支払いインターフェースは、ブラウザに関連して記憶されたショッピングカート品物にＡＰＩを介してアクセスし、異なるブラウザＡＰＩインターフェースだけでなく非ブラウザＡＰＩインターフェースにまたがって、それらの品物を複数の品物のワンクリック購入経験へと組み込むまたは集約することもある。
【０３６４】
複数のブラウザＡＰＩバージョン
[00434]ブラウザＡＰＩの異なる特色がある。同じＡＰＩの異なるバージョンを利用するＡｐｐｌｅ  ｐａｙと標準化されたＷ３ＣブラウザＡＰＩがある。他のものもあってよい。ユーザは、支払いを行うために、ＰａｙＰａｌアプリなどの異なるアプリもデバイス上で利用する。これらのブラウザＡＰＩのうちの１つを使用して精算手順を提供することを要望する任意の特定のウェブサイトは、どのブラウザＡＰＩが利用可能かを検出し、したがって、ユーザが対話するオブジェクトとして提示するために適切な買うボタンを選定することを必要とすることがある。ユーザがブラウザとしてＭｉｃｒｏｓｏｆｔ  ｅｄｇｅを使用している場合、販売業者サイトは、Ａｐｐｌｅ  ｐａｙ買うボタンを提示しないべきである。したがって、本明細書において開示される概念は、販売業者サイトが、どのブラウザＡＰＩが利用可能であるかを決定することを伴う。Ｓａｆａｒｉ、Ｍｏｚｉｌｌａ、Ｍｉｃｒｏｓｏｆｔ  ｅｄｇｅ、ｃｈｒｏｍｅ、Ｓａｍｓｕｎｇ、インターネットなどの間で、どのブラウザが使用されているかを決定するための販売業者サイト。販売業者サイトは、次いで、サイトをナビゲートするために使用されているそれぞれのブラウザに適切である買うボタンを提示することができる。販売業者サイトが、ユーザがＡｐｐｌｅｓ  Ｓａｆａｒｉブラウザを使用してサイトをナビゲートしていると決定した場合、ユーザが購入する意図を示すために対話することができる、提示されるオブジェクトは、Ａｐｐｌｅ  ｐａｙボタンとすることができる。これは、もちろん、ユーザがデバイス上でＡｐｐｌｅ  ｐａｙがセットアップされているかを決定するために、ＡＰＩを通じた呼び出しも伴うことがある。
【０３６５】
[00435]販売業者サイトは、支払いプロセスを管理するためにインターフェースの一部として何らかのブランディングを提供することもある。したがって、ユーザがＭｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔを有し、Ｍｉｃｒｏｓｏｆｔ  ｅｄｇｅを使用している場合、インターフェースは、Ｍｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔのためのブランディングを含むことができる。いずれのケースでも、販売業者サイトが、ユーザがオブジェクトをクリックするまたはこれと対話する際、どの買うボタンを提示するべきかを決定した後、販売業者サイトが、購入を完了し、製品を配達するために、支払いデータ、名前、住所、セキュリティコード、指紋識別、オーディオ情報、視覚的情報または顔情報などのうちの１つまたは複数を、ブラウザＡＰＩを通して受信することができるように、販売業者サイトは、それぞれのブラウザＡＰＩを通して支払い情報を要求し、購入に関連づけられた必要なデータを提供するために通信する。本開示のこの態様は、どのブラウザＡＰＩを使用するべきかと、不適切なまたは利用できないオプションが、改善された精算プロセスがブラウザＡＰＩの使用を通して利用可能であることの一部として、ユーザに提示されないことを保証するためにユーザインターフェースをどのようにして提示するかに関する、販売業者サイトによる決定評価を主に伴う。
【０３６６】
[00436]ブラウザＡＰＩ間の違いは、販売業者検証手順を利用する、またはユーザがブラウザを介してサイトにアクセスしている別個のユーザデバイスからの支払いデータの通信を可能にすることであることがある。たとえば、Ａｐｐｌｅ  ｐａｙは、異なるプロトコルをもつブラウザＡＰＩ、次いで、Ｗ３Ｃ支払い要求ＡＰＩを有する。Ａｐｐｌｅ  ｐａｙは、販売業者検証手順を必要とし、ユーザが、ラップトップコンピュータまたはデスクトップコンピュータ上でＳａｆａｒｉブラウザを介して販売業者サイトにアクセスすることも可能にし、ユーザがブラウザを介してサイト上でＡｐｐｌｅ  ｐａｙ買うボタンをクリックするとき、Ｓａｆａｒｉブラウザは、ラップトップコンピュータまたはデスクトップコンピュータとＢｌｕｅｔｏｏｔｈを介して通信する、ｉＰｈｏｎｅなどの別個のモバイルデバイス上の支払いデータにアクセスすることができる。したがって、Ａｐｐｌｅ  ｐａｙを使用するとき。このようにして、ユーザは、ラップトップコンピュータまたはデスクトップコンピュータ上で、Ａｐｐｌｅ  ｐａｙをクリックし、次いで、Ｂｌｕｅｔｏｏｔｈを介してラップトップコンピュータまたはデスクトップコンピュータにリンクされたｉＰｈｏｎｅ上での指紋検証を提供する。もちろん、他の変形形態は、第１のブラウザ支払い要求ＡＰＩと第２のブラウザ支払い要求ＡＰＩとの間に存在し得る。顔認識は、識別を検証するためにも使用可能である。
【０３６７】
[00437]別の態様では、ユーザは、Ｓａｆａｒｉを使用することではなく、ＭａｃＢｏｏｋ上のＭｏｚｉｌｌａを使用していることがある。ユーザは、Ａｐｐｌｅ  Ｐａｙのための支払い情報を記憶しているかもしれない。システムは、ユーザがユーザデバイス上のＳａｆａｒｉブラウザを通してであるがＭｏｚｉｌｌａを用いてブラウジングしていることを検出することがあり、ユーザがＡｐｐｌｅ  Ｐａｙを実施することがある。データの適切な通信は、ユーザが、Ｍｏｚｉｌｌａを用いてサーフィンしているときでも、Ａｐｐｌｅ  Ｐａｙを使用することが可能であるように提供されることがある。これは、たとえば、ユーザがＡｐｐｌｅ  ｉＯＳデバイスを使用しており、Ａｐｐｌｅ  Ｐａｙ構成を有するという検証を必要とするであろう。販売業者サイトは、Ａｐｐｌｅ  Ｐａｙが利用可能であるＭｏｚｉｌｌａブラウザを通して、通知を受信するであろう。データは、Ｍｏｚｉｌｌａが販売業者サイトへ情報を通してトンネリングするために、ユーザデバイス上でＭｏｚｉｌｌａブラウザからＳａｆａｒｉブラウザへの通信リンクを可能にすることがあることを確認するために通信されることがある。このようにして、Ｍｏｚｉｌｌａは、販売業者サイトがＡｐｐｌｅ  Ｐａｙボタンを提示することがあり、Ａｐｐｌｅ  Ｐａｙ支払いを行うために使用される同じ対話がＭｏｚｉｌｌａブラウザＡＰＩを通して行われることがあるように、ＭｏｚｉｌｌａがＳａｆａｒｉおよび販売業者サイトと通信することができるように、Ｓａｆａｒｉのインスタンスに、Ａｐｐｌｅデバイスのバックグラウンドにおいて開始させることがある。
【０３６８】
[00438]別の態様では、方法は、ユーザが、第１のブラウザまたは第２のブラウザを介してサイトにアクセスしているかどうかを決定することであって、決定をもたらすために、第１のブラウザは第１のブラウザ支払い要求ＡＰＩを実施し、第２のブラウザは第２のブラウザ支払い要求ＡＰＩを実施する、決定することを含む。決定が、ユーザが第１のブラウザを介してサイトにアクセスしていることを示すとき、方法は、購入に関連づけられたサイト上で第１の買うボタンを提示することと、ユーザによる、第１の買うボタンとの対話を受信することとを含む。方法は、ユーザデバイス上に記憶された支払いデータを受信するために、第１のブラウザ支払い要求ＡＰＩを介して支払い要求を送信することと、第１のブラウザ支払い要求ＡＰＩを介して支払いデータを受信することとを含む。決定が、ユーザが第２のブラウザを介してサイトにアクセスしていることを示すとき、方法は、購入に関連づけられたサイト上で第２の買うボタンを提示することと、ユーザによる、第２の買うボタンとの対話を受信することと、ユーザデバイス上に記憶された支払いデータを受信するために第２のブラウザ支払い要求ＡＰＩを介して支払い要求を送信することと、第２のブラウザ支払い要求ＡＰＩを介して支払いデータを受信することとを含む。
【０３６９】
[00439]第１のブラウザ支払い要求ＡＰＩは、第２のブラウザ支払い要求ＡＰＩからとすることができる。第１のブラウザ支払い要求ＡＰＩは、サイトを検証することができる。第１のブラウザ支払い要求ＡＰＩは、複数のユーザデバイスが第１のブラウザ支払い要求ＡＰＩを介してサイトに支払いデータを提供するために通信することを可能にすることができる。ユーザは、ユーザクライアントデバイス上で第１のブラウザを介してサイトにアクセスすることができる。第１のブラウザは、ユーザクライアントデバイスに、ユーザデバイス上に記憶された支払いデータをワイヤレスで受信させることができ、ユーザデバイスは、ユーザクライアントデバイスとは物理的に別個のデバイスである。ユーザデバイスは、Ｂｌｕｅｔｏｏｔｈワイヤレスプロトコルを介してユーザクライアントデバイスと通信することができる。
【０３７０】
[00440]さらに、調節された情報が、各インターフェースに提供可能である。たとえば、Ａｐｐｌｅ  ｐａｙは、それ自体のブラウザＡＰＩを有し、Ｍｏｚｉｌｌａ、Ｍｉｃｒｏｓｏｆｔ  ｅｄｇｅ、ｃｈｒｏｍｅなどの他のブラウザは、Ｗ３ＣブラウザＡＰＩを利用する。特定のウォレットが、各ブラウザとともに利用されることがある。たとえば、Ｍｉｃｒｏｓｏｆｔ  ｅｄｇｅは、ブラウザＡＰＩを通して支払い情報を提供するためにＭｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔを利用する。ユーザは、支払いを行うためにどのウォレットが使用されているかを見ることを要望することがある。たとえば、ユーザが、Ｍｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔ内にｖｉｓａを記憶させるが、Ｇｏｏｇｌｅ  ｗａｌｌｅｔ内にＭａｓｔｅｒＣａｒｄを記憶させることがある。したがって、本開示の一態様は、特定のトランザクションに使用されているウォレットを識別するブラウザＡＰＩに関連して支払いプロセスに関連づけられたインターフェース上で通知を提供することである。実際、ユーザがデバイス上で複数のブラウザを有することがあり、したがって、複数のウォレットを有することがある一態様では、本開示の一態様は、ブラウザＡＰＩインターフェース内でユーザを提示しており、異なるウォレットから選択するオプションは、ブラウザＡＰＩを通して通信されることになる支払いデータのための記憶ロケーションであった。この点に関して、方法は、ブラウザ支払い要求ＡＰＩインターフェースの一部としてユーザによって選択可能であるオブジェクトを提示することを含むことがある。オブジェクトは、支払いに使用するために、デフォルトウォレットに関連づけられることがある。別の態様では、インターフェースは、ユーザが適切なウォレットを選択するためにただ単純にクリックすることができるいくつかのオブジェクトを単に提示することがある。たとえば、インターフェースは、Ｍｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔのためのオブジェクト、Ａｐｐｌｅ  ｐａｙのためのオブジェクトを提示することがある。これらは、ユーザが、支払いを行い、特定のウォレットを使用することを要望することを単に示すワンクリック動作であってよい。別の態様では、Ａｐｐｌｅ  ｐａｙなどのデフォルトウォレットが、他の代替ウォレットが利用可能であることがあることを示すオブジェクトとともに提示されることがある。ユーザがデフォルトウォレットから変更するために選択することが不可能である、ボタン、ドロップダウンメニュー、またはリンクが提供されることがある。オブジェクトとのユーザ対話を受信すると、ブラウザＡＰＩを介する情報の交換は、選定されたウォレットに従って、通常のプロセスで継続する。
【０３７１】
[00441]上記のシナリオを使用して、アクションにおける手法の一例が、ユーザがＳａｆａｒｉを介してウェブをサーフィンしており、ウィジェットを購入することを望む場合であることがある。ユーザがＡｐｐｌｅ  ｐａｙアカウントを有するので、Ａｐｐｌｅ  ｐａｙボタンが、ユーザが選択するための支払いプロセスの一部として提示される。しかしながら、ユーザが、必要な支払いアカウント番号、ユーザ住所などを含む支払い情報をオートフィルデータベース内に含むデバイス上でＭｏｚｉｌｌａブラウザも有する場合、インターフェースは、Ｍｏｚｉｌｌａが記憶したデータを通して支払いするオプションをユーザに提示することができる。この点に関して、Ｓａｆａｒｉブラウザは、支払いのためにＡｐｐｌｅブラウザＡＰＩを通して販売業者に通信される支払いデータを受信するために、Ｍｏｚｉｌｌａブラウザと通信することがある。ＡＰＩは、データのブラウザ通信へのそのようなブラウザのために使用されることがある。さらに、ユーザは、Ｍｉｃｒｏｓｏｆｔ  ｅｄｇｅブラウザおよびＭｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔも有すると仮定する。この点に関して、ユーザは、支払いを行うためにＭｏｚｉｌｌａアカウントまたはＭｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔアカウントのどちらかに切り換えるオプションが提示されることがある。いくつかの点では、代替支払い機構が選択された場合、システムは、関連づけられたブラウザを起動し、次いで、このブラウザが販売業者と通信することがあり、支払い情報が、そのブラウザＡＰＩを通して販売業者に通信されることがある。言い換えれば、ユーザが、Ｓａｆａｒｉ上で販売業者サイトをブラウジングし始め、中で支払いにＭｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔを選択する場合、デバイスは、ＳａｆａｒｉブラウザとＭｉｃｒｏｓｏｆｔ  ｅｄｇｅブラウザとの間の必要な通信を引き起こすことができ、これは、Ｍｉｃｒｏｓｏｆｔ  ｅｄｇｅブラウザを起動し、販売業者が、Ｍｉｃｒｏｓｏｆｔ  ｅｄｇｅブラウザへの支払い要求ＡＰＩ呼び出しを起動する、または購入を取り扱うためにＭｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔ内に記憶された支払いデータを単に受信する、のどちらかを行うように、ウィジェットが購入されているセッションへのディープリンクまたは通信を提供する。この手法は、どのウォレットが特定の購入に使用されるかに対するより多くの制御をユーザに与えることができる。この手法は、任意の特定の部分の購入に使用されることがある利用可能なウォレットすべてをユーザに通知する、ユーザとの通信の容易さも提供する。この手法は、もちろん、購入を行うためにデバイス上で利用可能であり得るビットコインまたは他の暗号通貨を含むようにも拡張されることがある。
【０３７２】
[00442]銀行またはクレジットカード企業は、そのような選択を行うための割り引きまたはクーポンを提供することがある。たとえば、ユーザインターフェース内で、Ａｐｐｌｅ  ｐａｙがデフォルト支払い機構である場合、販売業者、または銀行、または他の任意のエンティティは、ユーザが支払いにＭｉｃｒｏｓｏｆｔ  ｗａｌｌｅｔ内の支払いアカウントを選択した場合、ウィジェットの価格に対する割り引きを提供することがある。これがあることがあるのは、Ａｐｐｌｅ  ｐａｙが販売業者に請求するからである、または特定のクレジットカードも、購入に対してより高い料金を請求するからである。この点に関して、本開示の一態様は、特定の購入に対して、ブラウザＡＰＩを介してユーザデバイスから行われるために利用可能である各可能な支払いアカウントに関連づけられたさまざまな料金または代金を評価することを含む。１つの特定の利用可能な支払いアカウントが、より低い料金を有するまたは特定の利益を提供するという決定が行われた場合、方法は、代替支払いアカウントを選択し、それによってウィジェットに関する割り引きされた価格または何らかの他の利益を受け取る機会をユーザに提供するユーザ支払いインターフェースの一部として、割り引き、またはクーポンを提示することを含むことができる。ユーザは、デバイス上の各ブラウザを通してさまざまなウォレットを利用可能にする手法を選ぶ。そのうえ、広告または通知も、ソーシャルメディアデータ、以前の購入履歴、購入に使用するために利用可能なウォレットなどに基づくことがあるブラウザＡＰＩインターフェース上に提示されることがある。
【０３７３】
ワンクリック支払いのための全体的なアーキテクチャ
[00443]図１８Ａは、販売業者ショッピングカートを事前にポピュレートするため、ならびにブラウザＡＰＩを使用するための、例示的なアーキテクチャ１８００を示す。この例では、ウェブブラウザ１８０６を実行しているコンピューティングデバイス１８０４のユーザ１８０２は、統一された入力フィールドをもつウェブページまたはソーシャルネットワーキングサイトなどの他の任意のサイトをロードする。サイトは、ＡＰＩ１８１２を介してサーバ１８１０と通信する。サーバ１８１０は、任意のサイトまたはアプリ、支払いサービスアプリケーションすら表すことができる。ユーザ１８０２が、統一された入力フィールド内でデータを入力すると、または、そのそれぞれの機能に基づいて他の任意の手段でサイトと対話すると、ブラウザ１８０６は、ＡＰＩ１８１２を介してサーバ１８１０にデータを送る。サーバ１８１０は、統一された入力フィールド内に入力されたデータに基づいてユーザ１８０２の意図が購入を行うことであることを識別するために、データを分析することができる。サーバ１８１０は、所望の品物を販売する販売業者ウェブサイト１８１６を識別し、その販売業者ウェブサイト１８１６と、利用可能である場合はその関連づけられたブラウザ支払い要求ＡＰＩ１８１８を介して、通信することができる。このシナリオにおける一態様では、記憶された支払いデータ１８１４は、サイト１８１０が支払いを処理し、製品を配達するために販売業者とＡＰＩを介して支払い詳細および情報を販売業者１８１６に通信することを可能にすることができる。ＡＰＩが利用可能でない場合、サーバ１８１０は、ＨＴＴＰを介して販売業者ウェブサイト１８１６と通信することができ、ユーザが販売業者ウェブサイト１８１６をクリックしているまたはその上でデータを入力しているかのように自動化されたやり方でウェブサイトをナビゲートすることができる。サーバ１８１０は、支払いおよび配達データまたはユーザ１８０２についての他の個人データのネットワークベースのデータベース１８１４を使用して、販売業者ウェブサイト１８１６におけるデータフィールドにポピュレートすることができる。
【０３７４】
[00444]しかしながら、ネットワークベースのデータベース１８１４が不完全でないまたは存在していない場合、サーバ１８１０は、ＡＰＩ１８１２を介して、ブラウザ１８０６またはコンピューティングデバイス１８０４のローカルにある支払いおよび配達データのデータベース１８０８に、データを要求することができる。支払いデータ１８０８は、ＹｏｕＴｕｂｅアカウント、または電子メールアカウントに関連づけられる、またはｉＴｕｎｅｓアカウントなどの他の目的の場合であっても、ローカルデバイス上に（またはネットワークベースのサービスにおいて）記憶される任意の支払いデータとすることができる。ユーザが、ブラウザ、または電子メールアカウントもしくは他の任意のタイプのアカウントにログインし、記憶された支払いデータがある場合、システムは、商業購入を開始するために、その支払いデータを利用するまたはこれにアクセスすることができる。ユーザが購入を行っているとき、システムは、Ｇｏｏｇｌｅ  Ｗａｌｌｅｔ内のクレジットカード、およびＰｌａｙ  Ｓｔｏｒｅアカウントなどの、記憶されたさまざまな支払いアカウントを提示し、ユーザに、利用可能な支払いオプションの中から選定させることができる。これはまた、Ｃｈｒｏｍｅ内に記憶された情報およびＡｍａｚｏｎ．ｃｏｍ上に記憶されたＡｍａｚｏｎアカウントなどのプラットフォームにまたがって発生することができる。このシナリオでは、Ａｍａｚｏｎ．ｃｏｍデータは、サーバ１８１０およびデータ１８１４によって表されることができ、ＡＰＩ１８１２または他の手段を通してブラウザ１８０６に提供可能である。ブラウザ１８０６は、任意の記憶された支払いデータにアクセスし、これを、支払いプロセスを単純化するために利用することができる。サーバ１８１０は、販売業者ウェブサイト１８１６における購入のために選択された製品を介して統一された入力フィールド内でユーザによって入力された追加のデータを連続的に受信し、販売業者ウェブサイト１８１６において入力されたデータを更新または修正することができる、または異なる販売業者ウェブサイトに完全に切り換えることすらできる。サーバ１８１０は、ＡＰＩ１８１２を介してブラウザ１８０６に応答を送信することができ、そのため、ブラウザ１８０６は、統一された入力フィールド内で入力されたデータに基づいて、アクションまたは宛先をユーザ１８０２に提示することができる。次いで、ユーザが、アクションまたは宛先のうちの１つを選択した場合、ブラウザ１８０６は、そのページにナビゲートし、直接的に、またはサーバ１８１０なしで、販売業者ウェブサイト１８１６と通信することができるが、サーバ１８１０は、販売業者ウェブサイト１８１６においてユーザ１８０２の行動を追跡するためにブラウザ１８０６と引き続き通信することがある。たとえば、サーバ１８１０は、統一された入力フィールドを通して参照される最終的な購入詳細を追跡することがある。サーバ１８１０は、ローカル支払いおよび配達データ１８０８から処理された情報に基づいて、またはユーザ入力に基づいて、ネットワークベースの支払いおよび配達データ１８１４を時々更新することができる。ブラウザ支払い要求ＡＰＩ１８１８は、���払いプロセスを単純化するために、販売業者サイト１８１６とブラウザ１８０６との間で情報を通信するための基本プロトコルを確立する。ブラウザ１８０６はまた、音声制御アシスタントまたは機器などの任意のデバイスを表すことができる。ブラウザ１８０６からＡＰＩ１８１８を通して販売業者サイト１８１６に通信される支払いデータは、セキュリティ目的でトークン化可能である。次いで、販売業者サイト１８１６は、支払いプロセッサ１８２０を用いて製品のための支払いを処理することができる。この手法の利益は、同じ支払いインフラストラクチャが、販売業者によって使用可能であり、サイトに対する小さな変化のみが、ブラウザＡＰＩ１８１８を利用して、支払いを処理するために必要なデータを取得するために必要とされる。図１８Ａに示されるように、任意の種類のデータ１８０８を取得するためにＡＰＩ１８１８を介したブラウザ１８０６と販売業者サイト１８１６との間の通信は、双方向で発生することができる。したがって、販売業者１８１６は、ブラウザＡＰＩを通じてデータの要求を開始し、ユーザが支払いアカウント、住所情報、ならびにシャツのサイズ、ズボンのサイズ、靴のサイズ、色の好み、ワンクリック購入パラメータなどの他の任意のデータを手動で埋め込む必要性を回避するために、支払いデータなど、任意の目的で、そのデータを受信することができる。
【０３７５】
[00445]たとえば、販売業者サイト１８１６がａｍａｚｏｎ．ｃｏｍであり、サイトは、ａｍａｚｏｎ．ｃｏｍに到着するユーザの支払いアカウントおよび住所を既に持っている場合、ワンクリック購入許可またはパラメータが、宛先状態が「ワンクリック」購入状態であるためにブラウザ１８０６上で設定されることが必要であることがある。サーバ１８１０からサイト１８１６への遷移では、プロセスは、アクセスすることまたはユーザがサイト１８１６に到着することを可能にするためにワンクリック購入状態がブラウザに対して「オン」であることを確認することを含み、製品を購入するために次の対話をワンクリックにすることができる。
【０３７６】
[00446]支払い要求ＡＰＩ１８１８を実施するさまざまな例示的な態様が、本明細書において開示されている。支払いおよび／または配達データは、購入を処理するために使用されることがある他の任意のデータ（ユーザプロファイルデータ、ワンクリック購入データ、設定、パラメータなど）のように、ローカルに、ユーザデバイス１８０４上で、記憶可能である１８０８、またはネットワークサーバもしくはサービス、もしくは両方の組み合わせから取り出されることがあることが留意される。たとえば、ブラウザ１８０６が、ＡＰＩ１８１８を通して支払い要求を受信するとき、ブラウザ１８０６は、購入に関連づけられたネットワークサーバとデータを通信することがある。ネットワークサーバは、支払いを処理するために販売業者に渡すために、データを暗号化し、ユーザデバイスに戻すように送信されるトークンを作成することができる。サーバ１８１０は、ソーシャルメディアサイトなどの検索サイト以外の任意のサイトも表すことができ、それぞれのサイトに関連づけられたそれぞれの機能は、どのようにして第１のサイト１８１０との対話から宛先販売業者エンティティサイト１８１６に遷移することがあるかに適用される。言い換えれば、遷移対話を開始することは、データを入力フィールドへと入力することではないかもしれず、ゲーム、地図アプリケーション、会議アプリケーションに関連づけられた広告または対話と対話することなどの、それぞれのサイトに関連づけられた任意の対話であることがある。
【０３７７】
[00447]一態様では、図１８Ａに示されるように、サイト１８１６はまた、ＡＰＩ１８１８を介してサーバ１８１０に支払いデータを要求することができ、サーバ１８１０は、支払いデータ、ユーザデータ、および／または他のデータへのアクセスを有することができる。したがって、たとえば、サイトは、ユーザが、製品のためにナビゲートし、購入を行うことを決めると、買うボタンを提示することがあり、その購入をワンクリックタイプ経験に変えるために、サイトは、たとえば、ＧｏｏｇｌｅベースのサーバまたはＡｍａｚｏｎベースのサーバなどのサーバへのＡＰＩ呼び出しを実行し、ＧｏｏｇｌｅもしくはＡｍａｚｏｎ、または他の任意のエンティティに記憶された支払い情報および／または他のデータを取り出すことがあり、これらの情報および／またはデータは、製品の支払いおよび潜在的には買い手への配達を処理するためにＡＰＩを通して販売業者サイトに渡され得る。したがって、たとえばＧｏｏｇｌｅ  Ｐｌａｙ内に、または電子メールアドレスまたはＹｏｕＴｕｂｅとともに、またはＡｍａｚｏｎにおいて、記憶された支払いデータは、ユーザが購入を行うためにデータを手動で入力する必要がないように、迅速および容易にアクセスおよび提供されることがある。サーバ１８１０はまた、支払いを行うためにブラウザ１８０６に関連して記憶された支払いデータにアクセスする場合がある。実際、ＡＰＩ１８１８および／またはＡＰＩ１８１２は、ユーザインターフェースを介して、たとえば、ブラウザ１８０８内に記憶された１つの支払いオプションおよびＧｏｏｇｌｅサーバ１８１４において記憶された１つの支払いオプション、またはＡｎｄｒｏｉｄ  Ｐａｙなどのいくつかの異なる支払いオプションを提示し、ユーザがどの支払いアカウントを支払いに使用するべきかを選定することを可能にするために使用されることがある。選定された支払いアカウントについての情報は、処理のためにＡＰＩ１８１８を通してサイト１８１６に渡され得る。
【０３７８】
[00448]図１８Ｂは、図１８Ａに示されるブラウザＡＰＩに関連する方法例を示す。この方法は、ブラウザによって実行され、ユーザのための支払いデータをユーザクライアントデバイスの非一時的な記憶媒体内に記憶するステップを含むことができる（１８３０）。一態様では、支払いデータは、住所情報、支払いアカウント情報、有効期限、ＣＶＣコード、販売業者による使用のための支払いトークンを提供するために使用または暗号化可能であるトークンまたはコード、ユーザの配達の好み、ユーザの衣服のサイズ情報などのうちのいずれか１つまたは複数を含むことができる。購入を処理することに関係する任意のデータは、支払いデータ内に含まれ得る。支払いデータは、一般的には、特定のサイトに関連づけられておらず、複数のサイトにまたがって使用可能である。任意のセキュリティ機構は、購入を処理するための支払いデータまたは修正された支払いデータのサイト１８１６への安全な通信を保証するために実施可能である。ユーザのサイズ情報は、ブラウザＡＰＩを通して通信されるとき、トークン化されることもある。購入が、ソーシャルネットワーキングサイトと販売業者サイトとの間でアプリケーションプログラミングインターフェースを介して発生するとき、ソーシャルネットワーキングサイトは、販売業者サイトが製品の購入を処理することができるように、アプリケーションプログラミングインターフェースを通して支払いデータを送信することができる。
【０３７９】
[00449]方法は、ブラウザなどのユーザインターフェースを介して、ユーザによる、ブラウザ内に提示されたサイトに関連づけられたオブジェクトとのクリック対話を受信する（１８３２）ことであって、このクリック対話は、購入を行うユーザ意図を示す、受信することと、ブラウザにおいて、クリック対話に基づいて、サイトとブラウザとの間で支払いデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、サイトから購入に関連した支払いデータの要求を受信する（１８３４）ことと、取り出された支払いデータをもたらすために、ブラウザを介して、支払いデータ（またはセキュリティのためにトークン化または暗号化される支払いデータのバージョン）を取り出す（１８３６）ことと、サイトに、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、取り出された支払いデータを送信することであって、取り出された支払いデータは、支払いを処理するまたは購入に関連づけられた製品を配達するために使用可能である、送信する（１８３８）こととを含むことができる。一態様では、ブラウザは、販売業者サイト１８１６への通信のためにブラウザ１８０６に戻すように渡されるトークンを生成することなど、支払いデータ１８１４を処理することもできる別のサーバ１８１０と対話することもできる。図１９、特徴１９０８は、販売業者サイト１８１６とブラウザ１８０６との間の対話を開始するために対話可能であるそのようなオブジェクトを示す。別の態様では、支払いデータ１８０８は、全体および一部としてブラウザに記憶可能であり、他のデータは、支払いを処理するために販売業者１８１６に通信される支払いデータまたは支払い情報を生成するために全体および一部としてネットワークサーバ１８１４を介してアクセス可能である。この例では、支払いデータは、ユーザのサイズ情報、登録データ、またはブラウザＡＰＩを介して交換される他の任意のデータと交換されることがある。
【０３８０】
[00450]図１８Ｃは、販売業者サイトの観点からプロセスを示す。このケースでは、方法は、ブラウザ１８０６などのユーザインターフェースを介して提示するために、ユーザが対話することができるオブジェクト１９０８を送信することであって、このオブジェクトは、ボタン、ドロップダウン画面、またはハイパーリンクのうちの１つを含む、送信する（１８４０）ことと、サイトに関連づけられたオブジェクトとのユーザによるクリック対話を受信することであって、このクリック対話は、購入を行うユーザ意図を示す、受信する（１８４２）ことと、クリック対話に基づいて、サイトとブラウザとの間で支払いデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、サイトから購入に関連したユーザデバイス１８０４上に記憶された支払いデータの要求を送信することであって、支払いデータは、複数のサイトにまたがって支払いに使用可能である、送信する（１８４４）ことと、サイトにおいて、ブラウザ支払い要求アプリケーションプログラミングインターフェース１８１８を介して、支払いデータ１８０８（または支払いデータに基づいたトークンなどのセキュアなデータ）を受信することであって、支払いデータは、製品のための支払いを処理するまたは購入に関連づけられた製品を配達するために使用可能である、受信する（１８４６）こととを含むことができる。販売業者１８１６は、購入を処理するために、受信された支払いデータまたは情報を支払いプロセッサにサブミットすることができる。
【０３８１】
[00451]ブラウザＡＰＩは、ＰａｙＰａｌシナリオなどのサイトと支払いサーバとの間のＡＰＩと、および一般的なハイパーテキストマークアップ言語（ＨＴＭＬ）プロトコルと、それを区別することができるいくつかの特性を有する。ＨＴＭＬは、ウェブブラウザがテキスト、画像、および他の材料を解釈し、視覚的なウェブページまたは可聴ウェブページへと構成するために使用するマークアップ言語である。ウェブブラウザは、ウェブサーバから、またはローカルストレージからＨＴＭＬ文書を受信し、次いで、それらのウェブページをレンダリングする。ＨＴＭＬは、一般に、そのようなウェブページの構造を意味論的に記載し、プロトコルを使用して記載する。ブラウザ上での文書の外観のための指示カスケーディングスタイルシートおよびＪａｖａＳｃｒｉｐｔは、ＨＴＭＬの一部とすることもができる。ＨＴＭＬマークアップのあらゆる項目のためのデフォルト特性は、ブラウザ内で定義され、これらの特性は、ウェブページデザイナーの追加のＣＳＳの使用によって変化または強化可能である。対照的に、アプリケーションプログラミングインターフェースは、サブルーチン定義、ツール、およびさまざまなソフトウェア構成要素間の通信のための明らかに定義された構造のセットを概説するプロトコルのセットを表す。アプリケーションプログラミングインターフェースは、販売業者サイトなどのサイトとブラウザとの間で通信するための確立されたＡＰＩである。したがって、ブラウザは、ＡＰＩを利用することを要望するそれぞれのサイトが支払い要求呼び出しを行い、支払いを処理するためにＡＰＩを介して適切なデータを受信することを可能にするために、ルーチン、データ構造、オブジェクトクラス、変数、および／またはリモート呼び出しとともにプログラムされなければならない。ブラウザＡＰＩはＨＴＭＬインターフェースではなく、サイト間およびネットワークベースの支払いサーバまたは支払いサービスとの直接的な通信のために設計されたＡＰＩでもない。本明細書において開示されるのは、ブラウザが、エージェントとして機能し、ブラウザとネットワークベースの支払いサービスとの間の他のＡＰＩを通して、支払いを行うまたはトークン化されたデータなどの支払いデータを販売業者サイトに提供するプロセスを管理することができるプロセスであることが留意される。しかしながら、そのシナリオでは、サイトは、ブラウザがプロセスを管理するためにエージェントとして確立されるので、ネットワークベースのサーバへの別個のＡＰＩ呼び出しを行う必要はなく、したがって、ブラウザＡＰＩを通しての呼び出しのみが、認証、許可、ネットワークベースのプロセスが発生するために行われることが必要であるようにサイトのための通信を単純化する。したがって、ＨＴＴＰ要求メッセージのセットとすることができるＡＰＩは、ＸＭＬまたはＪａｖａＳｃｒｉｐｔオブジェクト表記フォーマットで確立可能である要求メッセージおよび応答メッセージの構造の定義とともに、ブラウザへと組み込まれ、ブラウザが、許可された支払いデータ、パスワードデータ、ログインデータ、トークン化された支払いデータを提供するためのエージェントとして機能すること、またはすべてブ��ウザＡＰＩを通してサイトから行われる支払い要求または他の呼び出しを通して、ネットワークベースの支払い処理もしくはログイン処理をエージェントとして管理することを可能にする。ブラウザＡＰＩは、ブラウザとサイトとの間のデータの流れを管理し、ブラウザが、認証、データ、トークン、または他のネットワークベースのサービスを別個に得ようとすることを可能にする。ＡＰＩは、支払い方法、システム、プラットフォーム、および販売業者にまたがって一貫した経験を提供する。典型的なウェブベースのＡＰＩは、サイトとウェブサービスとの間のインターフェースを定義しており、本明細書において開示される新規な概念は、支払いまたはログインプロセスがサイトにまたがって簡略化および統一可能であるように、ブラウザが、プロセスが支払いプロセスであるにせよ、ログインプロセスであるにせよ、支払い要求を受信し、許可された支払いデータを取り出し、要求に応答することができるように、ブラウザへと組み込まれる、アーキテクチャおよびプログラム可能なインターフェース、データ構造などを定義する新たなＡＰＩである。
【０３８２】
[00452]図１９は、事前にポピュレートされた販売業者ショッピングカートのための例示的なユーザインターフェースを示す。第１のユーザインターフェース１９００内で、ユーザは、ブラウザ内のウェブページの統一された入力フィールド１９０２内に「ＡＣＭＥトースター４．５を買う」というテキストを入力した。ｅｎｔｅｒを打ったまたは検索ボタンをクリックした後、ブラウザは、販売業者ウェブサイトにおけるショッピングカートに所望のトースターをポピュレートするために販売業者ウェブサイトに既にナビゲートされている（または、現在、これにナビゲートするプロセス内である）サーバと通信する。サーバは、精算またはショッピングカートプロセス内の特定の時点で継続するために、そのブラウジングセッションをブラウザに引き渡すことができる、または、統一された入力フィールド内に入力されたテキストに基づいてポピュレートされたショッピングカートに直接的に進むために形成されたブラウザにＵＲＬを返すことができる。このケースでは、ｅｎｔｅｒを打ったまたは検索ボタンをクリックした後、ブラウザは、既にショッピングカート内に置かれている品物、注文の詳細、およびワンクリック購入ボタン１９０８をリストする販売業者ウェブサイト１９０４に直接的および自動的にナビゲートする。あるいは、ブラウザは、ユーザが購入するボタン１９０８をクリックした後でロードされるであろうページなど、注文が既になされている段階にナビゲートすることができる。特に、販売業者は、画面１９０４上に何らかのブランディングを有する。購入ボタン１９０８が、検索エンジンサイトにおいて記憶された支払い情報を使用して支払いを処理するために使用される場合、本明細書において本開示を介して諒解され得るように、ＡＰＩの検索エンジン側での支払い処理とＡＰＩの販売業者側で取り扱われている配達との間の協調が、プロセスを、買い手にとってより単純で容易なものにし、したがって、販売が発生する可能性を増加させる。
【０３８３】
[00453]画面１９０４は、ユーザが購入を行う１９０８ことが確定される時点に到達するように、ユーザによる販売業者サイト上での単純なナビゲーションも表すことができる。クリックまたは買うボタン１９０８と対話することは、支払いを処理するために必要な支払いデータを要求し、これを最終的に受信するために、ブラウザＡＰＩを通して通信を開始することができる。
【０３８４】
[00454]画面１９０４は、検索エンジン／ソーシャルメディアサイトおよび／または販売業者によってホスト可能である。システムはまた、ユーザに代わってショッピングカートの他の詳細を自動的にポピュレートすることができる。システムは、ユーザが、その販売業者とのアカウントを持たない場合、ユーザに代わって販売業者における新しいアカウントを作成することすらできる。このようにして、ユーザがその販売業者に以前に登録していなかった場合、または販売業者が「Ａｍａｚｏｎスタイル」ワンクリック購入インターフェースを提供しない場合でも、システムは、ウェブサイトがワンクリック購入販売業者ウェブサイトであるかかのように、ユーザが、統一された検索フィールドを通してウェブサイトにアクセスすることを可能にする。たとえば、一般化された入力フィールドを提供することに関連づけられた第１のウェブサイトエンティティは、それが記憶し、品物の配達を最終決定すると販売業者と協調する支払いアカウント情報に基づいて、品物のための支払いを処理することができる。
【０３８５】
２つのＡＰＩを使用した支払いプロセスの管理
[00455]本明細書において開示される別の態様は、第１のＡＰＩ１８１８と第２のＡＰＩ１８１２との間の協調に関し、第１のＡＰＩ１８１８と第２のＡＰＩ１８１２の両方は、支払いプロセスを管理するために相関された手段でブラウザ１８０６とインターフェースする。この手法は、ユーザが登録されておらず、サイト１８１６においてアカウントをもたないとき、サイト１８１６上での購入が、Ａｍａｚｏｎ．ｃｏｍ「ワンクリック」購入経験により似ていることを可能にする。いくつかのケースでは、ユーザは、Ｐａｙｐａｌアカウントを有することができるが、依然として、支払いを行うために、そのアカウントにログインしなければならない。サイト１８１６と支払いプロバイダ１８１０との間のエージェントとして機能する、ＡＰＩ１８１２、１８１８、およびブラウザ１８０６の協調は、購入プロセスを単純化することができる。この点に関して、方法は図１８Ｄに示されており、販売業者サイト１８１６から製品を購入したいという要望を示す入力をユーザから受信する（１８５０）ことを含む。入力は、クリック、ダイアログの一部としての音声入力、バーチャルリアリティ入力、または任意の種類の入力とすることができる。方法は、入力に基づいて、ブラウザ１８０６において、ブラウザ１８０６と販売業者サイト１８１６との間の第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェース１８１８を介して、製品を購入するために販売業者サイトからユーザの支払いデータの支払い要求を受信する（１８５２）ことを含む。
【０３８６】
[00456]支払い要求に応答して、方法は、ブラウザ１８０６から、ブラウザ１８０６と支払いサービス１８１０との間で支払い情報を通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェース１８１２を介して、支払い要求イベントを支払いサービス１８１０に通信することであって、支払いサービス１８１０は、支払い要求イベントに基づいて製品のための支払いを処理することができる、通信する（１８５４）ことを含む。方法は、ブラウザ１８０６において、支払いサービス１８１０から、第２のアプリケーションプログラミングインターフェース１８１２を介して、製品のための支払いの確認を受信する（１８５６）ことと、ブラウザ１８０６から、第１のアプリケーションプログラミングインターフェース１８１８を介して販売業者サイト１８１６に、製品のための支払いの確認を通信する（１８５８）こととを含む。支払いサービス１８１０は、Ｐａｙｐａｌ、Ｇｏｏｇｌｅ支払いサービス、もしくは他の任意の支払いサービスのようなサービス、または支払いプロセッサとすることができる。手法は、新しい様式でブラウザ１８０６およびいくつかのＡＰＩ１８１２、１８１８を利用する、販売業者１８１６と支払いサービス１８１０との間の一般的なインターフェースが、そのようなサービスのためにサインアップされるユーザのための購入プロセスを単純化することまたはサービスなどを利用することを可能にする。
【０３８７】
[00457]第１のアプリケーションプログラミングインターフェース１８１８は、ブラウザ１８０６と販売業者サイト１８１６との間で支払いデータおよび住所データのうちの少なくとも１つを通信するための第１のプロトコルを定義することができる。第２のアプリケーションプログラミングインターフェース１８１２は、ブラウザ１８０６と支払いサービス１８１０との間で製品の支払いに関連づけられたデータを通信するための第２のプロトコルを含むことができる。支払い要求は、さらに、ユーザの住所および／またはユーザに関連づけられたもしくは購入に関連づけられた他のデータの要求を含むことができる。したがって、支払いは、支払いサービスプロバイダ１８１０によって実行可能であり、住所は、第１のＡＰＩ１８１８を通してブラウザによって提供されてよい。
【０３８８】
[00458]方法は、支払い要求に基づいて、ブラウザ１８０６から、第１のアプリケーションプログラミングインターフェース１８１８を介して、ユーザに製品を配達する際に使用するために販売業者サイト１８１６にユーザの住所１８０８を送信することをさらに含むことができる。第１のアプリケーションプログラミングインターフェース１８１８は、支払いデータおよび／またはユーザに関連づけられた他のデータについての販売業者サイト１８１６からの要求を伴うので、ブラウザ支払い要求アプリケーションプログラミングインターフェースを含むことができる。第２のアプリケーションプログラミングインターフェース１８１２は、より具体的には、支払いプロセッサ１８１０による支払いの取り扱いを伴うので、支払い取り扱いアプリケーションプログラミングインターフェースと呼ばれることがある。本開示のこの態様は、販売業者の観点からの、ならびに支払いプロセッサの観点からの実施形態も有することができる。
【０３８９】
[00459]図１８Ｅは、支払いプロセッサ１８１０の観点から本開示のこの態様を示す。方法は、販売業者サイト１８１６から製品を購入したい要望を示す、ユーザからの入力に基づいて、およびブラウザ１８０６において、ブラウザ１８０６と販売業者サイト１８１６との間の第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェース１８１８を介して、製品を購入するために販売業者サイト１８１６からユーザの支払いデータ１８０８のための支払い要求を受信するブラウザ１８０６に基づいて、支払いサービス１８１０において支払い要求イベントを受信することであって、支払い要求イベントが、ブラウザ１８０６から、ブラウザ１８０６と支払いサービス１８１０との間の支払い情報を通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェース１８１２を介して受信される、受信する（１８６０）ことと、支払いサービス１８１０において、支払い要求イベントに基づいて製品のための支払いを処理する（１８６２）ことと、ブラウザ１８０６に、支払いサービス１８１０から、第２のアプリケーションプログラミングインターフェース１８１２を介して、製品のための支払いの確認を送信することであって、ブラウザ１８０６が、第１のアプリケーションプログラミングインターフェース１８１８を介して販売業者サイト１８１６に、製品のための支払いの確認を通信する、送信する（１８６４）こととを含む。この手法では、販売業者は、販売業者１８１６が支払いアカウントデータまたは購入を処理するためのトークンを受信している場合に発生するであろう自身の支払いプロセッサ１８２０を使用していない。購入は支払いサービス１８１０によって実行されているので、販売業者１８１６は、購入が完了したという、その確認を必要とする。支払いサービスは、記憶された支払いデータ１８１４および／またはユーザのアカウントを利用することができる。したがって、Ｓｔｒｉｐｅ、Ｇｏｏｇｌｅ．ｃｏｍ、ＢｒａｉｎＴｒｅｅ、Ａｍａｚｏｎ．ｃｏｍ、Ｐａｙｐａｌなどのような支払いサービスが、支払いサービス１８１０によって表され得る。ユーザが、ブラウザ、またはＧｏｏｇｌｅアカウント（電子メール、ｙｏｕｔｕｂｅなど）にログイン可能であるので、ユーザの証明書は、ユーザがアカウントデータに手動で入力することなく支払いに使用される任意の特定のアカウントにログインするために利用可能である。
【０３９０】
[00460]販売業者サイトの観点から実行される方法が、図１８Ｆに示されている。方法は、販売業者サイト１８１６から製品を購入したいという要望を示す入力をユーザから受信する（１８７０）ことと、入力に基づいて、ブラウザ１８０６に、ブラウザ１８０６と販売業者サイト１８１６との間の第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェース１８１８を介して、製品を購入するためにユーザの支払いデータの支払い要求を販売業者サイト１８１６から送信する（１８７２）ことであって、（１）ブラウザ１８０６は、支払い要求に応答して、ブラウザ１８０６から、ブラウザ１８０６と支払いサービス１８１０との間で支払い情報を通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェース１８１２を介して、支払いサービス１８１０に支払い要求イベントを通信し、（２）支払いサービス１８１０は、支払い要求イベントに基づいて製品のための支払いを処理することができ、（３）ブラウザ１８０６は、支払いサービス１８１０を介して、および第２のアプリケーションプログラミングインターフェース１８１２を介して、製品のための支払いの確認を受信する、送信することとを含む。方法は、ブラウザ１８０６から、販売業者サイト１８１６において、第１のアプリケーションプログラミングインターフェース１８１８を介して、製品のための支払いの確認を受信する（１８７４）ことを含む。
【０３９１】
[00461]開示されるさまざまなＡＰＩを使用する、ブラウザと、支払いサービスと、販売業者サイトとの間の任意の通信は、販売業者サイト１８１６においてユーザによるワンクリックタイプ購入経験を達成するための本開示の一部とすることができる。
【０３９２】
[00462]サイトに対する支払いを処理する支払いプロセッサに関する追加の概念が、次に検討される。一態様では、方法は、ブラウザにおいて、サイトとブラウザとの間で購入についての情報を通信するための第１のプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのためのサイトからの製品の購入に関連づけられたデータを有する支払い要求を受信することと、この支払い要求に基づいて、ブラウザから、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義するブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払いサービスに対する製品のための支払いを処理するために要求を送信することとを含む。この態様による方法は、ブラウザにおいて、ブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払いサービスがサイトに対する製品のための支払いを処理したという確認を支払いサービスから受信することを含むことができる。
【０３９３】
[00463]方法は、ブラウザから、支払い要求アプリケーションプログラミングインターフェースを介してサイトに、支払いサービスから受信された確認を送信することをさらに含むことができる。方法は、ブラウザから、支払い要求アプリケーションプログラミングインターフェースを介して、ユーザに製品を配達するために、サイトにユーザのための住所情報を送信することをさらに含むことができる。
【０３９４】
[00464]支払いプロセッサの見地の視点からの方法は、ブラウザにおいて、サイトとブラウザとの間で購入についての情報を通信するための第１のプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して受信された支払い要求であって、ユーザのためのサイトからの製品の購入に関連づけられたデータを有する支払い要求に基づいて、ブラウザから、支払いサービスにおいて、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義するブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、製品のための支払いを処理する要求を受信することと、ブラウザに、ブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払いサービスがサイトに対する製品のための支払いを処理したという確認を支払いサービスから送信することとを含むことができる。
【０３９５】
[00465]サイトコンテキストから、例示的な方法は、サイトから、ブラウザに、サイトとブラウザとの間で購入についての情報を通信するための第１のプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのためのサイトからの製品の購入に関連づけられたデータを有する支払い要求を送信することと、支払いサービスから製品のための支払いを受信することであって、この支払いは、支払い要求に基づいて、ブラウザから、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義するブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払いサービスに対する製品のための支払いを処理する要求を送信するブラウザに基づいて受信される、受信することとを含むことができる。方法は、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払いサービスから開始された、支払いサービスがサイトに対する製品のための支払いを処理したという確認を受信することも含むことができる。方法は、ブラウザから、支払い要求アプリケーションプログラミングインターフェースを介して、ユーザに製品を配達するために、サイトにおいてユーザのための住所情報を受信することも含むことができる。
【０３９６】
複数の支払いオプション
[00466]図１８Ｇは、支払い方法の選択肢を提供することに関係する本開示の別の態様を開示する。方法は、この態様では、ブラウザにおいて、サイトとブラウザとの間で購入についての情報を通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのためのサイトからの製品の購入に関連づけられたデータを有する支払い要求を受信する（１８８０）ことと、ブラウザまたはブラウザインターフェースを介して、製品を購入するための第１の支払い方法と第２の支払い方法との選択肢を提示することであって、ここにおいて、第１の支払い方法と第２の支払い方法は各々、ユーザデバイス上に記憶された支払いデータ、ネットワークサーバ上に記憶された支払いデータ、および支払いサービスのうちの１つを含むまたは必要とする、提示する（１８８２）ことと、選択された支払い方法をもたらすために、第１の支払い方法および第２の支払い方法のうちの１つのユーザから、支払い方法の選択を受信する（１８８４）ことと、選択された支払い方法に基づいて、支払い要求に応答して、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、選択された支払い方法に関連づけられたデータをサイトに送信する（１８８６）こととを含む。
【０３９７】
[00467]方法は、選択された支払い方法が支払いサービスを含むとき、支払い要求および選択された支払い方法に基づいて、ブラウザから、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義するブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払いサービスに対する製品のための支払いを処理するために要求を送信するステップと、ブラウザにおいて、ブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、サイトが支払われるように、支払いサービスが製品のための支払いを処理したという確認を支払いサービスから受信するステップとを含むことができる。
【０３９８】
[00468]方法は、ブラウザから、支払い要求アプリケーションプログラミングインターフェースを介してサイトに、支払いサービスから受信された確認（または他のデータ）を送信することも含むことができる。方法は、選択された支払い方法がユーザデバイス上に記憶された支払いデータを含むとき、支払い要求および選択された支払い方法に基づいて、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、応答データをサイトに送信するステップを実行することであって、この応答データは、ユーザデバイス上に記憶された支払いデータに基づく、実行することも含むことができる。
【０３９９】
[00469]応答データは、ユーザデバイス上に記憶された支払いデータに基づいて生成されたトークンであって、サイトによって製品の購入を処理するために使用可能であるトークンを含むことができる。サイトは、支払いデータを使用して製品のための支払いを処理することができる。選択された支払い方法が、ネットワークサーバ上に記憶された支払いデータを含むとき、方法は、支払い要求および選択された支払い方法に基づいて、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ネットワークサーバ上に記憶された支払いデータをサイトに送信することをさらに含むことができる。支払いデータは、処理のために、ブラウザに関連づけられた１つまたは複数のＡＰＩを通してサイトに通信可能である。
【０４００】
[00470]方法は、ブラウザから、支払い要求アプリケーションプログラミングインターフェースを介して、ユーザに製品を配達するために、サイトにユーザのための住所情報（または他の任意の情報）を送信することも含むことができる。一態様では、他の情報は、ユーザが単に、欲しい靴を求めてショッピングし、その靴を買うことがあるように、衣服のサイズ、ショーのサイズ、シャツのサイズ、ズボンのサイズなどを含むことがある。サイズ、自身のサイズすら選定する必要がないであろう。ユーザのサイズがＡＰＩを通して渡されるので、靴は、ちょうど適切なサイズで提供されるであろう。
【０４０１】
[00471]サイトの観点からの複数の支払いオプションのこの概念は、ブラウザに、サイトとブラウザとの間で購入についての情報を通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ユーザのためのサイトからの製品の購入に関連づけられたデータを有する支払い要求を送信することと、ブラウザインターフェースを介して、製品を購入するための第１の支払い方法と第２の支払い方法との選択肢を提示することであって、第１の支払い方法と第２の支払い方法は各々、ユーザデバイス上に記憶された支払いデータ、ネットワークサーバ上に記憶された支払いデータ、および支払いサービスのうちの１つ（または複数）を含むまたは必要とする、提示することと、選択された支払い方法をもたらすために、第１の支払い方法および第２の支払い方法のうちの１つのユーザから、支払い方法の選択を受信することと、選択された支払い方法に基づいて、支払い要求に応答して、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、サイトに対する選択された支払い方法に関連づけられたデータを受信することとを含むことができる。
【０４０２】
[00472]選択された支払い方法に関連づけられたデータは、製品を購入するためにサイトが支払いを処理するための支払いデータ、または製品を購入する支払いが支払いサービスによって実行されたという確認、のうちの１つを含むことができる。
【０４０３】
[00473]支払いプロセッサの観点から、方法は、以下の概念を含むことができる。（１）ブラウザにおいて、サイトとブラウザとの間で購入についての情報を通信するための第１のプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、受信された支払い要求であって、ユーザのためのサイトからの製品の購入に関連づけられたデータを有する支払い要求に基づいて、および（２）製品の購入を処理するために支払いプロセッサを必要とする、ユーザデバイスを介して提示される複数の支払い方法からの支払い方法のユーザ選択に基づいて、方法は、ブラウザから、支払いサービスにおいて、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義するブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、製品のための支払いを処理する要求を受信することと、支払い確認をもたらすために、支払いサービスによって製品のための支払いを処理することと、支払いサービスからブラウザに、ブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払い確認を送信することとを含むことができる。
【０４０４】
[00474]ブラウザは、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、サイトに支払い確認（または関係データ）を送信することができる。ブラウザのビューからのこの概念の別の変形形態では、方法は、製品の購入に関連して、ブラウザにおいて、支払いを管理するために販売業者サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払い要求を受信することと、ユーザインターフェースを介して、第１の支払い方法および第２の支払い方法を提示することと、選定された支払い方法をもたらすために、第１の支払い方法または第２の支払い方法のユーザインターフェースを介して選択を受信することと、支払い要求に応答して、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払い情報を送信することであって、この支払い情報は、選定された支払い方法に関連づけられている、送信することとを含むことができる。
【０４０５】
[00475]支払い情報は、購入を処理するための、販売業者サイトによる使用のための支払いデータを含むことができる。支払い情報は、支払いが支払いプロセッサによって処理されたという確認を含むことができる。
【０４０６】
[00476]方法は、ブラウザから、ブラウザと支払いプロセッサとの間でデータを通信するためのプロトコルを定義するブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払いを処理するために支払いプロセッサに情報を通信することをさらに含むことができる。方法は、ブラウザにおいて、ブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して確認情報を受信することであって、この確認情報は、支払いプロセッサが販売業者サイトに対する製品のための支払いを行うのに成功したことを確認する、受信することも含むことができる。
【０４０７】
証明書管理ＡＰＩ
[00477]次に、サイトのための、名前および／またはパスワードなどのログイン証明書を通信するための１つまたは複数の例示的なアプリケーションプログラミングインターフェースが開示される。図１８Ｈは、この例を、ブラウザ１８０６の観点から示す。方法は、サイト１８１６から、ブラウザ１８０６において、ユーザ１８０２がサイト１８１６にログインすることを可能にするためにサイト１８１６とブラウザと１８０６の間でデータを通信するためのプロトコルを定義するブラウザ証明書管理アプリケーションプログラミングインターフェース１８１８を介して、サイトのために必要とされるログイン証明書に関連づけられた要求を受信する（１８９０）ことと、要求に基づいて、ユーザデータ１８０８／１８１４を取り出す（１８９２）ことと、サイト１８１６に、ブラウザ１８０６から、ブラウザ証明書管理アプリケーションプログラミングインターフェース１８１８を介して、要求に対する応答を送信する（１８９４）こととを含む。例示的なＡＰＩは、図１８ＡではＡＰＩ１８１８として開示されている。ユーザデータを取り出すことは、ブラウザ１８０６が、ローカルストレージ１８０８からデータを取り出すことまたはブラウザ１８０６とネットワークベースのサーバ１８１０との間のＡＰＩ１８１２を使用してユーザデータ１８１４を取り出すことを含むことができる。ユーザデータは、さまざまなアカウント、またはユーザ証明書を提供する方法を含むことがある。たとえば、１つの方法は、ブラウザに記憶されたまたはブラウザ１８０６によってアクセス可能なユーザ名およびパスワードを使用することであることがある。別の方法は、ブラウザ１８０６またはサイト１８１６によってアクセスされ得る、証明書サービス、別個のアカウント、またはネットワークデバイスであることがある。ユーザは、どの手法をログインに使用するべきかを選定するためのオプション（視覚的インターフェース、口頭によるインターフェースまたは対話、テキスト、マルチモーダルインターフェースなど）が提示されることがある。選定された手法を用いて、ＡＰＩ１８１８は、選定された方法に従って、およびＡＰＩ１８１８または任意の標準化されたプロトコルに従って、ブラウザ１８０６からサイト１８１６に、またはネットワークデバイス１８１０からサイト１８１６に、証明書データを渡すために使用されることがある。そのようなサイト１８１０は、ユーザを許可し、適切であることをサイトが信頼することができる、識別情報プロバイダであることがある。そのようなプロバイダは、たとえば、Ｇｏｏｇｌｅ、Ｆａｃｅｂｏｏｋ、または他の任意のエンティティであってよい。インターフェースは、異なるユーザの間の選択肢も提供することがある。通信されたデータは、セキュリティのための１つもしくは複数のトークンであってもよいし、直接的にユーザ名および／もしくはパスワードであってもよい。
【０４０８】
[00478]ブラウザ証明書管理ＡＰＩ１８１８の目的は、サイト１８１６が、ユーザ名、パスワード、コード、または他の任意のデータのうちの１つまたは複数などのログイン証明書を容易に取り出すことを可能にすることである。ユーザの認証は、指紋などの受信されたバイオメトリクスに関連して実行されることもある。サイト１８１６は、ログイン証明書を取り出す目的で、ＡＰＩ１８１８を通して通信する。ＡＰＩ１８１８を介して要求および応答および／または他のデータを通信するプロセスは、ブラウザ１８０６またはネットワークサーバ１８１０と通信するときのＡＰＩ１８１８との間の任意の組み合わせまたは協調、ならびにＡＰＩ１８１２を介したネットワークサーバ１８１０とブラウザ１８０６との間の任意の通信を含むができる。実際には、これらのＡＰＩは、一般に、サイト１８１６が、最終的にユーザがサイト１８１６にログインするためのログイン証明書を受信するために、あるフォーマットでデータを要求し、データを送信し、データを受信するためのプロトコルを必要とする。サイト１８１６は、サイト１８１６がそのログインフロー内で受信する証明書および／またはトークンを使用して、ユーザが、１つまたは少数のクリックで（または、自動である場合はクリックせずに）ログインすることを可能にし、したがって、ユーザの、ユーザ名、パスワード、または他の任意の証明書をタイプする必要性を軽減する。サイト１８１６は、たとえば、サイト上で、または別のサーバへの呼び出しを介して、ユーザを認証することがある。そのようなプロトコルに関連づけられたそのような詳細のすべては、本開示の範囲内で考慮される。
【０４０９】
[00479]応答は、ユーザ名およびパスワード、または虹彩スキャン、指紋、コード、もしくはそのようなデータの任意の組み合わせなどの他のデータのうちの少なくとも１つを含むことができる。一態様では、ユーザ名およびパスワード、または他のデータ、のうちの少なくとも１つは、ブラウザ内に記憶される。データは、ネットワークノード内に記憶されることもある。応答は、ネットワークベースのエンティティがサイトへとログインするために証明書データを提供することを示すことができる。この点に関して、サイトは、サイトとネットワークベースのエンティティとの間の第２のアプリケーションプログラミングインターフェースを介して、ユーザがサイトにログインするための証明書データにアクセスすることができる。図１８Ａに示されるＡＰＩ１８１８は、サイト１８１６とネットワークサーバ１８１０との間のＡＰＩを表すことができ、ネットワークサーバ１８１０は、ユーザデータ１８１４を記憶する。ＡＰＩ１８１２は、ブラウザ１８０６によって、ネットワークエンティティ１８１０からログイン証明書を取り出すために使用されることもある。ＡＰＩ１８１８と、ブラウザ１８０６と、ＡＰＩ１８１２と、ネットワークエンティティ１８１０との間のデータおよび情報の通信の任意の組み合わせまたは協調は、本開示の範囲内で企図されている。たとえば、サイト１８１６は、ブラウザ１８０６を介して、ＡＰＩ１８１８を通してログイン証明書を要求することがある。しかしながら、ユーザは、ログイン証明書１８１４を記憶するネットワークサービス１８１０を有することがある。したがって、要求に応答して、サイト１８１６は、ユーザデータ１８１４を取り出すように、ＡＰＩ１８１８を通してネットワーク証明書プロバイダ１８１０に向けられることがある。
【０４１０】
[00480]一態様では、方法は、ブラウザ証明書管理アプリケーションプログラミングインターフェースを介してユーザ証明書の変更を受信することを含む。このシナリオでは、ユーザは、サイト１８１６にログインしようとすることがあり、変更されたパスワードまたは更新された証明書を提供することがある。ＡＰＩ１８１８は、記憶および後での使用のために、更新されたログイン証明書をブラウザ１８０６に送信するために利用可能である。ＡＰＩ１８１８および／またはＡＰＩ１８１２のうちの１つまたは複数は、更新されたログイン証明書をネットワークエンティティ１８１０に通信するために使用されることもある。
【０４１１】
[00481]証明書管理ＡＰＩ１８１８は、サイト１８１６上で発生する処理から見られることもある。この態様では、方法は、サイト１８１６から、ブラウザ１８０６に、ユーザがサイトにログインすることを可能にするためにサイト１８１６とブラウザ１８０６との間でデータを通信するためのプロトコルを定義するブラウザ証明書管理アプリケーションプログラミングインターフェース１８１８を介して、サイトに必要とされるログイン証明書に関連づけられた要求を送信することと、サイト１８１６において、ブラウザ１８０６から、ブラウザ証明書管理アプリケーションプログラミングインターフェース１８１８を介して、要求に対する応答を受信することとを含む。
【０４１２】
[00482]応答は、ネットワークベースのエンティティ１８１０がサイトへログインするために証明書データを提供することを示すことができる。方法は、サイト１８１６とネットワークベースのエンティティ１８１０との間の第２のアプリケーションプログラミングインターフェース１８１８を介して、ユーザがサイトにログインするための証明書データを要求することをさらに含むことができる。二次ＡＰＩは、ＡＰＩ１８１２も含むことがあり、ＡＰＩ１８１２は、ブラウザ１８０６とネットワークエンティティ１８１０との間で要求および応答、または他のデータを動作させ、通信する。方法は、ブラウザ証明書管理アプリケーションプログラミングインターフェースを介してユーザ証明書の変更を送信することを含むことができる。
【０４１３】
[00483]応答は、ユーザ名、パスワード、および／またはサイト１８１６にユーザ１８０２をログインさせるためにサイト１８１６上でログイン手順に適用するためにサイト１８１６によって利用可能である他の証明書データのうちの少なくとも１つを含むことができる。
【０４１４】
車両／モノのインターネットアプリケーション
[00484]別の態様では、ブラウザ支払い要求アプリケーションプログラミングインターフェースは、車両インターフェースに適用されることができる。車両は、コンピュータ構成要素と、ブラウザまたは本明細書において開示されるインターフェース機能を有するグラフィカルインターフェース（または音声インターフェース）とを有することができる。たとえば、レストランにあるドライブスルーを自動車で通り抜ける自動車内のユーザは、自動車に組み込まれたタッチスクリーンを利用して、支払いを取り扱うことがある。短距離通信プロトコル、ＷｉＦｉプロトコル、セルラープロトコル、または他の任意のワイヤレスプロトコルを通して、車両は、レストランと通信し、支払い、レストランおよび／または車両の支払い能力、金額、注文された品物などについての情報を交換することがある。その人が、注文し、たとえば、食事の金額は１５ドルであることがある。ユーザは、ウォレットを取り出したりモバイルデバイスを取り出したりするのではなく、注文された品物および購入金額の概要を見て、ユーザインターフェースを介して購入を確認するために、車両に組み込まれたタッチスクリーンと対話することがある。指紋読み取り装置が、ユーザインターフェースに組み込まれてもよいし、ステアリングホイールまたは、ユーザのモバイルデバイスを含む、車両内の他の任意の容易にアクセス可能なデバイスに組み込まれてもよく、これらは、購入を確認するために使用され得る。インターフェースは、一態様では、セキュリティのためにインターフェース上でＣＶＶコードを入力するために、ユーザに提示されることがある。ロケーションベースのサービスまたは能力が、プロセスを機能させるために含まれることがある。一態様は、モバイルデバイスを取り出すまたは使用することをユーザに求めない様式で購入プロセス全体を提供することを伴う。別の態様では、支払いプロセスは、車両のコンピューティングデバイスとユーザのモバイルデバイスの組み合わせを利用する。
【０４１５】
[00485]プロセスは、ユーザのモバイルデバイスだけを介して発生することもある。この点に関して、対話型アプリケーションまたはサイトは、ユーザがレストランのためのＷｉ−Ｆｉ信号の範囲を入力する、またはより容易な選択、購入、および支払いを可能にする通信インターフェースを記憶して開始すると、ユーザに追従することがある。たとえば、家族が、レストランでＷｉ−Ｆｉネットワークの範囲内に到着すると、レストランに歓迎し、一行は何人かを尋ねるインターフェースが、モバイルデバイス上に提示されることがある。家族は、３人の大人と２人の子供をユーザインターフェースへと入力し、いつ着席し得るかのタイミングを与えられることがある。それは、家族がボックス席などの座席を選定するための機会すら含むことがある。家族の名前および他のデータについての情報は、ブラウザとレストランまたはサイトとの間でＡＰＩを通して通信されることがある。家族は、ボックス席が１０分で準備が整うと言われることがある。サイトが、その家族のための待ち時間に対して調節されたメディアプレゼンテーションを提供してもよいし、もちろん、家族は、ドライブして、１０分以内に戻ってきてもよい。ボックス席の利用可能性の通知は、アプリケーションを介して提供されることがある。メニューも、この間に、モバイルデバイスを介して、またはユーザインターフェースを介して、または利用できるようになる所定の時間の前に、提供されてよい。機械学習および人工知能が、予測された利用可能時間をスケジュールおよび管理するために使用されることがある。家族がレストランに入り、テーブルのシステムに入るとき、ロケーションベースのデータは、家族がボックス席におり、メニューがユーザインターフェースに提供され得ることを示すことがある。家族は、インターフェースを介して正しく注文することができ、ボックス席への飲食物の配達の予測時間が提供されることがある。飲食物の配達に続いて、インターフェースは、支払うためのオプションが提示され、デザートメニュー、チップを置いていくためのオプションなどの、他の任意の構成要素を含むことがある。ブラウザＡＰＩが、支払いを取り扱うために、レストランサイトとブラウザとの間で利用されることがある。ロケーションベースのサービスが、食事を注文したモバイルデバイスが支払いをせずにレストランを出たかどうかを示すために使用されることがある。後日ですら、ユーザは、食事のための支払いを許可することがある。モバイルデバイスが識別されると、呼び出しが、支払いを許可することをユーザに思い出させるために、ユーザに対して行われることがある。このシナリオでは、支払い要求ＡＰＩを使用して、レストランまたは任意の店舗または任意の施設に行き、モバイルデバイスとの対話を介してグッズまたはサービスまたは飲食物を購入することが可能であり、購入を行うためにクレジットカードまたは現金を持ってくる必要すらない、ユーザ。上記のシナリオでは、購入のために品物を選択し、それらの品物を取り出し、モバイルデバイスを通して支払いを行う能力を達成するために、任意の要求、薬剤、データ、ビデオ、画像などがモバイルデバイス上のブラウザと販売業者に関連づけられたサイト��の間で交換されることが本明細書に含まれる。
【０４１６】
[00486]さらに別の態様では、上記で述べられたように、車両に組み込まれたコンピューティングデバイスが、ユーザのモバイルデバイスと通信することがある。たとえば、モバイルデバイスは、ユーザが、支払いデータ、ログインデータ、ユーザデータ、またはモバイルデバイス上にある他の任意のデータを利用して車両のコンピューティングデバイスと対話し得るように、Ｂｌｕｅｔｏｏｔｈなどのワイヤレスインターフェースを通して、車両のコンピューティングデバイス上にロードされるブラウザまたはインターフェースとブラウザ情報およびＡＰＩを協調させることがある。したがって、レストラン、または料金所、または駐車場、または車両からの支払いを必要とする任意のエンティティなどのエンティティとの間で、情報、許可、支払いデータ、または支払いの確認の通信および交換が、販売業者サイトとブラウザを有するユーザデバイスとの間の、本明細書において開示されるものと同じ様式で、エンティティと車両との間で発生することができる。ユーザが靴屋または衣料品店、または他の任意のタイプの店舗に行くシナリオなどにおいて、他のデータも通信されてよく、衣服のサイズ、靴のサイズ、帽子のサイズ、衣服または身体のモデルなどのデータが通信されてよく、または、他の任意のデータが、エンティティによって提供されるサービスを合理化する助けとなるためにＡＰＩを介して通信されてよい。
【０４１７】
[00487]車両アプリケーションの１つのシナリオでは、ある家族がディナーのためにレストランに行く予定であると仮定する。この家族は、レストランで食事をすることを望んでいる。この家族が注文し、購入を行うことを可能にするためのブラウザＡＰＩの使用は、以下のようであるとすることができる。家族または車両が、たとえば、Ｐａｎｅｒａ  Ｂｒｅａｄ、またはロケーションベースのジオフェンシング、またはＰａｎｅｒａシステムが、家族が駐車場内にいる、レストランに近づいている、もしくは何らかの意味で「オン」にされることを知ることを可能にする他のアプリケーションのためのＷｉＦｉ範囲内に入る。アイデアは、モバイルデバイスすら使用することのない、またはモバイルデバイスに関連することのない、注文および購入を可能にすることである。自動車内のシステム（コンピューティングデバイス）（これは、もっぱらモバイルデバイスを用いることもある）は、情報の交換を提供する接続を確立する。たとえば、家族の写真、車両の説明、支払いデータ（Ｐａｎｅｒａによって受け付けられる支払い方法およびユーザに利用可能な支払い方法）、スピーチ認識文法、または他のスピーチを可能にするデータなどの識別情報。ある意味で、家族が車で駐車場に入ると、必要な情報が交換される前またはその後に、おそらく適切な情報の交換に基づいて、ブランドの入ったサウンドが車両内で提供されると仮定する。このサウンドは、Ｐａｎｅｒａ  Ｂｒｅａｄ用のものとすることができ、または一般的な音とすることができ、または画像がディスプレイ上に提示可能である。別の態様では、通知は提供されない。次いで、車両内にいる人が、「Ｐａｎｅｒａ、注文したい」と言うことがある。ユーザは、飲食物を注文するためのダイアログ（口頭もしくは筆記による、グラフィティ、またはそれらの任意の組み合わせ）に関与することがある。
【０４１８】
[00488]車両内の画面が、オプションを提示する、ダイアログ交換のテキストを示す、購入可能である飲食物の画像を示す、などを行うことがある。車両は、「ブラウザ」、または本明細書において開示されるブラウザとして機能する、そのコンピューティングデバイス上にインストールされたインターフェースを有する。注文およびデータの交換が完了すると、エンティティ（Ｐａｎｅｒａ  ｂｒｅａｄ）は、ユーザが支払う準備ができたかどうかを尋ねることができる。ユーザは「はい」と言うことができ、Ｐａｎｅｒａ  Ｂｒｅａｄとブラウザとの間のブラウザＡＰＩを使用して、ブラウザと支払いサービスとの間の二次ＡＰＩを含む、本明細書において開示される支払い機構のいずれかを利用して、支払いが処理される。ユーザのシステムが家族の画像を含むことがある、または車両が、車内にいる全員の写真を撮るために使用されるカメラ（たとえば、バックミラーによるカメラ）を含むことがある。システムは、一行は何人か、および幼児用椅子が必要かのような詳細を尋ねることがあきる。誕生日情報などのソーシャルメディアデータが提供されることがある。支払い処理は、本明細書において開示されるように発生する。次いで、家族は、ただ着席してよく、家族の画像、名前、説明、人数などが、レストランに提供されることがある。次いで、レストランの労働者が、その画像を利用して、飲食物をもつ家族を見つけることがある。レストランが、「ご注文の支払いが済みました。入って左にある２３番のボックス席へどうぞ」と言うことすらある。システムは、飲食物を持ってくるため、および家族がどこに座るかを調整するために、家族を特定の場所に入れることがある。ユーザの好みおよび要望などの特別なことも、通信されることを必要とする。ウェイターが飲食物を家族のボックス席に持ってきたとき、ウェイターは、「Ｊｏｎｅｓ様、ようこそお越しくださいました。お誕生日おめでとうございます、Ｊｅｎｎｙ！ディナーをお持ちしました」と言うことができる。飲食物は支払われており、一態様では、ユーザは、モバイルデバイスを利用することすら必要としなかった。別の態様では、この処理のすべてが、モバイルデバイス上で行われることがある。システムはまた、ユーザが、注文し、支払い、飲食物の準備ができ、テーブルが利用可能になるので２５分以内に戻ってくるべきであると言われ得るように、バックログを取り扱うことがある。
【０４１９】
[00489]数多くのレストランが１つの近接したエリア内にある場合、ＷｉＦｉサービス、または他のサービスは、家族が、１つの駐車場によってサービスされる異なるレストランから選定することを可能にすることがある。異なるスピーチ文法が、どのレストランが選定されたかに基づいて提供および実施されることがある。システムは、家族を識別するために使用されることもある注文番号またはパスワードを家族に提供することがある。おそらく、モバイルデバイスと協調して、ある数が、ウェイターＩＤのための数をもつテーブルの上にモバイルデバイスを置くだけでよいように提示されることがある。
【０４２０】
[00490]類似の手法が、労働者が自動車を見て、注文が何であるかを知り、ユーザが車で窓にきたときに、その注文を単にユーザに手渡すことができるように、自動車識別情報がレストランに提供されるように、ドライブスルーの役に立つことがある。ユーザが、窓のところで、またはモバイルデバイスをもつ労働者に、クレジットカードを手渡すまたは現金で支払う必要はない。上記で述べられたように、自動車内の任意のロケーションにおいて任意の運転手または同乗者が使用するために提供可能である自動車内の指紋読み取り装置は、セキュアな購入のために実施可能である。
【０４２１】
[00491]電子的な手段を通して、自動車は、異なる家族からのモバイルデバイスも車内にあることを知ることもある。２組のカップルがディナーに行く予定であり、彼らが、各々がそれぞれの食事の代金を支払うことを望む、または任意の品物が、人々のグループによって支払い可能である場合、システムは、２人の人々に支払わせるオプションを取り扱うことができ、一義化ダイアログが発生することができ、モバイルデバイスと車両システムとの間の任意の種類の協調が、適切な一行が自分たちの分の代金を支払い、ユーザが全員食事または品物を手に入れるように、発生することができる。
【０４２２】
[00492]手法は、ユーザが会社までドライブしていることがあり、品物を注文して支払うためにダイアログに関与する場合、会社の役に立つことがある。次いで、労働者は、購入が通知されることがあり、ユーザは、たとえば、Ｗａｌｍａｒｔに行って、労働者に品物を自動車まで（ロケーションベースのデータが助けとなることがある）または特定のピックアップロケーションに持ってこさせることがある。または、ユーザは、品物を見つけに行って、労働者にモバイルデバイス上でバーコードをスキャンすることを可能にさせる、またはユーザがただ品物を持ってドアから歩いて出ることができるように画像認識を有することがある。
【０４２３】
[00493]諒解され得るように、ブラウザＡＰＩは、任意のデバイスおよび任意のモノのインターネットシナリオにおいて適用可能である。たとえば、冷蔵庫は、単一のクリックを介して食品雑貨を注文して代金を支払うために販売業者と通信し、ブラウザＡＰＩまたはＡＰＩの組み合わせを利用することができる、ブラウザまたはインターフェースを装備することがある。在庫品、および目覚まし時計、電気、水、もしくはガスのためのユーティリティインターフェース、または他の任意の種類のデバイスを含む棚は、登録されているユーザがエンティティに支払い情報を提供することなく、そのエンティティに対する支払いを達成するために、本明細書において開示されるように機能するように装備可能である。たとえば、ルータ、スイッチ、サーバ、記憶デバイスなどのＩＴデバイスなどの任意のオブジェクトは、本明細書において開示される支払い手法を適用することができる。他の例としては、環境モニタ、公安車両、販売時点情報管理端末、自動販売機、看板、照明、飛行機、料金所、ポンプ、バルブ、コンベア、パイプライン、モータ、駆動装置、組み立ておよび包装機器、容器、外科用器具、ポンプ、遠隔医療デバイス、インプラント、デジタルカメ、電力系統、読み取り装置、洗濯機および乾燥機、さまざまなメータ、ＴＶ、ＭＰ３デバイス、ゲームコンソール、タービン、風車、バッテリ、ジェネレータ、燃料電池、ドリル、ＨＶＡＣシステムなどがある。１つまたは複数の任意のそのようなデバイスは、本明細書において開示されるように購入情報を取り扱うために、ブラウザ支払い要求ＡＰＩおよびその関連づけられた技術を利用することができる。
【０４２４】
ブラウザＡＰＩインターフェースを通して提供される追加の特徴
[00494]ブラウザＡＰＩインターフェース（すなわち、参照により本明細書に組み込まれるＷ３Ｃ．ｏｒｇ支払い要求ＡＰＩ）を使用することは、インターネット上で一般的なインターフェース内で支払いを取り扱うことに関して非常に有用で効率的である。それは革命的である。他のエリアでは、買うボタンは、人々がいるところおよび人々が時間を費やすところに提示されているので、現在、ソーシャルメディア、Ｆａｃｅｂｏｏｋなどにおいて非常に一般的である。現在、ブラウザＡＰＩに関して、問題は、人々がいるところに買うボタンを持ってくることではなく、支払いプロセスを単純化するブラウザＡＰＩインターフェースに関連して何をするべきかである。現在、ウェブ上の人々は、製品およびサービスを買うために一般的なインターフェースを使用している。Ｗ３Ｃ標準支払い要求ＡＰＩは、Ｍｉｃｒｏｓｏｆｔ、Ｇｏｏｇｌｅ、Ｍｏｚｉｌｌａ、Ｓａｍｓｕｎｇ、Ｓａｆａｒｉ（所有権を主張できるバージョン）などによって実装されている。本開示は、他のサービスにアクセスすることをより効率的にする他の機能を包含する。
【０４２５】
[00495]たとえば、支払いインターフェースは、対話するとき、行われた購入および各品物に対するそれぞれの処理のリストをユーザに提示することができる、ボタン、ドロップダウンメニュー、またはハイパーリンクなどの対話可能なオブジェクトを用いて補足可能である。これは、Ａｍａｚｏｎ．ｃｏｍを介した購入すべてのステータスをリストする、Ａｍａｚｏｎ．ｃｏｍにおいてユーザに提示されるアカウント情報に類似している。このシナリオでは、購入は、ａｍａｚｏｎだけでなく異なるサイトにまたがる購入のために、中央エージェントに報告可能である。それは、ａｍａｚｏｎ．ｃｏｍも含むことができる。したがって、ブラウザＡＰＩインターフェース内で、ユーザは、「購入を管理する」オブジェクトなどを見ることができる。ユーザは、ブラウザの選択フィールド内でエージェントを選択することがある。たとえば、異なるエージェントは、標準化された呼び出しおよび応答が提供可能であるように、ブラウザＡＰＩに統合可能であるサービスを提供することができる。または、ユーザは、支払いインターフェースと統合し、ユーザが効率的な様式で製品購入履歴およびステータスへのアクセスを得ることを可能にするアカウント／購入管理エージェントから情報を受信するために、ハイパーリンクすることができる。
【０４２６】
[00496]したがって、標準的なｍｅｒｃｈａｎｔ．ｃｏｍウェブサイトにあるように見えることがあるが、ユーザアカウント購入履歴および情報へのアクセスを提供するブラウザＡＰＩ内にあるユーザインターフェースが、提示可能である。これは、複数のサイトにまたがる購入の集約がはるかに容易に管理されることを可能にする。「アカウント」は、そのユーザまたは家族もしくは他の結び付きの中でリンクされたユーザのグループのためのインターネット上での購入をすべて包含することができる。ユーザは、ブラウザＡＰＩが利用可能になることなどの、一般的な購入技法を使用することがより快適になると、購入のすべてへの容易なアクセスを要求する。したがって、ユーザが、購入の制御、レビュー、およびさらなる管理へのアクセスを要求するので、ユーザは、そのような容易なアクセス可能性を要望し、要求する。
【０４２７】
[00497]販売業者サイトは、要望する場合、そのような機能を可能にするために、ブラウザＡＰＩへの呼び出しを提供することがある。たとえば、ユーザが購入プロセスを経験するとき、ユーザアカウントへのアクセスを可能にする対話可能なオブジェクトのブラウザＡＰＩインターフェース内での提示を販売業者がオンまたはオフにすることがあるパラメータが、設定されることがある。したがって、販売業者は、そのようなアクセスを提供しないことによって購入プロセスを単純化することが可能であることがある。販売業者は、もちろん、ブラウザＡＰＩが購入に関連づけられた基本データを、そのような対話可能なオブジェクトを通してアクセス可能にする可能である購入された品物２購入履歴を記憶および追加することができるサービスに通信することが可能であるための許可も含むことがある。したがって、ブラウザＡＰＩは、ユーザおよび販売業者と支払いプロセスを接続するエージェントになることが可能であるだけでなく、そのような購入をすべて受信し、それらの購入を、ユーザによって多数の異なるプラットフォームにまたがってアクセス可能とすることができる１つの完全なアカウント履歴へと組み合わせるサービスまたはシステムに、購入データを通信するためのエージェントになることもある。一例では、単にそのようなサーバを活用してアクセスし、購入のすべてを管理するユーザの能力を提供する別個の「アプリ」が、モバイルデバイス上で提供されることがある。たとえば、そのような「アプリ」またはサービスは、Ａｍａｚｏｎ．ｃｏｍ購入のすべて、ならびにサービスに報告されるインターネット上での購入を引き込み、現在Ａｍａｚｏｎ．ｃｏｍ上または個々のｍｅｒｃｈａｎｔ．ｃｏｍウェブサイトを用いてのどちらかでのみ利用可能である機能性および制御のすべてを提供することがある。
【０４２８】
[00498]加えて、ブラウザＡＰＩインターフェースと対話する状態から、システムは、ユーザが誰であるか、ユーザの支払い情報、および購入された製品についての情報を知る。したがって、このインターフェースから、およびプロセスに沿った任意の状態から、システムは、代替製品を広告する、高く売りつける、提案する、割り引きを提供する、追加のサービスを提供する、保証を提供するなどを行うことがある。そのうえ、このインターフェースから、ソーシャルネットワーキング機会が提示されることがある。したがって、ユーザは、その製品に関係するＦａｃｅｂｏｏｋページまたはＰｉｎｔｅｒｅｓｔ投稿へのリンクが提示されることがある。特定の関連のある状態のソーシャルネットワーキングサイトへの「ディープリンク」が作成され、ブラウザから取り出されたデータを通して可能にされることがある。たとえば、買い手の友人が、同じ製品を一週間前に購入し、それについて何かを投稿した場合、システムは、その情報を識別し、ユーザが支払いインターフェース上での購入を完了した後で、友人の投稿をもつソーシャルネットワーキングフィードにユーザを遷移させるオブジェクトを提示することがある。たとえば、時々、Ｆａｃｅｂｏｏｋフィードは、数十または数百の投稿を有することができ、友人の特定の投稿を見つけることが難しい。遷移は、ブラウザＡＰＩ支払いインターフェースから、行われたばかりの購入に関連のある特定のソーシャルネットワーク投稿に行われ得る。システムは、購入の前、その間、またはその後に、「この購入をツイートする」または「Ｆａｃｅｂｏｏｋ上でこの購入を投稿する」と示すボタンをインターフェース上に提示することができる。これは、任意のソーシャルネットワーキングサイト内で、または販売業者サイトなどの他の任意のサイト内ですら、発生することができる。どのようにＴｗｉｔｔｅｒが機能するか、どのようにＦａｃｅｂｏｏｋが機能するか、どのようにＦａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒが機能するか、どのようにテキスト送信が機能するか、どのように電子メール送信が機能するか、どのようにＰｉｎｔｅｒｅｓｔが機能するか、どのようにＩｎｓｔａｇｒａｍが機能するかなどの、他の任意のサイトの特定の機能が本明細書に組み込まれ、本開示の一部として仮定される。言い換えれば、システムは、購入、ユーザ情報、支払い履歴、購入に関係するデータのための買い手および友人／家族に関するソーシャルメディアデータなどのうちの１つまたは複数を分析し、支払いプロセスに沿った任意の段階において（支払いの前、ユーザが、ブラウザＡＰＩを通して対話に至るプロセスを開始したとき、支払いの後など）ソーシャルメディアオブジェクト（または製品を購入したアカウントオブジェクトなどの他の任意の遷移オブジェクト）を提示することができる。たとえば、システムは、メッセージを送信するために製品を先週買った友人をユーザが選択したかのような状態でＦａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒにユーザを遷移させるように構成されたオブジェクトを提示することがある。オブジェクトは、このボタンを押すことによって、ユーザが、メッセージを受信するＪｏｈｎとともにＦａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒに��移され、Ｆａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒは、タイプする準備が整っていることを示すことがある。
【０４２９】
[00499]さらに、提示されるオブジェクトが、ソーシャルネットワーキングサイト上での投稿であるように構成されることがある。たとえば、Ｆａｃｅｂｏｏｋアカウントを有するユーザは、購入についての情報（品物、サイズ、数、説明など）を利用することができ、購入についてのＦａｃｅｂｏｏｋタイムライン上での投稿を準備することができる支払いインターフェース上でのオブジェクトを許可することができる。したがって、オブジェクトと対話することによって、システムは、製品の写真、説明、およびユーザのフォロワーがおそらく買うための投稿に対する買うボタンすらともに事前構成されたＦａｃｅｂｏｏｋに対する投稿を構成および準備することができる。これは、ユーザが、製品を購入することによって、広告を投稿することができる新しい種類の広告である。ユーザは、自分のコメントを挿入することすらある。したがって、オブジェクトをクリックすることによって、ユーザは、製品についての詳細、「ＧｏＰｒｏバージョン１０を買ったところです。とても興奮します」という購入についての何らかのテキストをタイプする機会を示す投稿が提示され、その投稿を、含まれる買うオプションとともにフォロワーにシステムに送信させることがある。これが異なるのは、それが、必ずしも販売業者からではなく、ユーザからの個人的な投稿であるからである。しかしながら、ＳｈｏｐｉｆｙまたはＢｉｇｃｏｍｍｅｒｃｅのような企業は、プロセスを可能にするためにバックエンド処理サービスも提供することがある。投稿者は、購入を投稿するための割り引きを手に入れることすらある。割り引きの通知は、購入プロセスのいずれの段階においても来ることがある。たとえば、購入を行うとき、販売業者は、ユーザがソーシャルメディアボタンをクリックした場合に５％割り引きを与えることがあり、買うことのできる投稿を、ユーザからソーシャルネットワークを通して送信させる。在庫追跡は、購入するためのオプションまたは購入プロセス機会が、追加の品物の在庫がある（ユーザが品物を買ったばかりである）ときのみ提示されることを保証することができる。もはや品物がない場合、投稿は、製品がいつ補充されるかについての情報を守り通すことができる。
【０４３０】
[00500]このプロセスは、本質的に、ソーシャルネットワーキングサイト上での非販売業者の投稿であるが、販売業者の構成要素を伴う。それが強力であるのは、人々が、その投稿が個人的な投稿であり、販売業者の投稿でないことを理解しているが、その投稿は、依然として、買うことのできる対話のために構成されるからである。この種類の投稿またはこの種類の投稿に至るオブジェクトは、支払い要求ＡＰＩインターフェースの外部でも発生することができるが、ａｍａｚｏｎ．ｃｏｍまたは任意の支払い機構を使用する任意の販売業者サイトなどの任意のサイト上で機能し得ることが留意される。ある時点において、ユーザがログインし、システムは、構成された投稿のためにソーシャルネットワーキングサイトに遷移することを可能にするのに十分な情報を有する。関係が、バックエンドプロセスにおいて現在多くの販売業者によって使用される買うことのできるオプション処理と個人的な投稿を接続するように、ソーシャルメディアサイト上で販売業者と個人投稿者との間で発展可能である。
【０４３１】
[00501]この点に関して、個人ユーザからの投稿は、ある意味では、ユーザと販売業者との間で「ブランド提携」可能である。プレゼンテーションは、おそらくユーザのプロフィール写真を販売業者のロゴと結合するグラフィックスを含むことができる。ユーザが、買うことのできる投稿を個人的に投稿しようとしている場合、投稿の受信者が、品物がｃａｎｏｎカメラ、またはＭａｃｙ’ｓの製品であることだけでなく、友人によって個人的に投稿されたものであり、会社の投稿でないことも認識することができるように、システムが、動的に、または事前に、投稿に付随するブランド提携画像を生成することができるプロセスが、機能することがある。この手法は、その投稿に基づいて購入を行う際に受信者がもつことができる信頼を強化することができる。
【０４３２】
[00502]購入インターフェースは、Ｆａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒのような何かに遷移するオプションも含むことがある。ユーザは、購入を行うプロセスの中にいて、質問があることがあり、メッセンジャーは、製品についての販売業者との対話を可能にすることができる。ユーザは、２年の保証があるもしくは四輪駆動であることを確認することを望むことがある、または質問があることがある。システムは、メッセンジャーアプリケーション内でなされるように最終的な購入を遷移させてもよいし、購入を確認するためにＡＰＩインターフェースに戻るように遷移させてもよい。ＡＰＩは、インターフェースへのおよび／またはからのそのような遷移を行うのに適切な呼び出しおよび機能性を含むことがある。このプロセスは、もちろん、Ｆａｃｅｂｏｏｋ  Ｍｅｓｓｅｎｇｅｒアプリケーションだけでなく、販売業者とインターフェースするための任意のアプリケーションを組み込むことができる。
【０４３３】
[00503]他のオプションが、人々が製品に関してソーシャルネットワークを通して個人的に投稿し、取引、割り引き、ポイント、クレジット、無料製品などを得ることを可能にするために利用可能である。たとえば、ソーシャルネットワークユーザが、Ａｍａｚｏｎ．ｃｏｍまたはｃａｎｏｎ．ｃｏｍによって投稿されたｃａｎｎｏｎ  ７Ｄカメラなどの製品の広告を見ることがある。現在、アクションに関連づけられた今すぐショッピングボタンまたは今すぐ買うボタンまたは他のボタンがある。提案は、同じ構造でその製品をユーザが自力で投稿し得る別のボタンを追加することである。このケースでは、投稿は個人化され、ユーザは、コメント、または自分の写真（おそらく、買った製品とともに、またはビデオ）を追加して、投稿してよい。変化するものは、投稿は、ユーザのソーシャルネットワークを通じてであるが、ユーザがその製品の購入を行うために遷移可能であるように、今すぐ買うオプションを保有することができることである。それは、企業からではなく友人からであるので、より個人的な投稿である。ユーザは、自分も製品を購入した後で、そのような投稿を得ることがある。そのため、ユーザがｃａｎｏｎ  ７Ｄカメラを買ったと仮定する。ユーザは、選定可能なオプションをもつｃａｎｏｎ  ７Ｄカメラ投稿を見て、次回購入の１０ドルオフを求めて再投稿することがある。投稿は、準備されているニュースフィード内で構成され、ユーザが再投稿するように構成されることがある。たとえば、それは、「このカメラを買う」と述べるのではなく、「友人たち、このカメラを買ったばかりで、とても気に入っています。Ａｍａｚｏｎは、このカメラを割り引き料金で提供します」と述べることがある。したがって、ユーザが投稿を再投稿したとき、投稿は、ユーザから、フォロワーに対してであり、既にやや個人化されている。これは、ユーザが製品を共有しやすくし、投稿を、容易な購入のために構成させやすくするであろう。購入は、ソーシャルネットワーキングサイト、別個の支払いプロセッサ、販売業者サイトによって、Ａｐｐｌｅ  ＰａｙもしくはＡｎｄｒｏｉｄ  ｐａｙを通して、またはブラウザ支払い要求ＡＰＩを通して、またはＡｍａｚｏｎ．ｃｏｍもしくは従来の支払い手法を通して、処理されてよい。このシナリオにおける買い手はまた、それを友人の投稿から買った場合、１つの割り引きなどの構造化された割り引きを得ることがあり、それを買って自分でソーシャルネットワーク上に投稿した場合、追加の割り引きを得ることができる。買い手が購入後にソーシャルネットワーク上で投稿した場合、追加の割り引きが、支払いアカウントの貸し方に記入されることがある。買い手が購入を行ったときにソーシャルネットワーク上で購入または品物を再投稿しないことがあるが、システムは、１日後、１週間後、または何らかのインテリジェントな時間の後にそのユーザに対して機会を投稿し、ユーザがこの品物を先週買って、それをとても気に入っていると投稿した場合、５ドルの返金もしくはクーポンもしくは割り引き、またはマイル、または何らかの他の利益の機会をユーザに与えるようにプログラムされる場合がある「再ターゲティング」手法も含まれることがある。
【０４３４】
[00504]この例における利益は、ユーザが製品を買うと、ユーザが購入製品をテストするまたは試す時間の期間があるということである。次いで、ユーザは、たとえば、どれほどカメラを気に入っているか、または掃除機などの製品についての感情をソーシャルネットワーク上で投稿し、友人がそれを買うことを提案することができる。システムは、製品の使用法に関する何らかの種類のネットワークベースのフィードバックを取得することがあり、このフィードバックは、再投稿をトリガすることがある。たとえば、ユーザがｉｐｈｏｎｅ  ７を買うことがあり、システムは、ユーザが５０枚の写真を撮った後、ユーザは、個人化された投稿のためにいくつかを選ぶべきだと決定することができる。投稿は、製品とユーザの写真に加えて、買うオプションと、個人なコメントとを含むことができる。
【０４３５】
[00505]上記の概念の別の態様は、ディープリンク遷移をどのように取り扱うかである。たとえば、Ｊｏｈｎが製品に関するａｍａｚｏｎ．ｃｏｍの投稿を得た場合、彼は、あちこち見るおよび／またはショッピングするために、今すぐショッピングするまたは今すぐ買う（または類似のラベル）をクリックすることができる。いくつかのケースでは、投稿がＪｏｈｎに知られているので、彼がオブジェクトをクリックした場合、システムは、彼が自動的にログインされ、支払いおよび配達情報が既に記憶されており、遷移の直後にワンクリック購入するまたは非常に少ないクリックで購入を行うことができる、ａｍａｚｏｎ．ｃｏｍ内のディープリンクに、彼を遷移させることができる。ａｍａｚｏｎ．ｃｏｍの「状態」は、購入の容易さのためにユーザおよび製品に関連づけられたディープリンクである。ワンクリック購入パラメータにアクセスするなど、ディープリンクワンクリック購入状態を可能にするためにブラウザからデータにアクセスすることが、利用されることがある。
【０４３６】
[00506]個人的な製品投稿に戻ると、Ｊｏｈｎの１００人のフォロワーが投稿を見て、同じく購入を行うことができるように、Ｊｏｈｎが製品投稿を再投稿することがあると、情報の追加の転送または共有が必要であることがある。システムは、今すぐ買うをクリックした受信者も、ログインされた状態でａｍａｚｏｎ．ｃｏｍ内のディープリンクに遷移され、支払い情報または配達情報を手動で入力する必要なしにワンクリックするまたは少ないクリックで購入を行うことができるように、各受信者を追跡する。ＡＰＩは、上記で説明された結果およびプロセスを達成するために遷移およびバックエンド処理を取り扱う目的で、ソーシャルネットワーキングサイト、販売業者サイト、ブラウザ、支払いプロセッサ、および／または他の任意のエンティティとの間で確立可能である。
【０４３７】
[00507]一態様では、機会および概念は、ソーシャルネットワーキング構造間での遷移を含む。たとえば、ユーザが、ニュースフィード内にＦａｃｅｂｏｏｋ広告を得て、それを買うことのできるピンとしてＰｉｎｔｅｒｅｓｔアカウント内で再投稿することを望むことがある。システムはまた、買うことのできる構成を保ちながら、投稿をあるフォーマットから別のフォーマットに翻訳することができる。ある支払い構造から別の支払い構造への遷移が必要とされる場合、その遷移も発生することができる。たとえば、ａｍａｚｏｎ．ｃｏｍの投稿は、ユーザがＦａｃｅｂｏｏｋ、Ｐｉｎｔｅｒｅｓｔ、Ｉｎｓｔａｇｒａｍ、Ｔｗｉｔｔｅｒ上で販売業者投稿を自分のものとして再投稿すると、またはユーザが、あるタイプのソーシャルネットワークから別のタイプのソーシャルネットワークに遷移した場合、支払いのためのディープリンク処理からブラウザＡＰＩ支払いまたはＡｎｄｒｏｉｄ支払い手法に遷移されることがある。ユーザの好みも変更され、どの種類の遷移が発生するかを駆動することがある。ａｍａｚｏｎ．ｃｏｍが、既にユーザ支払いおよび住所情報を記憶させている場合、遷移は、依然として、ワンクリック購入パラメータセットなどのブラウザ内のデータにアクセスすることを必要とすることがある。
【０４３８】
[00508]ブラウザＡＰＩ支払いインターフェースからの別の例示的な遷移は、ユーザをサイト内に戻ってのショッピング状態にさせ得る「ショッピングを続ける」ボタンまたはオブジェクトであることがある。ユーザは、検索が行われていないかのように新しい検索フィールドへ連れて来られてもよいし、ユーザは、購入した製品の最終的な状態に手段を分けたであろう部分的な検索に遷移してもよい。
【０４３９】
[00509]ブラウザＡＰＩはまた、価格設定の自動的な調整、パラメータ変更（色またはサイズ、数など）などを用いて、２つ以上の製品を買うオプションなどの追加の機能を提供するように強化されることがある。
【０４４０】
[00510]追加の機能はまた、そのためにブラウザＡＰＩが開発された基本的な購入プロセスと無関係であることができる。販売業者サイトおよび／もしくはブラウザ、ユーザ、または他のエンティティは、ＡＰＩへの呼び出しを通して、この追加の機能を開始することができる。たとえば、ブラウザＡＰＩが、ユーザを支払い履歴および管理機構と接続する追加の特徴を含むように修正され、販売業者サイトが、その機能をブラウザＡＰＩインターフェース上で提供したい場合、パラメータが設定可能である、または、呼び出しが、購入履歴管理構成要素をオンにするブラウザとの他の通信に関連して行われ得る。その特徴がオンにされた場合、ブラウザは、別のＡＰＩまたは他の機構を介して、そのユーザに関する支払い履歴をウェブ上で記憶し、情報および管理能力で応答するサービスと対話することができる。ブラウザＡＰＩは、その情報をフォーマットする助けとなり、ユーザによって対話されたとき、ユーザによるレビューおよび／またはアクションのために購入履歴を提示する、ブラウザＡＰＩインターフェース、および対話可能ボタン、ハイパーリンク、またはドロップダウンメニュー上に存在することができる。システムはまた、ユーザに、その特徴が選択された場合、購入を管理するための別個のサイトに、遷移することがある。この手法の利益は、インターネット購入にまたがって標準化される予定であるインターフェースにおいてユーザに追加の機能を提供することである。これは、それぞれのサービスへのアクセスの開始が、多くの人々が使用するインターフェースであるブラウザＡＰＩを通して適切に行われ得るので、ユーザによるより少ないクリックまたはより少ない対話を必要とする様式でサービスへのアクセスを提供することによって、「ビジネスバリューチェーン」を減少させる。
【０４４１】
[00511]一態様では、販売業者は、販売業者が提供するサービスの種類の報告を提供することがある。これは、ある意味で、販売業者が、Ｖｉｓａ、Ｄｉｓｃｏｖｅｒ、およびＭａｓｔｅｒＣａｒｄなどの、許可された支払い機構のリストを提供することに類似している場合がある。ユーザ支払い機構へのアクセスを有するブラウザＡＰＩは、支払いが進むことができるような合致で応答する。この追加のコンテキストでは、販売業者は、ブラウザＡＰＩインターフェースを通して実行されるために利用可能である代替サービスのリストを提供することがある。たとえば、販売業者は、ユーザの個人的な友人が類似の購入を行った、購入履歴管理アクセス、Ｆａｃｅｂｏｏｋ投稿アクセス、Ｐｉｎｔｅｒｅｓｔアクセス、およびＦａｃｅＴｉｍｅアクセスを提供することがある。ユーザプロファイル内で、ユーザは、ブラウザＡＰＩインターフェースにアクセスすることを望むであろうまたはそうする場合があるサービスの代替タイプを選択することもできる。したがって、ユーザが、購入履歴へのアクセスを要望し、Ｆａｃｅｂｏｏｋのメンバーである場合、ＡＰＩを通して、ブラウザＡＰＩインターフェースは、Ｆａｃｅｂｏｏｋのためのあるオブジェクトおよび購入履歴のための別のオブジェクトを提示するべきであることが決定される。
【０４４２】
[00512]次いで、ユーザがＦａｃｅｂｏｏｋオブジェクトと対話する場合、システムは、いくつかの異なる機能を実行することがある。システムは、単に、Ｆａｃｅｂｏｏｋおよびユーザの一般的なニュースフィードにユーザを転送することがある。システムは、特定の購入に接続され、特定の購入のために構成される投稿のプレビューをユーザのタイムライン上で生成することがある。オプションはまた、そのような投稿を確認する、投稿がショッピングボタンまたは買うことのできるボタンが提示可能である場合に５％割り引きを受け入れるなどのために、提示されることがある。これらのパラメータは、必要に応じて代替サービスに接続される場合がある他のデータもともに、ＡＰＩを通して配信可能である。
【０４４３】
[00513]たとえば、ユーザの親友が同じ帽子を買っており、それについて話したいであろうことを示す１つのオブジェクトが、インターフェース内に提示されることがある。ボタンが、発呼、ＦａｃｅＴｉｍｅ、Ｓｋｙｐｅ対話、および電子メール、テキストなどを開始することがある。任意のタイプの通信が、２人の関係者の能力、過去の履歴などに基づいて開始されることがある。したがって、一態様では、ブラウザＡＰＩが、単に支払いプロセスをより単純および均一にする目的で、ブラウザと販売業者との間の通信を提供することを越えて拡張される。ブラウザＡＰＩは、他の任意の種類のサービスまたは情報のためのエージェントであるようにも拡張可能である。支払いプロセスでは、コスト、製品、ユーザ、住所、電子メールアドレスなどの、ある一定の情報が知られている。そのデータを利用することができる任意の追加のサービスまたは能力が、ユーザがいるその点または地所にその追加の機能および能力を追加するために、ブラウザＡＰＩを通して活用可能である。したがって、購入に直接的に関係することもしないこともあるこの新しい機能、すなわち、たとえば、Ｆａｃｅｂｏｏｋ投稿を提供するために、販売業者サイトを離れて追加のまたは別個のサイトに進むことを必要とすることなく、これらの追加のサービスにユーザが遷移またはアクセスする能力を追加することによって、ユーザは、最小限の数の対話で、この追加の機能にアクセスし、これを達成することができる。
【０４４４】
[00514]ブラウザＡＰＩインターフェースを通して提示され得るオプションのタイプはまた、対話の状態に応じて変化してもよい。言い換えれば、プロセスは簡潔であるが、プロセス全体を通じて、異なる状態がある。最終的な確認の前に支払いおよび購入概要を提示する状態がある。最終的な確認に続く状態などがある。対話の状態に応じて、異なるサービスが提示可能である。状態が、購入の最終的な確認の前にある場合、コメント、または格付け、またはサードパーティサービスサイトから入手可能であることがある製品についての情報の概要を提供するオブジェクトが提示されることがある。これは、販売業者サイトのみを通して得られないことがある製品についての追加の情報をユーザに提供することができる。購入に続いて、エンティティは、販売業者と提携することもしないこともある、保証、サービスプラン、追加の購入のためのオプションなどを提供する場合がある。販売業者は、ＡＰＩインターフェースを通して、そのような追加のアクティビティを協調させ、許可することがある。たとえば、販売業者は、許可された保証提供企業がブラウザＡＰＩインターフェースを通して保証の機会を提示することが可能にされ得ることを示すパラメータを設定または送信することがある。このようにして、販売業者は、インターフェースを通して、そのような追加の機能のレベルを制御することができる。
【０４４５】
[00515]いくつかのケースでは、ブラウザＡＰＩインターフェースは、実行されている機能に応じて追加のページまたは対話を追加することすらある。したがって、単に選択可能なオブジェクトを追加すること以外に、機能に応じて、ブラウザＡＰＩは、ユーザが追加の選択を行い、提供されている機能を達成または実行することを可能にする、追加のインターフェースまたはより多くのインターフェースを提示することがある。この機能は、インターフェースの一部であるかのように提示可能である、販売業者サイトの一部であるかのように提示可能である、または、販売業者サイトからソーシャルネットワーキングページ、サイト、アプリケーションなどの別の環境への遷移を明らかに開始することができる。これらのコンテキストにおいて、ユーザが、対話している人物に対して安心することが重要である。したがって、ブラウザＡＰＩは、販売業者サイト上で支払いプロセスの一部として提示される。この追加の機能は、サイト上でも、または別個に、提示可能である。
【０４４６】
[00516]さらに、ブラウザＡＰＩインターフェースは、他の機能を含むように拡張可能である。ユーザは、ブラウザに拡張機能をインストールするによく似て、インターフェースへの拡張機能をインストールすることができる。インターフェース内に提示されるＡｍａｚｏｎ  Ａｓｓｉｓｔａｎｔは、インストールされることがある。前処理は、インターフェースを通して購入から取得されたデータを使用して発生することがある。たとえば、ユーザが１対のズボンを買う。システムは、ユーザのウエストサイズおよびズボンのスタイルを知っている。ａｍａｚｏｎアシスタントは、アクセサリがＡｍａｚｏｎ．ｃｏｍ上で容易にショッピングされ得るように、「ベルト」または「茶色の革のベルト、ウエスト３４」という語句が事前にポピュレートされた入力フィールドを提示することがある。検索結果を調節させ、購入したばかりの品物と合致させる他のパラメータが設定可能である。一態様では、ブラウザに追加された拡張機能は、ブラウザＡＰＩインターフェースを通してアクセス可能である。言い換えれば、ブラウザ上にインストールされたＡｍａｚｏｎアシスタントは、単に主なブラウザインターフェースではなく、ＡＰＩインターフェースからアクセスされることがある。
【０４４７】
[00517]Ｇｏｏｇｌｅ検索またはｅＢａｙ検索などのさらなる検索を可能にするオブジェクトが、ＡＰＩインターフェース上に提示されることがある。ＡＰＩを通して行われた購入に基づいて検索アクティビティを絞るまたはフィルタリングするパラメータも設定されることがある。たとえば、ユーザが品物を購入したばかりである場合、Ｐｉｎｔｅｒｅｓｔ検索フィールドが、ユーザがアクセサリまたは類似の品物を検索および閲覧するためにＡＰＩインターフェースからＰｉｎｔｅｒｅｓｔに遷移することを可能にする語句が事前にポピュレートされたまたはポピュレートされていない提示されることがある。
【０４４８】
バーチャルリアリティ
[00518]ブラウザＡＰＩはまた、バーチャルリアリティなどの他のコンテキストにおいて利用可能である。たとえば、ユーザが、バーチャルリアリティゴーグルまたはヘッドセットを使用して衣服などの品物をショッピングするための機会を有する場合、ブラウザＡＰＩの使用が適用可能とすることができる。ブラウザＡＰＩプロトコルへの修正は、特にそのコンテキストに提供するために行われ得る。たとえば、セキュリティ目的で適切なユーザ識別を提供することが、上記で検討されている。それが、購入を行う適切なユーザであることを確認するために指紋許可またはセキュリティコードを使用すること。バーチャルリアリティゴーグルは、ユーザの顔に位置決め可能である。要素は、異なるタイプのユーザ識別を提供するためにゴーグルへと組み込み可能である。たとえば、指紋許可を提供することをユーザに要求するのではなく、ゴーグルが、ユーザの虹彩をスキャンするための機構に組み込まれることがある。虹彩スキャンは、ユーザの識別情報と合致し、購入を許可するための機構とすることができる。特定のユーザジェスチャまたは動きは、購入確認を示すことができる。そのうえ、いくつかのバーチャルリアリティゴーグルは、その画面のためにモバイルデバイスを受信する。これらのゴーグルは、ユーザがモバイルデバイスにアタッチすることができるような構成を、次いでバーチャルリアリティ経験のためのゴーグルとしての構成を提供する。モバイルデバイスは、ユーザが、バーチャルリアリティ経験を視聴しながら、単に指紋スキャナに手を伸ばして触れて購入を確認するように、その後部上の指紋スキャニング構成要素を用いて構成されることがある。一般的には、指紋スキャナは、ユーザによる容易なアクセスのためにモバイルデバイスの前側にある。しかしながら、モバイルデバイスがゴーグル構成で取り付けられるとき、指紋スキャナは、ゴーグルの内側にあり、ユーザによって容易にアクセス可能でない可能性がある。別の態様では、指紋スキャナは、Ｂｌｕｅｔｏｏｔｈ、短距離通信、ワイヤード接続、または他の任意の機構のどちらかを通して、ゴーグル上での指紋スキャンからのデータは、購入を許可するために、さらなる処理のためにモバイルデバイスに通信可能であるように、ゴーグル上に置かれることがある。モバイルデバイスは、この点に関して、２つの指紋スキャナ−１つは通常使用のために前面に、１つはバーチャルリアリティヘッドセット内で行われる購入の使用のために背面に位置を有することがある。
【０４４９】
[00519]他の態様は、購入または他の理由のためのセキュリティ目的で個人を識別するために、額の形状、鼻の形状、ユーザのＤＮＡデータ、温度データ、運動パターン、スピーチ、顔認識などを識別することが可能であるゴーグル構成も含むことがある。たとえば、特定のまばたきパターンが、ユーザの識別を確認するために確立されることがある。これらのさまざまな手法は、ブラウザＡＰＩを使用して購入を確認するために、指紋またはセキュリティコードを確認または交換することができる。これらの手法をバーチャルリアリティコンテキストにおいて使用することは、バーチャルリアリティコンテキストにおいて購入を達成するためにユーザによって必要とされるクリックまたは対話の数を減少させることができる。したがって、本開示の一態様は、バーチャルアウトリアリティ（virtual out reality）経験をユーザに提示するためにゴーグルを用いて構成されたゴーグルとモバイルデバイスとの間の電子的協調を含むことができ、そこでは、モバイルデバイスがブラウザＡＰＩを利用して本明細書において開示される簡略化された購入プロセスを達成する。もちろん、バーチャルリアリティのための任意のヘッドセットは、分離可能なモバイルデバイスの一部であるにせよ画面に組み込まれているにせよブラウザＡＰＩを組み込むことができるブラウザ構成要素を含むことができる。一例では、ＨＴＣ  ＶｉｂｅのようなＶＲヘッドセットを使用して、ユーザが店舗内で購入を行っているかのようにバーチャルリアリティ世界内で対話する能力を含むことができる。仮想環境内での対話は、衣服を試着することまたは玩具で遊ぶことを含むことができる。ユーザは、仮想環境内で購入を行うことができ、ＶＲヘッドセットおよび／または協調されたコンピューティングデバイスは、ブラウザＡＰＩを通して仮想世界から行われた支払いを処理することができる。頭部の動きまたはジェスチャを感知するＶＲヘッドセット内のセンサは、その動きを、購入に至ることができる購入対話に翻訳することができる。さらに、ＶＲヘッドセットとコンピュータまたはゲームデバイスなどの別のデバイスとの間の任意の協調は、ブラウザＡＰＩを使用した購入を完了するために利用可能である。したがって、任意のステップまたは任意のプロセスは、購入を行う改善された手法を達成するためにＶＲヘッドセットと他の任意のデバイスとの間で分割可能である。
【０４５０】
[00520]問題は、どのようにしてブラウザＡＰＩをバーチャルリアリティ環境に組み込むかということである。Ａｐｐｌｅ  Ｐａｙでは、指紋を使用して購入を確認しなければならない。他の方法は、ＣＶＣコードまたは音声認証などを必要とすることがある。Ａｐｐｌｅ  Ｐａｙのような指紋環境の場合、解決策は、ユーザがバーチャルリアリティセッションを始めたときに指紋を受信することである。ユーザがモバイルデバイスをヘッドセットへと取り付ける、または分離可能なモバイルデバイスのない完全なヘッドセットとともに取り付けると、ヘッドセットは、指紋読み取り装置を含むことができる。事前に指紋を受信することによって、ユーザは、仮想環境内で購入を行いながら、記憶された認証を利用することができる。ユーザは、手のジェスチャを使用したり、仮想指紋読み取り装置上で指紋を提供したりしてでさえ、ショッピングし、仮想的に購入を行うことがある。購入が行われるべきであるという標識が仮想環境内で提供されるとき、ヘッドセットまたはモバイルデバイスは、セッションの冒頭で提供される指紋許可にアクセスし、その認証を、購入を完了するために適用することができる。仮想環境内のユーザは、指紋を使用して購入を許可する必要はないので、ワンクリック購入を本当に使用して支払うことすらできる。記録されている、以前の指紋許可は、どのようにしてバーチャルリアリティ環境内でユーザが支払いたいという要望を示すかにかかわらず、任意の仮想支払いに使用可能である。たとえば、環境は、誰かに現金を与えて品物を買うユーザをシミュレートする場合があるが、バックグラウンドでは、システムが、Ａｐｐｌｅ  Ｐａｙ、またはＧｏｏｇｌｅ  ＷａｌｌｅｔもしくはＡｎｄｒｏｉｄ支払いを処理することがある。仮想環境内で、ＣＶＣコードなどの任意の必要な認証、またはスピーチ、ジェスチャ、または他の任意の確認データは、仮想的に、または購入を行うために使用するためのＶＲセッションより前に、提供可能である。たとえば、ユーザは、セッションを始める前にＣＶＣコードを提供してもよいし、バーチャルリアリティ環境が、支払いを処理する目的で支払いデータを要求および受信するためにブラウザＡＰＩを利用することを可能にするために、支払い情報、住所情報などを提供してもよい。
【０４５１】
[00521]一例では、Ａｐｐｌｅ  ｐａｙは、２つのデバイスを相関づけることによってブラウザＡＰＩを利用する。ユーザは、指紋許可機構をもたないラップトップコンピュータをショッピングし、このラップトップは、ユーザに関連づけられた支払い情報を記憶し、指紋許可オブジェクトを有するセキュアな要素を含むｉＰｈｏｎｅと通信する。ユーザがラップトップコンピュータの購入を行うとき、ユーザは、別個のモバイルデバイス上での指紋許可を介して購入を確認する。バーチャルリアリティシナリオでは、ユーザによって装着され、それを通してユーザがバーチャルリアリティ経験を持っているバーチャルリアリティヘッドセットは、要求および応答を通信するように構成されたブラウザ（または類似のエージェントソフトウェア）、またはブラウザＡＰＩを介する販売業者とブラウザとの間の他の任意の通信を含むことがある。購入が仮想環境内で行われることになっているとき、ヘッドセットは、指紋許可機構を有するモバイルデバイスとワイヤレスで通信することがある。このシナリオでは、バーチャルリアリティヘッドセットは、指紋許可を必要とするその時間がきたとき、口頭で、視覚的に、または他の任意の様式で、ユーザが指紋許可を提供するために触れることを必要とすることを物理的モバイルデバイスに対してユーザに指示する命令を提供するように構成されることもある。この態様は、ユーザがセキュアに購入を行うことを可能にするようにバーチャルリアリティ環境に物理的構成要素を提供するために含まれることがある。
【０４５２】
[00522]この場合も、バーチャルリアリティ購入のコンテキストにおいてブラウザＡＰＩを使用するとき、使用されるヘッドセットまたは他のデバイスは、エージェントまたはブラウザとして機能することができる。モバイルデバイスが、ＶＲ環境を作成するためにヘッドセットの一部として使用される場合、モバイルデバイスは、支払いおよびユーザデータのための記憶機能を提供するために、本明細書において開示されるように機能することができ、ブラウザ（Ｍｏｚｉｌｌａ、Ｃｈｒｏｍｅ、Ｓａｆａｒｉ、Ｏｐｅｒａなど）は、販売業者から支払い要求を受信し、プロトコルに従って応答するように構成可能である。ヘッドセットが、取り外し可能なモバイルデバイスを使用しないが、内蔵型システムを含む場合、ヘッドセットは、ブラウザ、または同じくブラウザＡＰＩを用いて構成され、同じく類似のやり方で支払いおよびユーザデータ（ならびに本明細書において参照される他の任意のデータ）を記憶することができる類似のソフトウェアとともに、ロード可能である。機能は、ユーザ識別のための指紋読み取り装置または他のバイオメトリック読み取り装置を含む内蔵型ヘッドセット内に提供可能である。次いで、ユーザがバーチャルリアリティ環境に関与するので、ユーザが店舗に行く、または品物を仮想的に購入する場合、システムは、その購入を、ユーザが買うボタンをクリックする販売業者サイト上で購入するように扱うことができる。ユーザは、クレジットカードを仮想的に与えてもよいし、Ａｐｐｌｅ  Ｐａｙを仮想的に使用してもよいし、仮想店舗において販売時点で現金を仮想的に与えてもよい。ユーザは、仮想的に、オンライン購入を行うコンピュータにいてもよい。購入が行われるいかなる仮想状況も、ヘッドセット内で利用可能にされるブラウザＡＰＩに適用可能とすることができる。仮想対話内のある時点において、金銭が交換されるまたは支払いが確認された場合、確認が発生し、この時点で、サイトまたは販売業者もしくは売り手を表すエンティティは、ヘッドセットに関連づけられたブラウザＡＰＩへの支払い要求を開始し、プロトコルに従って、そのエンティティに利用可能な支払い機構を提供し、購入を処理するために、ブラウザＡＰＩを通して、本明細書において開示される、支払いデータ、住所データ、支払いを処理するためのワンタイム使用トークンなどを受信することができる。このシナリオでは、ユーザは、たとえば、仮想商店街を歩いて通り、衣服を試着し、玩具または本を見て、購入を行うことがあり、仮想世界内で購入された文字通りに物理的なオブジェクトは、購入され、ユーザの自宅に発送可能である。
【０４５３】
[00523]ブラウザＡＰＩに関連づけられたプロトコルは、仮想環境のために修正されることがある。たとえば、販売業者が仮想販売業者であり、買うボタンはクリックされず、異なるタイプのトリガがプロセスを開始し得ることを示すパラメータが、販売業者からブラウザへのブラウザＡＰＩを通して通信内で設定されることがある。ユーザは仮想環境内にいるので、仮想環境をユーザが使用し始めたとき、通常は、たとえば、Ａｐｐｌｅ  Ｐａｙとともに発生するように、リアルタイム指紋許可の必要性を軽減するために、ユーザが仮想経験中に購入を行う場合にアクセスされるが仮想環境内では便利または可能でないであろう指紋許可が受信および記憶されることを示すパラメータが設定されることがある。したがって、ブラウザＡＰＩプロトコルの一部としてのヘッドセットからの応答は、指紋許可が記憶され、購入を行うために使用できるように最新（current）であることを示すことがある。バーチャルリアリティ環境内でのブラウザＡＰＩの効率的な使用を達成するために必要または有用な任意のパラメータまたは情報は、バーチャルリアリティコンテキストのためのブラウザＡＰＩの修正されたバージョンを通して通信可能である。
【０４５４】
[00524]この手法は、通常のモバイルデバイスを用いてプロセスをさらに単純化するためにも使用可能である。たとえば、システムは、ユーザがデバイスを始動したとき指紋を適用することをユーザに要求することがあり、ある時間の期間にわたって、その指紋は、Ａｐｐｌｅ  Ｐａｙまたは似た購入のためにアクセスされ得る。通常、ユーザは、「Ａｐｐｌｅ  Ｐａｙ」ボタンをクリックし、次いで、指紋許可を提供しなければならない。しかし、許可が以前に行われていた場合、その許可は、ａｐｐｌｅ  ｐａｙボタン上のクリックに関連して適用され、Ａｐｐｌｅ  Ｐａｙをクリックした後で指紋を使用して購入を完了する必要性を除去することができる。指紋許可下での使用のタイミングが、たとえば３０分間に設定されている場合、システムは、再許可の必要性が近づいていることと、ユーザは、指紋許可なしで購入を行うために、たとえば５分残っているという通知を提示することがある。
【０４５５】
[00525]バーチャルリアリティ環境内のブラウザは、特にユーザがバーチャルリアリティ環境内で衣服のショッピングをしている場合、衣服のサイズ、靴のサイズなどの他のデータも含むまたはこれへのアクセスを有することがある。そのデータは、ユーザに提示されるものがユーザのサイズまたは他の好みに合うように、ユーザに提示されるものを駆動する助けとなることができる。
【０４５６】
ブラウザダウンロード
[00526]本開示の別の態様は、クライアントデバイスにネットワーク上でブラウザ最新版または完全なブラウザを送信またはダウンロードするために必要なデータを記憶するサーバを含む。プロセスは、ブラウザまたは更新されたブラウザを提供する要求を受信または識別することと、クライアントデバイス上でのインストールのためにクライアントデバイスにブラウザまたはブラウザ最新版をダウンロードまたは送信することとを含む。ダウンロードされるブラウザは、支払い要求ＡＰＩを通して支払い要求を受信および処理するために必要な機能を含む。したがって、プロセスは、支払い要求ＡＰＩ能力を含むまたはこれとともに構成されるブラウザまたはブラウザ最新版をダウンロードすることを含む。インストールされると、サイトは、ブラウザへの支払い要求呼び出しを開始することができ、これは、ユーザが支払いアカウント情報、配達情報などを入力する必要なしにサイトが購入を処理することを可能にするために支払い要求ＡＰＩを通して支払い情報を通信するプロセスを実行する。
【０４５７】
[00527]１つの方法は、データが、クライアント上にインストールされるとき、ブラウザをインストールまたは更新するように、サーバからクライアントにデータまたはコードをダウンロードすることを含む。ブラウザは、アクティブ化されるとき、本出願において開示されている機能のいずれかを含む動作を実行するように構成される。機能は、ブラウザ支払い要求ＡＰＩを動作させること、またはユーザ入力が受信された後で提示され、オブジェクトが選択されるとき、第２のサイトにおいて第２の入力フィールドに入力されたかのようにユーザ入力を処理することに基づいて提示される検索結果とともにユーザが第２のサイトに遷移される状態で前処理された一般的な入力フィールドから第２のサイトにユーザを遷移させるドロップダウンメニューを使用して第２のサイトに遷移するためにブラウザと第２のサイトとの間の通信を提供することを含む。
【０４５８】
第１のサイトから第２のサイトへの遷移
[00528]図２０Ａは、あるサイトから別のサイトに遷移するための方法例を示す。方法例におけるステップは、任意の順序で実行可能であり、追加のステップを含むまたは説明されるステップのうちのいくつかのすべてもしくは一部を除外する他の組み合わせまたは順列で実行可能である。システムは、ことができる第１のユーザインターフェース内で、ブラウザを介して処理された第１のウェブサイトに関連づけられた第１の入力フィールドを提示し（２００２）、ユーザから第１の入力フィールドへの入力を分析して、ユーザが検索を実行することを要望するか購入を行うことを要望するかを決定し、決定をもたらす（２００４）ことができる。決定が、入力以外のユーザからの他の任意の入力なしで、ユーザが購入を行うことを要望することを示す場合、システムは、第１のウェブサイトから、ショッピングカートモデルを介して製品の購入を処理することができる第２のウェブサイトにユーザを遷移させることができる（２００６）。システムは、第２のウェブサイトに関連づけられた第２の入力フィールドに入力を事前にポピュレートする（２００８）ことができる。
【０４５９】
[00529]システムは、ユーザが、自動遷移後の、入力に関連づけられた製品がユーザからワンクリックアクションを介して購入および配達のために処理可能である状態であるように、第２の入力フィールド内の入力を使用して第２のウェブサイトを前処理することができる（２０１０）。第２のウェブサイトを前処理することは、第１のウェブサイトおよびブラウザのうちの１つから第２のウェブサイトにユーザデータを送信すること、または製品がワンクリックアクションを介して購入および配達のために処理可能である状態をもたらすために第２のウェブサイトのショッピングカートモデルを自動的にナビゲートすることを含むことができる。システムは、ユーザが、入力に関連づけられた製品がユーザからのワンクリックアクションを介して購入および配達のために処理可能である自動遷移後の状態であるように、第３の入力フィールド内の入力を使用して第３のウェブサイトをさらに前処理し、ユーザが選定するオプションとして第３のウェブサイトをブラウザ内で提示することができる。
【０４６０】
[00530]前処理は、さまざまな好みをもつユーザプロファイルに従うものとすることができる。たとえば、第１のウェブサイトまたはブラウザに関連づけられたユーザプロファイル内。ユーザプロファイルは、支払いアカウントデータ、配達データ、好みなどの情報を利用して、電子メール通知、およびショッピングカートモデルを処理する際に行われ得る他の任意の可能な選択肢を受信することをクリックしないことができる。次いで、アプリケーション、ブラウザ、またはウェブサイトは、ＡＰＩを介して、バックグラウンドで通信することができ、そのような入力が、ユーザが、ユーザが「ワンクリック」し最終的な購入および配達を行う準備が整っている状態にある第２のウェブサイトが提示される程度まで自動的に取り扱われ得るように、それらのナビゲーションおよび必要な入力のすべてを実行することができる。ＡＰＩは、購入を最終決定するために必要なデータのすべてを埋め込み入力する必要である、第２のウェブサイトにとって必要な情報のすべてを含むことができる。たとえば、第１のサイトは支払いを処理することができ、第２のサイトは、注文を埋め、配達を取り扱うことによって、注文を最終決定することができる。第１のウェブサイトまたはブラウザまたはアプリケーションは、さまざまなショッピングカートモデルが要求することができ、購入を処理する際に要求するすべての可能な情報を保持することができる。特定の第２のウェブサイトは、それに対してまたはそれを通してユーザが購入を行う可能性が高いものとして選定されるので。第１のウェブサイトまたはブラウザは、入力を前処理するために必要なさまざまな情報をもつ第２のウェブサイトへのＡＰＩ接続を介して確立する。第１のサイトはまた、第１のサイトが支払いサービスである場合、支払いを処理するように販売業者サイトから命令を受信するためにブラウザＡＰＩを介して通信することもある。ユーザが買うことを望む製品を識別するユーザ入力などのデータ、およびワンクリック入力を介した購入のためにどの製品を提示するべきかを絞り込み一義化する助けとなる他の任意の生成されたデータ。たとえば、ユーザが、「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ」を入力するが、色は入力しないことがある。システムは、最も人気のある色を選定し、どのモデルを提示するべきかの絞り込みを可能にするために、そのデータを第２のウェブサイトに提供することができる。システムは、主な選択肢が間違った色であるまたは買うことが要望された製品でない場合、代替選択肢が、潜在的な選択のために第２のウェブサイトを介して容易にアクセス可能にされるように、二次オプションも提示することができる。
【０４６１】
[00531]さらなる強化も、次に説明される。以下は、あるサイト（ソーシャルメディアサイト、またはブラウザ検索フィールド、または検索エンジン、または任意のサイトもしくは状態）から別のサイトへの、またはサイト上での支払い処理のための、遷移の概念に関する。一態様では、システムは、ユーザが製品を検索、ログイン、および／または支払い情報を入力したかのように宛先サイトの状態に構成されたディープリンクを使用し、それによって、ユーザは、支払い情報を入力することなく、またはログインすることなく、購入プロセスを完了することができる。宛先サイトが、既にユーザのための支払いおよび住所データを記憶している場合、遷移は、ワンクリック購入状態に遷移するために利用するために、ワンクリック購入パラメータまたは他のデータなどの他のデータをブラウザから取り出すことを含むことができる。
【０４６２】
[00532]一態様は、Ｆａｃｅｂｏｏｋ上でのａｍａｚｏｎ．ｃｏｍ広告などの、宛先サイトからのステップも包含する。ａｍａｚｏｎ．ｃｏｍのようなサイトがソーシャルネットワーキングサイト上の受信者に投稿をサブミットするとき、このサイトは、受信者の識別についての情報を有する。その受信者がａｍａｚｏｎ．ｃｏｍに登録しており、ａｍａｚｏｎ．ｃｏｍに支払い情報を提供している場合、受信者が、広告として、またはニュースフィード内で、今すぐ買うオブジェクトまたはＦａｃｅｂｏｏｋ（任意のソーシャルネットワーキングサイト）上の投稿内で購入を行いたいという要望を示すオブジェクトをクリックするとき、受信者は、製品に関連づけられたソーシャルネットワーキングサイト投稿から、ユーザが、ユーザが製品を検索したかのような状態のサイトに遷移され、そのサイトは、ユーザが製品を「ワンクリック」購入することができる状態である「ディープリンク」をもつａｍａｚｏｎ．ｃｏｍなどの投稿サイトに遷移することができる。これが可能であるのは、ソーシャルネットワーキング投稿からサイトへの遷移が、ユーザがサイトにログインされることを可能にすることと、ユーザが最小のさらなるクリックで製品を購入することができるインターフェースをユーザに提示することとを含むからである。ブラウザに記憶された情報は、ディープリンク宛先到達を達成するために利用可能である。
【０４６３】
[00533]別の態様では、第１のサイトはソーシャルネットワーキングサイトであってよく、宛先サイトは販売業者サイトであってよい。購入を達成するためにユーザがワンクリック対話に関与することができる（またはおそらく、２回のクリックまたは他の小さい確認対話、しかし、支払い、住所などを手動で入力することはない）ようにディープリンク状態である宛先サイト上の到着へのワンクリック手法は、ユーザが宛先サイトに到着すると呼び出されるブラウザ支払い必要アプリケーションプログラミングインターフェースを通して行われ得る。この態様における方法は、ソーシャルネットワーキングサイトを通して品物の投稿を受信することであって、ソーシャルネットワーキングサイトは、投稿エンティティから受信エンティティに投稿された品物を受信および送信する、受信することを含むことができ、投稿が、製品データベース内の購入のための製品に関連づけられていないとき、方法は、買うオプションなしで、ソーシャルネットワーキングサイトを通して投稿を送信することを含むことができる。これは単に、たとえば、ニュースフィード上の通常の投稿である。投稿が、製品データベース内の製品を参照し、したがって、販売関係意図を示すとき、方法は、ソーシャルネットワーキングサイトによって、製品投稿をもたらすために支払いプロセス開始オブジェクトを投稿に挿入することであって、この支払いプロセス開始オブジェクトは、ユーザによって対話されるとき、製品投稿内の製品を購入するためにプロセスを開始する、ユーザによる意図を示す、挿入することと、製品に関連づけられた支払いプロセス開始オブジェクトをもつソーシャルネットワーキングサイトを通して製品投稿を送信することであって、支払いプロセス開始オブジェクトは、ボタン、ドロップダウンメニュー、またはハイパーリンクのうちの１つを含むことができる、送信することと、支払いプロセス開始オブジェクトに関連づけられた対話を受信することとを含むことができる。一態様では、投稿エンティティは、投稿が発生したとき、買うオプションオブジェクトを含むことができる。買うオプションオブジェクトは、ソーシャルネットワーキングサイトから投稿エンティティサイトに戻るようにディープリンク遷移を引き起こすように構成可能である。
【０４６４】
[00534]対話に基づいて、方法は、ソーシャルネットワーキングサイトから製品投稿に関連づけられた販売業者サイトにユーザを遷移させることを含むことができる。販売業者サイト上での支払うオブジェクトとのユーザによる買う対話に基づいて、方法は、販売業者サイトから、ユーザに販売業者サイトを提示するブラウザと販売業者サイトとの間のブラウザアプリケーションプログラミングインターフェースを介して、支払い要求を受信することを含むことができる。支払い要求に応答して、方法は、販売業者サイトが支払いデータを使用して製品の購入を完了することを可能にするために販売業者サイトにブラウザアプリケーションプログラミングインターフェースを通してユーザのための支払いデータを通信することを含むことができる。諒解され得るように、一態様では、買うオプションまたは店舗ボタンを提示することに関するソーシャルネットワーキングサイトにおける機能は、宛先サイトが支払いプロセスを達成するためにブラウザＡＰＩを呼び出すことができるように一般に宛先サイトに遷移する限り、変化することができる。
【０４６５】
[00535]ユーザが、購入を行うために宛先サイトに到着するまたは宛先サイトにナビゲートすると、システムは、販売業者サイトとブラウザとの間の第１のブラウザＡＰＩおよびブラウザと支払いサービスとの間の第２のＡＰＩを使用して支払いを処理するために支払いサービスを提供することができる。さまざまな通信が、支払いサービスによる支払いを完了するためにそれぞれのＡＰＩのプロトコルに従って発生し、販売業者サイトが支払いを受信してユーザに製品を配達することができるように、販売業者サイトに通知することがある。
【０４６６】
[00536]図２０Ｂは、遷移の別の態様、あるサイトから別のサイトへの遷移の別の態様を示す。図１８Ａの特徴１８１０として表されるサーバは、そのサイトのそれぞれの機能が本開示に適用可能であるとすることができるにおいて、任意のサイトを表すことができる。ソーシャルメディアサイトは例として検討されるが、任意のサイトの任意の機能が本開示内に含まれる。
【０４６７】
[00537]サーバ１８１０が、Ｆａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍ、Ｐｉｎｔｅｒｅｓｔなどのソーシャルメディアサイトを表すと仮定する。サイトは、もちろん、任意のサイトとすることができ、サイト上のオブジェクトとの対話は、サイトの機能に依存することができる。各サイトのそれぞれの機能が本開示内に含まれ、サイトとの任意の対話は、本開示による二次サイトへの遷移をトリガすることができる。例として、サイトはソーシャルメディアサイトであり、このソーシャルメディアサイトは、投稿、または購入のための品物に関連づけられた広告を受信すると仮定する。他のサイトでは、データは、ゲーム対話もしくはテレビ会議呼び出しインターフェース、または他の任意のサイト機能であることがある。広告は、一般に、ニュースフィード内またはサイト上にあることができる。問題は、ユーザが支払い情報、ログイン情報、住所情報、および／またはパスワードなどを入力する必要なしにオブジェクトに対するワンクリック購入状態で到着するように第１のサイト１８１０から販売業者サイト１８１６にどのようにして遷移するかということである。方法は、ユーザから、ソーシャルネットワーキングサイトを介して製品に対する、ブラウザ１８０６内で提示されるオブジェクトとの対話（この例では広告、または他のサイト機能に対する他の任意のコンテキストでは他の任意のオブジェクトに関連づけ可能である）を受信する（２０２０）ことを伴う。たとえば、トースターに関するソーシャルメディアサイト上の広告は、「今すぐ買う」ボタンを有することができる。ユーザが「今すぐ買う」ボタンをクリックするまたはエンティティ販売業者からの広告と対話するとき、イベントのシリーズが、特定の状態の販売業者エンティティに関連づけられたサイトにユーザを遷移させるために開始される。イベントのシリーズは、ソーシャルネットワーキングサイト（または任意の第１のサイト）からの遷移の一部として、ブラウザ１８０６からワンクリック購入データを取り出す（２０２２）ことを含む。方法は、ブラウザからのデータを使用して、ユーザが第１のサイトからディープリンク状態の宛先販売業者サイトに遷移することを可能にする。ブラウザからのデータは、たとえばハイパーリンクをもつウェブサイト上で見つけられる単なるハイパーリンクデータでない。データは、好ましくは、一態様では、ユーザプロファイルまたは記憶されたユーザパラメータ、ワンクリック購入パラメータ、支払いデータ内など、ブラウザ内に記憶されるデータである。ディープリンク状態は、支払いアカウントデータまたはユーザ住所データを手動で入力することなくユーザが購入オブジェクトとの単一の対話を介して製品を購入する（遷移直後に、他の任意の対話なしで、または異なる製品を選定する継続されたショッピング後に、のどちらか）ことを可能にする。ワンクリック購入データは、ユーザがワンクリック購入状態の宛先販売業者エンティティサイトに到着することを可能にする任意のデータを表す。ワンクリック購入データは、支払いデータ、配達データ、名前、住所、ブラウザ設定、ワンクリック購入設定、ユーザプロファイルオプション、好み、ワンクリック購入パラメータ、登録情報、電子メー��アドレスなどを含むことができる。遷移プロセスは、ブラウザ１８０６からワンクリック購入データを取り出すことを含む。これは、ＡＰＩ１８１８を通して、またはデータを取り出す何らかの他の機構を通して、なされ得る。データは、他のユーザ対話が、日付を取り出すためまたは「今すぐ買う」オブジェクトもしくは購入する意図を示す他のオブジェクトと対話すること以外に必要とされないように、バックグラウンドで取り出される。
【０４６８】
[00538]次に、システムは、ワンクリック購入データを利用し、ワンクリック購入データに基づいて、ソーシャルメディアサイトからディープリンク状態の販売業者エンティティサイトにユーザを遷移させ、ユーザは、販売業者エンティティサイト上に提示されるワンクリック購入オブジェクトとの単一の対話を介して製品を購入することができる（２０２４）。ディープリンク状態は、何らかのある特性を有する。そのうちの１つまたは複数が適用可能である、例示的な特性は、ソーシャルメディアサイト上の通知または広告に関連づけられた製品または品物が販売業者エンティティインターフェースに示される状態を含む。販売業者エンティティインターフェースは、販売業者サイト上にあり、ワンクリック購入オブジェクトを含む。支払い情報、住所配達情報、発送方法などは、販売業者エンティティサイトに既に利用可能である。ブラウザから取り出され、販売業者エンティティサイトに提供されるワンクリック購入データは、ユーザが宛先販売業者サイトに到着することを可能にする。ソーシャルメディアサイトにおける買うボタン上の第１のクリックの後の次の対話が、販売業者サイト上のワンクリック購入対話とすることができる、そのような状態において。販売業者サイトは、ブラウザからのワンクリック購入データを利用して、このディープリンク状態を可能にする。別の態様では、ユーザは、宛先販売業者エンティティサイトに到着し、ショッピングを続けるまたは製品のパラメータを変更することが可能であり、したがって、販売業者エンティティサイトにおける他の対話を有することがあり、ユーザが、購入することを要望する製品に到着したとき、ユーザは、購入者がＡｍａｚｏｎ．ｃｏｍであるようにワンクリックを介して購入を行うことができる。このようにして、第１のサイトから販売業者サイトへの遷移は、購入に到着するために、必要なクリックまたは対話の数を減少させる。
【０４６９】
[00539]販売業者エンティティサイトの観点からのプロセスが、図２０Ｃに提示されている。販売業者エンティティサイトの観点から、販売業者エンティティは、プレゼンテーションのために第１のサイトに通知または広告を送信する（２０３０）。これは、一般にサイト上の広告、または提示するための、ニュースフィードまたは他のソーシャルネットワーク投稿上の、在庫にリンクされた広告とすることができる。第１のサイト上の広告に関連づけられたオブジェクトとのユーザからの対話に基づいて、方法は、ブラウザからワンクリック購入データを取り出す（２０３２）ことと、ワンクリック購入データに基づいて、第１のサイトからディープリンク状態の販売業者エンティティサイトへの遷移を受信することであって、ユーザは、販売業者およびサイト上のワンクリック購入オブジェクトとの単一の対話を介して製品を購入することができる、受信する（２０３４）こととを含む。この段階において、ユーザは、販売業者サイトに位置決めされ、他の製品を引き続きショッピングするなど、販売業者エンティティサイトとの通常の対話を継続する。
【０４７０】
[00540]図２０Ｄは、販売業者サイトの観点からの別の態様を示す。方法は、販売業者から、ブラウザ内での第１のサイト上でのプレゼンテーションのために第１のサイトに広告を送信する（２０４０）ことと、販売業者に関連づけられた宛先販売業者サイトにおいて、広告内のオブジェクトとのユーザの対話に基づいて、第１のサイトからディープリンク状態の宛先販売業者サイトへのユーザの遷移を受信する（２０４２）こととを含む。この遷移は、ブラウザからデータを取り出す（２０４４）ことと、ブラウザからのデータを使用して、ユーザが第１のサイトからディープリンク状態の宛先販売業者サイトに遷移することを可能にすることであって、宛先販売業者サイトのディープリンク状態は、販売業者サイトオブジェクトを含むことができる、可能にする（２０４６）こととを含む、いくつかのステップを利用することができる。販売業者サイトオブジェクトは、製品のためのさらなるナビゲーションおよびブラウジングを可能にすることができる、または広告内で識別される製品を購入するための単一のクリックオブジェクトとすることができる。方法は、宛先販売業者サイトにおいて販売業者サイトオブジェクトとの対話を受信する（２０４８）ことと、支払いアカウントデータまたはユーザ住所データを手動で入力することをユーザに要求することなく、販売業者サイトオブジェクトとの対話に基づいて製品の購入を処理する（２０５０）こととをさらに含む。
【０４７１】
ユーザ入力が、一般化された非購入問い合わせであるか、購入する意図をもつ問い合わせであるかの決定
[00541]ウェブサイト内または何らかの他のコンピュータベースのユーザインターフェース内の任意の入力フィールドが統一された入力フィールドとして機能することを可能にする、システム、方法、およびコンピュータ可読記憶デバイスが開示される。統一された入力フィールドは、ユーザが、検索結果のリストに至ることができるだけでなく、所望の品物が事前にポピュレートされた販売業者ショッピングカートに直接的にナビゲートすること、または購入を自動的に実行して所望の品物を発注しさえすることなど、いくつかの他のアクションのいずれかをユーザに代わって実行させることもできる入力を提供することを可能にする。そのような統一された入力フィールドを使用すると、著しい時間、労力、およびクリックをユーザのために節約することができる。しかしながら、そのような統一された入力フィールドは、あらゆるウェブサイトまたはユーザが要望する他のユーザインターフェース内に実装されるとは限らない。ユーザは、統一された入力フィールドを扱うとき特定のワークフローまたは能力のセットに習慣づけられることがあり、従来の限られた入力フィールドを使用するとき制限または限定されたように感じることがある。
【０４７２】
[00542]一例では、ユーザが、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍなどの統一された入力フィールド対応サイトからＡｐｐｌｅ．ｃｏｍに向けられる場合、Ａｐｐｌｅ．ｃｏｍとのそのユーザの対話は、Ａｐｐｌｅ．ｃｏｍ（またはＧｏｏｇｌｅ．ｃｏｍもしくはＡｍａｚｏｎ．ｃｏｍなどの任意のウェブサイト）の検索フィールドが、ｏｎｅ−ｓｅａｒｃｈ．ｃｏｍの統一された入力フィールドに似たものになるように修正可能である。たとえば、ＪａｖａＳｃｒｉｐｔスクリプトまたはブラウザプラグインは、非統一入力フィールド対応サイト上のテキストフィールドまたは非統一入力フィールドへと入力されるテキストを妨害し、これらの特徴を実施してオートコンプリートオプションおよびワンクリック購入オプションを提示するために、その入力をｏｎｅ−ｓｅａｒｃｈ．ｃｏｍにリダイレクトすることができる。言い換えれば、特定のウェブサイトの外部で任意の数の異なる処理オプションをするオプションは、ユーザに利用可能にされ得る。このようにして、任意の検索フィールド、テキストフィールド、または入力フィールドは、本明細書において開示される統一された入力フィールドであるように適合可能である。もちろん、本明細書において開示される機能のすべては、任意のウェブサイト、アプリケーション、またはユーザインターフェース上の任意の検索フィールドまたは入力フィールドに組み込まれてよい。
【０４７３】
[00543]ブラウザの機能は、既存の入力フィールドの代わりに統一された入力フィールドを実装するために、直接的に、またはプラグイン、スクリプト、もしくは拡張機能を介して、修正可能である。ユーザは、メニュー内のチェックボックスをチェックすること、ボタンをクリックすること、ユーザ名およびパスワードでログインすること、または何らかの他のユーザ識別証明書を提供することなどによって、入力フィールドエンハンサー（enhancer）をアクティブ化することができる。次いで、入力フィールドエンハンサーは、ユーザを識別し、ブラウザキャッシュ内に記憶されたプロファイルまたはサーバ上に記憶されたプロファイルなどの、ユーザについての個人データを取り出すことができる。システムは、プロファイルデータからユーザの好みを識別することができ、プロファイルデータは、統一された入力フィールドになるようにある入力フィールドをいつどのようにして修正するかに関するルールまたは好みを提供することがある。たとえば、ユーザプロファイルは、ｃｒａｉｇｓｌｉｓｔ．ｏｒｇ上の入力フィールドを修正することではなく、他のあらゆる場所における入力フィールドを修正することを示すことがある。別のユーザプロファイルは、ウェブサイトの上部１０％内に配置されるすべてのテキスト入力フィールドを修正することを示すことがある。別のユーザプロファイルは、スマートフォンおよびタブレットなどのモバイルデバイス上のテキスト入力フィールドを修正することではなく、デスクトップコンピュータまたはラップトップコンピュータ上のテキスト入力フィールドを修正することを示すことがある。ユーザは、ユーザの好みおよび他の個人データが、１つのローカルマシンに限定されず、代わりに、任意のそのような対応マシンからアクセス可能であるように、サーバ上で記憶されるユーザプロファイルにログインすることができる。したがって、ユーザは、統一された入力フィールドを可能にするために作業コンピュータ上のブラウザにログインすることができ、同じ個人プロファイル、好み、および履歴を使用しながら、ホームコンピュータ上で同じことをすることができる。この個人情報は、比較的短い入力文字列に基づいて意図を決定するとき、分類器にとって重要とすることができ、統一された入力フィールドが複数のデバイスにわたって同様に振る舞うとき、一貫性の意味をユーザに提供することができる。
【０４７４】
[00544]エンハンサーは、新しいページがブラウザ内にロードされるとき、またはページ要素を動的にロードもしくは修正するＡｊａｘ呼び出しなどによってページがリフレッシュまたは更新されるとき、トリガ可能である。エンハンサーは、ページをレンダリングしながら入力フィールドを識別するために、レンダリングエンジンまたはウェブブラウザエンジンに関連して動作することができる。この変形形態では、エンハンサーは、ページが解析および／またはレンダリングされているとき、ページのためのコードを修正することができる。エンハンサーは、戻って既にロードおよびレンダリングされたページを改訂する投稿ロード動作として動作することができる。いずれの手段においても、エンハンサーは、統一された入力フィールドと類似したまたは同じ機能を提供するために入力をキャプチャしてローカルサーバまたはリモートサーバにリダイレクトするように、識別された入力フィールドの機能を修正する。次いで、サーバは、ウェブページ上の裂け目として、新しいタブまたはウィンドウとしてワンクリック購入アクションのプレビューを提示すること、そのようなワンクリック購入アクションを「検索」ボタンまたは何らかの他のボタンを介して公開することなどの、統一された入力フィールドのさまざまな利益および機能を実装するためにブラウザと通信することができる。
【０４７５】
[00545]システムは、入力フィールドをマークする、または入力フィールドが統一された入力フィールドとして修正されているもしくは可能にされているという何らかの種類の視覚的標識もしくは可聴標識を提示することができる。たとえば、システムが、ｅｂａｙ．ｃｏｍの上部にある検索フィールドなどの標準的なテキスト入力フィールドを検出したとき、システムは、その標準的なテキスト入力フィールドが、統一された入力フィールドとして転用するのに適しているかどうかを決定することができる。システムが肯定的な決定を行った場合、システムは、標準的なテキスト入力フィールドの機能ならびにその外観を修正することができる。たとえば、システムは、テキストフィールドのまわりに異なる色の境界をレンダリングすることができる、またはフォーカスがテキスト入力フィールド上もしくはその中に移動したとき、もしくはマウスもしくはテキストカーソルがテキストフィールドに入ったとき、音を立てることができる。システムは、サイズ、フォント、外観の変更を適用する、または修正されたテキストフィールドを強調表示するアニメーションすら導入することができる。ユーザの好みは、システムが修正されたテキストフィールドをどのように強調表示するかを命令することもできる。
【０４７６】
[00546]次いで、ユーザが、修正されたテキストフィールドへとテキストを入力したとき、システムは、分類器を介して入力を処理して意図を決定し、その意図に基づいて行われ得る１つまたは複数のアクションを生成することができる。いくつかのケースでは、分類器が、確実性閾値を上回る意図を決定することができないとき、システムは、入力に基づいたアクションを提示しないことがあり、意図および／または確実性閾値を変更することがある追加の入力を待機することを選定することがある。どのようにしてシステムが、決定された意図に基づいてワンクリックアクションを提示することを決定するかは、ページを表示するブラウザ、または修正されたテキストフィールドをホストするページのレイアウトに基づいて、変化することがある。たとえば、テキストフィールドが、十分な隣接するホワイトスペースを有する場合、システムは、さまざまなアクションを実行するための、テキストフィールドに近接したワンクリックボタンをレンダリングすることができる。システムは、修正されたテキストフィールドを含むレンダリングされたウェブページの外部に、ブラウザの一部としてワンクリックアクションをもつドロップダウンメニューを提示することができる。システムは、ＪａｖａＳｃｒｉｐｔを使用して、ワンクリックアクションのためのユーザインターフェース要素を一時的または永続的に（レンダリングされるページ寿命の間）収容するように、あるページ要素を修正または再配置することができる。システムは、ＪａｖａＳｃｒｉｐｔを使用して、ワンクリックアクションへのアクセスを提供するためにレンダリングされたページの上に新しいユーザインターフェース要素を重ねることができる。一例では、システムは、レンダリングされたページの下にあるように見えるページの一部分を示すためにレンダリングされたページを通して覗く「裂け目」のように見えるユーザインターフェース要素を提示する。
【０４７７】
[00547]しかしながら、テキストフィールドが修正されたときですら、システムは、統一された入力フィールドとしても機能するように入力フィールドを拡張しながら、入力フィールドの元の機能を依然として保存することができる。たとえば、ユーザは、入力フィールドの始まりでｓｈｉｆｔを押すことによって、修正された機能と元の機能の間でトグルすることができる。システムはまた、修正された入力フィールドのどの機能に対してユーザが入力を命令しているかを示すために、修正された入力フィールドの外観をトグルすることができる。
【０４７８】
[00548]システムは、修正されることになる候補であるテキストフィールドを識別することができるが、統一された入力フィールド機能を要求する何らかのユーザコマンドまたは入力を受信するまで、それらのテキストフィールドを触れないままにしておくことができる。たとえば、システムは、ユーザが、キーもしくはキー組み合わせを押すこと、または入力フィールド内でダブルクリックすることによって、機能をアクティブ化または要求すると、統一された入力フィールド機能へのアクセスを提供することができる。ユーザは、このようにして、入力フィールドのための異なる機能の間でトグルすることができる。これは、入力フィールドの特定の機能に依拠するいくつかのウェブサイトを壊すことを回避するために有益とすることができる。しかしながら、システムは、その動作を妨げることなく、入力フィールドの既存の元の機能の上に統一された入力機能を重ねることができる。たとえば、システムは、元の機能が変化せずに進むことを可能にしながら、ユーザインターフェースの異なる領域内で統一された入力フィールドワンクリックアクションを実施することができる。または、システムは、統一された入力機能を介して提示されるワンクリックアクションのうちの１つとして、元の機能を組み込むことができる。たとえば、ユーザが、ｅＢａｙ．ｃｏｍ上の修正された入力フィールド内で「ｉＰｈｏｎｅ  ５Ｃ  ３２ＧＢイエロー」というテキストを入力した場合、システムは、ＪａｖａＳｃｒｉｐｔを介してページの上に重ねられたボタンのセット、すなわち、示されたｉＰｈｏｎｅ  ５ＣをＡｍａｚｏｎ．ｃｏｍを介して購入するための第１のワンクリックアクションボタン、示されたｉＰｈｏｎｅ  ５ＣをＡｐｐｌｅ．ｃｏｍを介して購入するための第２のワンクリックアクションボタン、示されたｉＰｈｏｎｅ  ５Ｃをａｔｔｗｉｒｅｌｅｓｓ．ｃｏｍを介して購入するための第３のワンクリックアクションボタン、およびｅＢａｙ．ｃｏｍ上でオークションの検索を実行する元の入力フィールド機能を実施するための第４のワンクリックアクションボタンを生成することができる。
【０４７９】
[00549]システムは、ブラウザの検出されたタイプまたはインターフェース上で利用可能なスペースに基づいて、統一された入力フィールドの機能をさらに適合させることができる。たとえば、システムは、修正された入力フィールドをホストするページのルックアンドフィールに一致するユーザインターフェースを提示することができる。修正された入力フィールドをホストするページが広告を有する場合、システムは、それらの広告を曖昧にすることを回避するために、そのような手段でワンクリックアクションボタンまたは他のユーザインターフェース要素を位置決めすることができる。この設定は、修正された入力フィールドの行動をガイドすることを意図されたトークンまたは命令など、修正された入力フィールドをホストするページにおいてコードまたは設定によって命令可能である。
【０４８０】
[00550]一例では、ウェブサイトは、入力フィールドを統一された入力フィールドを意識したものにすることによって、入力フィールドを事前に修正することができる。ウェブサイトが、ユーザが統一された入力フィールドと関係しないするまたはこれを使用しないことを検出した場合、入力フィールドは、その元の機能を保持することができる。しかしながら、ウェブサイトが、ユーザが、ユーザのブラウザ内でクッキーを検出することなどによって、統一された入力フィールドと関係するまたはこれを使用することを検出したとき、ウェブサイトは、そのユーザにとってよりなじみの深いインターフェースを提供するために、統一された入力フィールドを先だって修正またはアクティブ化することができる。ウェブサイトは、確立されたアプリケーションプログラミングインターフェース（ＡＰＩ）を介してそのような統一された入力フィールド要求を管理するために、サーバと対話することができる。
【０４８１】
[00551]図２１は、方法例を示す。方法例におけるステップは、任意の順序で実行可能であり、追加のステップを含むまたは説明されるステップのうちのいくつかのすべてもしくは一部を除外する他の組み合わせまたは順列で実行可能である。システムは、第１のユーザインターフェース内で、ブラウザを介して処理された第１のウェブサイトに関連づけられた第１の入力フィールドを提示することができ、この第１のウェブサイトは、ユーザが製品を検索して購入する購入ウェブサイトである（２１０２）。システムは、ユーザから第１の入力フィールドへの入力を分析して、ユーザが一般化された検索を実行することを要望するか購入を行うことを要望するかを決定し、決定をもたらすことができる（２１０４）。一般化された検索の一例は、Ｇｏｏｇｌｅ．ｃｏｍ上ですることがある検索である。たとえば、ユーザは、「Ｎｏｒｔｈ  Ｄａｋｏｔａ」という語句を使用して検索することがある。そのケースでは、ユーザは、その州に関する情報を探している。しかしながら、ユーザがＡｍａｚｏｎ．ｃｏｍのＵＲＬにいる場合、「Ｎｏｒｔｈ  Ｄａｋｏｔａ」と入力することは、ユーザが州全体の不動産購入を行うことを要望することを必ずしも意味しない。そのユーザ入力は、ユーザが購入を行うことを望まず、むしろＡｍａｚｏｎ．ｃｏｍ上で購入するために製品を検索することとは対照的に、一般化された検索を実行することを望むという強力な標識を有する。決定が、入力以外のユーザからの他の任意の入力なしで、ユーザが検索を実行することを要望することを示す場合、システムは、少なくとも一部は、第１のウェブサイトから、検索を処理することができる第２のウェブサイトにユーザを遷移させることができる（２１０６）。第１のウェブサイトから第２のウェブサイトにユーザを遷移させることは、第２のウェブサイトの少なくとも一部分を明らかにする、第１のユーザインターフェース内の裂け目を介して、第２のウェブサイトを提示することを含むことができる。次いで、ユーザは、ユーザが第２のウェブサイトにナビゲートすることを要望するという標識を、裂け目を通して提供することができ、この標識に基づいて、システムは、第２のウェブサイトにユーザをナビゲートすることができる。システムは、第１のウェブサイトの構造の分析に基づいて、第１のウェブサイト内の裂け目の位置を選択することができる。システムは、第２のウェブサイトに関連づけられた第２の入力フィールドに入力を事前にポピュレートすることができ（２１０８）、ユーザが、遷移した後で選択可能な検索結果を閲覧する状態であるように、第２の入力フィールド内の入力を使用して第２のウェブサイトを前処理することができる（２１１０）。
【０４８２】
[00552]図２２は、この例の基本的構成要素２２００のうちのいくつかを示す。ブラウザ２２０２またはスマートフォンアプリのようなアプリケーションは、任意の入力フィールドを介して入力の処理を改善する助けとなるためにユーザの好み２２１２のデータベースと通信することができるモジュールまたは構成要素であるエンハンサー２２０４を有することができる。ブラウザ２２０２は、ａｍａｚｏｎ．ｃｏｍなどのウェブサイトまたはアプリケーションを出す（serve up）ウェブサーバ２２０８と、ネットワーク２２０６を介して通信することができる。ブラウザおよび／またはエンハンサー２２０４は、ネットワーク２２０６を介して、統一された入力フィールドサーバ２２１０とも通信することができる。この統一された入力フィールドサーバ２２１０は、それに応じてユーザ入力の処理を調節するようにブラウザ２２０２によって指示されるように、ユーザの好み２２１２のデータベースとも通信することができる。この手法を使用すると、システムは、任意のウェブサーバ２２０８から出される任意の入力フィールドを処理し、統一された入力フィールドサーバ２２１０に処理を接続することによって統一された入力フィールドにすることができる。このようにして、ユーザが、一般的には購入の品物を予想する入力フィールドを有するＡｍａｚｏｎ．ｃｏｍなどのウェブサイト上にいる間、その入力フィールドは、他の場所にジャンプし、他の機能も実行するための、より統一された入力フィールドにされ得る。したがって、統一された入力フィールドサーバ２２１０への接続を利用して、そのａｍａｚｏｎ．ｃｏｍの入力フィールドは、一般化された検索、通話、Ｓｋｙｐｅタイプの呼び出し、テレビ会議、または本明細書において開示されるより柔軟でオープンな入力フィールド処理手法を通して達成可能である他の任意の目的の出発点になることができる。
【０４８３】
ウェブサイトではなくアプリケーションベースのポータルを介した検索
[00553]図２３は、方法例を示す。この例は、ウェブサイトではなく別のものとのアプリケーション通信に、より焦点を当てる。しかしながら、基本的な概念は類似している。たとえば、タブレットまたはスマートフォンを有するユーザが、検索を実行するためのアプリケーションを有することがある。これは、ユーザが単に検索エンジンＵＲＬにナビゲートすることを可能にするデバイス上のブラウザとは異なる。アプリケーション、同じく検索アプリ、またはＳｋｙｐｅもしくはＦａｃｅＴｉｍｅアプリ、銀行アプリケーションなどの何かとすることができる。第１のタイプのいかなるアプリケーションも、入力フィールドを有することができる。ここでのポイントは、アプリケーションの特定の目的に従来関連づけられているその入力フィールドを、入力を処理し、をユーザが別のアプリに自動的に遷移されるべきか決定することができる、より一般化された入力フィールドにすることである。ブラウザとアプリケーションとの間の切り換えも可能である。たとえば、ユーザは、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍ上に位置決めされたＵＲＬをもつブラウザアプリケーションを使用するスマートフォン上にあることがある。しかしながら、ユーザは、製品を検索フィールドへと入力することがある。システムは、（ローカルに、サーバ上で、または両方の組み合わせを使用する処理を介して）ユーザが、入力に基づいて購入を行うことを要望すると決定する。システムは、Ａｍａｚｏｎ．ｃｏｍアプリケーション（ブラウザを介してａｍａｚｏｎ．ｃｏｍに遷移することではなく）を自動的に起動し、ユーザがアプリケーションおよび検索を既に起動した、またはユーザが単に購入を行う「ワンクリック」状態のアプリケーションを位置決めすることがある、のどちらかであるように、検索結果を提示するために、入力を使用してａｍａｚｏｎ．ｃｏｍアプリケーションの入力および「状態」が位置決めされるように事前に交渉することができる。
【０４８４】
[00554]方法は、第１のタイプの第１のアプリケーションに関連づけられた統一された入力フィールドを介してユーザから入力を受信する（２３０２）ことと、入力を分析して、入力に対して実行されることになるプロセスが、決定をもたらすために第２のタイプの第２のアプリケーションによって処理されるべきであるかどうかを決定することであって、第１のタイプと第２のタイプは異なるタイプである、決定する（２３０４）こととを含む。決定が、入力に従ってユーザの意図を実行するために、第２のアプリケーションが入力を処理するべきであることを示す場合、システムは、入力を含む第２のアプリケーション情報と通信し、ここにおいて、第２のアプリケーションが開始され、処理された状態の第２のアプリケーションをもたらすために入力を使用して前処理される（２３０６）。最後に、システムは、処理された状態でユーザに第２のアプリケーションを提示する（２３０８）。
【０４８５】
[00555]提示は、第２のアプリケーションにナビゲートするためのユーザからの追加の入力なしで発生する。第２のアプリケーションと通信することは、ユーザ識別情報、支払いアカウント情報、配達住所情報、およびユーザの好みのうちの少なくとも１つを第２のアプリケーションに通信することをさらに含むことができる。上記で述べられたように、プロセスは、スマートフォンまたはタブレットまたは他のデバイス上のアプリに特定のウェブサイトにおいてブラウザ間で切り換えることを伴うことができる。このケースにおけるアプリケーションは、一般に知られている。そのアプリケーションは、Ａｍａｚｏｎを通して購入を可能にすることまたはＳｋｙｐｅのようなビデオおよびオーディオ呼び出しを取り扱うことのような単一の汎用タスクを一般的に実行する、無料で購入またはダウンロードされるソフトウェア製品である。そのようなアプリケーションは、もちろん、同じ会社に関連づけられるが、その会社のサービスにアクセスする異なる機構を提供することができるＵＲＬとは異なる。
【０４８６】
[00556]第１のアプリケーションおよび第２のアプリケーションは、スマートフォンアプリケーションおよびタブレットアプリケーションのうちの１つである。同じく、別の態様では、本開示は、ＵＲＬ（ウェブサイト）とアプリケーションを切り換えることの説明を提供する。システムは、第１のアプリケーションを自動的に閉じ、処理された状態の第２のアプリケーションをユーザインターフェース上で開始および提示することができる。これは、ユーザが１つのアプリを閉じて所望のアプリケーションを手動で起動するプロセスを回避することを可能にする。一例では、第１のタイプは検索タイプであり、第２のタイプは製品購入タイプである。第１のタイプは、たとえば、製品を購入することに関連づけられていないタイプとすることができ、第２のタイプは、製品を購入することに関連づけ可能である。これは、コンテキスト、タイプ、アプリケーション目的などを切り換えるが、単一の入力フィールドを使用している間の一例を提供する。この手法は、所望の機能を実行する別個のＵＲＬまたは別個のアプリケーションにナビゲートする必要性をなくすので、ユーザが機能を実行させる（検索、購入、配達、呼び出しなど）ために必要な対話を減少させる。一例では、第１のアプリケーションは、品物のための支払いを処理し、買い手への品物の配達のために第２のアプリケーションと協調することができる。
【０４８７】
検索インターフェース間での遷移タイプの選択
[00557]図２４は、方法例を示す。この例は、あるインターフェースから別のインターフェースに遷移するモードを選定することに焦点を当てる。方法は、複数の異なる処理タイプを可能にする第１のアプリケーション上の統一された入力フィールドを介してユーザから入力を受信する（２４０２）ことと、入力を分析してユーザの意図を決定する（２４０４）こととを含む。ユーザプロファイルに基づいて、方法は、選定されたモードをもたらすために第１のアプリケーションから第２のアプリケーションにユーザを遷移させるモードを決定する（２４０６）ことであって、このモードはモードのグループから選定される、決定する（２４０６）ことと、選定されたモードに基づいて、第１のアプリケーションから第２のアプリケーションにユーザを遷移させる（２４０８）こととを含む。
【０４８８】
[00558]第１のアプリケーションは、第１のウェブサイトおよび第１のスマートフォン／タブレットアプリケーションのうちの１つとすることができ、第２のアプリケーションは、第２のウェブサイトおよび第２のスマートフォン／タブレットアプリケーションのうちの１つとすることができる。モードのグループは、裂け目、自動変更、検索ボタンモーフィング、ドロップアップメニュー、ドロップダウンメニュー、処理インジケータモーフィング、および複数の減少されたサイズのワンクリック対応ウィンドウを含むことができる。「裂け目」は、第１のインターフェースがその下に別のインターフェースを明らかにするために避けて開いていることを見えるようにする、第１のインターフェース内の開口を表す。そのため、第１のアプリケーションがｇｏｏｇｌｅ．ｃｏｍであり、ユーザが、ユーザが購入を行うことを要望することを示すことが決定された検索語句を入力した場合、ｇｏｏｇｌｅ．ｃｏｍページのホワイトスペース内の開口または裂け目が見えることがあり、その開口を通して、ユーザが、開口スペースをクリックし、ｇｏｏｇｌｅ．ｃｏｍからａｍａｚｏｎ．ｃｏｍに容易に遷移することができ、入力フィールドデータも遷移するように、検索語句で前処理されたａｍａｚｏｎ．ｃｏｍウェブページの一部分が見える。この手法は、必要なクリックの数を減少させる。自動変更特徴は、システムが、切り換えが必要とされることを決定するとき、システムがそれを自動的に行い、おそらくユーザ入力に基づいて宛先ウェブサイトをワンクリック購入状態にするようにさらに処理するように、ユーザ入力なしでｇｏｏｇｌｅ．ｃｏｍからａｍａｚｏｎ．ｃｏｍに（または、たとえどのような２つの異なるウェブサイトであろうとも）ＵＲＬを自動的に置き換える。検索ボタン（ユーザが「ｅｎｔｅｒ」をクリックした場合にどのプロセスが実行されるかを示すボタン）は、ユーザ入力に基づいて、その機能がモーフィングすることができる。処理されることになる機能の通知もモーフィングすることができる。オートコンプリートを行うだけでなく、ワンクリック購入オプション、呼び出しオプション、ビデオ会議オプションなども提示する、ドロップアップメニュー、ドロップダウンメニュー、拡張メニューも提供可能である。これらのさまざまなモードは、新しいウェブページ、アプリケーション、または機能に自動的に遷移する代替機構を提示する。しかしながら、そのような遷移を行うさまざまな手段があることを考えると、ユーザは、その遷移をどのようにして行うべきかの好みを提示および記憶することができる。あるいは、さまざまなオプションが提示されることがあり、ユーザ履歴、以前の検索およびインターネットもしくはアプリケーションの使用状況、またはユーザプロファイルの外部にある他の要因もしくはこれに関連したが、選定されたモードの決定を行うために使用可能である。
【０４８９】
[00559]別のページに開いた「裂け目」は、ユーザがワンクリック購入を行うためにクリックすることができるワンクリックオプションを含むことができる。システムは、追加の検索を実行しながら、他の検索結果を調べながら、または他のウェブサイトにブラウジングしながら、検索インターフェース上の他のページの裂け目ビューを維持することができる。たとえば、ユーザは、裂け目を所定の位置に「ピンで留める」ことができ、そのため、ユーザが追加のブラウジングアクティビティを行っている間、裂け目は利用可能であるままである。したがって、ユーザは、レビューし、調べ、ウェブを検索する間、ワンクリック購入裂け目を保持することができ、ユーザは、依然として、裂け目を使用して、後で購入を行うことができる。
【０４９０】
[00560]ユーザを遷移させることは、ユーザが手動で第２のアプリケーションにナビゲートすることなくユーザを遷移させることを含むことができる。ユーザを遷移させることは、ユーザが遷移を開始および完了するために単一のクリックアクションを実行することを通して達成可能である。第１のアプリケーションから第２のアプリケーションにユーザを遷移させることは、ワンクリック購入状態の第２のアプリケーションをもたらすために、入力、ユーザ識別、ユーザアカウント情報、ユーザ配達情報、およびユーザの好みのうちの少なくとも１つを使用して第２のアプリケーションを前処理することをさらに含むことができる。たとえば、第１のアプリケーションは、支払いを処理し、配達のために第２のアプリケーションに必要なデータを協調させることができる。モードを決定することは、第１のアプリケーションを実行するデバイスの画面構成にさらに基づくことができる。モードは、あるタイプのアプリケーション（ブラウザを介してアクセスされるウェブサイトのような）からスマートフォン／タブレットアプリケーションのような別のタイプのアプリケーションに変化していることもある。前処理などのすべては、ユーザが、ユーザが検索結果をブラウジングする（たとえば、ｇｏｏｇｌｅ．ｃｏｍ上で提供される入力が検索結果を提示するために使用されるＡｍａｚｏｎ上で）ことまたはユーザが品物を購入するために単にクリックすることができるワンクリック状態であることのどちらかを可能にする宛先内で状態に置かれるように、任意の遷移において発生することができる。
【０４９１】
広告
[00561]図２５は、方法例を示す。この例は、さまざまな広告が本明細書において開示される統一された入力フィールドの使用に関連してどのように提示可能であるかに関する。方法は、いくつかの異なる手段において入力を処理することができる第１のウェブサイト内の統一された入力フィールドを介してユーザから入力を受信する（２５０２）ことを含む。第１のウェブサイトは、第１のアプリケーションであってもよし、第１のユーザインターフェースであってもよい。方法は、第２のウェブサイトまたはアプリケーションに関連づけられた広告を識別する（２５０４）ことと、あるウェブサイト（アプリケーション）から別のウェブサイト（アプリケーション）に遷移するモードに関連づけられた手段で広告を提示することとを含む。スムーズに遷移するさまざまな手段があり、広告は、遷移のモードに調節可能である。たとえば、広告は、以下の手段のうちの１つで提示可能である、または以下の遷移のうちの１つに関連づけ可能である。第２のウェブサイトの少なくとも一部分を明らかにする第１のウェブサイト内の裂け目、第２のウェブサイトを識別する拡張メニューに関連づけられ、ユーザによる選択のために利用可能である様式で、入力から識別された意図に基づいてその機能を交互にするモーフィングされた検索ボタンに関連づけられた様式で、ユーザがナビゲーションを命令することなしに第１のウェブサイトから第２のウェブサイトへの自動遷移に関連づけられた様式で、およびユーザによる選択のために第２のウェブサイトをワンクリック購入状態にする第２のウェブサイトの交渉されたバージョンに関連づけられた様式で（２５０６）。
【０４９２】
[00562]ユーザが宛先環境にアクティブにナビゲートする必要なしに第１の入力フィールドコンテキストまたは環境から別の入力フィールドコンテキストまたは環境に遷移するいくつかの異なる手段がある。この例では、システムは、ユーザの入力データの分析に基づいてユーザの意図を知っているので、システムは、その意図および宛先サイトを知っていることを使用して、遷移中のある時点において広告を提示することができる。
【０４９３】
[00563]たとえば、ユーザがｇｏｏｇｌｅ．ｃｏｍ上におり、「ｉＰｈｏｎｅ  ５Ｓ  ６４ＧＢ  シルバー」を入力した場合、システムが、意図は購入を行うことであると決定することがある。裂け目は、ウェブページのホワイトスペース内で開き、ユーザが単にｉＰｈｏｎｅを「ワンクリック」して買い、それを配達させることができる購入状態であるａｍａｚｏｎ．ｃｏｍページの一部分を明らかにすることができる。しかしながら、ホワイトスペース上の他の場所で、システムは、Ｓａｍｓｕｎｇデバイスの広告を提示することができ、Ｓａｍｓｕｎｇデバイスの広告はまた、ユーザに異なる製品を購入するまたは異なる製品を調べる気にさせるようにワンクリック状態で位置決めされてもよい。広告を提示することは、広告のために支払われる価格に基づいてよい。広告の第２のウェブサイトまたはアプリケーションの拡張メニュー内の位置は、交渉された価格に基づいてもよい。このケースでは、拡張メニューが提示されるとき、最も高く支払った広告主が、入力フィールドの近くに位置決めされてよい。識別された手段の１つで広告を提示することは、交渉された価格に基づいて選定可能である。方法は、手動ユーザナビゲーションのない、入力から識別された意図に基づいて、第１のウェブサイト（またはアプリケーション）から第２のウェブサイト（またはアプリケーション）にユーザを遷移させることを含むことができる。
【０４９４】
汎用検索インターフェース内での宛先ウェブサイトのプレビューの提示
[00564]図２６は、方法例を示す。この例は、統一された入力フィールドの入力を処理した結果として宛先ウェブサイトの１つまたは複数の小型バージョンまたは他のウェブサイトの修正されたバージョンを提示することに焦点を当てる。たとえば、入力に関連づけられた製品を特徴とし、ユーザが「ワンクリック」ボタンに触れて購入を行うことができるように前処理された、ａｍａｚｏｎ．ｃｏｍの小さいバージョンを提示すること。方法例は、第１のタイプの第１のウェブサイトに関連づけられた統一された入力フィールドを介してユーザから入力を受信する（２６０２）ことと、入力を分析して、入力に対して実行されることになるプロセスが、決定をもたらすために第２のタイプの第２のウェブサイトによって処理されるべきであるかどうかを決定することであって、第１のタイプと第２のタイプは異なるタイプである、決定する（２６０４）こととを含む。決定が、入力に従ってユーザの意図を実行するために、第２のウェブサイトが入力を処理するべきであることを示す場合、方法は、プロセッサに、入力を含む第２のウェブサイト情報に通信する動作を実行させ、ここにおいて、第２のアプリケーションが開始され、処理された状態の第２のウェブサイトをもたらすために入力を使用して前処理される（２６０６）。処理された状態は、ユーザが他のウェブサイトにナビゲートし、入力を入力し、製品を検索することの等価物である検索結果状態であることがある。処理された状態は、その製品を購入するワンクリックオプションに関連して、ユーザの入力および他の要因に基づいて、ユーザが買うことを要望する、最良で最も可能性の高い結果として得られる製品とすることができる。買うオプションは、ユーザによって対話されるとき、システムが、第１のアプリケーションとともに記憶された支払いデータを介して支払いを処理し、第２のアプリケーションを介して品物の配達を協調させることという結果になることができる。方法は、ユーザインターフェース上のエリア内の統一された入力フィールドのまわりの位置において、処理された状態でユーザに第２のウェブサイトを提示する（２６０８）ことを含む。
【０４９５】
[00565]提示は、第２のウェブサイトにナビゲートするためのユーザからの追加の入力なしで発生することができる。言い換えれば、ユーザは、ただ入力を入力フィールドにタイプし、他のウェブサイトの前処理およびいくつかの可能な前処理された状態のうちの１つでのそれらのウェブサイトのプレゼンテーションが、ユーザからのナビゲーション入力なしで自動的に実行される。処理された状態で提示される代替ウェブサイトの数は、必要とされる一義化情報の量にも基づいてなされてよい。ユーザが「ｉＰｈｏｎｅ  ５Ｓ」のみを挿入した場合、多くの代替の前処理されたウェブサイトが、３２ＧＢのワンクリック購入、ゴールド６４ＧＢのワンクリック購入などのために提示されることがある。ユーザは、これらのさまざまな提案を見て、「３２」および「シルバー」などの一義化データをタイプするだけで明確にすることができる。次いで、他のウェブサイトのプレゼンテーションは、提案をおそらくＡｍａｚｏｎからのワンクリックおよびＡｐｐｌｅからのワンクリックに絞り込むように、自動的にモーフィングすることができる。図２７は、検索フィールド２７０２と、検索ボタン２７０４と、ワンクリック購入のためのＡｍａｚｏｎからのサイト２７０６およびワンクリック購入のためのＡｐｐｌｅウェブサイト２７０８などのさまざまな代替宛先サイトとをもつインターフェース２７００を示す。このシナリオにおけるＡｐｐｌｅは、もちろん、ＡＰＩを介して検索エンジン／ソーシャルメディア／非販売業者サイトと通信する任意の販売業者を表すことができる。ワンクリックまたは買うオプションボタン２７１４は、広告２７０８が、サイトにおいてまたはＡｐｐｌｅ  Ｐａｙのようなサーバを介して記憶された支払い情報は支払いを処理するために使用可能であり、配達が販売業者によって管理および完了される改善された支払い処理を可能にするように構成されるという標識とすることができる。したがって、ユーザは、広告２７０８またはボタン２７１４をクリックし、支払い情報を同じく入力するために販売業者ウェブサイトに完全に転送される苦痛を減少させるステップのこの改善されたセットに従って購入プロセスを完了するように求められることがある。したがって、この意味では、「ワンクリック」ボタン２７１４は、ワンクリックまたは本明細書において開示されるこの新しい支払い処理／配達手法を使用して購入を行うことをユーザが要望するという標識を文字通りに意味することができる。
【０４９６】
[00566]ワンクリック購入またはワンクリック付け値ボタンをもつｅＢａｙウェブサイト２７１０、およびＡｍａｚｏｎ検索結果提供２７１２、ここにおいて、ユーザがそのボタンをクリックした場合、ＵＲＬがａｍａｚｏｎ．ｃｏｍに切り換わり、ユーザが「ｉＰｈｏｎｅ  ５Ｓ  ３２ＧＢ」を入力し、Ａｍａｚｏｎ．ｃｏｍ上で直接的に「検索」を打ったかのように前処理される。諒解され得るように、このようにして入力を前処理することは、Ｇｏｏｇｌｅ．ｃｏｍのような検索ウェブサイトからＡｍａｚｏｎ．ｃｏｍのような製品購入ウェブサイトにナビゲートし、次いで検索および購入を行うために入力を提供するためにユーザによって必要な対話の数を減少させる。別の態様では、Ａｍａｚｏｎ．ｃｏｍのような第２のサイトに遷移することは、ユーザが、ユーザがワンクリックで製品を購入することができるディープリンク状態の宛先サイトに到着するように、ワンクリック設定などのブラウザ内に記憶されたデータを利用することができる。
【０４９７】
[00567]処理された状態は、状態のうちの１つを含むことができ、ここにおいて、ユーザが、入力に関連づけられた品物の購入および配達を引き起こす単一のクリックを実行することがある、またはここにおいて、ユーザが、単一のクリックを実行し、ユーザが第２のウェブサイトにナビゲートして検索のための入力を入力したかのように第２のウェブサイト上で検索結果を閲覧することがある。方法は、入力を処理し得る第３のウェブサイトを識別することと、ユーザインターフェース上のエリア内の統一された入力フィールドのまわりの第２の位置において第３のウェブサイトを提示することとを含むことができる。図２７は、この手法を示す。第２のウェブサイトと第３のウェブサイトは、異なる状態であることができる。さらに、統一された入力フィールドに対する第２のウェブサイトおよび第３のウェブサイトの位置は、第２のウェブサイトと第３のウェブサイトのうちどちらが、入力に基づいた最も可能性の高い意図をもつかに依存することができる。宛先サイトのうちの１つにおいて「ワンクリック」ボタンまたは「検索」ボタンをクリックすることは、購入および配達を引き起こすだけでなく、第１のウェブサイトＵＲＬ（ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍなど）から選定されたウェブサイトＵＲＬ（ｗｗｗ．ａｍａｚｏｎ．ｃｏｍなど）に自動遷移することも引き起こす。言い換えれば、「ワンクリック」ボタン（または「検索結果」などの他の機能ボタン）をクリックすることは、購入および配達を処理するだけなく、他のウェブサイトへの遷移も引き起こす。ユーザが、最初にｗｗｗ．ａｍａｚｏｎ．ｃｏｍにナビゲートし、ワンクリック購入ボタンをクリックするまで検索した場合、ユーザは、ｗｗｗ．ａｍａｚｏｎ．ｃｏｍにおいて、「１クリック購入ありがとうございます。処理中です」という通知を見る。その段階では、ユーザは、アカウントに進む、注文を変更またはキャンセルする、注文を追跡することなどをしてよい。ここでのポイントは、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍというＵＲＬ上に提示される図２７の特徴２７０６内に提示されるワンクリックボタンをクリックすることによって、システムは、自動的にＵＲＬを、そのメッセージ、「１クリック購入ありがとうございます。処理中です」を提示するような処理された状態のｗｗｗ．ａｍａｚｏｎ．ｃｏｍに変更させる。その段階では、ｗｗｗ．ａｍａｚｏｎ．ｃｏｍへの初期ナビゲーションとｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍからのこの自動遷移との間に本質的に違いはない。もちろん、ナビゲーションは、任意のウェブサイトまたはアプリケーションから他の任意のウェブサイトまたはアプリケーションにすることができる。遷移は、支払いの処理と配達を管理することを分離することも含むことができる。たとえば、ｇｏｏｇｌｅ．ｃｏｍは、品物のための支払いを取り扱うが、注文の配達に関してｗｗｗ．ｍｅｒｃｈａｎｔ．ｃｏｍと協調することがある。
【０４９８】
[00568]図２８Ａは、本明細書において開示される処理に関係する別の例を示す。システムは、ユーザインターフェース上で入力フィールドを提示することができ、ここにおいて、この入力フィールドは、少なくとも２５，０００の個々のドメインからのウェブページを巡回しインデックスを付けることに基づいた検索結果をサービスする一般化されたインターネット検索エンジンに関連づけられる（２８００）。この数は、もちろん、変化することができるが、ＧｏｏｇｌｅまたはＹａｈｏｏを介するインターネット検索とｗｗｗ．ｎｅｗｙｏｒｋｔｉｍｅｓ．ｃｏｍを検索することのような単一のウェブサイト上での検索を区別することを意味する。方法は、入力フィールド内のユーザからのユーザ入力を受信する（２８０２）ことと、ユーザインターフェース上でユーザ選択可能なオプションを提示することであって、このユーザ選択可能なオプションは、ユーザ入力に関連づけられた品物の購入を処理することに関連づけられ、ここにおいて、この購入は、プロセス購入エンジン（入力フィールドエンティティによって動作可能である）を介して、ユーザとユーザ選択可能なオプションとの間の単一の対話に基づいて、処理および完了され、単一の対話は、ユーザ入力を受信した後の第１の対話である、提示する（２８０４）こととを含む。品物の配達は、入力フィールドエンティティとは別個の販売業者を介して達成可能である。
【０４９９】
[00569]一例として、ユーザは、検索フィールドへとｉＰｈｏｎｅ  ６を入力し、したがって、「ユーザ入力」は「ｉＰｈｏｎｅ  ６」である。ユーザは、テキストを打ち込み、「ｅｎｔｅｒ」または「検索」を打つ。システムは、その入力を処理し、ユーザが「ｅｎｔｅｒ」を打った後でさらなる対話を実行することのない（すなわち、別のウェブサイトにナビゲートするまたは別のアプリケーションにジャンプすることを必要としない）ことを可能にするユーザのための対話を構築し、したがって、次の対話は、ｉＰｈｏｎｅ  ６を買う（購入するおよび／または配達する）ためにユーザ選択可能なオプションとのユーザ対話であることができる（そうである必要はないが、そうであることができるように構築される）。したがって、方法は、ユーザからユーザ選択可能なオプションとの単一の対話を受信する（２８０６）ことと、単一の対話に基づいて、ユーザ入力に関連づけられた品物の購入を処理する（２８０８）こととを含む。もちろん、処理は、購入および配達を含むことができる。ユーザに利用可能な他のオプションは、もちろん、親類または友人（購入者以外の誰か）への配達であるように、またはユーザプロファイル上で設定される好ましい異なる手段で支払うように、購入プロセスを調節することを含むことができる。Ａｍａｚｏｎ．ｃｏｍのようなアウトレットを用いた購入プロセスおよび能力によく似て、本開示は、この段階におけるそのような機能をもすべて包含する。たとえば、買うオプションとの対話は、統一された入力フィールドに関連づけられた第１のエンティティが品物の支払いを処理し、買い手に品物を配達することによって注文を埋めるまたは最終決定するために別個の販売業者と協調するという結果になることができる。次いで、第１のエンティティは、販売業者への支払いを行うことを取り扱う。
【０５００】
[00570]図２８Ｂは、実際に購入を行うことをユーザに求めない別の例を示す。方法は、一般化された検索エンティティのユーザインターフェース上の入力フィールドを提示することであって、この一般化された検索エンティティは、販売業者サイトと非販売業者サイトの両方にインデックスを付け検索する一般化された検索エンジンを使用してデータを処理する、提示すること（２８２０）と、入力フィールド内の問い合わせ（たとえば、他の入力モードも企図されているが、テキストベースの問い合わせなど）を受信すること（２８２２）と、このテキストベースの問い合わせを販売業者からの販売のための製品の製品データベースと相関づけて相関をもたらすこと（２８２４）とを含む。相関は、単に、買うオプションを用いた検索結果の一部としてとして提示され得る製品の在庫があるかどうかを決定するために製品のデータベースにアクセスすることを意味することができる。
【０５０１】
[00571]方法は、を含むこの相関に少なくとも一部は基づいて、問い合わせが、決定をもたらすために検索意図および購入意図のうちの１つに関連づけられると決定すること（２８２６）を含む。決定が検索意図を示すとき、方法は、非販売業者サイトを含む検索結果を提示する（２８２８）ことと、非販売業者サイトに関連づけられた検索対話を受信する（２８３０）ことと、この検索対話に基づいて、非販売業者サイトに遷移する（２８３２）こととを含む。決定が購入意図を示すとき、方法は、問い合わせに関連づけられた買うオプションを含む購入関係検索結果を提示する（２８３４）ことを含む。購入関係検索結果は、ユーザが購入関係検索結果と対話し、買うオプションと対話することを介して購入を確認するとき、一般化された検索エンティティ（または販売業者とは別個の、別個の支払いサービス）は、品物の購入の処理を開始するように構成可能である。方法は、購入関係検索結果に関連づけられたユーザから対話を受信する（２８３６）ことを任意選択で含むことができる。買うオプションを有する検索結果の構造は、この態様の一部である。ユーザが検索結果と対話することおよび／または購入トランザクションを完了することは、任意選択の特徴である。
【０５０２】
[00572]方法は、買うオプションとの対話をユーザから受信することと、一般化された検索エンティティ、ブラウザ、または別の支払いサービスにおいて記憶された支払い情報に基づいて品物の購入を管理することであって、品物の配達は、一般化された検索エンティティとは別個の販売業者サイトを介して取り扱われる、管理することとを含むことができる。ユーザは、検索結果、購入関係検索結果、および買うオプションのうちの１つがどのように提示されるかを支配する好みを記憶する既存のアカウントを有することができる。購入関係検索結果は、さらなる検索結果を受信するためにユーザによって選択可能なオプションを含むことができる。ユーザインターフェースは、一態様では、モバイルデバイス上にあることができる。別の態様では、購入関係検索結果は、ユーザが、販売業者サイトに遷移したいという要望を示す購入関係検索結果と対話するとき、方法が、購入関係検索結果に関連づけられた販売業者サイトに遷移することをさらに含むようにさらに構成可能である。このケースでは、一般的には、販売業者は、支払いを処理することを続行する。言い換えれば、検索結果は、買うオプションを含むことができるが、継続された検索のために販売業者サイトに遷移するおよび／または購入を行うオプションも含むことができる。一般化された検索エンティティと販売業者サイトは、品物の購入および配達を管理するためのアプリケーションプログラミングインターフェースを介して通信することができる。
【０５０３】
[00573]別の態様では、ステップは、販売業者によって実行可能である。このケースでは、販売業者は、販売業者サイトから、通信インターフェースを介した販売業者サイトと一般化された検索エンティティとの間の通信を確立する。一般化された検索エンティティは、上記に記載された様式で質疑を処理する。販売業者は、製品在庫へのアクセスを提供し、ＡＰＩを通して、製品提案を提供し、販売業者が配達を処理および管理することができるように、一般化された検索エンティティまたは他の支払いサービスからの支払いならびに購入についてのデータを受信する。
【０５０４】
ソーシャルメディア
[00574]本開示は、ここで、ソーシャルメディアまたは検索サイト機能に戻る。図２９は、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍのような検索サイトとソーシャルネットワーキングサイトとの間で異なるサイトにまたがって適用されることができる方法の一般的な例を示す。概念は、購入／販売意図を有するサイトへの入力（テキスト、画像、ビデオ、ツイートなど）にユーザが含まれるかどうかを非従来のステップの使用を通して技術的に決定するように、これらのサイトのいずれかの従来の処理を変更することである。第１のステップは、サイトへのユーザ入力を受信する（２９０２）ことである。システムは、製品データベースを指すデータのためのユーザ入力を評価する（２９０４）。システムは、意図は存在しないと決定することがあり、または製品データベースへのリンクもしくは製品データベース内でリストされた製品に合致することがある製品への参照を識別しないことがある。製品データベースへの参照がないとき、システムは、それぞれのサイト（Ｇｏｏｇｌｅ、Ｔｗｉｔｔｅｒ、Ｆａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍ、Ｐｉｎｔｅｒｅｓｔ）のための従来のやり方でユーザ入力を処理する（２９０６）。製品データベースにリンクするユーザ入力内にある種類のデータがあるとき、システムは、ユーザ入力のさらなる処理の受信者に関連づけられた買うオプションを提示するために非従来の処理に変化する（２９０８）。ツイート、Ｆａｃｅｂｏｏｋ投稿、Ｉｎｓｔａｇｒａｍ写真、Ｇｏｏｇｌｅ検索の結果などの受信者などは、買うオプションを見て、Ａｐｐｌｅ  Ｐａｙのようなサービスを通して、またはユーザのための支払いデータを記憶および処理するサイトを通して、サイト内で製品を購入することが可能にされる。ユーザが買うオプションと対話するとき、新しい処理が、品物の支払いおよび／または配達を処理するために発生する。たとえば、サイトからユーザ入力を投稿した販売業者または売り手サイトへのディープリンクへのスムーズな遷移が、ユーザが販売業者サイトから品物を容易に購入することができるように発生することができる（２９１０）。あるいは、サイトは、支払い情報を記憶することができる、または別個の支払いサービスが、サイトにおいて、販売業者によってまたは販売業者サイトを通して直接的にではなく、支払いを一般に処理するために利用可能である。
【０５０５】
[00575]図３０は、ソーシャルメディアおよび特にＦａｃｅｂｏｏｋに関係する例を示す。例示的な方法は、ソーシャルネットワーキングサイトを通してテキスト、画像、またはビデオのうちの少なくとも１つの投稿を受信することであって、ソーシャルネットワーキングサイトは、投稿エンティティから投稿された品物を受信して受信エンティティに送信する、受信する（３０００）ことと、投稿に関連づけられたデータを識別する（３００２）ことと、決定をもたらすために、データが、投稿エンティティからの販売のための製品のデータベース内の製品を識別するかどうかを決定する（３００４）こととを含む。決定が、製品のデータベース内に製品への参照がないことを示すとき、方法は、買うためのオプションのないソーシャルネットワーキングサイトを通して投稿を送信する（３００６）ことを含む。決定が、投稿は製品のデータベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、方法は、製品に関連づけられた買うオプションをもつソーシャルネットワーキングサイトを通して投稿を送信することと、買うオプションに関連づけられた買い手から購入対話を受信することとを含む（３００８）。これは、さらなる処理を発生させるためにユーザまたは受信者が投稿を閲覧またはクリックすることを単に含むことができる。任意選択で、方法は、購入を処理することが、ソーシャルネットワーキングサイトまたはサイトのバージョンを提示するｗｅｂｖｉｅｗ内で発生するように、購入対話に基づいて製品の購入を処理することを含む。ソーシャルネットワーキングサイト内の購入を処理することは、ソーシャルメディアサイトにおいて記憶された支払い情報を通して、またはＰａｙＰａｌ（登録商標）もしくはＡｐｐｌｅ  Ｐａｙ（登録商標）のような別の支払いサービスを通して、達成可能である。ブラウザＡＰＩは、ユーザインターフェースを介して支払いを処理するためにも使用されることがある。これらのサービスは、買うボタンとのユーザ対話が、ソーシャルメディアサイトと販売業者との間のプロセスへと統合されるサービスのうちの１つからの支払いをトリガするように、サイトと統合される。
【０５０６】
[00576]投稿が、投稿エンティティからの製品のデータベース内の製品に関連づけられているかどうかを決定することは、アプリケーションプログラミングインターフェースを介してソーシャルネットワーキングサイトと製品のデータベースとの間で通信することをさらに含むことができる。製品の配達を処理するステップは、製品を発送するためにアプリケーションプログラミングインターフェースを通して製品を販売する投稿エンティティに知らせることを含むことができる。ユーザは、どのように画像またはビデオおよび買うオプションが提示および処理されるかを支配する好みを記憶する既存のアカウントを有することができる。
【０５０７】
[00577]別の態様では、上記で説明されたようにサイトにおいて支払いを処理することではなく、方法は、ソーシャルネットワーキングサイトから投稿エンティティによって動作されるサイト内のディープリンクに買い手を遷移させることを含むことができる。このようにして、販売業者は、事前構成された位置にいるユーザと、直接的に販売業者サイトを通して製品を閲覧および購入するための販売業者サイト内の状態とを受信することができる。
【０５０８】
[00578]別の態様では、方法は、販売業者の観点から実施される。販売業者は、投稿エンティティとして、投稿をもたらすためにソーシャルネットワーキングサイトを通してテキスト、画像、またはビデオのうちの少なくとも１つをサブミットする。サイトは、次いで、上記で概説されたように投稿を処理する。ユーザが、投稿をクリックしたまたは投稿内の品物の購入に向けて処理を開始した場合、処理は、投稿エンティティによって、購入対話に基づいて製品の配達を処理することを含むことができる。投稿エンティティはまた、ショッピングを続ける、品物の支払いおよび配達を処理する、などのために、ソーシャルメディアサイトからそれ自体のサイトへのディープリンク遷移を受信することができる。上記で概説されたこのプロセスは、Ｆａｃｅｂｏｏｋなどのようなソーシャルメディアサイトを通して買うボタンを管理するためのさまざまな態様を提供する。
【０５０９】
[00579]図３１は、Ｐｉｎｔｅｒｅｓｔ、Ｉｎｓｔａｇｒａｍ、Ｙｏｕｔｕｂｅなどのメディアに適用可能とすることができる別の例示的なソーシャルメディア態様を示す。ソーシャルネットワーキングサイトは、ビデオもしくは画像の共有サイト、またはピンボードサイトのうちの１つとすることができる。方法は、投稿エンティティから、ソーシャルネットワーキングサイトを通して画像またはビデオの投稿を受信することであって、このソーシャルネットワーキングサイトは、投稿エンティティから投稿された品物を受信して受信エンティティに送信する、受信する（３１００）ことと、プロセッサを介して、関連づけられたテキストベースのデータのための画像またはビデオの投稿を分析する（３１０２）ことと、関連づけられたテキストベースのデータが、決定をもたらすために投稿エンティティからの販売のための製品データベース内の製品を識別するかどうかを決定する（３１０４）こととを含む。決定が、製品データベース内の製品への参照がないことを示すとき、方法は、今すぐ買うボタンのないソーシャルネットワーキングサイトを通して画像またはビデオの投稿を送信することを含む（３１０６）。決定が、画像またはビデオの投稿は製品データベース内の製品を参照することを示し、したがって、販売関係意図を示すとき、方法は、画像またはビデオの投稿に関連づけられた買うオプションをもつソーシャルネットワーキングサイトを通して画像またはビデオの投稿を送信することであって、買うオプションは、ボタン、ドロップダウンメニュー、またはハイパーリンクのうちの１つを含むことができる、送信する（３１０８）ことと、買うオプションに関連づけられた購入対話を受信する（３１１０）こととを含む。任意選択で、方法は、購入対話に基づいて品物の購入を処理することを含むことができる。これは、受信者が実際に投稿をクリックして購入を完了したときに発生する。特に、ここでの概念は、一般に、投稿の新規な構造を伴い、必ずしもユーザが購入を行うときの支払い処理を伴わない。買うボタンをもつ投稿も単に、投稿の一部として買うボタンをもつ広告タイプ投稿として投稿エンティティによって開始されることがある。
【０５１０】
[00580]画像またはビデオの投稿が、投稿エンティティからの製品データベース内の製品に関連づけられているかどうかを決定することは、アプリケーションプログラミングインターフェースを介してソーシャルネットワーキングサイトと製品データベースとの間で通信することを含むことができる。品物の配達を処理することは、支払いアカウントが投稿エンティティに記憶されないソーシャルネットワーキングサイトに関連づけられた（すなわち、サイトに記憶されたまたは別個の支払いサービスと統合された）支払いアカウントを介して品物のための支払いを管理することと、品物を発送するためにアプリケーションプログラミングインターフェースを通して品物を販売する投稿エンティティに知らせることとを含むことができる。ユーザは、どのように画像またはビデオの投稿および買うオプションが提示されるかを支配する好みを記憶する既存のアカウントを有することができる。
【０５１１】
[00581]上記のＦａｃｅｂｏｏｋ例と同様に、方法の別の態様が、販売業者の観点から実施可能である。販売業者は、投稿エンティティとして、投稿をもたらすためにソーシャルネットワーキングサイトを通してテキスト、画像、またはビデオのうちの少なくとも１つをサブミットする。サイトは、次いで、上記で概説されたように投稿を処理する。ユーザが、投稿をクリックしたまたは投稿内の品物の購入に向けて処理を開始した場合、処理は、投稿エンティティによって、購入対話に基づいて製品の配達を処理することを含むことができる。投稿エンティティはまた、ショッピングを続ける、品物の支払いおよび配達を処理する、などのために、ソーシャルメディアサイトからそれ自体のサイトへのディープリンク遷移を受信することができる。上記で概説されたこのプロセスは、Ｐｉｎｔｅｒｅｓｔ、Ｉｎｓｔａｇｒａｍ、Ｔｗｉｔｔｅｒ、ＹｏｕＴｕｂｅなどのようなソーシャルメディアサイトを通して買うボタンを管理するためのさまざまな態様を提供する。
【０５１２】
製品管理エンジン
[00582]本開示は、次に、製品管理エンジン、購入マネージャ、または複数のプラットフォームにまたがる製品購入を管理するエンジンについて考える。
【０５１３】
[00583]図３２は、本開示が対処する一般的な環境３２００を示す。特徴３２０２は、購入を行うためのさまざまなシステムを示す。たとえば、Ａｍａｚｏｎ．ｃｏｍは、示されるように、支払い方法を使用して、販売業者３２０６からインターネット３２０４を通して購入を提供することができる。同様に、上記で開示されたように、検索エンジンまたはソーシャルメディアアプリケーションなどの他のエンティティは、支払いが処理可能である買うボタンを提供することができ３２０２、インターネット３２０４を介した販売業者３２０２との通信は、そのような購入された製品の配達を可能にすることができる。同様に、Ｆａｃｅｂｏｏｋなどのソーシャルメディアサイトは、支払いが処理される３２０２買うボタンと、インターネット３２０４を通じた販売業者３２０６との通信も提供することができる。しかしながら、図２に示されるように、購入がインターネット上でユーザによって行われ得るこれらのさまざまなタイプの方法の間に協調はない。インターネットおよびモバイルアプリケーション上で複数のプラットフォームにまたがって製品を買う能力の異なる提供のために、人々は、自分が何を買ったかおよびそれをどこから買ったかを容易に忘れることができる。たとえば、ある人が、１週間前にワンクリック提供の傘を買ったことがあり、その傘が到着していないことがあり、傘をＴｗｉｔｔｅｒから買ったのか、Ｇｏｏｇｌｅ．ｃｏｍから買ったのか、Ｆａｃｅｂｏｏｋから買ったのかを覚えていないことがある。Ａｍａｚｏｎ．ｃｏｍのような１つのシステムでは、ユーザのアカウントに進み、購入履歴を管理することは簡単である。新しい買うボタン環境では、購入履歴にアクセスするは、さらに困難になる。したがって、本開示は、この問題に対処し、製品購入管理システムまたはエンジンを介して強化されたユーザアカウントを提供しようと努める。
【０５１４】
[00584]図３３は、この手法を示す。全体的なエコシステム３３００は、購入管理システム３３０２または製品購入履歴管理エンジンを伴う。さまざまな購入データを調和および受信し、そのデータを相関づけ、そのデータを調和させ、いくつかの異なる購入プラットフォームを通してアクセス可能である統一された購入履歴および管理ユーザアカウントを提示することを目的にした、いくつかの異なるエンティティからの通信を可能にするＡＰＩ３３０４が提供される。
【０５１５】
[00585]たとえば、ＡＰＩ３３０４は、Ａｍａｚｏｎ．ｃｏｍなどの販売業者アグリゲータサイト３３０８におよびこれから情報を通信することができる。したがって、ユーザのアカウントおよび購入履歴内で見られる情報のすべては、ＡＰＩ３３０４を通して通信可能であると考える。Ａｍａｚｏｎは、販売業者３３１０のために製品を販売する。そのような販売業者は、購入、価格、製品などをＡｍａｚｏｎ．ｃｏｍ３３０８と通信するのと同様の様式で、ＡＰＩ３３０４を通して購入管理システム３３０２と通信することもできる。
【０５１６】
[00586]類似の様式で、買うボタンおよびさまざまな異なる環境の出現とともに、検索エンジン３３０２を通して購入が行われるとき、検索エンジンは、ＡＰＩ３３０４を介して購入管理システム３３０２と通信することができる。同様に、検索エンジン３３１２を通して製品を販売する販売業者３３１４は、ＡＰＩを通して情報を通信することができる。類似の手段では、それぞれの販売業者３３１８を通してソーシャルメディア３３１６上で行われる購入は、インターネット３３０６およびＡＰＩ３３０４を介して購入管理システム３３０２と通信することもできる。配達サービス３３２０はまた、さまざまな販売業者３３１０、３３１４、３３１８と統合され、ＡＰＩ３３０４を介して購入管理システム３３０２と通信することもできる。そのうえ、広告主３３２２は、アウトレットのいずれかを通して、または販売業者のいずれかに、改善点が広告を提供することを可能にすることができる有益な購入行動情報を受信するために、ＡＰＩ３３０４を通して、または他の手段を通して、購入管理システム３３０２と通信することができる。したがって、販売業者３３１０、３３１４、３３１８のいずれかは、図３３に示されるさまざまな手段を通して製品を販売するためにアクセスを有することができるだけでなく、自身の別個のウェブサイトを有することもあり、ビジネスインテリジェントデータ３３２２が利用され、購入を行い、ユーザのための広告を改善するために、これらの手段のいずれかに提供可能である。ＡＰＩは、標準化された呼び出しおよび通信プロトコルが、このプロセスを実行するために必要とされるさまざまなタイプのデータのすべてを識別し、これを、エンジンまたは集約と管理を取り扱う他のエージェントと販売業者またはユーザとの間で交換するために使用可能であるように構造化可能である。これは、購入された製品、配達住所、製品がギフトであるかどうか、配達に関連づけられたメッセージ、配達スケジュール時間、現在の配達ステータス、断定された配達時間、保証情報、支払いステータス、繰り越し注文ステータス、返品ステータス、および／または情報などのデータを含むことができる。購入を管理するために有用なこれらおよび他の任意のデータは、要求可能である、送信可能である、受信可能である、またはＡＰＩとＡＰＩを通して通信する構成要素のいずれかとの間で通信可能である。
【０５１７】
[00587]ＡＰＩは、エンジンにアクセスするための対話型ボタンまたはグラフィックをいつどのように提示するべきかなどの特徴も含むことができる。たとえば、この管理エンジンの使用は、ユーザが異なるアプリケーションまたはウェブサイトにまたがってワンクリックまたは他の購入を行うコンテキストにおいてである。支払い要求ＡＰＩも、本明細書において開示される。販売業者は、たとえば、支払い要求ＡＰＩへの呼び出し、または他のＡＰＩへの呼び出しをサブミットするとき、またはそれ自体の処理を通して、生産物購入管理アクセスボタンも対話内で提示されることを要求することがある。このようにして、ユーザがソーシャルメディアサイト上にいる、ロケーションにおいて購入を行っている、などの場合、ユーザのアカウントにアクセスする能力が提示される。アクセスボタンを要求するための呼び出しは、ユーザがある種類の変更を行うまたはアカウントをチェックすることを要望する可能性がある確率があることを示すことがあるユーザのアカウントについての分析の要求または分析の結果を含むことがある。たとえば、販売業者は、ユーザが通常のアカウントアクセスおよび／または変更を有しており、タイミングが、ユーザが間もなくすぐアカウントにアクセスする可能性があるようなものである場合、買うボタン購入を行う間、またはその後に、アカウントアクセスボタンが提示されることを要求することがある。次いで、ユーザは、購入を行う「ゾーン内にいる」間、現在の購入を見て、他の購入をレビューすることがある。分析は、ユーザが、購入しようとしているまたは購入したばかりのものに類似した製品をアカウント内に有すると決定することがあり、二重に買っていないことを保証するために全体的なアカウントをレビューすることを望む可能性がある。したがって、システムは、ユーザ購入のために購入履歴および管理エンジンへのアクセスボタンを含むかどうかのインテリジェントな考慮事項を提供することができる。このアクセスボタンは、販売業者からの要求によって、ユーザプロファイル考慮事項によって、または別個のエンティティを介して、提供可能である。たとえば、ユーザは、行おうとしている購入が以前の購入と衝突するまたは以前の購入の重複になるまで毎回アクセスボタンを見ることを望まないというインジケータをプロファイル内に置くことがある。ユーザは、あらゆる購入の後で購入履歴を見ること、またはアカウント履歴にアクセスするためにユーザにオプションを提示させることを要望することがある。アクセスボタンは、購入履歴内に異常な何かがあることがあり（二重購入が起こったばかりである、または品物の配達の遅れが予想される）場合にユーザがチェックするべきであるという通知を与えるように視覚的におよび／または聞こえるように構成（すなわち、より明るい、閃光、ある音を立てること）可能である。このシナリオでは、たとえば限られた表示スペースがモバイル購入において与えられると、システムは、その表示が、ユーザが購入履歴をレビューするまたは購入履歴の変更を行う可能性のある必要性に接続されるように、アクセスボタン（または聞き取れるなどの他のアクセス機構）をいつユーザに提示するべきかをよりインテリ��ェントに決定することができる。
【０５１８】
[00588]機械学習エンジンは、ユーザの実際の使用状況およびアカウントのアクセスにも適用可能である。したがって、システムは、毎回もしくは２回ごとに、または何らかの他の戦略の下で、ボタンを提供することによって始まり、ユーザがどのようにしていつアカウントにアクセスするかを知ることがある。たとえば、システムは、ユーザがＡｍａｚｏｎ．ｃｏｍを通してアカウントにのみアクセスすることを知ることがあり、したがって、システムは、ソーシャルメディアまたは検索エンジンサイト上でアクセスボタンを提示することを止める。または、システムは、通常、購入の２週間以内にユーザがステータスをチェックするためにアカウントにアクセスすることを知っていることがある。したがって、機械学習アルゴリズムは、購入後２週間以内、および３日間は、アクセスボタンを提示するための新しいルールを学習し、適用し、ユーザがアカウントにアクセスしなかった場合、アクセスボタンは見えなくなる。もちろん、アクセスは、常に利用可能であるが購入履歴および管理システムへの「ワンクリック」アクセスは本明細書において開示されるように管理可能であるタブまたはアカウントボタンを通して、常に達成可能である。あるいは、購入履歴管理システムへのアクセスは、テキストもしくは電子メール内のリンク、または音声によりアクティブ化されるシステムを通してなど、他の手段を通しても提供可能である。ユーザプロファイル、機械学習アルゴリズム、または他のトリガインベントを通して、たとえば、システムに、ユーザは何かをチェックするためにアカウントにアクセスするべきであることをユーザに通知させることができる。たとえば、翌日配達がスケジュールされたパッケージが遅れそうである場合、システムは、電子メール、テキスト、ソーシャルメディアメッセージもしくは投稿、またはユーザがＧｏｏｇｌｅ．ｃｏｍ検索を行っているもしくはＦａｃｅｂｏｏｋ上にいるときなどにユーザが「いる」ところへの通知などのアウトレットを通して、通知を提供することができる。
【０５１９】
[00589]そのうえ、図３３は、ＡＰＩ３３０４とそれぞれの購入手段との間での双方向における通信を示す。したがって、例は、この点を示すものとする。ユーザがＡｍａｚｏｎアカウントを有し、Ａｍａｚｏｎ．ｃｏｍ３３０８を通して異なる販売業者から３個の購入を行ったと仮定する。そのユーザは、アカウントに進み、購入を追跡、配達、キャンセルするなどの、購入に関連づけられたさまざまな事柄を取り扱うことがある。しかしながら、そのアカウントは、Ａｍａｚｏｎ上で行われる購入のみに限定される。本明細書において開示される原理を使用すると、ユーザが検索エンジン３３１２を介して販売業者３３１４からウィジェットを購入した場合、その情報は、ＡＰＩ３３０４を通して購入管理システム３３０２に提供され、次いで、Ａｍａｚｏｎ．ｃｏｍユーザアカウント上の既存の購入と結合される。このアカウントでは、ユーザは、Ａｍａｚｏｎ．ｃｏｍ３３０８上のユーザアカウントに進み、検索エンジン３３１２を介してウィジェット購入を閲覧し、その購入も管理することも可能であることがある。加えて、その相関づけられたデータも、アウトレット３３１２および３３１６のすべてに提示されることがある。したがって、検索エンジンまたはソーシャルメディアサイトまたはおそらく製品を販売したことすらない何らかの他のサイトを介して、３個のＡｍａｚｏｎ購入および１つの検索エンジン購入がすべて完全にまたはほぼ完全に閲覧および管理されることがある相関づけられたユーザアカウントはアクセス可能であり、したがって、エンドユーザのための全体的なプロセスを単純化する。
【０５２０】
[00590]図３４Ａは、製品３４０６（帽子）のプレゼンテーションと、今すぐ買うボタン３４０２と、「購入を管理する」ボタン３４０４とを含むインターフェース３４００を示す。このインターフェース３４００は、製品を買うための手法のいずれかの上での任意のインターフェースを表すことができる。したがって、インターフェース３４００は、Ｇｏｏｇｌｅ．ｃｏｍ上の検索結果の一部、またはユーザがこの製品を買うことを可能にするＰｉｎｔｅｒｅｓｔ投稿などとして、今すぐ買う広告を表すことがある。これらのアウトレットのいずれかでは、購入を管理するボタン３４０４は、ユーザアカウントにアクセスするために、ユーザによって対話可能である。
【０５２１】
[00591]図３４Ｂは、例示的なユーザアカウント３４１０を示す。ここで、Ｇｏｏｇｌｅ購入３４１２、Ｆａｃｅｂｏｏｋ購入３４１４、およびＡｍａｚｏｎ購入３４１６の図示が、簡略化された様式で提示される。ユーザは、さまざまな手段でこれらの購入３４１８をリストするためのオプションが与えられる。ユーザは、たとえば、メディア、コスト、時間、配達日、返品、割り引きなどによって、これらの購入を編成することがある。
【０５２２】
[00592]図３５は、より詳細なユーザアカウント３５００を示す。ここで、ユーザが注文をレビューする、見計らい注文、デジタル注文、または注文をキャンセルすることを可能にするための、さまざまなタブ３５０２が提示される。さまざまなオプション３５０４は、ユーザが、メディアごと、コストごと、販売業者ごと、配達日ごとなどに、過去６か月（または任意の時間の期間）内になされた注文を管理することを可能にする。情報３５０６は、Ｇｏｏｇｌｅによって行われた購入などの情報を含むことができ、販売業者は、Ｊｏｅ’ｓ  Ｓｐｏｒｔｉｎｇ  Ｇｏｏｄｓである。ユーザは、製品を再び買う３５１０ためのオプションを有する、またはパッケージを追跡する、品物を返すまたは交換する、パッケージフィードバックを残す、製品レビューを書く、注文をアーカイブするなどの、他のオプション３５０８を含む。諒解され得るように、他の従来の非販売業者サイトからの購入詳細の追加は、ユーザが購入をより容易に管理することを可能にするために、ユーザアカウントの以前の動作および管理に対する改善を提供する。注文のリストのためのデータは、ブラウザまたはローカルユーザデバイス上にも記憶され、図１７Ｉに示すように、ブラウザインターフェースまたはＡＰＩを介して受信および／または送信されることがある。言い換えれば、図１７ＩのブラウザＡＰＩはまた、複数のサイトにまたがって品物のショッピングカートを記憶するためだけでなく、後での取り出しおよび処理または進捗の追跡のために、購入された製品の永続的なリストを維持するために実施されることがある。次いで、そのような取り出しはまた、購入履歴データのすべてがブラウザ内に記憶される場合、ちょうどブラウザオブジェクトから発生することがある。
【０５２３】
[00593]図３６は、製品管理エンジンの方法態様を示す。方法は、サーバまたは他のロケーションにおいて、第１のサイトから第１の変換データを受信することであって、第１のサイトは、一般化された検索エンジン、販売業者サイト、およびソーシャルメディアサイトのうちの１つを含み、第１の変換データは、第１のサイトのユーザに提示される第１の買うオプションとの対話に基づいて第１の製品の第１の購入に関連づけられた第１のデータを含むことができる、受信する（３６０２）ことと、サーバにおいて、第２のサイトから第２の変換データを受信することであって、第２のサイトは、一般化された検索エンジン、販売業者サイト、およびソーシャルメディアサイトのうちの１つを含み、第２の変換データは、第２のサイトのユーザに提示された第２の買うオプションとの対話に基づいて第２の製品の第２の購入に関連づけられた第２のデータを含むことができ、第１のサイトは第２のサイトとは異なる、受信する（３６０４）こととを含む。方法は、第１のデータと第２のデータを相関づけて、相関づけられたデータをもたらす（３６０６）ことと、相関づけられたデータの要求をユーザから受信することであって、この要求は、要求サイトをもたらすために第１のサイトおよび第２のサイトのうちの１つから受信される、受信する（３６０８）こととを含む。方法は、相関づけられたデータを要求サイトに送信する（３６１０）ことを含むことができる。諒解され得るように、この手法は、「微小の瞬間」が、購入決定だけでなく、購入履歴管理決定も包含することを可能にする。本開示は、ユーザがどこにいようとも、Ｆａｃｅｂｏｏｋ上であろうと、Ｉｎｓｔａｇｒａｍ上であろうと、Ｐｉｎｔｅｒｅｓｔ上であろうと、Ｔｗｉｔｔｅｒ上などであろうと、ユーザの指先における幅広いユーザ購入アカウントへのアクセスをする。ユーザアカウントデータの送信は、購入サイトに対してである必要はなく、任意のロケーション、任意のアプリケーションに対してであってよい。したがって、ユーザは、電子メールにｏｕｔｌｏｏｋを使用しており、ＡＰＩを介して購入アカウントにアクセスするためのオプションを有し、「今すぐ買う」ボタンまたはオプションがＯｕｔｌｏｏｋに利用可能でない場合であっても、Ｏｕｔｌｏｏｋアプリケーションを介して選択可能なオプションがアクセス可能である可能性がある。Ｔｗｉｔｔｅｒのようなアウトレットが、買うボタン特徴から離れた場合であっても、ユーザは、依然として、そのようなソーシャルネットワーキングサイト上で時間を費やし、購入履歴管理エンジンへのアクセスは、そこに付与可能である。
【０５２４】
[00594]ソーシャルメディアサイトは、画像を交換するためのサイト、画像およびコメントを投稿するためのサイト、ショートテキストメッセージを交換するためのサイト、およびビデオを投稿するためのサイトのうちの１つを含むことができる。上記で言及された第１のサイトは、購入意図および検索意図のうちの１つであるようにテキストのユーザ入力を分析することによってユーザの意図を決定する一般化された検索エンジンを含むことができる。ユーザの意図が購入意図であるとき、一般化された検索エンジンは、第１の製品に関連づけられた買うオプションを含む応答を用いてテキストのユーザ入力に応答することができる。相関づけられたデータを要求サイトにさらに送信することは、ユーザが以下の動作のうちの１つまたは複数を実行することを可能にする要求サイトにインターフェースを送信することをさらに含むことができる。（１）第１の製品の第１の購入または第２の製品の第２の購入をキャンセルする、（２）第１の製品の第１の購入または第２の製品の第２の購入を交換する、（３）第１の製品または第２の製品の発送を追跡する、（４）第１の製品または第２の製品のレビューを読む、（５）第１の製品または第２の製品のうちのより多くを購入する、（６）第１の製品または第２の製品を購入するために使用される購入アカウントを修正する、（７）第１の製品または第２の製品が配達される住所を修正する、（８）第１の製品または第２の製品が受信者住所に配達されるべき日付を修正する、（９）第１の製品または第２の製品のための製品レビューを書く、（１０）（１）どのそれぞれのサイトが第１の製品および第２の製品を購入するために使用されたか、（２）第１の製品および第２の製品のそれぞれのコスト、（３）第１の製品および第２の製品を販売または配達したそれぞれの販売業者、（４）第１の製品および第２の製品のそれぞれの購入の日付、（５）第１の製品および第２の製品に関連づけられたそれぞれの配達データ、（６）第１の製品および第２の製品の割り引き率またはパーセンテージ、（７）キャンセルされた注文、（８）デジタル注文、（９）見計らい注文、および（１０）ユーザがカスタマイズ可能なカテゴリ、のうちの１つによって、第１の製品および第２の製品のそれぞれのプレゼンテーションを編成する。ユーザは、第１の製品および第２の製品のうちの１つのための保証も購入することがある。
【０５２５】
[00595]相関づけられたデータを維持し、少なくとも第１のサイトおよび第２のサイトを含む複数の異なるタイプのサイトにまたがって購入を管理するユーザアカウントにアクセスするためのオプションとの、ユーザからの対話を受信することを介して、相関づけられたデータが、第１のサイトおよび第２のサイトに利用可能にされる。ユーザアカウントにアクセスするためのオプションは、第１のサイトおよび第２のサイト上で提示されるボタンまたはドロップダウンメニューを含むことができる。サーバは、アプリケーションプログラミングインターフェースを介して第１のサイトおよび第２のサイトと通信することができる。ユーザアカウントは、一態様では、販売業者集約サイトからの購入を管理する販売業者集約サイトユーザアカウントを有する販売業者集約サイトと相関づけ可能である。
【０５２６】
[00596]方法は、サーバにおいて、販売業者サイトからの第３の変換データを受信することであって、相関づけられたデータは第３の変換データをさらに含む、受信することも含むことができる。販売業者サイトは、販売業者アグリゲータサイトだけでなく、個々の販売業者サイトとすることができる。言い換えれば、Ａｍａｚｏｎ．ｃｏｍは、製品の販売を管理するために多くの販売業者を集約するが、個々の販売業者は、製品管理エンジンからのデータを提供および受信することもできる。
【０５２７】
暗号通貨
[00597]本明細書において開示されるＡＰＩまたは財政的トランザクションのいずれも、ブロックチェーン技術を通して実施可能であることが留意される。したがって、買い手と売り手または製品との間の任意の通信は、ブロックチェーン上でのコントラクトを通して実施可能であり、支払いは、ブロックチェーン技術によりユーザアドレスを通してサブミット可能である。たとえば、ブロックチェーン上でプログラムおよび実施されるスマートコントラクトは、トランザクション内で品物を受信および実施し得る。
【０５２８】
[00598]本開示の別の態様は、検索エンジン結果上で機会を購入する「ワンクリック」または買うボタン、購入が行われ得る販売業者サイトへのインターフェース、またはソーシャルネットワーク上で投稿する買うボタンをどのようにして実施するかである。概念はまた、品物またはサービスの購入が可能である任意のアプリケーションまたはウェブサイトから単に機能することがある。これらのコンテキストでは、購入プロセスをより効率的に行うために、支払い／配達情報は、データが、ユーザが購入を完了するためにフィールド（住所、クレジットカード番号など）を手動で埋める必要がないような手段で購入トランザクションに適用可能であるように、検索エンティティ、ソーシャルネットワーキングエンティティ、別個のエージェント、ブラウザにおいて、または他の任意のロケーション内に記憶される。これらのフィールドを埋めることは、より多くの購入変換を防止する。本明細書において開示される手法は、データを要求し、データを取り出し、支払いフォームを埋めて、より多くの「ワンクリック」タイプの経験をユーザに与えるために、ＡＰＩまたは他のプロトコルを通して行われ得る。これは、たとえば、Ｗ３Ｃ支払い要求ＡＰＩまたはＡｎｄｒｏｉｄ  Ｐａｙ  ＡＰＩを通して実施され、その詳細は、本出願に対する優先出願において説明される。ブラウザまたは支払いＡＰＩはまた、支払いアプリの機能に従って支払いプロセスも取り扱うために、ユーザのデバイス上の支払いアプリと通信することができる。
【０５２９】
[00599]しかしながら、アルトコイン支払いに使用されるブロックチェーン手法を用いると、クレジットカードのような支払いアカウントを「保持する」エンティティはない。ブロックチェーンに対する、暗号通貨を使用して購入を行う、３つの要素がある。アドレス、秘密鍵、およびウォレットソフトウェアがある。アドレスは、その人またはエンティティに他人がビットコインを送ることができるところである。秘密鍵は、ある人が他人にビットコイン（または任意のアルトコイン）を送ることができる暗号学的な機密である。「ビットコイン」のような特定のアルトコインが参照されるときはいつでも、それは、任意のタイプの暗号通貨に適用されてよい。ウォレットは、ブロックチェーン元帳に対して制御するアルトコインの金額のレコードも記憶することができる。
【０５３０】
[00600]ウォレットソフトウェアは、ある人が自分のビットコインを管理するために自身のコンピュータ上で動作させるソフトウェアである。ウォレットプロジェクトは、ＣｈｒｏｍａＷａｌｌｅｔ、ＣｏｉｎＳｐａｒｋ、およびＣｏｕｎｔｅｒＷａｌｌｅｔなどの企業によって提供される。他の企業は、Ｃｏｉｎｐｒｉｓｍ、Ｍｅｌｏｔｉｃ、およびＯｎｅＷａｌｌｅｔを含む。一般的には、誰かまたはエンティティにアルトコインを送るために、送り主は、ウォレットアドレスＱＲコード（登録商標）をスキャンする、または電子メールもしくは他の手段を介して受信者のためのアドレス文字を取得する。送り主は、ウォレットアプリケーションを使用して、量、料金、配達コストなどのトランザクションについての追加の情報を入力する。送り主が、秘密鍵を使用してトランザクションを確認するとき、送出アドレスからのｘ個の数のコインが今は新しいアドレスに属するというメッセージが、送出アドレスの所有者から、ネットワークにブロードキャストされる。それは、送り主の秘密鍵によって許可される。数分後、トランザクションは、ブロックチェーンマイナーごとにブロックチェーンに記入され、確認通知が送出可能である。ユーザがウォレットをセットアップしたとき、アルトコインアドレスならびに公開鍵および秘密鍵が自動的に生成される。アルトコインアドレスは、一般的には、１または３で始まり、アルトコイン支払いのために可能な宛先を表す、２６〜３４の英数字の識別子である。時々、アドレスは、ＱＲコードとして表される。アドレスは、電子メールアドレスのように動作することができる。ユーザの公開鍵ウォレットアドレスをもつ人々は、その人にアルトコインを送ることができる。
【０５３１】
[00601]本開示は、この機能を組み込み、それを、ウェブまたはモバイルアプリケーション上で購入を行うコンテキストにおいて単純化する。ビットコイン、Ｌｉｔｅｃｏｉｎ（または任意の暗号通貨）を使用するときに発生するものは、一例では、デバイス上に記憶された個人のウォレットおよび購入インターフェース（すなわち、買うボタン検索結果、販売業者サイト上の購入オプション、またはソーシャルメディアサイト上で投稿された品物を今すぐ買う）を通してアルトコイン支払いを協調させる新しいＡＰＩである。記憶、メッセージング、ウォレット対話、モバイル支払い、識別確認、セキュリティ、および評判などの構成要素は、広く採用されている支払い要求ＡＰＩにアルトコイン支払いを統合するために必要な情報のトークンおよび適切な通信プロトコルを使用して管理可能である。
【０５３２】
[00602]このシナリオでは、販売業者は暗号通貨を受け付けると仮定される。したがって、本明細書において開示される環境が適用可能であり、買うボタンがユーザに提示されるとき、ユーザは、アルトコイン、およびアルトコインの支払いを受信することを可能にする販売業者のアドレスにアクセスするために、秘密鍵を使用して購入を行うことが可能にされる。ウォレットソフトウェアは、コイントランザクションが検証される分散スキームの一部として、ブロックチェーンのコピー−特定の通貨において発生したトランザクションすべての記録−を保つことができる。ウォレットは、ブラウザベースとすることができる、アプリケーションベースとすることができる、またはＢｌｏｃｋｃｈａｉｎ．ｉｎｆｏ、Ｍｙｃｅｌｉｕｍ、Ｃｏｉｎｂａｓｅｄ、Ｅｌｅｃｔｒｕｍ、もしくは他のプロバイダからの別個のアプリケーションもしくはスマートフォンウォレットとすることができる。言い換えれば、本開示の一態様は、ユーザのクレジット／デビット／他の支払いアカウントが記憶される、アドレス、ならびにアルトコインように、ウォレットをブラウザに組み込むことである。あるいは、プロトコルは、ブラウザ（ブラウザと販売業者との間でＡＰＩを使用する）とアルトコインウォレットとの間でデータを通信することができる。たとえば、ウォレットは、支払いを実行するが、次いで支払いをブロックチェーンに追加するために詳細を受信するために、アドレスおよび秘密鍵を共有することがある。
【０５３３】
[00603]上記で述べられたように、ユーザが品物の購入を行うために販売業者にアルトコインを送るために、ユーザは、ソフトウェアが、販売業者に支払われることになるアルトコインに対する制御を有することをチェックする場合、販売業者のアドレスおよび買い手のウォレットの秘密鍵部分を必要とする。いくつかのケースでは、人々は、ウォレットアドレスに関してＱＲコードをスキャンする。通常、送り主（買い手）は、受信者のアドレスのＱＲコードをスキャンし、ウォレットアプリケーションを使用して、量、トランザクション料金（ウォレットソフトウェアによって事前特定された量を確認する）、または他の任意のパラメータなどのトランザクションについての追加の情報を入力する。送り主が、トランザクションをサブミットするとき、送出アドレスからのｘ個の数のコインが今は新しいアドレスに属するというメッセージが、送出アドレスの所有者から、ネットワークにブロードキャストされる。動作は、送り主の秘密鍵によって許可される。送り主は、秘密鍵もしくはパスワードもしくは指紋、声紋を入力することがある、または他の許可が、送り主の秘密鍵を取り出すために使用されることがある。トランザクションは、「未確認」ステータスとともに、受信者のウォレットアプリケーションにおいて、ほとんど即時に受信され、約１０分後、トランザクションが確認され、ブロックチェーンマイナーごとにブロックチェーンに記入可能である。
【０５３４】
[00604]基本的なアルトコイン動作を現在のシナリオに適用すると、いくつかの修正および新規な特徴が実施されなければならない。目的は、アルトコインは完全に別個の手段で処理されるが、アルトコイン支払いが、支払い要求ＡＰＩを通して管理されるＶｉｓａ支払いまたはＭａｓｔｅｒｃａｒｄ支払いであるかのように、ユーザがアルトコイン支払いを選定する能力を単純で容易なやり方で可能にすることである。現在、たとえば、ユーザのＡｍａｚｏｎ．ｃｏｍアカウントにおいて、いくつかのクレジットカードがリスト可能であり、１つが、支払いに選定可能である。この手法は、購入のためのアルトコイン支払いも可能にする。
【０５３５】
[00605]アルトコイン支払いプロセスを選定し、次いで、いくつかの問題を有する支払いを取り扱うための、単純な「ワンクリック」能力を可能にする。ユーザがモバイルデバイス上におり、購入を行うことを望む場合、ユーザは、販売業者アドレスのＱＲコードをスキャンすることができない。加えて、すべてではない買い手が、ビットコインタイプウォレットを有する。したがって、ＡＰＩを通して、ユーザが購入を行うために最終的に対話することができるインターフェースを広告または投稿する販売業者は、広告またはインターフェースを閲覧する人が暗号通貨ウォレットをセットアップさせ、ユーザがビットコインまたは他の通貨を通して購入を行うことがあることを示すプロファイルを有するというデータを受信することができる。ＡＰＩは、ユーザが、購入意図が示されるまたは行われ得る状態である広告または他のインターフェースのコンテキストにおいて、買い手のアルトコインウォレットによって使用される同じ種類の認証が、ユーザは秘密鍵にアクセスするために同じ種類の機能を実行する必要があるだけであるようにインターフェースに統合可能であるように、必要な要件およびデータを交換することができる。これは、バイオメトリックス、パスワードなどを通してである可能性がある。統合は、支払いは暗号通貨において行われ得るが、配達、製品購入および配達のライフサイクルの管理、ならびに潜在的な返品などが、販売業者によって通常のやり方で取り扱われるように、買い手の秘密鍵の適用および取り出しまたは受信ならびに暗号通貨ウォレットの使用を用いて、金額、配達の住所、日付、販売業者、およびそのようなデータのすべてを取り出すことを含むことができる。
【０５３６】
[00606]この点に関して、データが、ウォレットが存在することを示す、またはユーザの好みが、製品を買うためにアルトコインが使用される／使用可能であることを販売業者に通知すると仮定すると、広告またはグラフィカルプレゼンテーションは、そのデータの一部として、アルトコインが対処可能である販売業者アドレスを含む。１つのシナリオでは、「買うボタン」は、記憶されたクレジット／デビットカードまたは他の任意の従来の支払いアカウントを使用するためのオプションを含むことがある、またはユーザは、暗号通貨アカウントを選定することがある。従来の支払いアカウントが選定される場合、検索エンティティ、ソーシャルメディアサイト、ブラウザ、他の支払いエージェントまたは他のロケーションにおいて記憶された支払いアカウントを利用して、購入を処理する、または販売業者が支払いを処理するための必要なデータを提供するためにＡＰＩを通して販売業者サイトに支払いデータを送信する、のどちらかを行う（すなわち、そのため、ユーザは、フォームを埋める必要はない）ための、本明細書において開示されるプロセス。ＡＰＩを通して交換されるさまざまな要求および応答は、購入プロセスが単純であり、支払いフォーム内のフィールドを埋めることをユーザに要求しないように、支払い情報／配達情報および／または他の情報が販売業者サイトに通信されることを可能にする。
【０５３７】
[00607]本明細書において開示されるプロセスは、暗号通貨支払い機会を追加する。アルトコイン支払いが選定される場合、インターフェースは、ユーザの秘密鍵を取り出すために、または暗号通貨トランザクションが発生することができ、販売業者が支払われ得るように、ユーザが秘密鍵を入力することを可能にするために、ＡＰＩまたは他のプロトコルを通して、ユーザのウォレットと対話する。たとえば、支払い機能を実行することができるように販売業者サイトにアドレスおよび／または秘密鍵を提供するワンタイム使用トークンが生成されることがある。または、ＡＰＩは、量、販売業者アドレス、税金、料金などの他の任意のデータを販売業者サイトから受信することができ、ＡＰＩは、そのデータを受信し、ユーザのアルトコインウォレットからの支払いを処理するためにウォレットまたはブラウザと通信することができる。アルトコインウォレットは、処理がＣｈｒｏｍｅ、Ｍｏｚｉｌｌａ、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒなどによって実行されるように、ブラウザに統合可能である。ＡＰＩが販売業者とブラウザの間にある場合、別個のＡＰＩまたはプロトコルが、ユーザのデバイス上でブラウザとユーザのアルトコインウォレットとの間でデータを通信することがある。同じく、販売業者へのアルトコインの実際の転送は、機能可能である任意の構成要素内で発生することができる。この転送は、ユーザのアルトコインウォレットを通してであってもよいし、ブラウザに組み込まれたアルトコインウォレットのインスタンスを通してであってもよいし、転送を行う販売業者を通してであってもよい。
【０５３８】
[00608]一般的には、金額は、当初ドルで設定される可能性があるが、買い手が使用するそれぞれの暗号通貨の対応する値に変換される必要があるので、アルトコインにおける購入の金額が計算されなければならない。プロセスは、この点に関して、暗号通貨の現在の値をドル（または販売業者が使用している他の任意の通貨）として提供するデータフィードにアクセスすることを含むことがある。このアクセスは、買い手が購入を行うとき暗号通貨の適切な値が購入に適用されるように、リアルタイムまたはほぼリアルタイムで行われてよい。その値およびデータフィードは、購入時にユーザに提示されることがあり、買うインターフェースの一部であることがある。
【０５３９】
[00609]買うボタンと、購入プロセスの一部である後続する画面は、買い手のための暗号通貨ウォレットへのアクセスとのインターフェースの混合を含むことができる。したがって、インターフェースは、従来の支払いアカウントを通して支払いに接続されるまたはこれをトリガする一部分と、暗号通貨のための買い手のウォレットに関連づけられた別の部分とを含むことがある。ユーザは、Ｖｉｓａ、Ｍａｓｔｅｒｃａｒｄ、またはビットコインを用いて支払うための買うオプションが提示されることがある。ユーザが暗号通貨を選定する場合、システムは、自動的にまたは手動でアクセスすることを通して、ユーザの秘密鍵が提供またはアクセスされるように、ウォレットとの対話を可能にする。パスワード、指紋許可、または秘密鍵の手動入力は、品物のための購入インターフェースが、販売業者サイトの一部であるにせよ、広告の一部であるにせよ、Ｇｏｏｇｌｅ  Ｓｈｏｐｐｉｎｇグラフィックの一部であるにせよ、Ｇｏｏｇｌｅインターフェース（または任意の検索エンティティインターフェース）上のＰｕｒｃｈａｓｅｓの一部であるにせよ、任意のブラウザ画像もしくはアプリケーションインターフェースの一部であるにせよ、またはＷ３Ｃ．ｏｒｇによって開発された支払い要求ＡＰＩの使用の一部であるにせよ、品物のための購入インターフェースを通して発生することができる。販売業者はアドレスを提供することができ、買い手が秘密鍵を提供すると、製品にとって適切な金額に関する買い手から売り手への暗号通貨の送信が達成可能である。次いで、追跡、製品配達、配達情報の通信、キャンセル、修正などが発生することができるなど、プロセスのすべてが、通常通り製品を追従することができる。
【０５４０】
[00610]一例では、デバイス上のウォレット内のユーザの秘密鍵を維持するために、プロセスは、ユーザがビットコインを通して支払いを提供することを望むという確認を受信することを含むことがある。ＡＰＩを通して、販売業者アプリケーションは、コスト情報、トランザクションＩＤ、販売業者ＩＤ、販売業者住所、配達料、税金、および／または割り引きデータなどを提供することができる。ＡＰＩは、直接的に、またはブラウザを通して、または両方の組み合わせを通して、ユーザのウォレットにデータを通信することができる。ウォレットは、販売業者住所、金額、注記などなどのトランザクションに必要なそのフィールドを確認し、ポピュレートすることができる。典型的なウォレットは、トランザクションＩＤ、販売業者ＩＤ、ユーザの好み（２日で発送）などを含むように修正可能である。しかしながら、この情報の大半はまた、エージェント、ブラウザ、検索エンジンなどからＡＰＩを通して提供可能である。ユーザのウォレットが、トランザクションを実行するためのデータがポピュレートされると、次いで、ユーザが対話している販売業者サイトまたはアプリにおけるインターフェースが、トランザクションを完了するためにパスワードまたはバイオメトリック確認を要求することができる。あるいは、あまりセキュアでないが、ユーザは、ユーザが「支払う」または同様のスタイルにされたボタンをクリックしたとき、自動処理だけを選ぶことがある。買うインターフェースとのこの対話を用いて、ＡＰＩを通して、確認コマンドは、トランザクションを実行し、販売業者または受信者にアルトコインを転送するようにウォレットに指示する。
【０５４１】
[00611]現在、クレジットカード、デビットカードなどのための支払い処理システムは、販売業者による使用のためにセットアップされる。したがって、ＡＰＩを通しての標準的な支払い手法では、支払いアカウント情報は、支払い処理のためのＡＰＩを通してブラウザまたは他のエージェントから販売業者サイトに渡される。支払いアカウントデータは、セキュアなワンタイム使用のやり方で販売業者に送信され、支払いが処理可能であるが、販売業者はユーザの支払いアカウントデータを記憶することはできないように構成可能である。しかしながら、ユーザがアルトコイン支払い手法を選定する場合、ユーザが販売業者に秘密鍵を送ることを望む可能性は低い。アルトコイン支払いを処理することは、標準的なＶｉｓａ／Ｍａｓｔｅｒｃａｒｄタイプのトランザクションとは異なる。したがって、一態様では、ＡＰＩは、販売業者の住所、金額、および／またはアルトコイン支払いを完了するために必要とされる他の任意のデータを販売業者から受信する。次いで、ウォレットがブラウザまたは他のエージェントとは別個であるにせよ、ブラウザまたは他のエージェントに統合されているにせよ、ＡＰＩは、そのデータをユーザのアルトコインウォレットに提供することができる。次いで、アルトコインウォレットは、製品／サービスの代金を支払うために、販売業者住所に対するアルトコインの金額の支払いを行うことができる。トランザクションＩＤは、購入された製品に関連づけ可能である。次いで、通知は、ＡＰＩを通して販売業者に戻すように通信されることに進むことができる。ユーザは、インターフェースを通して、進捗およびバックエンドで何が起こっているかが通知可能である（「Ａｍａｚｏｎが、支払いを処理するためにお客様のビットコインウォレットにデータを送信中です」…「テレビジョンのための１．２ビットコインの支払いが確認されました」）。ユーザが複数の異なるアルトコインウォレットを有する場合、それらのアルトコインウォレットは、類似のやり方で並列に処理されることがある。すなわち、ユーザは、ビットコインで支払うべきかＬｉｔｅｃｏｉｎ（または所有する他の任意のアルトコイン）で支払うべきかを選定することが可能であることがある。どちらが選定されたかに応じて、そのそれぞれのアルトコインウォレットにアクセスするための特定の処理が、支払いのために実行される。
【０５４２】
[00612]上記の手法は、その完全に別個のブロックチェーンベースの支払いプロセスを用いてですら、ユーザが名前、住所、支払いアカウントデータなどで支払いフォームを埋める必要性を除去することによって購入プロセスを単純化する支払い要求ＡＰＩなどのＡＰＩを通しての他の標準的な形の支払いおよび支払い処理を用いて、暗号通貨の使用の統合を可能にする。
【０５４３】
[00613]この手法の例示的な方法は、購入者がアルトコインアカウントを有するという標識を受信することと、アルトコインアカウントを使用して支払いを行うためのオプションを提示することと、アルトコインを使用するために確認を受信することとを含むことができる。この方法は、品物の購入についての情報を提供するために販売業者サイトからＡＰＩを通してブラウザまたはエージェントと通信することを含む。アルトコインウォレットは、別個のアプリケーションとして構成可能である、またはブラウザまたは他のエージェントプロセスもしくは構成要素に統合可能である。アルトコインウォレットは、購入についてのデータを受信し、販売業者への支払いを処理する。ウォレットは、そのデータフィールドに、販売業者からＡＰＩを通して受信された情報をポピュレートすることができる。アルトコインウォレットは、プロトコルを通してブラウザに、またはＡＰＩを通して販売業者に戻すように、支払い詳細を通信する能力を含むことができる。販売業者サイトインターフェースは、購入を行うためにアルトコインアカウントを使用することの成功／失敗について、購入者に更新を通信することができる。データフィードは、ドルとして現在の価格設定を提供するためにアクセス可能である。品物が、買うために２０ドルである場合、購入時に、ユーザは、購入を行うためにたとえば０．０２ビットコインかかり、ユーザは現在５ビットコインを持っていることがわかることができる。実施形態は、アルトコインウォレット、ブラウザ、エージェント、スマートコントラクト、１つもしくは複数のＡＰＩの両側、および／または販売業者サイトの視点からの、本明細書において開示される処理を含むことができる。したがって、特許請求の範囲は、このプロセスにおける、任意の構成での（すなわち、アルトコインウォレットが分離する、またはブラウザに統合されるなど）、任意の構成要素に向けられ得る。最終的な目的は、アルトコインを通しての支払いを、「ワンクリック」購入がＶｉｓａタイプ支払いのためであるのと同じくらい簡単にすることである。
【０５４４】
[00614]そのような支払いのための処理はまた、スマートコントラクトの使用を通して達成され得る。スマートコントラクトは、ブロックチェーン上で実施可能であり、あるアクションを信頼できない様式で実行するプログラムである。言い換えれば、スマートコントラクトは、ブロックチェーン技術の分散手法を使用する既知の透過的な手段で、その動作を実行する。スマートコントラクトは自律的で、自給自足でき、分散化されている。スマートコントラクトは自動的に実行され、プログラムされた機能を実行する。コントラクトの一部を実行するために、ある人間を「信頼する」必要はない。一例では、スマートコントラクトは、本明細書において開示される処理のすべてまたは一部に使用可能である。たとえば、販売業者サイトのユーザインターフェースが、ユーザがアルトコインを使用して品物を買うためのオプションを提供すると仮定する。ユーザは、「支払う」ボタンを用いて購入を確認する。たとえば、金額は１ビットコインである。購入者によるその確定の指示または確認は、ブロックチェーン技術上で動作するスマートコントラクトに１ビットコインを用いて送信可能である。品物の売り手は、おそらく、製品を持っており、明日配達することができることを確認することができる。スマートコントラクトは、販売業者に１ビットコインを転送し、品物が間もなく到着するという通知を買い手に送ることができる。または、スマートコントラクトは、配達確認が発生したとき、販売業者に１ビットコインを配達するようにプログラムされてよい。ある段階において、パケットの通信および追跡は、行われた購入、返品ポリシーなどを管理するためにＡｍａｚｏｎ．ｃｏｍによって動作されるなどの、通常追跡および通知プロセスに遷移することができる。返品が行われる予定である場合、販売業者は、スマートコントラクトに１ビットコインを転送することができ、次いで、スマートコントラクトは、そのプロトコルに従って購入者への支払いを行うことができる。したがって、この点に関して、本開示は、通常の支払いアカウントと同じやり方で支払いにアルトコインを使用するワンクリック購入オプションを達成するために、販売業者サイトとの間で、ＡＰＩを通して、ブラウザ、アルトコインウォレット、スマートコントラクト、および／または他のエージェントに通信されるすべての通信、要求、応答、およびデータを包含する。アルトコインが使用される異なる手段のために、支払い要求ＡＰＩのような現在のＡＰＩは、アルトコインの代替支払い構造に対応するように修正されなければならない。ＡＰＩを拡張し、プロセスにおいて機能を実行するためにアルトコインウォレットおよび／またはスマートコントラクトの構成要素を含むことによって、購入が行われる手段の改善が、アルトコインを通して支払う能力を追加するために実施可能である。
【０５４５】
[00615]この手法のさらに別の態様は、ユーザのアルトコインウォレットへの支払いであることがある。たとえば、買い手のアドレスと販売業者アドレスとを含むことができる適切なアルトコイン構造を用いて、アルトコイン支払いは、両方の手段を流すことがある。したがって、少ない報奨がユーザに流れることがある。現在、広告が検索エンジン結果の一部としてクリックされた場合、検索エンジンは、代金が支払われる。ユーザのウォレットをプロセスに統合することは、広告主が、広告をクリックした買い手に何らかのアルトコインを支払うことを可能にすることがある。グラフィックスは、たとえば、広告をクリックして、販売業者のサイト上のコンテンツをブラウジングすることによってユーザがどれくらい多くのアルトコインを生成しているかを示すことができる。ユーザが、ナビゲーションにおいて購入が行われた状態に到達したとき、ユーザは、ブラウジングを介してユーザが作成したアルトコインを購入に適用してもよいし、それらのアルトコインを保ってもよい。購入の終わりにおけるすべてのバランスおよび調整は、スマートコントラクトへのサブミッションによることを含む任意のやり方で実施されてよい。特別料金、割り引き、報奨などは、販売の終わりに完了または最終決定されるユーザのアルトコインウォレットへのクレジットを通して提供可能である。そのようなクレジットはまた、プロセス全体を通じて自動的に作成されてもよい。したがって、ユーザが広告をクリックしたとき、アルトコインは、ブラウザ／エージェントとのアドレスの統合を通して自動的にアルトコインウォレットに転送されることがある、または、ある金額のアルトコインを転送するという約束は、存在してもよいし、ユーザがクリックスルーしてサイト上で製品を買う場合に最終的な実際の転送が発生するように提示されてもよい。転送は、ユーザが、アルトコインではなくドルまたは何らかの他の通貨を用いて買う場合にすら、発生することがある。この態様は、買い手が、サイトと、またはテキスト送信、電子メール送信、ソーシャルメディア対話などの他の手段を通して、対話するとき、どのようにして販売業者が買い手に戻すようにアルトコインを提供するかに関するすべての変形形態を包含する。ユーザが販売業者サイトまたは非販売業者サイトを好むとき、そのサイトは、ユーザのウォレットにアルトコインを送ることができる。これは、ユーザの経験を強化し、販売業者または他のサイトとより関わるようにユーザに勧める。
【０５４６】
[00616]別の態様は、ブロックチェーンを使用してブラウザＡＰＩトランザクションについての知識を記憶および維持することであることがある。ブロックチェーンは、ブロックと呼ばれる、注文された記録の連続的に成長するリストを維持する分散データベースである。各ブロックは、タイムスタンプと、以前のブロックへのリンクとを含む。設計上、ブロックチェーンは、データの修正に本質的に抵抗する−記録されると、ブロック内のデータは、遡及して変えられることはできない。ピアツーピアネットワークおよび分散タイプスタンプサーバの使用を通して、ブロックチェーンデータベースは自律的に管理される。ブロックチェーンは、「効率的に、検証可能で永続的な手段で、２つの当事者間のトランザクションを記録することができるオープンな分散元帳である。元帳自体も、自動的にトランザクションをトリガするようにプログラム可能である」。
【０５４７】
[00617]ブロックチェーンは、設計上セキュアであり、高い複雑なフォールトトレランスをもつ分散コンピューティングシステムの一例である。したがって、分散コンセンサスが、ブロックチェーンを用いて達成可能である。これは、ブロックチェーンを、本明細書において開示される購入トランザクションなどのイベントの記録に適したものにする。
【０５４８】
[00618]第１のブロックチェーンは、２００８年にＳａｔｏｓｈｉ  Ｎａｋａｍｏｔｏによって概念化され、翌年、デジタル通貨ビットコインのコア構成要素として実装され、すべてのトランザクションのための公的な元帳として役立つ。ビットコインのためのブロックチェーンの発明は、信頼される権威者または中央サーバの使用なしで二重支出問題を解決するためにビットコインを第１のデジタル通貨にした。ビットコイン設計は、他の適用例に対するインスピレーションである。
【０５４９】
[00619]たとえば、特定のブラウザを通して、特定のユーザのために行われたすべての購入のブロックチェーンレコードを作成することがある。ブロックチェーンはまた、ブラウザＡＰＩを通して利用可能である１つの支払いアカウントを使用する追跡トランザクションに絞り込まれることがある。そのため、ユーザが、利用可能なＶＩＳＡアカウントおよびＡｐｐｌｅ  Ｐａｙを有する場合、ｖｉｓａアカウントを使用するすべての支払いは、ブロックチェーン上で維持可能である。または、それは、記憶されたＡＰＩを通して行われた購入であってよい。この点に関して、ＡＰＩは、トランザクションに関連づけられたデータが、トランザクションに関連づけられた情報（名前、住所、支払いアカウント、製品、価格、提供される割り引き、注文の時間、配達の時間、支払われる税金など、それがギフトであったかどうか、返品された品物、購入の後続の履歴、Ｆａｃｅｂｏｏｋ上の広告などの購入のコンテキスト、またはＧｏｏｇｌｅ広告からの遷移など）のうちの１つまたは複数を使用することがあるように修正されることがある。そのようなブロックチェーンの構造は、他のサービスがアクセス可能であることがある。購入についての情報を利用してユーザを助ける管理システムは、そのトランザクションのためまたはそのブラウザのためのブロックチェーン内の情報に頼ることができる。Ａｍａｚｏｎ．ｃｏｍ購入などの他のトランザクションは、そのユーザまたはそのアカウントのためのブロックチェーンへの入力でもあることがある。
【０５５０】
[00620]請求項は、インターネットを介して行われた購入についての情報を受信することと、その情報を利用してブロックチェーンレコードを作成することとを包含することがある。アカウントを使用して後での購入が行われるので、ＡＰＩ、ブラウザ、ＰＷＡ、アプリ、人間などは、その情報を記録して利用可能にするために、そのブロックチェーンに追加可能である。
【０５５１】
[00621]解決されるべき問題は、ブラウザＡＰＩを使用してウェブ上で製品を買うとき、それらの購入を管理すること、購入を追跡すること、購入をキャンセルすること、パラメータ（発送モデル）を変更することなどの容易さにどのようにして近づくかということである。さまざまな購入のすべてを見ることができる１つの場所に進むための機構はない。ユーザのための各購入が、個人的であれ公的であれ、ブロックチェーンに追加される場合、各購入に基づいて継続的に構築されているブロックチェーンにインターネット上での購入を報告するためのＡＰＩまたは機構があり、次いで、本開示は、次いで個人用のそのデータにアクセスする能力も提供する。その個人のためのブロックチェーンへのアクセスは、購入のための許可の一部として付与されることがあり（Ａｐｐｌｅ  Ｐａｙのための指紋またはＶＩＳＡ購入のためのＣＶＣコード）、合意は、ユーザが、購入のブロックチェーンに追加するまたはこれにアクセスする許可を含む支払いを許可したときことを含むことができる。
【０５５２】
[00622]ユーザが、基本的に、変更を行うまたは購入を追跡するために購入履歴にアクセスしている場合、ユーザは、ユーザインターフェースを通してデータへのアクセスを許可することがあり、そのアクセスが付与されたとき、ブロックチェーンに関する情報は、Ａｍａｚｏｎ．ｃｏｍ上であるが販売業者および／またはアプリにまたがって購入された製品のリストに類似したユーザインターフェースに変換可能である。一態様では、また、ユーザは、ブロックチェーンへのアクセスを販売することがある。ユーザは、人々にブロックチェーンへのアクセスを提供することによって金を稼ぐことがある。名前および住所などの、そのケースにおける何らかの情報は、分解されることがある。データが、製品、時間、コンテキスト、および郵便番号については提供されるが、名前、住所、アカウント番号などは提供されないように、データは、匿名で提供されてよい。
【０５５３】
[00623]一態様では、販売業者サイトは、トークン化された支払いとして、または支払いアカウント番号、名前、有効期限などとして、ＡＰＩを通して支払い情報を受信する。ブロックチェーンを用いたプロセスは、その情報をどんなフォームにおいてでも使用して、現在のトランザクションのデータを追加するためにどのブロックチェーンにアクセスするべきかを識別することができる。それは、ユーザの名前またはブラウザに関連づけられた別のＩＤ番号のような何らかの他の機構を通してもアクセスされ得る。
【０５５４】
[00624]さらに、ブロックチェーンは、ユーザ識別によって識別されることがあり、したがって、複数のアカウントは、ユーザに関連づけられ、同じブロックチェーン上に記憶されることがある。シャツ、ズボン、靴のサイズ、および他の身体関係データを記憶するユーザ身体モデルなどの他のデータも、ブロックチェーン内に記憶可能である。
【０５５５】
[00625]ブロックチェーンは、ブラウザＡＰＩ購入または従来型の購入を含む他の任意の購入から構築されることがある。ユーザは、どのようにしてユーザが購入の履歴にアクセスし、これを管理することができるかと同様に、ユーザが、単一のユーザインターフェースからのそれらの購入のすべてにアクセスすることができるように、使用するさまざまなアカウントを使用した各購入に、ブロックチェーンサービスに報告させるサービスを契約することがある。ブロックチェーンサービスは、オンラインであるにせよ、Ａｍａｚｏｎ．ｃｏｍにおいてであるにせよ、ブラウザＡＰＩを通してなどであるにせよ、ユーザが購入を行うときはいつでも、企業が対話するＡＰＩを用いて確立可能である。パラメータは、購入に関連づけられた詳細のあるセットがブロックチェーンサービスＡＰＩに通信されるように支払いアカウントまたはユーザアカウントに関連づけられて設定されてよい。したがって、ある人が、記憶されたＶＩＳＡアカウントを使用してＡｍａｚｏｎ．ｃｏｍ上で本を購入した場合、購入された本の詳細は、その購入のためにブロックを作成するブロックチェーンサービスプロバイダにＡＰＩを通して通信可能である。次に、その人は、ＶＩＳＡカードを使用してＨｏｍｅ  Ｄｅｐｏｔにおいてハンマーを買う。パラメータが設定されているので、ハンマーの購入、時間、ロケーションなどのうちの１つまたは複数を含む購入の詳細は、ＡＰＩを介してサービスに通信可能であり、その購入は、ブロックチェーンに追加可能である。次に、質問は、どのようにしてユーザがそれらの購入すべてのデータへのアクセスを得るか？である。ユーザが、戻って本を返品することを望むことがある。人々が、異なる販売業者および異なる支払い手法にまたがって購入を行っている場合（ショッピングカートを使用する販売業者もいれば、ブラウザＡＰＩ、Ａｍａｚｏｎ．ｃｏｍ、直接などを使用する販売業者もいる）、ユーザは、購入のすべてを１つのロケーションにおいての管理に利用可能にさせることを要望する。ブロックチェーンサービスは、購入履歴およびステータスをユーザに提示する管理ユーザインターフェースを提案することができる。ブロックチェーンサービスはまた、追跡ステータスを特定の製品と関連づけ、ブロックチェーン上で更新されたデータを含むことができるＡＰＩを通して、配達エンティティ（ＦｅｄＥＸ、ＵＰＳなど）から追跡情報を受信することができる。したがって、この点に関して、ブロックチェーンは、継続的に更新可能である。ブロックチェーンサービスは、ユーザインターフェースを介して情報を提示することができる。ユーザインターフェースへのアクセスは、ウェブサイトを介して、アプリを介して、ブラウザＡＰＩインターフェースを介して、ソーシャルメディアを介して選択可能なオブジェクトもしくは選択可能なメニューを介して、デジタルウォレットインターフェース内で、またはＡｐｐｌｅ  ＰａｙインターフェースもしくはＡｎｄｒｏｉｄ  ｐａｙインターフェース内などで、可能である。言い換えれば、ユーザが「いる」任意の仮想ロケーションにおいて、購入管理インターフェースへのユーザアクセスを可能にする選択可能なオブジェクトが提示可能である。��択可能なオブジェクトは、ブラウザ内のオプションを含むユーザに利用可能な複数のロケーションにおいても提示可能である。たとえば、Ａｍａｚｏｎ  Ａｓｓｉｓｔａｎｔまたはブラウザへの別のプラグインにおいて、サービスは、以前の購入およびそのステータスの更新されたリストを提供することができる。このステータス更新のための基礎となるデータは、ブロックチェーンに基づくことができる。
【０５５６】
[00626]さらに、支払いアカウント、住所などの、ブラウザ内に記憶可能である情報は、ブロックチェーン上に記憶され、ブラウザからアクセス可能である。別個のＡＰＩは、ブロックチェーンに関するその情報を記憶し、支払いアカウントデータ、トークン、住所情報、名前などを返すサービスに呼び出されることもある。したがって、ブラウザではなく、ブロックチェーンが情報を保持することがあり、ブラウザが、支払い情報および／または購入に関連づけられた他の情報のためのＡＰＩ要求を受信すると、ブラウザは、必要な情報にブロックチェーンからアクセスすることができる。これは、いくつかのステップにおいても発生することができる。さらに、販売業者サイトは、ブラウザ機能を通してではなく、ＡＰＩを通してブロックチェーンに直接的に、ブロックチェーンからの情報にもアクセスすることもある。
【０５５７】
[00627]この手法を使用して、個人が、支払い情報、住所などを１つのブロックチェーン内に記憶することがあり、その支払い情報を必要とした任意のサイトは、適切なＡＰＩを通して、それにセキュアにアクセスすることができる。デバイス上のデジタルウォレットは、情報をもつブロックチェーンにアクセスする機構であってよい。ブラウザ（「ブラウザ」が使用されるときはいつでも、「ブラウザ」は、ユーザインターフェースまたは販売業者のためのエージェントも包含することができる）は、ＡＰＩ要求を受信すると、ｖｉｓａアカウントをブラウザ内に記憶させるのではなく、ブロックチェーンデジタルウォレット（またはアクセスエージェント）が情報を取得するために使用可能であることを識別することができる。ブラウザは、ブロックチェーンから情報を取り出し、それをブラウザに返すために、アクセスエージェントと通信する。ブラウザは、支払い処理のために販売業者サイトにブラウザＡＰＩを通して情報を通信する。
【０５５８】
[00628]本明細書において開示されるＡＰＩに関連する暗号通貨または元帳技術は、ブラウザを介して支払いデータを許可する方法を含むことができる。特許請求の範囲は、ブラウザの動作、システムデバイス／クライアントデバイスおよび動作、販売業者サイトの動作、暗号通貨支払いを提供するデジタルウォレットまたは支払いサービスの観点からの動作などを対象とすることができる。
【０５５９】
[00629]例示的な方法は、サイトから、ブラウザにおいて、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信することであって、この要求は、サイトによって受け付けられる暗号通貨支払い方法の識別を含む、受信することと、サイトに、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ブラウザのユーザが、サイトによって受け付けられる暗号通貨支払い方法を介して潜在的な購入の支払いをすることができることを示すデータを送信することと、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、暗号通貨支払い方法を使用して潜在的な購入が行われることが許可された支払いデータを受信することとを含む。方法は、暗号通貨ウォレットが支払いを行うことを可能にするために、許可された支払いデータを暗号通貨ウォレットにポピュレートすることと、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、暗号通貨ウォレットを開始することとをさらに含むことができる。
【０５６０】
[00630]許可された支払いデータは、支払いを受信するためのサイトアドレス、買い手の秘密鍵、受信者の公開鍵、電子メールアドレス、受信者識別情報、支払い額、およびユーザコメントのうちの少なくとも１つを含む暗号通貨支払い情報によることができる。暗号通貨ウォレットは、ブラウザを実行しているデバイス上にローカルに記憶されたウォレットおよびウェブベースのウォレットのうちの少なくとも１つを含むことができる。
【０５６１】
[00631]暗号通貨ウォレットがウェブベースのウォレットであるとき、方法は、支払いを処理するためのアプリケーションプログラミングインターフェースを介してウェブベースのウォレットに許可された支払いデータを送信することをさらに含むことができる。要求は、暗号通貨支払い方法に加えて、サイトによって使用されるサポートされた支払い方法を識別することができる。許可された支払いデータは、暗号通貨ウォレットを用いてトランザクションを署名するために使用される秘密鍵を含むことができる。方法は、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払いを受信するためにサイト暗号通貨ウォレットによる使用のためにサイトにデータを送信することも含むことができる。許可された支払いデータは、ブラウザにおいて記憶可能である、別個のエンティティからブラウザによってアクセス可能である、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介してサイトから受信可能である、サードパーティから受信可能である、またはブラウザによって指示されるサードパーティからサイトに配達可能である。
【０５６２】
[00632]暗号通貨支払い方法が、購入のためにユーザによって選択されるとき、方法は、支払いを確認するためのユーザによる使用のために支払い対話インターフェースと暗号通貨ウォレットインターフェースを混合するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して混合されたユーザインターフェースを生成することをさらに含むことができる。
【０５６３】
[00633]別の例では、方法は、サイトから、ブラウザに、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することであって、この要求は、サイトによって受け付けられる暗号通貨支払い方法の識別を含む、送信することと、サイトにおいて、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ブラウザのユーザが、サイトによって受け付けられる暗号通貨支払い方法を介して潜在的な購入の支払いをすることができることを示すデータを受信することと、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して暗号通貨支払い方法を使用して潜在的な購入を処理するためのユーザからの確認に基づいて、暗号通貨支払い方法を使用して支払いを受信することとを含むことができる。
【０５６４】
[00634]方法は、暗号通貨ウォレットからサイト暗号通貨ウォレットにおいて支払いを受信することであって、許可された支払いデータが、支払いを開始するために暗号通貨ウォレットをポピュレートする際に使用される、受信することをさらに含むことができる。許可された支払いデータは、サイト暗号通貨ウォレットを識別するデータおよび量のうちの少なくとも１つを含むことができる。
【０５６５】
[00635]暗号通貨ウォレットは、ブラウザを動作させるデバイスおよびこのデバイスとは別個のウェブベースのデバイスのうちの１つの上に記憶可能である。
【０５６６】
[00636]システム例は、プロセッサと、プロセッサによって遂行されるとき、プロセッサに、サイトから、ブラウザにおいて、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信することであって、この要求は、サイトによって受け付けられる暗号通貨支払い方法の識別を含む、受信することと、サイトに、ブラウザから、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ブラウザのユーザが、サイトによって受け付けられる暗号通貨支払い方法を介して潜在的な購入の支払いをすることができることを示すデータを送信することと、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入のための許可された支払いデータを受信することとを含む動作を実行させる命令を記憶するコンピュータ可読記憶媒体とを含む。
【０５６７】
[00637]許可された支払いデータは、支払いを受信するためのサイトアドレス、買い手の秘密鍵、受信者の公開鍵、電子メールアドレス、受信者識別情報、支払い額、およびユーザコメントのうちの少なくとも１つを含むことができる。許可された支払いデータに関連づけられた暗号通貨ウォレットは、ブラウザを実行しているデバイス上でローカルに記憶されたウォレットおよびウェブベースのウォレットのうちの少なくとも１つを含むことができる。
【０５６８】
[00638]暗号通貨支払い方法が、購入のためにユーザによって選択されるとき、コンピュータ可読記憶媒体は、プロセッサによって遂行されるとき、プロセッサに、支払いを確認するためにユーザによる使用のために支払い対話インターフェースと暗号通貨ウォレットインターフェースを混合するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、混合されたユーザインターフェースを生成することをさらに含む動作を実行させる追加の命令を記憶することができる。コンピュータ可読記憶媒体は、プロセッサによって遂行されるとき、プロセッサに、支払いを処理するためのアプリケーションプログラミングインターフェースを介して暗号通貨ウォレットに許可された支払いデータを送信すること、またはブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払いを受信するためにサイト暗号通貨ウォレットによる使用のためにサイトにデータを送信することをさらに含む動作を実行させる追加の命令を記憶することができる。
【０５６９】
[00639]支払いを処理する別の例示的な方法では、方法は、暗号通貨ウォレットにおいて、購入に関連づけられた許可された支払い情報を受信することと、ここにおいて、この許可された支払い情報は、サイトから、ブラウザにおいて、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ブラウザが潜在的な購入に関連づけられた要求を受信したことに基づいて、生成され、ここにおいて、この要求は、サイトによって受け付けられる暗号通貨支払い方法の識別を含む、暗号通貨ウォレットから暗号通貨を使用して、許可された支払い情報に基づいて、支払いを処理することと、暗号通貨を使用した支払いの処理に関連づけられた確認データをブラウザに送信することとを含むことができる。
【０５７０】
[00640]支払いを処理するための例示的なシステムは、プロセッサと、プロセッサによって遂行されるとき、プロセッサに、暗号通貨ウォレットにおいて、購入に関連づけられた許可された支払い情報を受信することであって、この許可された支払い情報は、サイトから、ブラウザにおいて、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、ブラウザが潜在的な購入に関連づけられた要求を受信したことに基づいて、生成され、この要求は、サイトによって受け付けられる暗号通貨支払い方法の識別を含むことができる、受信することと、暗号通貨ウォレットから暗号通貨を使用して、許可された支払い情報に基づいて、支払いを処理することと、暗号通貨を使用した購入の処理に関連づけられた確認データをブラウザに送信することとを含む動作を実行させる命令を記憶するコンピュータ可読記憶媒体とを含む。
【０５７１】
[00641]別の例示的な方法は、支払いを受信する方法であって、サイトから、ブラウザに、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することであって、この要求は、サイトによって受け付けられる支払い方法の識別を含むことができ、この支払い方法は暗号通貨を使用する、送信することと、サイトにおいて、支払い方法による支払いを受信することであって、支払い方法は、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して送信された要求に基づいて開始された暗号通貨支払いプロセスにより暗号通貨を使用する、受信することとを含む方法を含む。暗号通貨支払いプロセスは、第１の通貨を第２の通貨へと変換することも含むことができる。
【０５７２】
[00642]暗号通貨支払いプロセスは、買い手が、第１の通貨を使用して売り手から品物を購入することと、売り手が第２の通貨で支払われることを可能にすることができ、暗号通貨は、第１の通貨と第２の通貨との間の変換を橋渡しするために使用される。
【０５７３】
[00643]別のシステム例は、支払いを処理するためのシステムを含む。システムは、プロセッサと、プロセッサによって遂行されるとき、プロセッサに、サイトから、ブラウザに、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することであって、この要求は、サイトによって受け付けられる支払い方法の識別を備え、この支払い方法は暗号通貨を使用する、送信することと、サイトにおいて、支払い方法による支払いを受信することであって、支払い方法は、ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して送信された要求に基づいて開始された暗号通貨支払いプロセスにより暗号通貨を使用する、受信することとを含む動作を実行させる命令を記憶するコンピュータ可読記憶媒体を含むことができる。
【０５７４】
[00644]暗号通貨支払いプロセスは、買い手が、第１の通貨を使用して売り手から品物を購入することと、売り手が第２の通貨で支払われることを可能にすることができ、ここにおいて、暗号通貨は、第１の通貨と第２の通貨との間の変換を橋渡しするために使用される。
【０５７５】
[00645]支払いサービスを動作させる方法は、支払いサービスにおいて、購入に関連づけられた許可された支払い情報を受信することであって、この許可された支払い情報は、ブラウザが、サイトから、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信したことに基づいて、生成され、この要求は、少なくとも一部は暗号通貨を利用する支払いプロセスの識別を含むことができる、受信することと、暗号通貨を使用して、許可された支払い情報に基づいて支払いを処理することと、暗号通貨を使用した支払いの処理に関連づけられた確認データをブラウザに送信することも含むことができる。
【０５７６】
[00646]例示的な支払いサービスは、プロセッサと、プロセッサによって遂行されるとき、プロセッサに、購入に関連づけられた許可された支払い情報を受信することであって、この許可された支払い情報は、ブラウザが、サイトから、ブラウザにおいて、サイトとブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信したことに基づいて生成され、この要求は、少なくとも一部は暗号通貨を利用する支払いプロセスの識別を含むことができる、受信することと、暗号通貨を使用して、許可された支払い情報に基づいて支払いを処理することと、暗号通貨を使用した支払いの処理に関連づけられた確認データをブラウザに送信することとを含む動作を実行させる命令を記憶するコンピュータ可読記憶媒体とを含む。
【０５７７】
[00647]支払いを処理することは、第１の通貨を暗号通貨へと変換することをさらに含むことができる。支払いを処理することは、売り手に支払うために、買い手から受信された第１の通貨を暗号通貨へと変換することと、暗号通貨を第２の通貨へと変換することとをさらに含むことができる。
【０５７８】
[00648]別の例示的な方法は、サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザにおいて、ブラウザとサイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、購入に関連づけられた支払い要求を受信することと、ユーザから、第１のアプリケーションプログラミングインターフェースを介して、サイトによってサポートされる支払い方法の選択肢を受信することであって、支払い方法は、少なくとも一部は暗号通貨を利用し、支払いトランザクションは、少なくとも一部は支払いサービスによって管理される、受信することと、支払い要求および支払い方法の選択肢に応答して、ブラウザから、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して、支払いサービスに支払い要求イベントを通信することであって、この支払い要求イベントは、少なくとも一部は暗号通貨を利用して支払いを取り扱うために支払いサービスによる使用のためのデータを備える、通信することとを含む。
【０５７９】
[00649]支払い要求は、購入についての情報と、サイトによってサポートされる支払い方法の選択肢のセットとを含むことができる。支払いサービスによって管理される支払いプロセスは、暗号通貨で支払いを行うことができる。
【０５８０】
[00650]支払いサービスによって管理される支払いプロセスは、（１）第１の通貨から暗号通貨へと変換すること、および（２）暗号通貨から第２の通貨へと変換すること、のうちの少なくとも１つを実行することによって、支払いを行うこともできる。
【０５８１】
[00651]支払いサービスによって管理される支払いプロセスは、買い手によって提供される第１の通貨から暗号通貨へと変換し、暗号通貨から、売り手によって受け付けられる第２の通貨へと変換することによって、支払いを行うことができる。第１の通貨は、第１の法定通貨および第１の暗号通貨のうちの１つを含むことができ、ここにおいて、第２の通貨は、第２の法定通貨および第２の暗号通貨のうちの１つを含むことができる。
【０５８２】
[00652]例示的なシステムは、プロセッサと、プロセッサによって遂行されるとき、プロセッサに、サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザにおいて、ブラウザとサイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、購入に関連づけられた支払い要求を受信することと、ユーザから、第１のアプリケーションプログラミングインターフェースを介して、サイトによってサポートされる支払い方法の選択肢を受信することであって、支払い方法は少なくとも一部は暗号通貨を利用し、支払いトランザクションは、少なくとも一部は支払いサービスによって管理される、受信することと、支払い要求および支払い方法の選択肢に応答して、ブラウザから、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して、支払いサービスに支払い要求イベントを通信することであって、この支払い要求イベントは、少なくとも一部は暗号通貨を利用して支払いを取り扱うために支払いサービスによる使用のためのデータを備える、通信することとを含む動作を実行させる命令を記憶するコンピュータ可読記憶媒体とを含む。
【０５８３】
[00653]支払い要求は、購入についての情報と、サイトによってサポートされる支払い方法の選択肢のセットとを含むことができる。支払いサービスによって管理される支払いトランザクションは、暗号通貨で支払いを行うことができる。支払いサービスによって管理される支払いトランザクションは、（１）第１の通貨から暗号通貨へと変換すること、および（２）暗号通貨から第２の通貨へと変換すること、のうちの少なくとも１つを実行することによって、支払いを行うことができる。支払いサービスによって管理される支払いプロセスは、買い手によって提供される第１の通貨から暗号通貨へと変換し、暗号通貨から、売り手によって受け付けられる第２の通貨へと変換することによって、支払いを行うことができる。第１の通貨は、第１の法定通貨および第１の暗号通貨のうちの１つを含むことができ、ここにおいて、第２の通貨は、第２の法定通貨および第２の暗号通貨のうちの１つを含むことができる。
【０５８４】
[00654]別の方法例は、支払いサービスにおいて支払い要求イベントを受信することを含み、支払いサービスにおいて支払い要求イベントを受信することは、ブラウザが、ブラウザとサイトとの間のデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、製品の購入に関連づけられた支払いデータのためにサイトから支払い要求を受信することであって、この支払い要求は、製品を購入する要望を示すユーザからの入力に基づいており、購入についての情報を含むことができる、受信することと、ユーザから、第１のアプリケーションプログラミングインターフェースを介して、支払いサービスの選択肢を受信することであって、支払い要求イベントは、ブラウザから、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して受信される、受信することに基づく。方法は、支払いサービスにおいて、少なくとも一部は暗号通貨の使用を備える支払いプロセスを開始するために支払い要求イベントを処理することを含む。
【０５８５】
[00655]方法は、ブラウザに、支払いサービスから、第２のアプリケーションプログラミングインターフェースを介して、許可された支払い情報を送信することであって、ブラウザは、第１のアプリケーションプログラミングインターフェースを介して許可された支払い情報をサイトに通信する、送信することをさらに含むことができる。支払い要求は、購入についての情報と、サイトによってサポートされる支払い方法の選択肢のセットとを含むことができる。支払いサービスによって管理される支払いプロセスは、暗号通貨で支払いを行うことができる。支払いサービスによって管理される支払いプロセスは、（１）第１の通貨から暗号通貨へと変換すること、および（２）暗号通貨から第２の通貨へと変換すること、のうちの少なくとも１つを実行することによって、支払いを行うこともできる。支払いサービスによって管理される支払いプロセスは、買い手によって提供される第１の通貨から暗号通貨へと変換し、暗号通貨から、売り手によって受け付けられる第２の通貨へと変換することによって、支払いを行うことができる。第１の通貨は、第１の法定通貨および第１の暗号通貨のうちの１つを含むことができ、ここにおいて、第２の通貨は、第２の法定通貨および第２の暗号通貨のうちの１つを含むことができる。
【０５８６】
[00656]別の例示的なシステムは、支払いサービスを包含する。この点に関して、支払いサービスは、プロセッサと、プロセッサによって遂行されるとき、プロセッサに、支払い要求イベントを受信することを含む動作を実行させる命令を記憶するコンピュータ可読記憶媒体とを含み、支払い要求イベントを受信することは、ブラウザが、ブラウザとサイトとの間のデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、製品の購入に関連づけられた支払いデータのためにサイトから支払い要求を受信することであって、この支払い要求は、製品を購入する要望を示すユーザからの入力に基づいており、購入についての情報を含むことができる、受信することと、ユーザから、第１のアプリケーションプログラミングインターフェースを介して、支払いサービスの選択肢を受信することであって、支払い要求イベントは、ブラウザから、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して受信される、受信することに基づく。方法は、支払いサービスにおいて、少なくとも一部は暗号通貨の使用を備える支払いプロセスを開始するために支払い要求イベントを処理することを含む。
【０５８７】
[00657]支払い要求は、購入についての情報と、サイトによってサポートされる支払い方法の選択肢のセットとを含む。支払いサービスによって使用される支払いプロセスは、暗号通貨で支払いを行うことができる。支払いサービスによって使用される支払いプロセスは、（１）第１の通貨から暗号通貨へと変換すること、および（２）暗号通貨から第２の通貨へと変換すること、のうちの少なくとも１つを実行することによって、支払いを行うことができる。
【０５８８】
[00658]支払いサービスによって使用される支払いプロセスは、買い手によって提供される第１の通貨から暗号通貨へと変換し、暗号通貨から、売り手によって受け付けられる第２の通貨へと変換することによって、支払いを行うことができる。第１の通貨は、第１の法定通貨および第１の暗号通貨のうちの１つを含むことができ、ここにおいて、第２の通貨は、第２の法定通貨および第２の暗号通貨のうちの１つを含むことができる。
【０５８９】
[00659]別の方法例は、サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザにおいて、ブラウザとサイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、購入に関連づけられた支払い要求を送信することと、第１のアプリケーションプログラミングインターフェースを介して、サイトによってサポートされる支払い方法の選択肢を送信することであって、支払い方法は、少なくとも一部は暗号通貨を利用し、支払いトランザクションは、支払いサービスによって少なくとも一部は管理され、支払い要求および支払い方法の選択肢に応答して、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースは、支払いサービスに支払い要求イベントを通信し、支払い要求イベントは、少なくとも一部は暗号通貨を利用する支払いプロセスを介して支払いを取り扱うために支払いサービスによる使用のためのデータを備える、送信することと、支払いプロセスを介して支払いを受信することとを含む。
【０５９０】
[00660]別の例示的なシステムは、プロセッサと、プロセッサによって遂行されるとき、プロセッサに、サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザに、ブラウザとサイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、購入に関連づけられた支払い要求を送信することと、第１のアプリケーションプログラミングインターフェースを介して、サイトによってサポートされる支払い方法の選択肢を送信することであって、支払い方法は、少なくとも一部は暗号通貨を利用し、支払いトランザクションは、支払いサービスによって少なくとも一部は管理され、支払い要求および支払い方法の選択肢に応答して、ブラウザと支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースは、支払いサービスに支払い要求イベントを通信し、支払い要求イベントは、少なくとも一部は暗号通貨を利用する支払いプロセスに従って支払いを取り扱うために支払いサービスによる使用のためのデータを備える、送信することと、少なくとも一部は暗号通貨を利用する支払いプロセスを介して支払いを受信することとを含む動作を実行させる命令を記憶するコンピュータ可読記憶媒体とを含むことができる。
【０５９１】
[00661]上記で説明された任意の例示的なシステムまたは方法に関連づけられた任意の特徴は、他の任意の例示的なシステムまたは方法に適用可能である。
【０５９２】
動的な買うボタン
[00662]上記の動的なオブジェクトまたは動的なボタンの概念は、上記で検討されている。動的なボタンまたは二重目的ボタンの概念が提供可能である。この概念は、第１のブラウザタイプに関連づけ可能である第１のアカウントをもつ１人のユーザが製品を購入するために販売業者サイトにナビゲートするシナリオに対処する。販売業者サイトは、ブラウザタイプ、ブラウザ特性、支払い要求ＡＰＩタイプ、および／またはそのユーザのためのアカウントタイプのうちの１つまたは複数を検出し、対応する動的な買うボタンを提示するようにプログラム可能である。したがって、ユーザに提示される買うボタンは、これらの要因のうちの１つまたは複数に調節可能である。第２のユーザが、第２のブラウザタイプを使用して、または第２のアカウントタイプを使用して、または何らかの他の要因に基づいて、同じ販売業者サイトにナビゲートする場合、販売業者サイトは、買うボタンが特性のために調節可能であるように、そのユーザに提示されるオブジェクトを動的に適合させることができる。この手法の利益は、各ユーザが、ユーザがなじみの深い、ウェブサイトにまたがるブランディングまたは一貫した経験に関して信頼する、認識可能で、個人化され、動的に修正されるまたは動的に提示される買うボタンを有することができることである。以下の検討は、支払い要求ＡＰＩを使用し動的な買うボタンを提供するコンテキストにおいてクリックを減少させることに関連するいくつかの概念に関する。
【０５９３】
[00663]本明細書において開示される概念は、ブラウザ支払い要求ＡＰＩのコンテキストにおいてクリックをどのようにして減少させるかに関する。現在のプロセスは、ユーザがｍｅｒｃｈａｎｔ．ｃｏｍウェブサイト（任意のサイト、またはアプリ）上におり、ショッピングカートボタンに追加された「買う」ボタンをクリックする、または購入を開始するために音声のような何らかの他の入力を与えることである。ｍｅｒｃｈａｎｔ．ｃｏｍサイトは、サイトによって受け付けられる支払い方法とユーザに利用可能である支払い方法を協調させるためにサイトが閲覧されているブラウザと通信する。ビットコインおよびＶｉｓａが、ユーザと販売業者の両方に利用可能であると仮定しよう。ブラウザＡＰＩは、支払い方法の重複が決定されると、ユーザがビットコインまたはＶｉｓａを選定することができるインターフェース（または話す、または他のモダリティ）を提示する。鍵は、この段階において、ユーザが、どのようにし、支払い方法を選定することと支払いプロセスを開始することの両方を行うためにワンクリックまたは１つのコマンドを行うだけでよいことができるかである。これをするためのいくつかの手段がある。１つは、ユーザが使用することを望む支払いタイプと協調させられる動的なボタンまたは二重目的ボタンとすることがある。
【０５９４】
[00664]ブラウザＡＰＩは、ユーザが支払いプロセスを選定することとそれを開始することの両方を行うことができる二重目的ボタンを提示するようにプログラム可能である。ボタンは、動的であってもよく、ユーザが使用している支払いタイプまたはブラウザタイプに調節されてよい。ビットコインまたは任意の暗号通貨支払い方法のために、ユーザは、方法の選択を受け付け、ならびに「支払う」ボタンを再クリックする必要なしに支払いプロセスを開始する、ＡＰＩインターフェース内のビットコインオブジェクトをクリックすることができる。ＡＰＩは、「選定して支払う」ボタンのクリックに基づいて、ｍｅｒｃｈａｎｔ．ｃｏｍとブラウザと買い手ウォレットとの間のデータの通信を開始する。たとえば、ＡＰＩインターフェース内のビットコインをクリックした後、ＡＰＩは、ｍｅｒｃｈａｎｔ．ｃｏｍウォレットを識別するために公開鍵またはデータをｍｅｒｃｈａｎｔ．ｃｏｍサイトに要求することができる。これは、公開鍵、トランザクションＩＤ、サイトにおけるユーザ検索履歴、ソーシャルメディアデータ、動的な公開鍵データ、または他の任意のデータを含むデータのパッケージであってよい。しかしながら、データ内に含まれるのは、ｍｅｒｃｈａｎｔ．ｃｏｍウォレットの識別であるべきである。そのデータは、暗号通貨での購入の額、および他の任意のデータとともに、買い物ウォレットに通信可能である。暗号通貨ウォレットは、ウォレットを開く、データをポピュレートする、トランザクションを開始するなどのプロセスが、カバーの下で、ブラウザＡＰＩインターフェースからの暗号通貨のユーザ選択に自動的に基づいて実行されるように、ブラウザＡＰＩからデータおよび機能命令を受信するようにプログラムされる。
【０５９５】
[00665]ブラウザＡＰＩインターフェース内の、選定して開始するボタンを可能にする１つの手段は、インターフェースの外部の単なるボタンではなく、指紋を読み取ることが可能であるユーザインターフェースを作成することである。インターフェース全体またはインターフェースの選択された部分が、購入を確認するために指紋を読み取ることが可能である場合、「ビットコインを選定して支払う」ボタンが、ユーザインターフェースが、ユーザの識別を確認し、同じ対話をもつ支払いプロセスを開始するために、ビットコインを選択する指押しの指紋を読み取る間、その指押しを受信することができる。ユーザインターフェースの外部にある指紋読み取り装置も、ユーザが、支払い方法を選定することとセキュリティのレベルを用いて買い手を確認することの両方を行うために指紋を用いて「ビットコイン」または「Ａｐｐｌｅ  Ｐａｙ」をクリックするだけでよいように、ユーザがそのボタンを見ることができるグラフィカル構成要素を有することができる。指紋検知構成要素のロケーションは、ユーザによって選択されることになるオブジェクトのロケーションに基づいて、タッチスクリーン上でのロケーションが変化することができる。
【０５９６】
[00666]顔認識も、支払い方法の選択に関連して使用されることがある。ユーザは、ビットコインを選択し、または言い、次いで、顔認識ステップのためにインターフェースを単に見ることがあり、次いで、本明細書において開示される機能を確認して実行する。
【０５９７】
[00667]一態様では、グラフィカルディスプレイの領域のみが、指紋読み取り装置を含むことがある。このケースでは、グラフィカルインターフェースのプレゼンテーションは、「選定して支払う」オブジェクトが指紋読み取り装置領域上に提示可能であるように、指紋読み取り装置と協調可能である。グラフィカルディスプレイは、ユーザが、グラフィカルインターフェース上でビットコインまたはＡｐｐｌｅ  Ｐａｙのどちらかを選ぶためのオプションが与えられた場合、指で触れることにより選ばれたどちらか一方はまた、指紋を読み取らせ、支払い処理のためにユーザ識別を確認させるように、いくつかの領域を含むことができる。この領域は、買うボタンの位置に基づいて、タッチセンシティブスクリーン上の異なるロケーションに変化または移動することができる。
【０５９８】
[00668]別の態様では、ある企業が、他の当事者が使用しない通貨または暗号通貨で支払うことを望むことがある。受け付けられる支払い方法の間に重複がないシナリオであることがある。両方の当事者がサービスと契約されている場合、支払いが異なる通貨であっても、ＡＰＩを通して支払いを協調させることができるサービスが提供されることがある。たとえば、買い手はドルで支払うことを望むことがあるが、売り手は、ドルで支払われることを望まない可能性があり、または暗号通貨ウォレットのみを有することがある。サービスは、支払人が、ＡＰＩを通した支払いのためにたとえばＶＩＳＡを受け付けることができるが、支払いは、ＶＩＳＡからビットコインに支払いを変換し、次いでビットコインで売り手または販売業者に支払うサービスプロバイダに進む、支払い要求ＡＰＩトランザクションのための支払い方法オプションとして提供されることがある。１つのシナリオでは、両方の当事者は、この手法と契約される必要はなく、おそらく、一方の当事者のみが、この手法と契約される必要がある。このシナリオでは、販売業者がビットコインのみを受け付け、サービスに登録されている場合、販売業者サイトは、以下の機能を提供するようにプログラム可能である。
【０５９９】
[00669]販売業者がビットコインを受け付け、買い手は、Ｖｉｓａ、Ｍａｓｔｅｒｃａｒｄ、またはＰａｙＰａｌで支払うことができると仮定する。サービスは、Ｖｉｓａ支払い方法およびＭａｓｔｅｒｃａｒｄ支払い方法を受信するようにセットアップされていると仮定する。販売業者サイトは、ＶｉｓａまたはＭａｓｔｅｒｃａｒｄ（またはビットコイン）を受信することができる支払い要求ＡＰＩを介して提示するようにプログラム可能である。これは、ＡＰＩを通じたプロキシ通知に似ている。次いで、手法は、ＡＰＩが、買い手と売り手の両方のために機能する支払い方法を協調させることを可能にする。販売業者サイトがＶｉｓａおよびＭａｓｔｅｒｃａｒｄを提示するので、買い手は、支払いのためにＶｉｓａを選択し、支払いを確認することができる。ボタンは、これらのアカウントタイプに基づいて動的に変化することができる。支払いは、サイトに、またはサービスプロバイダに行われ得、サービスプロバイダは、次いで、支払いをビットコインに変換し、ビットコインを販売業者ウォレットに転送する。買い手は、最終的な支払いはビットコインであるということを考えないことがあるが、支払いプロセスが本質的に「ワンクリック」である限り、気にするべきでない。
【０６００】
[00670]たとえば、サイトが、トランザクションのための支払いデータとともにＡＰＩを介してトークンを受信することがある。サイトは、ＶＩＳＡ支払いまたはクレジットカード支払いを受け付けないので、支払いを処理して元の通貨からの異なる通貨をサイトに返すサービスプロバイダにトークンをフォワーディングすることができる。したがって、ｖｉｓａ支払いが処理可能であり、ビットコインは返され得る。この処理は、販売業者サイトにおいて、または別個のサービスプロバイダによって、全部または一部が行われ得る。販売業者がビットコインを受け付け、買い手がビットコインで支払うことができる上記のシナリオでは、プロキシプレゼンテーションまたはサービスプロバイダがドルをビットコインに変換する必要はない。トランザクションは、標準的なやり方で発生することができる。しかしながら、当事者に関する通貨合致がない場合、支払いが受信され、売り手に許容できる新しい通貨に変換されて、次いで売り手に送信または提供されることができるように、買い手のために機能する支払い方法で支払いが行われることを可能にするＡＰＩを介してプロキシプレゼンテーションを通して当事者の一方または両方のために通貨変換が発生することができるプロキシ手法が、利用可能である。プロセスは、トークンと同様にＡＰＩを通してではなくＵＲＬにより識別されるロケーションまたはネットワークベースの支払いプロセッサに買い手の支払いが送信されるべきであるという命令を、ＡＰＩを通して含むことがある。任意のレールは、データ、トークン、公開／秘密鍵などを送信するために使用されることがある。
【０６０１】
[00671]図３７は、買うボタンを動的に修正することに関するこの方法の一態様を示す。方法は、サイトにおいて、ブラウザを介してサイトにアクセスするユーザが、（１）第１のブラウザもしくは第２のブラウザのうちの１つを使用しているか、または（２）決定をもたらすために第１のアカウントもしくは第２のアカウントを使用して購入を行うことができるかを決定する（３７０２）ことを含む。決定が、ユーザが、第１のブラウザを使用しているまたは第１のアカウントを使用して購入を行うことができるのどちらかであることを示すとき、方法は、第１のアカウントに関連づけられた動的に修正された第１の買うボタンを提示する（３７０４）ことと、第１のブラウザに、サイトと第１のブラウザとの間で購入についての情報を通信するためのプロトコルを定義する第１のブラウザアプリケーションプログラミングインターフェースを介して、ユーザのためにサイトからの購入に関連づけられた第１の情報を有する第１の支払い要求を送信する（３７０６）ことと、第１のブラウザから、第１のブラウザアプリケーションプログラミングインターフェースを介して、第１のアカウントに関連づけられた第１のデータを受信する（３７０８）ことであって、この第１のデータは、購入を処理することに関連づけられる、受信する（３７０８）ことを含む。データは、支払いサービスがデータを処理したという確認とすることができる、またはサイトが購入を処理するもしくは支払いプロセッサにデータをサブミットするトークンもしくはアカウントデータとすることができる。データは、非通貨データであるが、価値のあるものとすることができる。
【０６０２】
[00672]決定が、ユーザが、第２のブラウザを使用しているまたは第２のアカウントを使用して購入を行うことができるのどちらかであることを示すとき、方法は、第２のアカウントに関連づけられた動的に修正された第２の買うボタンを提示する（３７１０）ことと、第２のブラウザに、サイトと第２のブラウザとの間で購入についての情報を通信するためのプロトコルを定義する第２のブラウザアプリケーションプログラミングインターフェースを介して、ユーザのためにサイトからの購入に関連づけられた第２の情報を有する第２の支払い要求を送信する（３７１２）ことと、第２のブラウザから、第２のブラウザアプリケーションプログラミングインターフェースを介して、第２のアカウントに関連づけられた第２のデータを受信する（３７１４）ことであって、この第２のデータは、購入を処理することに関連づけられる、受信する（３７１４）ことを含む。
【０６０３】
[00673]第１のブラウザと第２のブラウザは異なるブラウザタイプとすることができ、第１のブラウザは、第１のデバイス上で動作することができ、第２のブラウザは、第２のデバイス上で動作することができる。第１のブラウザアプリケーションプログラミングインターフェースおよび第２のブラウザアプリケーションプログラミングインターフェースは各々、第１のブラウザおよび第２のブラウザの動作にそれぞれ関連づけ可能である。第２のアカウントに関連づけられた第２のデータは、製品を購入するための支払いが支払いサービスによって実行されたことを確認する支払いデータを含むことができる。第１のアカウントに関連づけられた第１のデータは、製品を購入するための支払いが支払いサービスによって実行されたことを確認する支払いデータを含むことができる。
【０６０４】
[00674]方法は、第１のブラウザから、第１のブラウザと支払いサービスとの間でデータを通信するためのプロトコルを定義するブラウザ支払いハンドラアプリケーションプログラミングインターフェースを介して、支払いサービスが支払いを処理したことを確認する情報を通信するデータに基づいて、通信を受信することをさらに含むことができる。
【０６０５】
[00675]図３８は、本開示の別の方法態様を示すことができる。方法は、ブラウザを介してサイトとインターフェースするユーザが、選択されたブラウザおよび選択されたブラウザアプリケーションプログラミングインターフェースをもたらすために第１のブラウザアプリケーションプログラミングインターフェースまたは第２のブラウザ支払い要求アプリケーションプログラミングインターフェースを介して支払いを行うことができるかどうかを決定する（３８０２）ことであって、選択されたブラウザアプリケーションプログラミングインターフェースは、支払いを管理するためにサイトと選択されたブラウザとの間でデータを通信するためのプロトコルを定義する、決定する（３８０２）ことと、選択されたブラウザまたは選択されたブラウザを介して可能にされたユーザ支払いアカウントに関連づけられた動的に修正された買うボタンを提示する（３８０４）ことと、動的に修正された買うボタンとの対話に関連して、選択されたブラウザに、選択されたブラウザアプリケーションプログラミングインターフェースを介して、支払い要求を送信する（３８０６）ことと、支払い要求に応答して、選択されたブラウザから、選択されたブラウザアプリケーションプログラミングインターフェースを介して、サイトにおいて支払い情報を受信する（３８０８）こととを含むことができる。
【０６０６】
[00676]動的に修正された買うボタンは、ユーザ支払いアカウントに関連づけ可能である。サイトプログラミングは、たとえば異なる支払い機構を受け付けるように構成可能であり、ＡＰＩは、どれをユーザが利用可能であるかをブラウザから単に識別する。支払い情報は、支払いがデバイス上で支払いサービスまたは支払いアプリによって処理されたという確認を含むことができる。方法は、選択されたブラウザから、選択されたブラウザアプリケーションプログラミングインターフェースを介して、確認情報を受信することも含むことができる。確認は、支払いサービスがサイトへの製品のための支払いを行うのに成功したことを確認することができる。クーポン、割り引き、ポイントなども、これらのＡＰＩを通して支払いに組み込み可能である。
【０６０７】
[00677]これらの実施形態は、方法、システム、およびコンピュータ可読媒体に関して説明可能であり、販売業者サイト、ブラウザ、ブラウザ作成者、およびサービスプロバイダの観点からも発生することができる。
【０６０８】
[00678]他のＡＰＩは、購入を行うためにブラウジングしている特定のユーザについてのデータもサイトに提供することができる。たとえば、ロケーション、年齢、収入レベル、購入習慣、ソーシャルメディアデータ、ブラウジング履歴、ユーザが使用するアカウントのタイプ、１つもしくは複数のユーザアカウントにどれくらいの金銭があるか、またはユーザについての他の情報が、データが、支払いボタンをどのようにして提示するかまたはそのユーザのための支払いフローをどのようにして修正するかについての意志決定プロセスに組み込まれ得るように、サイトに提供可能である。機械学習、人工知能、ルールベースの論理、または他の任意のそのような手法は、どのようにユーザが支払いフローに反応するかに関する訓練データを利用して、支払いプラットフォームにまたがって経験が一致可能であるように特定のユーザのための特定のフローを動的に提示することができる。これは、ＮＦＣ  ＰＯＳ購入、オンライン、アプリ内、およびモバイル購入を含むことができる。実施形態は、上記で説明されたようにデータを送信および受信する販売業者サイトの観点からの請求項と、サイトがユーザのために支払いインターフェースを構成する助けとなるために要求を受信し、応答を提供するサーバまたはクラウドベースのサービスの観点からの請求項と、購入プロセスにおけるより少ない摩擦のためにインターフェースを改善するようにサイトにパラメータまたはデータを与えるためにエージェントとして機能するブラウザから要求を受信し、応答を提供するためにＡＰＩが更新されるブラウザベースの請求項とを含むことができる。ブラウザはまた、ネットワークベースの適用例と通信する別のＡＰＩを使用してブラウザに戻すようにデータを送ることができ、次いで、インターフェースを動的に提示するためにサイトに戻すようにデータを送ることができる。
【０６０９】
[00679]本開示の範囲内の例は、コンピュータ遂行可能な命令またはデータ構造を運ぶまたはこれをその上に記憶させる有形のおよび／または非一時的なコンピュータ可読記憶デバイスも含むことがある。そのような有形のコンピュータ可読記憶デバイスは、上記で説明された任意の特殊目的プロセッサの機能設計を含む、汎用コンピュータまたは特殊目的コンピュータによってアクセス可能である任意の利用可能なデバイスとすることができる。限定ではなく、例として、そのような有形のコンピュータ可読デバイスは、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、またはコンピュータ遂行可能な命令、データ構造、もしくはプロセッサチップ設計の形で所望のプログラムコードを運ぶもしくはこれを記憶するために使用可能である他の任意のデバイスを含むことができる。情報または命令が、ネットワークまたは別の通信接続（ハードワイヤード、ワイヤレス、またはそれらの組み合わせ）を介してコンピュータに提供されるとき、コンピュータは、その接続をコンピュータ可読媒体として適切に見る。したがって、任意のそのような接続は、コンピュータ可読媒体と適切に呼ばれる。上記の組み合わせも、コンピュータ可読記憶デバイスの範囲内に含まれるべきである。
【０６１０】
[00680]コンピュータ遂行可能な命令は、たとえば、汎用コンピュータ、特殊目的コンピュータ、または特殊目的処理デバイスにある機能または機能のグループを実行させる命令およびデータを含む。コンピュータ遂行可能な命令は、スタンドアロン環境またはネットワーク環境でコンピュータによって遂行されるプログラムモジュールも含む。一般に、プログラムモジュールは、特定のタスクを実行するまたは特定の抽象データ型を実装する、特殊目的プロセッサなどの設計に固有のルーチン、プログラム、構成要素、データ構造、オブジェクト、および関数を含む。コンピュータ遂行可能な命令、関連づけられたデータ構造、およびプログラムモジュールは、本明細書において開示される方法のステップを実行するためのプログラムコード手段の例を表す。そのような遂行可能な命令または関連づけられたデータ構造の特定のシーケンスは、そのようなステップにおいて説明された機能を実施するための対応する行為の例を表す。
【０６１１】
[00681]本開示の他の例は、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む多くのタイプのコンピュータシステム構成を持つネットワークコンピューティング環境内で実施されることがある。例はまた、通信ネットワークを通してリンクされる（ハードワイヤードリンクによって、ワイヤレスリンクによって、またはそれの組み合わせによって、のいずれかで）ローカル処理デバイスおよびリモート処理デバイスによってタスクが実行される分散コンピューティング環境内で実施されることがある。分散コンピューティング環境では、プログラムモジュールは、ローカルメモリ記憶デバイス内とリモートメモリ記憶デバイス内の両方に配置されることがある。
【０６１２】
[00682]上記で説明されたさまざまな例は、例として提供されているに過ぎず、本開示の範囲を制限すると解釈されるべきでない。さまざまな修正および変更が、本明細書において図示および説明される例示的な例および適用例に追従せず、本開示の趣旨および範囲から逸脱することなく、本明細書において説明される原理に対して行われることがある。セット「のうちの少なくとも１つ」を記載する請求項の言い回しは、セットのうちの１つのメンバーまたはセットのうちの複数のメンバーが請求項を満たすことを示す。特に、任意の例または実施形態において説明される任意の特徴は、実施形態の任意の例の他の任意の特徴と組み合わされ得る。たとえば、検索エンジン例に関して検討される任意の特徴は、適用可能であり、ソーシャルメディア例または製品購入管理エンジン例と交換可能であることができる。
【図１】
2020523716.tif 000003
【図２Ａ】
2020523716.tif 000004
【図２Ｂ】
2020523716.tif 000005
【図３】
2020523716.tif 000006
【図４Ａ】
2020523716.tif 000007
【図４Ｂ】
2020523716.tif 000008
【図４Ｃ】
2020523716.tif 000009
【図５】
2020523716.tif 000010
【図６】
2020523716.tif 000011
【図７】
2020523716.tif 000012
【図８】
2020523716.tif 000013
【図９】
2020523716.tif 000014
【図１０】
2020523716.tif 000015
【図１１】
2020523716.tif 000016
【図１２Ａ】
2020523716.tif 000017
【図１２Ｂ】
2020523716.tif 000018
【図１２Ｃ】
2020523716.tif 000019
【図１２Ｄ】
2020523716.tif 000020
【図１２Ｅ】
2020523716.tif 000021
【図１２Ｆ】
2020523716.tif 000022
【図１３】
2020523716.tif 000023
【図１４Ａ】
2020523716.tif 000024
【図１４Ｂ】
2020523716.tif 000025
【図１４Ｃ】
2020523716.tif 000026
【図１５】
2020523716.tif 000027
【図１６】
2020523716.tif 000028
【図１７Ａ】
2020523716.tif 000029
【図１７Ｂ】
2020523716.tif 000030
【図１７Ｃ】
2020523716.tif 000031
【図１７Ｄ】
2020523716.tif 000032
【図１７Ｅ】
2020523716.tif 000033
【図１７Ｆ】
2020523716.tif 000034
【図１７Ｇ】
2020523716.tif 000035
【図１７Ｈ】
2020523716.tif 000036
【図１７Ｉ】
2020523716.tif 000037
【図１７Ｊ】
2020523716.tif 000038
【図１７Ｋ】
2020523716.tif 000039
【図１７Ｌ】
2020523716.tif 000040
【図１７Ｍ】
2020523716.tif 000041
【図１８Ａ】
2020523716.tif 000042
【図１８Ｂ】
2020523716.tif 000043
【図１８Ｃ】
2020523716.tif 000044
【図１８Ｄ】
2020523716.tif 000045
【図１８Ｅ】
2020523716.tif 000046
【図１８Ｆ】
2020523716.tif 000047
【図１８Ｇ】
2020523716.tif 000048
【図１８Ｈ】
2020523716.tif 000049
【図１９】
2020523716.tif 000050
【図２０Ａ】
2020523716.tif 000051
【図２０Ｂ】
2020523716.tif 000052
【図２０Ｃ】
2020523716.tif 000053
【図２０Ｄ】
2020523716.tif 000054
【図２１】
2020523716.tif 000055
【図２２】
2020523716.tif 000056
【図２３】
2020523716.tif 000057
【図２４】
2020523716.tif 000058
【図２５】
2020523716.tif 000059
【図２６】
2020523716.tif 000060
【図２７】
2020523716.tif 000061
【図２８Ａ】
2020523716.tif 000062
【図２８Ｂ】
2020523716.tif 000063
【図２９】
2020523716.tif 000064
【図３０】
2020523716.tif 000065
【図３１】
2020523716.tif 000066
【図３２】
2020523716.tif 000067
【図３３】
2020523716.tif 000068
【図３４Ａ】
2020523716.tif 000069
【図３４Ｂ】
2020523716.tif 000070
【図３５】
2020523716.tif 000071
【図３６】
2020523716.tif 000072
【図３７】
2020523716.tif 000073
【図３８】
2020523716.tif 000074
【手続補正書】
【提出日】令和1年12月26日(2019.12.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソフトウェアモジュールにおいて、およびアプリケーションのグラフィカルユーザインターフェースを介したユーザ入力に基づいて、前記アプリケーションに関連づけられた潜在的な支払いに関連づけられた支払い要求を受信することと、ここにおいて、前記支払い要求は、前記潜在的な支払いについての情報を備え、前記ソフトウェアモジュールは、デバイス上にあり、前記アプリケーションと前記ソフトウェアモジュールとの間でデータを通信するためのプロトコルを定義するソフトウェアモジュールアプリケーションプログラミングインターフェースを備え、
ユーザから支払いのための許可確認を受信することと、
前記許可確認に基づいて、前記支払いのための許可された支払いデータを受信することと、ここにおいて、前記許可された支払いデータの少なくとも一部分は、前記デバイス上のメモリから受信されたユーザ支払いデータを備え、
前記ソフトウェアモジュールアプリケーションプログラミングインターフェースにしたがって、および前記アプリケーションに、前記許可された支払いデータを送信することと、ここにおいて、前記アプリケーションは、支払いプロセスの少なくとも一部で前記許可された支払いデータを使用することができ、前記支払いプロセスは、ブロックチェーンベースの暗号通貨を少なくとも部分的に使用する、
を備える方法。
【請求項２】
前記ソフトウェアモジュールはブラウザを備え、前記アプリケーションは、前記ブラウザと通信するウェブサイトを備える、請求項１に記載の方法。
【請求項３】
前記ソフトウェアモジュールは、前記デバイス上に構成され、前記アプリケーションは、ダウンロードされたアプリケーションを前記デバイス上に備える、請求項１に記載の方法。
【請求項４】
前記ユーザ支払いデータは暗号鍵を備える、請求項１に記載の方法。
【請求項５】
前記ユーザ支払いデータは、前記デバイス上のセキュアなメモリに記憶される、請求項１に記載の方法。
【請求項６】
前記ブロックチェーンベースの暗号通貨を使用して行われるトランザクションは、複数の分散ノード上で動作する分散コンセンサスアルゴリズムにしたがって分散元帳上に記録される、請求項１に記載の方法。
【請求項７】
プロセッサと、
アプリケーションとソフトウェアモジュールとの間でデータを通信するためのプロトコルを定義するソフトウェアモジュールアプリケーションプログラミングインターフェースを備えるソフトウェアモジュールと、
ユーザ支払いデータを記憶するためのメモリと、
命令を記憶するコンピュータ可読記憶媒体と
を備え、前記命令は、前記プロセッサによって実行されると、前記プロセッサに、
前記アプリケーションから、前記ソフトウェアモジュールにおいて、およびグラフィカルユーザインターフェースを介したユーザ入力に基づいて、潜在的な支払いに関連づけられた支払い要求を受信することと、ここにおいて、前記支払い要求は、前記潜在的な支払いについての情報を備え、
ユーザから支払いのための許可確認を受信することと、
前記許可確認に基づいて、デバイスまたはネットワークベースのエンティティのうちの１つから前記支払いのための許可された支払いデータを受信することと、ここにおいて、前記許可された支払いデータの少なくとも一部分は、前記メモリから受信された前記ユーザ支払いデータを備え、
前記ソフトウェアモジュールアプリケーションプログラミングインターフェースにしたがって、および前記アプリケーションに、前記許可された支払いデータを送信することと、ここにおいて、前記アプリケーションは、支払いプロセスの少なくとも一部で前記許可された支払いデータを使用することができ、前記支払いプロセスは、ブロックチェーンベースの暗号通貨を少なくとも部分的に使用する、
を備える動作を行わせる、デバイス。
【請求項８】
前記ソフトウェアモジュールはブラウザを備え、前記アプリケーションは、前記ブラウザと通信するウェブサイトを備える、請求項７に記載のデバイス。
【請求項９】
前記ソフトウェアモジュールは、前記デバイス上に構成され、前記アプリケーションは、ダウンロードされたアプリケーションを前記デバイス上に備える、請求項７に記載のデバイス。
【請求項１０】
前記ユーザ支払いデータは暗号鍵を備える、請求項７に記載のデバイス。
【請求項１１】
前記ユーザ支払いデータは、前記デバイス上のセキュアなメモリに記憶される、請求項７に記載のデバイス。
【請求項１２】
前記ブロックチェーンベースの暗号通貨を使用して行われるトランザクションは、複数の分散ノード上で動作する分散コンセンサスアルゴリズムにしたがって分散元帳上に記録される、請求項７に記載のデバイス。
【請求項１３】
アプリケーションから、デバイス上のソフトウェアモジュールに、前記アプリケーションに関連づけられた潜在的な支払いに関連づけられた要求を送信することと、ここにおいて、前記要求は、前記潜在的な支払いについての情報を備え、前記ソフトウェアモジュールは、前記アプリケーションと前記ソフトウェアモジュールとの間でデータを通信するためのプロトコルを定義するソフトウェアモジュールアプリケーションプログラミングインターフェースを備え、
前記アプリケーションにおいて、前記ソフトウェアモジュールから、および前記ソフトウェアモジュールアプリケーションプログラミングインターフェースを介して、許可された支払いデータを受信することと、ここにおいて、前記ソフトウェアモジュールは、前記要求に基づいて、前記デバイスまたはネットワークベースのエンティティからの前記潜在的な支払いのための前記許可された支払いデータを受信またはそれにアクセスし、前記許可された支払いデータの少なくとも一部分は、前記デバイス上のメモリから受信されたユーザ支払いデータを備え、前記許可された支払いデータは、ブロックチェーンベースの暗号通貨支払いのために少なくとも部分的に使用されることができる、
を備える方法。
【請求項１４】
前記許可された支払いデータは、前記デバイスのメモリからの少なくともユーザ支払いデータを備える、請求項１３に記載の方法。
【請求項１５】
前記ソフトウェアモジュールはブラウザを備え、前記アプリケーションは、前記ブラウザと通信するウェブサイトを備える、請求項１３に記載の方法。
【請求項１６】
前記ソフトウェアモジュールは、前記デバイス上に構成され、前記アプリケーションは、ダウンロードされたアプリケーションを前記デバイス上に備える、請求項１３に記載の方法。
【請求項１７】
前記ユーザ支払いデータは暗号鍵を備える、請求項１３に記載の方法。
【請求項１８】
前記ユーザ支払いデータは、前記デバイス上のセキュアなメモリに記憶される、請求項１３に記載の方法。
【請求項１９】
前記ブロックチェーンベースの暗号通貨支払いを使用して行われるトランザクションは、複数の分散ノード上で動作する分散コンセンサスアルゴリズムにしたがって分散元帳上に記録される、請求項１３に記載の方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０６１２
【補正方法】変更
【補正の内容】
【０６１２】
[00682]上記で説明されたさまざまな例は、例として提供されているに過ぎず、本開示の範囲を制限すると解釈されるべきでない。さまざまな修正および変更が、本明細書において図示および説明される例示的な例および適用例に追従せず、本開示の趣旨および範囲から逸脱することなく、本明細書において説明される原理に対して行われることがある。セット「のうちの少なくとも１つ」を記載する請求項の言い回しは、セットのうちの１つのメンバーまたはセットのうちの複数のメンバーが請求項を満たすことを示す。特に、任意の例または実施形態において説明される任意の特徴は、実施形態の任意の例の他の任意の特徴と組み合わされ得る。たとえば、検索エンジン例に関して検討される任意の特徴は、適用可能であり、ソーシャルメディア例または製品購入管理エンジン例と交換可能であることができる。
以下に、本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
ブラウザを介して支払いデータを許可する方法であって、
サイトから、前記ブラウザにおいて、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信することと、ここにおいて、前記要求が、前記サイトによって受け付けられる暗号通貨支払い方法の識別を備え、
前記サイトに、前記ブラウザから、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記ブラウザのユーザが、前記サイトによって受け付けられる前記暗号通貨支払い方法を介して前記潜在的な購入の支払いをすることができることを示すデータを送信することと、
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記暗号通貨支払い方法を使用して潜在的な購入が行われることが許可された支払いデータを受信することと
を備える方法。
［Ｃ２］
前記暗号通貨ウォレットが支払いを行うことを可能にするために、前記許可された支払いデータを暗号通貨ウォレットにポピュレートすることと、
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記暗号通貨ウォレットを開始することと
をさらに備える、Ｃ１に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ３］
前記許可された支払いデータが、前記支払いを受信するためのサイトアドレス、買い手の秘密鍵、受信者の公開鍵、電子メールアドレス、受信者識別情報、支払い量、およびユーザコメントのうちの少なくとも１つを備える暗号通貨支払い情報である、Ｃ２に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ４］
前記暗号通貨ウォレットが、前記ブラウザを実行しているデバイス上にローカルに記憶されたウォレットおよびウェブベースのウォレットのうちの少なくとも１つを備える、Ｃ２に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ５］
前記暗号通貨ウォレットが前記ウェブベースのウォレットであるとき、前記方法が、
前記支払いを処理するためのアプリケーションプログラミングインターフェースを介して前記ウェブベースのウォレットに前記許可された支払いデータを送信すること
をさらに備える、Ｃ４に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ６］
前記要求が、前記暗号通貨支払い方法に加えて、前記サイトによって使用されるサポートされる支払い方法を識別する、Ｃ１に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ７］
前記許可された支払いデータが、前記暗号通貨ウォレットとのトランザクションに署名するために使用される秘密鍵を備える、Ｃ２に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ８］
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、支払いを受信するためにサイト暗号通貨ウォレットによる使用のために前記サイトにデータを送信すること
をさらに備える、Ｃ１に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ９］
前記許可された支払いデータが、前記ブラウザに記憶される、別個のエンティティから前記ブラウザによってアクセスされる、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して前記サイトから受信される、サードパーティから受信される、または、前記ブラウザによって指示されたように前記サードパーティから前記サイトに配達される、Ｃ１に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ１０］
前記暗号通貨支払い方法が、購入のためにユーザによって選択されるとき、前記方法が、
支払いを確認するために前記ユーザによる使用のために支払い対話インターフェースと暗号通貨ウォレットインターフェースを混合する前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、混合されたユーザインターフェースを生成すること
をさらに備える、Ｃ１に記載のブラウザを介して支払いデータを許可する方法。
［Ｃ１１］
サイトから、ブラウザに、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することと、ここにおいて、前記要求が、前記サイトによって受け付けられる暗号通貨支払い方法の識別を備え、
前記サイトにおいて、前記ブラウザから、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、前記ブラウザのユーザが、前記サイトによって受け付けられる前記暗号通貨支払い方法を介して前記潜在的な購入の支払いをすることができることを示すデータを受信することと、
前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して前記暗号通貨支払い方法を使用して前記潜在的な購入を処理するための前記ユーザからの確認に基づいて、前記暗号通貨支払い方法を使用して支払いを受信することと
を備える方法。
［Ｃ１２］
暗号通貨ウォレットからサイト暗号通貨ウォレットにおいて前記支払いを受信すること、ここにおいて、許可された支払いデータが、前記支払いを開始するために前記暗号通貨ウォレットをポピュレートする際に使用される
をさらに備える、Ｃ１１に記載の方法。
［Ｃ１３］
前記許可された支払いデータが、前記サイト暗号通貨ウォレットを識別するデータおよび量のうちの少なくとも１つを備える、Ｃ１２に記載の方法。
［Ｃ１４］
前記暗号通貨ウォレットが、前記ブラウザを動作させるデバイスおよび前記デバイスとは別個のウェブベースのデバイスのうちの１つの上に記憶される、Ｃ１３に記載の方法。
［Ｃ１５］
支払いを処理する方法であって、
暗号通貨ウォレットにおいて、購入に関連づけられた許可された支払い情報を受信することと、ここにおいて、前記許可された支払い情報が、ブラウザが、サイトから、前記ブラウザにおいて、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信したことに基づいて、生成され、ここにおいて、前記要求が、前記サイトによって受け付けられる暗号通貨支払い方法の識別を備える、
前記暗号通貨ウォレットから暗号通貨を使用して、前記許可された支払い情報に基づいて、前記支払いを処理することと、
前記暗号通貨を使用して前記支払いの前記処理に関連づけられた確認データを前記ブラウザに送信することと
を備える方法。
［Ｃ１６］
支払いを受信する方法であって、
サイトから、ブラウザに、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を送信することと、ここにおいて、前記要求が、前記サイトによって受け付けられる支払い方法の識別を備え、ここにおいて、前記支払い方法が暗号通貨を使用し、
前記サイトにおいて、前記支払い方法による支払いを受信することと、ここにおいて、前記支払い方法が、前記ブラウザ支払い要求アプリケーションプログラミングインターフェースを介して送信された前記要求に基づいて開始された暗号通貨支払いプロセスにより前記暗号通貨を使用する
を備える方法。
［Ｃ１６］
前記暗号通貨支払いプロセスが、第１の通貨を第２の通貨へと変換することを備える、Ｃ１５に記載の方法。
［Ｃ１７］
前記暗号通貨支払いプロセスが、買い手が第１の通貨を使用して売り手から品物を購入することと、および、前記売り手が第２の通貨で支払われることを可能にし、ここにおいて、暗号通貨が、前記第１の通貨と前記第２の通貨との間での変換を橋渡しするために使用される、Ｃ１５に記載の方法。
［Ｃ１８］
支払いサービスを動作させる方法であって、
前記支払いサービスにおいて、購入に関連づけられた許可された支払い情報を受信することと、ここにおいて、前記許可された支払い情報が、ブラウザが、サイトから、前記サイトと前記ブラウザとの間でデータを通信するためのプロトコルを定義するブラウザ支払い要求アプリケーションプログラミングインターフェースを介して、潜在的な購入に関連づけられた要求を受信したことに基づいて、生成され、ここにおいて、前記要求が、少なくとも一部は暗号通貨を利用する支払いプロセスの識別を備え、
前記暗号通貨を使用して、前記許可された支払い情報に基づいて支払いを処理することと、
前記暗号通貨を使用した前記支払いの前記処理に関連づけられた確認データを前記ブラウザに送信することと
を備える方法。
［Ｃ１９］
前記支払いを処理することが、買い手から受信された第１の通貨を前記暗号通貨へと変換することをさらに備える、Ｃ１８に記載の方法。
［Ｃ２０］
前記支払いを処理することが、売り手に支払うために、買い手から受信された第１の通貨を前記暗号通貨へと変換することと、前記暗号通貨を第２の通貨へと変換することとをさらに備える、Ｃ１９に記載の方法。
［Ｃ２１］
サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザにおいて、前記ブラウザと前記サイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、前記購入に関連づけられた支払い要求を受信することと、
前記ユーザから、前記第１のアプリケーションプログラミングインターフェースを介して、前記サイトによってサポートされる支払い方法の選択肢を受信することと、ここにおいて、前記支払い方法が少なくとも一部は暗号通貨を利用し、ここにおいて、支払いトランザクションが、少なくとも一部は支払いサービスによって管理され、
前記支払い要求および前記支払い方法の前記選択肢に応答して、前記ブラウザから、前記ブラウザと前記支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して、前記支払いサービスに支払い要求イベントを通信することと、前記支払い要求イベントが、少なくとも一部は前記暗号通貨を利用して支払いを取り扱うために前記支払いサービスによる使用のためのデータを備える、
を備える方法。
［Ｃ２２］
前記支払い要求が、前記購入についての情報と、前記サイトによってサポートされる支払い方法の選択肢のセットとを備える、Ｃ２１に記載の方法。
［Ｃ２３］
前記支払いサービスによって管理される支払いプロセスが、前記暗号通貨で前記支払いを行う、Ｃ２１に記載の方法。
［Ｃ２４］
前記支払いサービスによって管理される支払いプロセスが、（１）第１の通貨から前記暗号通貨へと変換することおよび（２）前記暗号通貨から第２の通貨へと変換することのうちの少なくとも１つを実行することによって、前記支払いを行う、Ｃ２１に記載の方法。
［Ｃ２５］
前記支払いサービスによって管理される支払いプロセスが、買い手によって提供される第１の通貨から前記暗号通貨へと変換し、前記暗号通貨から売り手によって受け付けられる第２の通貨へと変換することによって、前記支払いを行う、Ｃ２１に記載の方法。
［Ｃ２６］
前記第１の通貨が、第１の法定通貨および第１の暗号通貨のうちの１つを備える、ここにおいて、前記第２の通貨が、第２の法定通貨および第２の暗号通貨のうちの１つを備える、Ｃ２５に記載の方法。
［Ｃ２７］
支払いサービスにおいて支払い要求イベントを受信することと、ここにおいて、前記支払いサービスにおいて前記支払い要求イベントを受信することが、
ブラウザが、前記ブラウザとサイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、製品の購入に関連づけられた支払いデータのために前記サイトから支払い要求を受信することと、ここにおいて、前記支払い要求が、製品を購入する要望を示すユーザからの入力に基づいており、前記購入についての情報を備え、
前記ユーザから、前記第１のアプリケーションプログラミングインターフェースを介して、前記支払いサービスの選択肢を受信すること、ここにおいて、前記支払い要求イベントが、前記ブラウザから、前記ブラウザと前記支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースを介して受信される
に基づき、
前記支払いサービスにおいて、少なくとも一部は暗号通貨の使用を備える支払いプロセスを開始するために前記支払い要求イベントを処理することと
を備える方法。
［Ｃ２８］
前記ブラウザに、前記支払いサービスから、前記第２のアプリケーションプログラミングインターフェースを介して、許可された支払い情報を送信すること、ここにおいて、前記ブラウザが、前記第１のアプリケーションプログラミングインターフェースを介して前記許可された支払い情報を前記サイトに通信する
をさらに備える、Ｃ２７に記載の方法。
［Ｃ２９］
前記支払い要求が、前記購入についての情報と、前記サイトによってサポートされる支払い方法の選択肢のセットとを備える、Ｃ２７に記載の方法。
［Ｃ３０］
前記支払いサービスによって管理される前記支払いプロセスが、前記暗号通貨で支払いを行う、Ｃ２７に記載の方法。
［Ｃ３１］
前記支払いサービスによって管理される前記支払いプロセスが、（１）第１の通貨から前記暗号通貨へと変換することおよび（２）前記暗号通貨から第２の通貨へと変換することのうちの少なくとも１つを実行することによって、支払いを行う、Ｃ２７に記載の方法。
［Ｃ３２］
前記支払いサービスによって管理される前記支払いプロセスが、買い手によって提供される第１の通貨から前記暗号通貨へと変換し、前記暗号通貨から売り手によって受け付けられる第２の通貨へと変換することによって、支払いを行う、Ｃ２７に記載の方法。
［Ｃ３３］
前記第１の通貨が、第１の法定通貨および第１の暗号通貨のうちの１つを備える、ここにおいて、前記第２の通貨が、第２の法定通貨および第２の暗号通貨のうちの１つを備える、Ｃ３２に記載の方法。
［Ｃ３４］
サイトから、購入を行う要望を示したユーザからの入力に基づいて、ブラウザにおいて、前記ブラウザと前記サイトとの間でデータを通信するための第１のプロトコルを定義する第１のアプリケーションプログラミングインターフェースを介して、前記購入に関連づけられた支払い要求を送信することと、
前記第１のアプリケーションプログラミングインターフェースを介して、前記サイトによってサポートされる支払い方法の選択肢を送信することと、ここにおいて、前記支払い方法が、少なくとも一部は暗号通貨を利用し、ここにおいて、支払いトランザクションが、支払いサービスによって少なくとも一部は管理され、ここにおいて、前記支払い要求および前記支払い方法の前記選択肢に応答して、前記ブラウザと前記支払いサービスとの間でデータを通信するための第２のプロトコルを定義する第２のアプリケーションプログラミングインターフェースが、前記支払いサービスに支払い要求イベントを通信し、前記支払い要求イベントが、少なくとも一部は前記暗号通貨を利用する支払いプロセスを介して支払いを取り扱うために前記支払いサービスによる使用のためのデータを備える、
前記支払いプロセスを介して前記支払いを受信することと
を備える方法。
【国際調査報告】
2020523716.tif 000075