CN111279336A - 通过浏览器应用程序编程接口提供加密货币支付 - Google Patents
通过浏览器应用程序编程接口提供加密货币支付 Download PDFInfo
- Publication number
- CN111279336A CN111279336A CN201880044997.7A CN201880044997A CN111279336A CN 111279336 A CN111279336 A CN 111279336A CN 201880044997 A CN201880044997 A CN 201880044997A CN 111279336 A CN111279336 A CN 111279336A
- Authority
- CN
- China
- Prior art keywords
- payment
- user
- browser
- website
- purchase
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 1216
- 230000008569 process Effects 0.000 claims description 476
- 230000003993 interaction Effects 0.000 claims description 274
- 238000012545 processing Methods 0.000 claims description 265
- 238000012790 confirmation Methods 0.000 claims description 89
- 230000004044 response Effects 0.000 claims description 85
- 238000006243 chemical reaction Methods 0.000 claims description 49
- 230000000977 initiatory effect Effects 0.000 claims description 30
- 230000036961 partial effect Effects 0.000 claims description 18
- 230000006855 networking Effects 0.000 description 175
- 230000007704 transition Effects 0.000 description 172
- 238000012384 transportation and delivery Methods 0.000 description 146
- 230000006870 function Effects 0.000 description 133
- 238000004891 communication Methods 0.000 description 118
- 238000003860 storage Methods 0.000 description 70
- 238000007726 management method Methods 0.000 description 60
- 230000007246 mechanism Effects 0.000 description 54
- 239000008186 active pharmaceutical agent Substances 0.000 description 53
- 238000013459 approach Methods 0.000 description 51
- 230000009471 action Effects 0.000 description 49
- 238000013475 authorization Methods 0.000 description 45
- 230000008859 change Effects 0.000 description 45
- 239000003795 chemical substances by application Substances 0.000 description 38
- 239000000306 component Substances 0.000 description 38
- BQCADISMDOOEFD-UHFFFAOYSA-N Silver Chemical compound [Ag] BQCADISMDOOEFD-UHFFFAOYSA-N 0.000 description 26
- 229910052709 silver Inorganic materials 0.000 description 26
- 239000004332 silver Substances 0.000 description 26
- 238000003825 pressing Methods 0.000 description 25
- 230000000875 corresponding effect Effects 0.000 description 24
- 238000004458 analytical method Methods 0.000 description 23
- 238000004422 calculation algorithm Methods 0.000 description 22
- 230000015654 memory Effects 0.000 description 22
- 238000012546 transfer Methods 0.000 description 22
- 238000012552 review Methods 0.000 description 19
- 230000008901 benefit Effects 0.000 description 17
- 238000012905 input function Methods 0.000 description 15
- 238000010801 machine learning Methods 0.000 description 15
- 238000012986 modification Methods 0.000 description 15
- 230000004048 modification Effects 0.000 description 15
- 230000002085 persistent effect Effects 0.000 description 15
- 238000012549 training Methods 0.000 description 15
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 14
- 229910052737 gold Inorganic materials 0.000 description 14
- 239000010931 gold Substances 0.000 description 14
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 13
- 230000000694 effects Effects 0.000 description 13
- 238000011049 filling Methods 0.000 description 13
- 230000002452 interceptive effect Effects 0.000 description 13
- 238000007781 pre-processing Methods 0.000 description 13
- 235000013305 food Nutrition 0.000 description 12
- 239000003826 tablet Substances 0.000 description 10
- 230000000007 visual effect Effects 0.000 description 10
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 10
- 239000003623 enhancer Substances 0.000 description 9
- 235000012054 meals Nutrition 0.000 description 9
- 230000026676 system process Effects 0.000 description 9
- 239000003086 colorant Substances 0.000 description 8
- 230000001815 facial effect Effects 0.000 description 8
- 235000013550 pizza Nutrition 0.000 description 8
- 235000014510 cooky Nutrition 0.000 description 7
- 238000009826 distribution Methods 0.000 description 7
- 230000001976 improved effect Effects 0.000 description 7
- 238000009877 rendering Methods 0.000 description 7
- 230000002776 aggregation Effects 0.000 description 6
- 238000004220 aggregation Methods 0.000 description 6
- 230000006399 behavior Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 6
- 230000001276 controlling effect Effects 0.000 description 6
- 239000000463 material Substances 0.000 description 6
- 230000002829 reductive effect Effects 0.000 description 6
- 238000013461 design Methods 0.000 description 5
- 230000033001 locomotion Effects 0.000 description 5
- 230000001737 promoting effect Effects 0.000 description 5
- 238000013473 artificial intelligence Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000004931 aggregating effect Effects 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 230000009193 crawling Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000009191 jumping Effects 0.000 description 3
- 238000013515 script Methods 0.000 description 3
- 230000029305 taxis Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000001755 vocal effect Effects 0.000 description 3
- 235000002566 Capsicum Nutrition 0.000 description 2
- WQZGKKKJIJFFOK-GASJEMHNSA-N Glucose Natural products OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O WQZGKKKJIJFFOK-GASJEMHNSA-N 0.000 description 2
- 239000006002 Pepper Substances 0.000 description 2
- 241000722363 Piper Species 0.000 description 2
- 235000016761 Piper aduncum Nutrition 0.000 description 2
- 235000017804 Piper guineense Nutrition 0.000 description 2
- 235000008184 Piper nigrum Nutrition 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000004397 blinking Effects 0.000 description 2
- 239000008280 blood Substances 0.000 description 2
- 210000004369 blood Anatomy 0.000 description 2
- 238000007635 classification algorithm Methods 0.000 description 2
- 230000002596 correlated effect Effects 0.000 description 2
- 230000007812 deficiency Effects 0.000 description 2
- 238000002716 delivery method Methods 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 239000012530 fluid Substances 0.000 description 2
- 239000008103 glucose Substances 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000011068 loading method Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 239000000203 mixture Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000003672 processing method Methods 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 150000003839 salts Chemical class 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- VBMOHECZZWVLFJ-GXTUVTBFSA-N (2s)-2-[[(2s)-6-amino-2-[[(2s)-6-amino-2-[[(2s,3r)-2-[[(2s,3r)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-6-amino-2-[[(2s)-2-[[(2s)-2-[[(2s)-2,6-diaminohexanoyl]amino]-5-(diaminomethylideneamino)pentanoyl]amino]propanoyl]amino]hexanoyl]amino]propanoyl]amino]hexan Chemical compound NC(N)=NCCC[C@@H](C(O)=O)NC(=O)[C@H](CCCCN)NC(=O)[C@H](CCCCN)NC(=O)[C@H]([C@@H](C)O)NC(=O)[C@H]([C@H](O)C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCCN)NC(=O)[C@H](C)NC(=O)[C@H](CCCN=C(N)N)NC(=O)[C@@H](N)CCCCN VBMOHECZZWVLFJ-GXTUVTBFSA-N 0.000 description 1
- 206010012186 Delayed delivery Diseases 0.000 description 1
- 235000012308 Tagetes Nutrition 0.000 description 1
- 241000736851 Tagetes Species 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000037237 body shape Effects 0.000 description 1
- 235000008429 bread Nutrition 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000013145 classification model Methods 0.000 description 1
- 238000010835 comparative analysis Methods 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 238000007418 data mining Methods 0.000 description 1
- 238000003066 decision tree Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 235000021185 dessert Nutrition 0.000 description 1
- 235000021186 dishes Nutrition 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 229940079593 drug Drugs 0.000 description 1
- 238000001035 drying Methods 0.000 description 1
- 239000000428 dust Substances 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 229910001254 electrum Inorganic materials 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- XXOYNJXVWVNOOJ-UHFFFAOYSA-N fenuron Chemical compound CN(C)C(=O)NC1=CC=CC=C1 XXOYNJXVWVNOOJ-UHFFFAOYSA-N 0.000 description 1
- 238000005429 filling process Methods 0.000 description 1
- 235000019138 food restriction Nutrition 0.000 description 1
- 210000001061 forehead Anatomy 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 230000008571 general function Effects 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 239000011521 glass Substances 0.000 description 1
- 210000003128 head Anatomy 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 239000007943 implant Substances 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 108010068904 lysyl-arginyl-alanyl-lysyl-alanyl-lysyl-threonyl-threonyl-lysyl-lysyl-arginine Proteins 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000002483 medication Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012011 method of payment Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000001537 neural effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000003909 pattern recognition Methods 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000010079 rubber tapping Methods 0.000 description 1
- 238000010845 search algorithm Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000008093 supporting effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 208000008918 voyeurism Diseases 0.000 description 1
- 238000005406 washing Methods 0.000 description 1
- 230000003245 working effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/951—Indexing; Web crawling techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3223—Realising banking transactions through M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
- G06Q20/3267—In-app payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/384—Payment protocols; Details thereof using social networks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
公开接收支付的系统和方法。该方法包括从网站到浏览器并通过浏览器支付请求应用程序编程接口传输与购买支付相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求包括由所述网站接受的支付方法的标识，其中所述支付方法使用加密货币，并且在所述网站处根据所述支付方法接收支付，其中支付方法根据通过所述浏览器支付请求应用程序编程接口传输的请求启动的加密货币支付方法来使用所述加密货币。
Description
要求优先权
本申请要求于2018年4月6日提交的美国专利申请15/947,395的优先权，该申请是2017年9月29日提交的美国专利申请15/720,878的部分继续申请，是2017年8月16日提交的美国专利申请15/678,664的部分继续申请，是2017年8月16日提交的美国专利申请15/678,378的继续申请，是2017年5月23日提交的美国非临时专利申请15/602,868的部分继续申请，是2017年5月19日提交的美国非临时专利申请15/600,599的继续申请，是2017年5月19日提交的美国非临时专利申请15/600,388的继续申请，是2017年5月4日提交的美国非临时专利申请15/586,999的部分继续申请，是2016年9月19日提交的美国非临时专利申请15/269,451的部分继续申请，现在的美国专利申请9,767,520，2017年9月19日公开，是2016年9月12日提交的美国非临时专利申请15/263,066的继续申请，是2016年2月9日提交的美国非临时专利申请15/018,954的继续申请，现在的美国专利申请9,734,526，2017年8月15日公开，是2015年9月14日提交的美国非临时专利申请14/853,579的继续申请，现在的美国专利申请9,396,491，2016年7月19日公开，是2015年8月10日提交的美国非临时专利申请14/822,368的继续申请，现在的美国专利申请9,292,871，2016年3月22日公开，是2015年3月30日提交的美国非临时专利申请14/672,876的继续申请，现在的美国专利申请9,361,638，2016年6月7日公开，该申请要求2014年4月1日提交的美国临时专利申请61/973,287的优先权，并且是2014年3月31日提交的美国非临时专利申请14/230,864的部分继续申请，现在的美国专利申请9,430,794，2016年8月30日公开，并要求2014年3月31日提交的美国临时专利申请61/972,843、2014年3月31日提交的美国临时专利申请61/972,834、2014年3月31日提交的美国临时专利申请61/972,848、2014年3月31日提交的美国临时专利申请61/972,865、2014年3月31日提交的美国临时专利申请61/972,879、2014年3月31日提交的美国临时专利申请61/972,861、2014年3月31日提交的专利申请61/972,878、2014年3月31日提交的美国临时专利申请61/972,892、2014年3月31日提交的美国临时专利申请61/972,890的优先权，其每一个的内容通过引用整体并入本文。
本申请是2017年9月29日提交的美国专利申请15/720,878的部分继续申请，它是2017年8月16日提交的美国专利申请15/678,664的部分继续申请，要求2017年3月23日提交的美国临时专利申请62/475,578、2017年1月26日提交的美国临时专利申请62/450,900、2016年9月26日提交的美国临时专利申请62/399,761、美国临时2017年9月19日提交的专利申请62/560,261的优先权，其内容通过引用整体并入本文。
本申请是2017年9月29日提交的美国非临时专利申请号15/720,878的部分继续申请，是2016年9月12日提交的美国非临时专利申请15/263,057的部分继续申请，是2016年2月9日提交的美国非临时专利申请15/018,954的继续申请，现在的美国专利9,734,526，2017年8月15日公开，是2015年9月14日提交的美国非临时专利申请14/853,579的继续申请，现在的美国专利9,396,491，2016年7月19日公开，是2015年8月10日提交的美国非临时专利申请14/822,368的继续申请，现在的美国专利9,292,871，2016年3月22日公开，是2015年3月30日提交的美国非临时专利申请14/672,876的继续申请，现在的美国专利9,361,638，2016年6月7日公开，要求2014年4月1日提交的美国临时专利申请61/973,287的优先权，并且是2014年3月31日提交的美国非临时专利申请14/230,864的部分继续申请，现在的美国专利9,430,794，2016年8月30日公开，要求2014年3月31日提交的美国临时专利申请61/972,843、2014年3月31日提交的美国临时专利申请61/972,834、2014年3月31日提交的美国临时专利申请61/972,848、2014年3月31日提交的美国临时专利申请61/972,865、2014年3月31日提交的美国临时专利申请61/972,879、2014年3月31日提交的美国临时专利申请61/972,861、2014年3月31日提交的美国临时专利申请61/972,878、2014年3月31日提交的美国临时专利申请61/972,892、2014年3月31日提交的专利申请61/972,890的优先权，其每一个的内容通过引用整体并入本文。
本申请要求2017年10月9日提交的美国临时专利申请No.62/569,841的优先权，其全部内容通过引用合并于此。
相关申请
本申请与下列专利申请相关：2015年9月14日提交的美国非临时专利申请14/853,545，现在是2016年6月21日公开的美国专利9,373,138；2016年2月8日提交的美国非临时专利申请15/018,432，现在是2016年9月20日公开的美国专利9,449,338；2016年2月8日提交的美国非临时专利申请15/018,457，现在是2016年10月11日公开的美国专利9,466,081；2016年2月8日提交的美国非临时专利申请15/018,497，现在是2016年9月6日公开的美国专利9,436,957；2016年2月8日提交的美国非临时专利申请15/018,514，现在是2016年12月20日公开的美国专利9,524,519；2016年2月9日提交的美国非临时专利申请15/018,934；2016年2月9日提交的美国非临时专利申请15/018,923，现在是2016年8月30日公开的美国专利9,430,790；2016年2月9日提交的美国非临时专利申请15/018,939；其每一个的内容通过引用整体并入本文。
技术领域
本公开涉及用于浏览器使用在浏览器与商家网站之间的应用程序编程接口来管理支付方法的各种实施方案。本案例着重于通过网站与应用程序编程接口之间的交互提供加密货币支付方法。
背景技术
本申请解决与简化和管理商品的在线购买以及Internet上网站之间的导航有关的许多问题。还讨论本文解决和相关专利申请中涵盖的其他问题。本介绍可包括对新颖特征的讨论，并且不应视为承认本节中讨论的任何概念都是现有技术。
本文解决的一个问题涉及利用购物车。如果用户在第一网站上选择第一商品并将商品放置在购物车中，然后没有完成购买并转到第二网站上以查看第二商品，则没有保存或维护有关第一商品的信息的机制。显然，用户对该商品感兴趣，但是并没有做好购买的充分准备。此外，如果用户确实导航说三个不同的网站，并且购买了三个不同的商品，即使每个网站都配置“一键购买”功能，或者即使用户在每个单独的网站上注册，该用户仍然必须进行三次独立点击以购买这三种商品。因此，本文提出的一个问题涉及跨多个网站购物的改进机制，特别是在减少实现购买多个商品所需的交互次数方面。在某些情况下，可存在多个网站的购物车，这可能需要用户注册或向服务提供支付信息，这对于用户而言可能是不希望的。
本文解决的另一个问题是在“一键式”购买选项的上下文中，它涉及解决潜在买方的购买问题。购买问题可包括复杂的购物车模型，这些模型需要太多的数据(支付帐户、地址、姓名等)，尤其是在移动设备上，这导致人们放弃购物车、未选择的商品规格或参数，例如衣服的尺寸或颜色、或电子设备的存储容量。其他购买问题可包括对商品的不良评论或对商家反映不佳的文章。另一个问题可包括在最终确定购买之前解决有关购买的问题。买方的购买关注点可包括与商品、服务、商家或任何其他主题有关的任何内容。因此，希望有一种方法能够过渡到有关商品的对话框，以解决购买问题，从而最终确定参数，然后有效地确认支付。本案中的权利要求解决了这个问题。
本文解决的另一个问题是如何轻松地将用户从搜索引擎或浏览器网站转换为目标网站。Safari的全功能提供了一种实现此过渡的方法。Safari用户使用omnikey扩展名输入指示符，指示它们要使用哪些替代网站来处理输入。例如，在输入字段中，用户将键入“amazonheadphones”，这将指示处理输入的算法在amazon.com上搜索“headphones”并返回结果。这种方法的问题在于，与在搜索开始时键入“amazon”相比，单击“amazon”选项卡并在“Amazon搜索”字段中键入“headphones”可能容易。此外，要告诉搜索引擎用户不希望转换到amazon，用户将不得不以感叹号“！”开始搜索，这强制进行常规搜索。在大多数用户输入可能涉及根据默认搜索引擎进行常规搜索的功能时，使用这种功能可能会要求用户经常以“！”开始搜索。因此，将用户转换到其他网站的努力仍然存在问题。
另一个问题涉及长期存在的问题，即要求用户在购买时输入诸如信用卡信息和用户地址之类的支付数据。某些网站(例如Amazon.com)提供“一键式”购买选项，但这些简化操作仅在受控的Amazon.com环境中可用。对于所有其他商家，用户必须输入繁琐的支付数据。Amazon.com以外的移动用户仍需要包括并输入很多信息，这可以减少在台式机或移动设备上进行在线购买时的转换次数。
本公开还解决了本领域中的问题，该问题是通过在不同平台上使用购买按钮引起的。由于本申请要求公开在搜索引擎、社交媒体等上的购买按钮的各种实现的应用的优先权，因此本介绍的任何部分都不旨在表征“现有技术”。再次，本申请中的任何讨论都不应被认为是申请人承认本文的任何主题是现有技术。
鉴于google.com、facebook.com、instagram.com、pinterest.com、bing.com、yahoo.com、youtube.com、amazon.com和twitter.com等网站上的购买按钮均可用，在跟踪购买方面出现特定的挑战。用户可以在facebook.com上购买第一种商品，并且第二天在google.com上购买第二种商品。为了能够进行此类购买，诸如google.com之类的网站会维护购买信息，例如信用卡或支付帐户信息。任选地，提供与
或Apple Pay的接口，使得可以轻松处理购买。在购买按钮不断扩展的同时，尚不存在协调或组织购买的机制，以便用户可以轻松地管理购买。用户可能会忘记在哪里进行购买，并且当他们无法管理购买或查看其购买历史时可能会感到沮丧。对于诸如www.amazon.com之类的封闭式汇总商家网站，购买是通过一个网站控制的，多个商家将其商品提供给它们。在这样的网站上管理用户帐户和购买历史的功能相当容易。
但是，各种网站上的“购买”按钮的目的是使当人们使用社交媒体(例如Facebook或Instagram)看到他们可能想要购买的东西时，可以在这些“微小时刻”进行购买。在传统的非商家网站中加入“购买”按钮的好处是，可以利用人们花时间的网站轻松进行购买，例如google.com等搜索引擎和社交媒体网站。但是，在非商家网站上展示购买选项以利用此类微时刻，会带来管理分布在不协调、分散的网站上的购物的困难。
发明概述
本公开提供了许多创新来解决如上所述的各种问题。在所公开的许多解决方案中，初始权利要求集通过使用浏览器应用程序编程接口通过网站与浏览器之间的交互(请求/响应等)来部分或全部解决加密货币的购买。有许多与此示例相关的示例方法。声明可以针对由商家网站执行的操作、由浏览器执行的操作、由支付服务执行的操作、由加密货币钱包执行的操作、支付服务的操作，这些操作利用桥接加密货币桥接不同的法定货币，等等。在该概述中，描述了一种示例系统和方法。下面在本申请的主体中阐述了许多其他示例。
与通过浏览器支付API使用加密货币支付有关的示例方法包括从网站到浏览器并通过浏览器支付请求应用程序编程接口传输与购买支付相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求括该网站接受的支付方式的标识，其中所述支付方法使用加密货币以及在所述网站处根据所述支付方法接收支付，其中所述支付方法根据通过所述浏览器支付请求应用程序编程接口传输的请求启动的加密货币支付方法来使用所述加密货币。
本文公开的其他解决方案包括当进行购买时用户如何从多种不同的支付方式中进行选择。用户通常具有不同的帐户、信用卡、借记卡等。
一种方法包括在网站上确定通过浏览器访问网站的用户(1)使用的是第一浏览器还是第二浏览器，或者(2)可以使用第一帐户或第二帐户进行购买以产生收益。因此，可以检测使用的浏览器类型或可以检测用户的帐户类型。当确定指示用户正在使用第一浏览器或可以使用第一帐户进行购买时，该方法包括：(1)呈现与第一帐户相关联的动态修改的第一购买按钮，(2)并经由第一浏览器支付请求应用程序编程接口(该接口定义用于在网站和第一个浏览器之间传达有关通信信息的协议)、具有与从网站为用户购买相关的第一信息的第一支付请求向第一浏览器传输，并且(3)从第一浏览器并通过第一浏览器支付请求应用程序编程接口、与第一账户相关的第一数据、与处理购买相关的第一数据接收。
当确定指示用户正在使用第二浏览器或者可以使用第二帐户进行购买时，该方法包括(1)呈现与第二帐户相关联的动态修改的第二购买按钮，(2)向第二浏览器并通过第二浏览器支付请求应用程序编程接口(该接口定义用于在网站和第二个浏览器之间传达有关购买通信信息的协议)、第二支付请求(该第二支付请求具有与该用户从网站的购买相关联的第二信息)传输，(3)从第二浏览器并通过第二浏览器支付请求应用程序编程接口、与第二账户相关的第二数据、与处理购买相关的第二数据接收。第一浏览器和第二浏览器可以是不同的浏览器类型。
在另外方面，所公开的方法包括确定经由浏览器与网站接口的用户是否可以经由第一浏览器支付请求应用程序编程接口或第二浏览器支付请求应用程序编程接口进行支付，以产生所选浏览器和所选浏览器支付请求应用程序编程接口，其中选定的浏览器支付请求应用程序编程接口定义用于在网站和所选浏览器之间传递数据以管理支付的协议，呈现与所选浏览器或通过所选浏览器启用的用户支付帐户相关联的动态修改的购买按钮，结合与动态修改的购买按钮的交互经由选择的浏览器支付请求应用程序编程接口向选择的浏览器发送支付请求，并响应于该支付请求，从所选浏览器并通过所选浏览器支付请求应用程序编程接口接收网站处的支付信息。动态修改的购买按钮可以与用户支付帐户关联。因此，当用户去某个网站进行购买时，“购买”按钮可以针对他们使用的支付服务进行动态调整。
本案例重点介绍如何在浏览器API上下文中管理多个帐户。在这个方面，该方法包括在浏览器处并且经由浏览器支付请求应用程序编程接口(该接口定义用于在网站和浏览器之间传达关于购买的通信信息的协议)接收通过浏览器或浏览器界面呈现的、具有与用户从网站上购买商品相关的数据的支付请求、用于购买商品的第一支付方式和第二支付方式之间的选择，其中，第一支付方式和第二支付方式各自包括或要求以下之一：存储在用户设备上的支付数据、存储在网络服务器上的支付数据以及支付服务，以从以下方法中的一个接收对支付方法的选择：第一支付方法和第二支付方法产生选择的支付方法，并基于选择的支付方法，并响应于支付请求，从浏览器并经由浏览器支付请求应用程序编程接口传输与所选的网站支付方式有关的数据。这是从浏览器的角度来看的。还可以从商家网站的角度以及从支付方法的角度来涵盖该概念。
另一解决方案涉及凭证管理应用程序编程接口，该接口使网站能够通过API用户从浏览器或基于网络的实体中请求登录凭证，以简化用户的登录过程。在这方面的方法包括从网站在浏览器处并且经由浏览器凭证管理应用程序编程接口接收，该接口定义了用于在网站和浏览器之间传递数据的协议以使用户能够登录到该网站，该请求与使用网站所需的登录凭据有关，根据请求检索用户数据(来自浏览器和/或网络实体)，并从浏览器通过浏览器凭据管理应用程序编程接口将其传输到网站，以响应请求。响应可以包括用户的登录凭据，例如用户名、密码、代码、指纹和虹膜扫描中的一项或多项，或此数据的任意组合，此数据可以使网站登录用户而无需用户手动输入或输入此类数据。该凭证管理API的实施方案可以是从浏览器的角度、从网站的角度或从存储用户数据的网络实体的角度。也可以组合使用一个或多个API，以最终实现通过API将登录凭据传递到网站。
本文公开的另一解决方案涉及如何通过与浏览器的多个应用程序编程接口来管理与支付处理器的支付方法。在这方面，一种方法包括：从用户接收指示希望从商家网站购买商品的输入(输入可以是单击，作为对话框一部分的语音输入、虚拟现实输入或任何类型的输入)，并且基于该输入，在浏览器处并经由第一应用程序编程接口来接收该输入，该第一应用程序编程接口定义浏览器和商家网站之间的第一协议，商家网站对用户购买商品的支付数据的支付请求。
响应于支付请求，该方法包括：从浏览器并经由第二应用程序编程接口通信，该第二应用程序编程接口定义了用于在浏览器和支付服务之间传递支付信息的第二协议，向支付服务发送支付请求事件，其中支付服务可以根据支付请求事件处理商品的支付。该方法包括在浏览器处并且从支付服务并且经由第二应用程序编程接口接收对商品的支付的确认，并且从浏览器并且经由第一应用程序编程接口向商家网站传达对商品的支付的确认。支付服务可以是诸如Paypal之类的服务。该方法以新的方式利用浏览器和几个API实现了商家和支付服务之间的通用接口。
第一应用程序编程接口可以定义用于在浏览器和商家网站之间传递支付数据和地址数据中的至少一个的第一协议。第二应用程序编程接口可以包括第二协议，用于在浏览器和支付服务之间传递与商品支付相关的数据。支付请求还可以包括对用户地址的请求。因此，支付可以由支付服务提供商执行，并且地址可以由浏览器通过第一API提供。
该方法还可以包括：基于支付请求，从浏览器并通过第一应用程序编程接口发送用户地址到商家网站，以用于将商品传递给用户。第一应用程序编程接口可以包括浏览器支付请求应用程序编程接口，因为它涉及来自商家网站的关于支付数据和/或关于用户的其他数据的请求。第二应用程序编程接口可以被称为支付处理程序应用程序编程接口，因为它更具体地涉及支付处理器的支付处理。从商家的角度以及从支付处理器的角度，本公开的这个方面也可以具有实施方案。
本文公开的另一解决方案涉及如何在语音对话中提供商品购买体验。在这方面的示例方法包括经由信使应用程序并且在商家网站与用户之间的对话的一部分中接收来自用户的语音输入，在信使应用程序中呈现与语音输入相关联的用户文本，作为对话的一部分并且由商家网站对具有语音响应的语音输入做出响应，在Messenger应用程序中呈现与语音响应相关联的响应文本，并标识用户希望通过该对话框从商户网站购买的商品。基于用户通过对话框的口头购买交互，该方法包括在浏览器上并通过浏览器支付请求应用程序编程接口接收来自商家网站的、用于购买商品的用户的支付数据的支付请求，并且响应于支付请求，从浏览器并通过浏览器支付请求应用程序编程接口传达用户的支付信息，其中，商家网站使用支付信息来处理商品的支付。
该方法可以包括在浏览器处并且经由浏览器支付请求应用程序编程接口从商家网站接收地址请求，以获取用户的地址数据。响应于该地址请求，该方法可以包括：从浏览器并且经由浏览器支付请求应用程序编程接口将用户的地址数据传送到商家网站。商家网站使用支付信息处理支付。支付信息可以包括商家网站可以用来处理商品支付的用户支付帐户信息。浏览器可以将Messenger应用程序呈现给用户。该对话框也可以是文本对话框，而不是口头对话框。还可以从商家网站的角度要求保护该方法。
其他创新包括使用多种解决方案将技术从搜索字段转换到目标网站，应用浏览器支付请求API来将任何网站转变为“一键式”或比传统方式更少的点击购买体验，以及其他社交媒体创新解决了上述各种问题以及其他问题。
公开了许多用于因特网搜索、浏览和购买过程的不同解决方案。本公开的一个方面适用于多网站通用购物车，并且特别提出了一种解决方案，该解决方案可使用W3C实现的浏览器支付请求应用程序编程接口的修改版本。在一个方面，一种方法、系统或计算机可读存储设备从浏览器的角度进行操作。该方法包括通过与浏览器相关联的浏览器购物车应用程序编程接口接收与第一商品相关联的第一数据，该第一数据与用户使用该浏览器在第一网站上导航的用户所观看到，其中用户没有在第一网站上购买该商品。浏览器可访问的第一个数据。该存储可以通过浏览器，在用户设备上或在网络设备上。浏览也可以在第一设备上进行，该第一设备可以包括移动设备、台式设备、语音接口设备或用户可以用来一般地搜索内容并进行购买的任何设备。该方法包括向用户呈现用于管理第二商品的购买的浏览器支付界面，该浏览器支付界面与浏览器支付请求应用程序编程接口相关联，其中用于用户的支付数据通过浏览器支付请求应用程序编程接口从浏览器传递到第二网站。还可以通过单独的设备访问第二网站，该设备可以是移动设备、台式设备、语音接口设备或任何类型的设备。网络设备可以在用户使用的各种设备之间协调通用购物车。例如，搜索实体可以从移动设备上的第一浏览器搜索中识别放入购物车中的第一商品，然后使用第二设备上的语音指令识别用户，以识别要放入购物车中的第二商品。然后，用户可以在任一设备上或任何时候购买两种商品。该系统可以通过语音识别或通过其他方式来识别用户，以将物品连接为同一用户购物车的一部分。基于语音的设备可以已经与特定的支付帐户相关联，或者可以基于语音标识调整为不同的支付帐户。例如，在家中的用户可以将第一款商品从台式计算机放到通用购物车中，然后送到朋友家。通过社交网络数据或语音/语音识别，用户可以与朋友家中的基于语音的设备交谈，后者可以通过询问“这是玛丽·史密斯吗？”来确认自己的身份，此时用户可以通过语音命令将另一个商品添加到购物车中，然后购买所有商品。社交媒体数据或偏好设置可以使玛丽潜在地使用其朋友的基于语音的设备进行购买。在这些情况下，也可以提供单独的生物识别确认，以确认购买的是正确的人。在一个示例中，当玛丽去朋友家时，基于语音的设备或其他设备可以通过手机识别她。也可以根据玛丽的位置提供地理位置数据。根据此数据，可以将通过搜索实体的基于语音的设备配置为可能期望玛丽通过该基于语音的设备在朋友家中发出购物请求。语音识别模型、说话者识别模型或可能需要发生的任何其他与语音相关的预配置都可以启动或传输到基于本地语音的设备。因此，当玛丽对基于语音的设备说“请在我的购物车中添加纸巾”时，系统可以识别玛丽的语音，使用量身定制的语音识别模型解释语音，然后回答“好吧玛丽，昨天您的购物车中有纸巾，上面放了盐和胡椒粉，您要结帐吗？”。
该方法进一步包括在浏览器支付界面上呈现关于第一商品的信息，并且基于用户与浏览器支付界面的交互或者通过可访问支付凭证的搜索实体进行管理，来处理第一商品和第二商品的支付。可以使用浏览器/设备与第一网站之间经由浏览器支付请求应用程序编程接口的第一通信和浏览器/设备与第二网站之间通过浏览器支付请求应用程序编程接口的第二通信来进行第一商品和第二商品两者的支付的处理。如果多个商品来自单个商家，则基于网络的实体(例如搜索实体)还可以协调向各个商家或单个商家的支付。不同之处在于，第二个网站已经在与浏览器通信以进行第二个商品的支付方法。但是，用户已经离开了第一网站，因此返回第一网站的通信必须识别商品，并向第一网站提供支付和/或交付数据，以“提醒”先前搜索的商品的第一网站。处理第一商品和第二商品两者的支付还可以包括通过浏览器应用程序编程接口传输数据包，该数据包使得第一网站能够处理第一商品的第一购买。数据包可以包括用于第一网站的支付数据以处理针对第一商品的支付以及与用户相关联的地址信息以用于第一网站以交付商品。该方法还可以包括：利用用于经由浏览器支付界面购买一个商品的同一组对象交互，从用户接收对第一商品和第二商品的购买的确认。换句话说，由于用户已经在浏览器界面中用于处理第二种商品的支付，因此该方法可以包括利用相同的“一键式”加上一个指纹识别或CVC代码输入，或使用很少的几个步骤购买第二个商品，也可以处理第一个商品的支付。
当基于网络的实体(例如搜索实体)管理支付时，各种商家可以接收相应的支付和说明，以在指定地址将商品交付给用户。如果一个以上的商家在通用购物车中有商品，则搜索实体可以对可分摊给不同商家的服务收取费用。分配可以基于来自相应商家的每种商品的相对成本。
处理第一商品和第二商品的支付可以包括通过浏览器支付请求应用程序编程接口将第一信息传达给第一网站，以完成从第一网站的第一商品的购买和交付，以及通过浏览器支付请求应用程序编程接口将第二信息传达给第二网站，以完成从第二网站购买和交付第二商品。接收与使用浏览器在第一网站上导航的用户所观看的与第一商品相关联的第一数据还可以包括：基于与第一商品相关联的阈值用户交互来接收第一数据。例如，用户可能需要将第一个商品放入购物车，或单击按钮，或查看商品一段时间，以表明可能有购买兴趣。
从第一网站的观点来看，该方法可以包括：从第一网站并且经由与浏览器相关联的浏览器购物车应用程序编程接口传输与第一商品相关联的第一数据，该第一数据与用户使用该浏览器在第一网站上导航的观看的第一商品相关，其中用户没有在第一网站上购买商品，其中浏览器可以管理存储第一数据，以便浏览器可以访问它，并且在用户从第一网站导航到第二网站之后，从浏览器支付请求应用程序编程接口接收数据包，以处理第一商品的支付，其中，该数据包标识了第一商品，并且可以包括与用户相关联的支付数据，用于处理针对第一商品的支付，其中，用户通过与浏览器支付界面的交互来确认对第一商品的支付，该交互作为使用浏览器应用程序编程界面来管理第二个网站上第二个商品的购买的一部分。在第一网站处接收的数据包还可以包括用于用户的第一商品的交付的地址信息。该方法可以包括所需的任何通信，其从第一网站和第二网站两者进行的用于标识支付方法，传达购物车和浏览器的支付能力、商品数据、与用户在第一网站上的搜索相关联的会话数据、用户数据、支付数据、交付数据、尺寸数据或与处理第一商品的支付或将第一商品和第二商品汇总到与浏览器支付请求API关联的浏览器支付界面相关的任何其他数据，这样就可以通过一个购物车购买来自不同网站的多种商品。
当基于网络的实体管理通用购物车时，商家通常会在实体中注册其商品或注册为商家，以便用户可以使用来自搜索或通过搜索引擎发出的语音请求的商品搜索结果，将商品放入通用购物车中。即使将商品从多个不同的设备放入购物车中，搜索实体或基于网络的实体也可以管理各个商家之间的支付方法。可以将所有设备协调为与同一帐户或购物车或个人相关联。通过识别用户，协调也可以在多个位置发生。
还公开了一种用于管理从第一网站到目的地商家网站的转换以及深度链接状态的方法。方法方面包括：从用户接收与与用于商品或任何种类的通知的广告相关联的对象的交互，该广告或通知是通过在浏览器内呈现的第一网站来呈现的；以及在深度链接状态下将用户从第一个网站转换到目标商家网站。过渡过程包括从浏览器检索数据，并使用来自浏览器的数据以使用户能够在深度链接状态下从第一网站过渡到目标商家网站。深度链接状态使用户可以通过与购买对象的交互来购买商品，而无需手动输入支付帐户数据或用户地址数据。从第一个网站转换后，深层链接状态可以实现“一键式”购买体验。一方面，来自浏览器的数据可以通过浏览器和目标网站之间的API检索或直接访问。数据可以是支付数据、用户数据、一键购买数据、地址信息、浏览器设置、加密货币数据等中的一项或多项。
该对象可以是购买按钮。还可以在第一网站上用户的新闻源(例如Facebook新闻源)中向该对象显示广告。第一网站可以是任何类型的网站或应用程序，例如搜索网站、游戏网站、虚拟现实体验、商家网站、媒体网站、音频网站或社交网站。与目标商家网站上的购买对象的交互可以是与对象交互之后经由浏览器的第一次交互。可以通过目标商家网站和浏览器之间的浏览器支付请求应用程序编程接口自动进行从浏览器中检索数据。在提供与购买对象的交互以从目标商家网站购买不同商品之前，用户可以继续在目标商家网站上购物。来自浏览器的数据可以是以下一项或多项：支付数据、地址数据、一键购买参数、用户名、登录信息、注册信息、用户设置和用户配置文件数据。也可以使用其他数据来促进一键式购买体验。
本公开内容还解决了其他几个问题。例如，存在一个问题，使用户能够在完成购买之前了解有关商品的更多信息并询问有关该商品的后续问题。在某些情况下，一键购买选项或购买选项可能适用于需要一些其他数据(例如尺寸或颜色或其他参数)的商品。用户可能还有其他有关交付、不良宣传、不良评论等的担忧。在这种情况下，可以基于与对象或其他对象的交互，将用户转换为对话应用程序的完整信息，解决用户的顾虑并进行购买。过渡可以在单个网站(例如Facebook)(从新闻提要中的广告到Messenger应用程序)之内，也可以跨越多个网站。例如，如果用户有疑问或需要对商品做出其他选择，则过渡到FacebookMessenger应用程序(或任何对话框应用程序)可以帮助完成购买。因此，可以在过程的任何网站和任何阶段过渡到对话应用程序，以帮助向用户提供有关购买的更多数据。一种示例方法可以包括呈现带有支付方法发起对象的广告。支付方法发起对象可以包括对话应用程序的链接或过渡，在对话应用程序中，用户参与有关讨论商品/商品的对话并完成购买。配置过渡和讨论，以便一旦回答问题或收集信息，便可以轻松支付。浏览器API可以部署在可能发生购买的任何上下文中和任何阶段。任何用户界面(例如Messenger应用程序)都可以被视为“浏览器”，并且可以配置为与网站交换通信以实现购买体验。
就这一点而言，示例方法包括通过社交网站接收物品的发布，使得社交网站接收发布物品并将其从发布实体发送到接收实体。当发布与商品数据库中的购买商品不相关时，该方法包括通过社交网站发送发布，而无需选择购买。当确定指示发布涉及商品数据库中的商品，并因此指示与销售有关的意图时，该方法包括通过社交网站将发布与支付对象或支付发起对象一起发送。支付方法启动对象与商品相关联，并且可以包括按钮，下拉菜单或超链接之一。社交网站接收与支付方法发起对象相关联的交互，该交互由用户执行。基于购买互动，该方法包括与用户进行有关该商品的对话，作为支付方法的一部分，以便在对话结束时，用户可以完成商品购买。在与对话上下文分开的另一方面，系统基于支付交互可以将用户以深层链接状态转换到目标网站，这可以通过访问存储在浏览器中的数据来实现。在另一方面，在目的地网站，用户可以单击目的地网站中的购买对象，可以使用浏览器API来请求和检索用于处理商品支付的支付信息。
当用户转变为对话时，该方法可以包括：作为对话框的一部分，从用户接收购买交互，并基于购买交互来处理商品的购买。处理购买发生在社交网站之一中，通过支付代理或通过社交网站与销售商品的商家网站之间或浏览器与商家网站之间的应用程序接口。社交网站或浏览器可以存储支付数据，以供用户处理购买。当通过社交网站或浏览器与商家网站之间的应用编程接口进行购买时，社交网站或浏览器可以通过应用编程接口传输支付数据，从而商家网站可以处理商品的购买。
该对话框可使用户选择与商品关联的参数。示例参数包括颜色、尺寸、形状、配置和技术特征中的一个或多个。可以在对话框中管理交货选项，解决任何其他问题、礼物问题、折扣、优惠券等。支付方法启动对象可以简单地包括购买按钮或通知“通过单击此处讨论并购买此商品”。可以通过对话框应用程序在用户和商家之间管理对话框。可以通过转换到管理对话框和商品购买的对话框应用程序来实现参与对话框。
本公开中以上解决的另一问题使用当搜索以第一网站上的用户输入字段开始时呈现的对象。新方法改进了将用户转移到第二个网站的机制。公开了一种用于经由浏览器的用户界面接收输入字段中的用户输入并响应于用户输入来呈现对象的第一实例的方法。换句话说，只有在将搜索或数据输入到输入字段中之后，该对象才会显示在用户界面上。这减少了混乱。该对象被配置为使得当用户与该对象交互时，该用户被转换到与该对象相关联的第二网站，并且用户输入被填充到第二网站输入字段中。就像用户在第二网站输入字段中输入用户输入一样，在第二网站处处理用户输入。例如，用户无需在文本字段中键入“amazon”来指示在第二个网站进行搜索。输入可以由系统进行分析以确定要呈现的对象，或者可以始终呈现用户可以选择的替代搜索模式。参考前面解释的omnikey功能，用户可以添加其他第二个网站以进行过渡，每个网站都有其必要的关键词来指示浏览器向何处过渡。这种方法的问题在于，用户将不得不记住与特定网站相关的关键词。“Amazon”很容易记住，但是要输入很多字母。用户可能会忘记快捷方式(例如Wikipedia.org的“wiki”)，或者仅仅是太多。因此，本文公开的解决方案消除了记住特定快捷方式的需要，并且简化了通过简单的点击将用户输入从一个网站转换到另一网站的过程。
本公开内容还解决了以上确定的其他需求。例如，本文解决了改善用户在互联网上的购买体验的需求。填写表格的购物车购买模型需要太多的用户输入和交互，并减少了用户实际完成购买过程的转换次数。公开了一种更新的浏览器，其具有浏览器支付请求应用程序编程接口，该接口用于在浏览器和用于处理购买支付的网站之间传递支付数据，并减少购买过程所需的用户交互次数。该方法包括经由用户界面接收用户与与网站相关联的对象的交互，该交互指示用户意图进行购买。该方法包括基于交互作用并且经由应用程序编程接口接收来自网站的与购买有关的支付数据的请求，并且经由应用程序编程接口将支付数据传输到网站。支付数据可确认购买，或可用于处理或交付与购买相关的商品。支付数据可以包括处理购买所必需的任何类型的支付数据。它可以包括帐号、支付数据的令牌化版本、地址信息、首选项、运输选择、其他用户数据等。
此应用程序包括购买按钮和API的公开内容，这些API和API用于实现“一键式”的购买体验，从而消除了购买过程中不需要繁琐的表格填写过程。在本公开的另一方面，公开了一种API，该API用于在浏览器或代理与商家网站之间传递数据以预填写字段以进行购买。该过程可以进一步完善，不仅包括填写预设字段，还可以进一步简化流程，以减少用户对交互步骤的需求。API方法可以为商家网站提供数据，而不仅仅是自动填写与用户手动输入的表单相同的表单，该数据可以更高级。一种方法包括在通用搜索实体的用户界面上呈现输入字段，以使通用搜索实体使用通用搜索引擎处理数据。搜索引擎对商家网站和非商家网站进行索引和搜索，并在输入字段中接收用户输入。用户输入包括基于文本的查询，并且搜索引擎将基于文本的查询与要从商家出售的商品的商品数据库相关联以产生相关性。基于该相关性，确定用户输入与搜索意图和购买意图之一相关联。当确定指示搜索意图时，呈现包括非商家网站的搜索结果。接收与非商家网站相关联的搜索交互，并且执行到非商家网站的转换。当确定指示购买意图时，呈现包括与用户输入相关联的购买选项的与购买相关的搜索结果。购买相关的搜索结果被配置为使得当用户与购买相关的搜索结果进行交互并通过与购买选项进行交互来确认购买时，广义搜索引擎(或某些其他支付服务)会参与处理商品的购买，并接收与购买相关的搜索结果相关的互动。
该方法可以进一步包括：接收与购买选项的交互；以及基于存储在广义搜索实体(或某些其他支付服务)处的支付信息来管理物品的购买。商品的交付是通过与广义搜索实体不同的商家网站进行的。通用搜索引擎(或浏览器)通过经由应用程序编程接口从商家网站接收对支付数据的请求来参与商品的购买处理，并将支付数据发送到商家网站，以使商家网站可以处理商品的购买。通过浏览器API，浏览器还可以与单独的支付服务进行协调，该服务可以生成令牌或执行该过程的某些部分，并将信息提供回浏览器，以便通过浏览器API通信回商家网站。
在另一方面，一种方法包括在用户界面上呈现输入字段，使得该输入字段与使用通用搜索引擎的处理数据相关联。搜索引擎对商家网站和非商家网站进行索引和搜索，并在输入字段中接收用户输入。用户输入包括基于文本的查询，搜索引擎将基于文本的查询与商家销售的商品数据库相关联。进行关联，并且搜索引擎通过处理器并基于该关联来确定用户输入是否与搜索意图和购买意图之一相关联。当确定指示搜索意图时，呈现包括非商家网站的搜索结果，接收与非商家网站相关联的搜索交互，并执行向非商家网站的转换。当确定指示购买意图时，基于用户与购买相关搜索结果之间的交互来呈现与用户输入相关联的购买相关搜索结果，从而导致显示购买按钮。与购买按钮相关联的物品的购买至少部分地通过经由应用程序编程接口接收对支付数据的请求来管理。根据请求，支付数据通过应用程序编程接口传输到商家网站，以处理物品的购买。该方法可以包括基于来自用户的交互而转变到与购买按钮相关联的商家网站，使得商家网站基于传输到商家网站的支付数据来处理物品的购买。
另一个方面涉及当经由API将支付数据传递到商家网站时从浏览器或搜索引擎侧进行的处理。该方法包括在图形用户界面上呈现演示，该演示是通过网络从网站接收的。它包括通过用户界面并从用户接收与演示的交互，并通过应用程序编程接口从网站接收针对用户的支付账户数据的请求。该方法还包括将支付账户数据传输到网站并经由应用程序编程接口，使得支付账户数据可用于填充支付字段以用于网站上的支付处理，或者使用支付数据执行更高级的处理，以简化用户交互。该演示可以包括用于购买的商品和服务之一。该方法可以包括使网站能够使用用于用户进行支付的支付账户数据来处理对物品或服务的支付。图形用户界面可以与浏览器或应用程序关联。一方面，API在网站(商家网站)和可以存储用户的支付帐户数据的浏览器之间传递数据。
该方法可以进一步包括更新表示以包括购买选项，该购买选项被配置为基于来自用户的确认，以使网站能够利用通过API收到的支付帐户数据来处理商品或服务的购买，而无需用户填写网站上的支付字段。通过API进行通信的浏览器或其他代理也可以为“立即支付”类型的按钮提供图形，以与网站图形集成。支付账户数据可以进一步包括用户的地址数据、支付账户号、有效期、安全码、持卡人姓名和用户的运输指令中的一个或多个。一方面，支付帐户数据可以包括多种支付方法，例如多种信用卡。
通过API进行的请求可以进一步包括以下一种或多种：网站支持的支付方式、购买的总金额、可以显示购买的商品、运送选项、支付修改项、对用户电子邮件地址的请求、对用户电话号码的请求以及对信息更新的请求。与浏览器相似或分离的用户代理可以在应用程序编程接口和网站之间传递支付帐户数据。
在另一方面，从网站的角度来看，该方法包括概念。在这种情况下，该方法包括：为了在图形用户界面上观看而发送演示文稿，该演示文稿是通过网络从网站发送到具有图形用户界面的设备上的，并且通过网络和用户接收与演示文稿的交互。该方法包括：向应用程序编程接口发送对用户的支付账户数据的请求；以及在网站处并且经由应用程序编程接口接收支付账户数据，以及使用支付帐户数据填充与支付流程相关联的支付数据字段，以使用户产生已填充的支付数据字段。该网站可以使用用户的支付帐户数据来处理商品或服务的支付。支付数据可以是用于一次性支付方法的令牌化数据包。API可以协调浏览器和网站之间的数据，以便浏览器存储用户的支付帐户数据。在从用户接收到对与演示相关联的商品或服务的购买的确认之后，该方法可以包括使用接收到的数据处理商品的支付。
该方法可以进一步包括，在接收到支付账户数据时，更新演示以包括购买选项，该购买选项被配置为基于来自用户的确认，以使得网站能够利用支付账户数据来处理商品或服务的购买，而无需用户手动填写网站上的支付数据字段。支付账户数据可以进一步包括以下各项中的一个或多个：令牌、用户的地址数据、支付账户号、有效期、安全码、持卡人姓名和用户的运输说明。演示还可以包括以下一种或多种：网站支持的支付方式、购买的总金额、可以显示购买的商品、运输选项、支付修改、对用户电子邮件地址的请求、用户的电话号码、以及更新信息的请求。用户代理还可以在应用程序编程接口和网站之间传递支付帐户数据。在另一方面，一种方法包括在图形用户界面上呈现演示，该演示是通过网络从网站接收的，并且经由用户界面并从用户接收与该演示的交互。该方法包括：经由应用程序编程接口，从网站接收对用户的支付账户数据的请求；自动填充与具有支付账户数据的呈现相关联的支付字段，并且经由应用程序编程接口向网站发送支付帐户数据。该网站可以根据用户的支付帐户数据处理支付。该方法还可以包括在自动填写支付字段之后，从购买者接收确认。
本公开还解决了管理诸如amazon.com提供的在线购买的用户帐户的问题，但该问题已扩展为关联跨多个不同场所，例如google.com、facebook.com、amazon.com等等。公开了一种API，该API旨在与当前分别管理购买的多种不同类型的网站之间来回传递信息。例如，API可以接收有关通过Google购买按钮(在Google上购买)、Facebook购买按钮、Pinterest购买按钮、Amazon.com购买等进行的购买的转换数据。购买管理引擎接收各种数据，并将数据关联到跨多个购买平台的单个用户帐户。该账户也可以存储在区块链上。本方法与amazon.com用户帐户不同，因为它仅针对在amazon.com上进行的购买而维护，而不针对从不同类型的网站(例如google.com或facebook.com)进行的购买。但是，相关数据可以传输到amazon.com之类的界面，这样，除了在amazon.com上管理购买交易的所有优势外，amazon.com的用户帐户也可以填充google.com、facebook.com、instagram.com、pinterest.com、youtube.com和其他网站购买。完整的相关数据实际上可以在任何传统的非商家网站，单个商家网站(例如walmart.com或widgets.com)以及amazon.com上显示。呈现相关数据的方式与amazon.com一样是用户可定义的，并具有amazon.com并未考虑的其他功能，例如从哪个购买按钮网站进行购买。因此，用户界面可以显示从google.com购买的商品，其次是facebook.com，然后是amazon.com。
因此，本文公开的概念从“微时刻”扩展到仅涉及某人想要购买但扩展机会的那一刻。用户可能会经历的微小时刻可能是希望取消前一天的购买，或者是购买另一种商品(如昨天的购买)的愿望。通过这种方式，通过网站上的下拉菜单或位于购买选项附近的系统，系统可以显示“用户帐户”访问选项，该选项使用户可以访问其帐户并进行进一步的更改/修改。由于相关性和API，可以轻松地在所有平台上进行修改。因此，在一个用户界面上，用户除了可以购买前一天通过Google的“购买按钮”购买的小部件之外，还可以购买其他小部件，以及取消当天早上通过Facebook进行的购买。
由于上述购买通常是在网站(Google、Facebook、Apple Pay、AndroidPay、SamsungPay等)、商家(可能会或可能不会处理支付，但通常会处理交货)和交付服务(联邦快递、UPS等)之间进行协调的，因此本API将根据需要与多个不同的网站和服务提供商进行接口，以协调需要采取的任何行动。因此，可以在购买管理引擎、商家、amazon.com(或类似网站)和购买按钮网站(Google，Facebook，Instagram等)的API的任何一侧划分以下一个或多个操作：(1)处理额外的购买；(2)取消购买；(4)实施“再买一次”选择；(5)提供商品退货；(6)撰写商品评论；(7)；跟踪包裹；(8)更改交货时间表；(9)变更支付方式；(10)投诉；(11)向买方、接收者、商家、送货提供商、购买按钮网站等中的一个或多个发送任何采取的行动的通知。
商品管理引擎可以协调在不同平台上需要执行的各种操作。因此，如果用户通过Facebook网站访问其用户帐户并取消购买，则商品交付引擎可以协调各种操作，例如通知商家、网站、交付服务等，以实现行动。
在另一方面，可以将经由商品管理引擎通过商品管理获得的知识和数据进一步提供给登广告者，登广告者然后可以通过任何网站更智能地提供广告或购买按钮选项。另外，如果用户允许，则可以通过社交网站与朋友或同事共享数据。例如，可以共享有关某个人通常自己购买的商品尺寸或颜色的数据，以用于将来的礼物机会。社交网络上的朋友或同事可以使用商品管理引擎来确定用户过去是否购买过特定商品，以避免将商品复制为礼物。例如，用户可以查询引擎以确定他的朋友鲍勃在过去一年中是否购买了任何乐高玩具。收到查询结果后，可以决定购买乐高玩具套装作为给鲍勃的礼物。
用户可以从中访问用户帐户的“帐户按钮”也可以创造性地呈现给用户。例如，当如本文公开的那样呈现购买按钮时，也可以呈现“管理购买”等。也可以在过程中为此类按钮提供一层或多层。例如，通常在与购买选项交互时，向用户提供有关商品的更多详细信息，有关销售该商品的商家的信息以及通过购买选项(使用此处所披露的从商家网站其他位置存储的购买帐户信息)进行购买的机会。在此阶段(在与购买选项进行交互之后但实际上转换为完整购买之前)，可以显示“管理购买”选项，因为已知用户处于考虑购买的模式，并且他们可能想要检查/管理他们的购买历史。来自他们的购买帐户的信息还可以用于定制广告或响应他们与购买选项的交互的响应的表示。
本文公开的其他创新包括跨网站购物车，该网站使用浏览器API在多个网站上存储购物车条目以进行汇总购买。例如，此方法可以减少在三个不同网站上的三个不同的购买，每个网站可以通过浏览器支付请求API使用单独的一键购买方法，并结合使用浏览器购物车API和浏览器支付请求API，将其汇总为一个单一的一键购买过程。
又一创新包括在诸如虚拟现实、媒体观看等的其他上下文中应用浏览器支付请求API。任何用户界面都可以视为浏览器，并且浏览器支付请求API的基本结构和协议也可以在其他情况下实现，从而可以提供一键式购买机会。
附图简述
图1示出系统架构；
图2A示出示例搜索字段；
图2B示出用于处理用户输入的示例方法；
图3示出根据本公开的一方面的下拉菜单和下拉菜单；
图4A示出根据本公开的一方面的第一示例结果界面；
图4B示出根据本公开的一方面的第二示例结果界面；
图4C示出用于通过语音对话框提供支付选项的方法示例；
图5示出用于呈现与搜索输入有关的一键购买选项的方法示例；
图6示出响应于接收到的用户输入的另一图形结果界面；
图7示出示例系统示例；
图8示出用于处理来自用户的选择的示例方法示例；
图9示出与示例相关联的用户界面；
图10示出用于基于指向从另一源集成的用户界面的输入来执行动作的方法示例；
图11示出用于可修改的输入按钮的示例方法示例；
图12A示出示例可修改输入按钮；
图12B示出具有可修改的输入按钮的输入到输入字段中；
图12C和12D示出当用户键入输入字段时发生的各种变化和修改。
图12E示出随着用户输入输入而发生的修改的方法方面；
图12F示出随着用户输入用户输入而发生的修改的另一方法方面；
图13示出示例用户界面；
图14A示出用于搜索应用程序编程接口(API)的操作的示例方法示例；
图14B示出用于从处理的搜索引擎侧操作搜索应用程序编程接口(API)的另一示例方法；
图14C示出用于从处理的商家方操作搜索应用程序编程接口(API)的另一示例方法；
图15示出经由应用程序编程接口(API)的通信；
图16示出用于示例性修改的浏览器界面的示例性方法示例；
图17A示出示例性浏览器界面；
图17B示出具有预填充标签的示例界面；
图17C示出示例方法；
图17D示出另一示例方法；
图17E示出使用浏览器API的方法；
图17F示出使用浏览器API的另一种方法；
图17G示出用于浏览器API的用户界面；
图17H示出用于浏览器API的另一用户界面；
图17I示出持久性浏览器购物车API；
图17J示出用于购物车浏览器API的方法；
图17K示出购物车的界面；
图17L示出跨网站购物车的方法实施方案；
图17M从网站的角度示出方法实施方案；
图18A示出用于预先填充商家购物车和使用浏览器API的示例架构；
图18B示出用于浏览器API的方法实施方案；
图18C示出浏览器API的又一方法实施方案；
图18D示出从浏览器的角度来看使用两个API来管理支付方法的另一实施方案；
图18E示出从支付处理器的角度来看使用两个API来管理支付方法的另一实施方案；
图18F示出从商户网站的角度来看使用两个API来管理支付方法的另一实施方案；
图18G示出用于多种支付方式选择的另一种方法实施方式；
图18H示出凭证管理API实施方案；
图19示出用于预先填充的商家购物车的示例用户界面；
图20A示出与预先填充商家购物车有关的示例方法；
图20B示出用于从第一网站过渡到商家实体网站和深度链接状态的示例方法；
图20C示出用于从第一网站过渡到商家网站以及从商家网站的观点来看的深层链接状态的另一示例方法；
图20D从商家网站的角度示出用于从第一网站接收转变的示例方法；
图21示出用于将用户意图确定为广义非购买搜索或具有购买意图的搜索之一的方法示例；
图22示出可以与图21所示的方法示例一起使用的一些组件；
图23示出用于基于应用的搜索门户而不是经由网站的搜索的方法示例；
图24示出用于选择接口之间的过渡类型的方法示例；
图25示出用于呈现广告的方法示例；
图26示出用于呈现目的地网站的微型版本的方法示例；
图27示出具有处于预处理状态的各种目的地网站的用户界面；
图28A示出另一方法示例；
图28B示出另一示例方法；
图29示出另一方法方面；
图30示出Facebook方法示例；
图31示出Pinterest类型社交媒体方法示例；
图32示出采购经理的示例环境；
图33示出购买管理器与各个实体之间的进一步交互；
图34A示出具有管理购买访问按钮的立即购买广告；
图34B示出用于购买经理的账户界面；
图35示出用于购买经理的帐户界面的另一示例；
图36示出另一方法示例；
图37示出基于浏览器类型或账户类型来修改购买按钮的方法示例；和
图38示出修改购买按钮的另一示例。
发明详述
以下公开内容描述了与简化在线购买，简化在互联网上的导航，提供统一的输入搜索字段，提供用于改善购买体验的浏览器支付请求应用程序编程接口以及改善社交媒体网络有关的许多不同的创新和其他创新。因此，本公开将从一种创新迈向另一种创新，并且可以结合任何其他特征或示例来利用任何单独的特征。
下面详细描述本公开的各种示例。尽管描述了具体的实现方式，但是应该理解的是，这样做仅是出于说明的目的。在不脱离本公开的精神和范围的情况下，可以使用其他组件和配置。当讨论特定的方法示例时，可以以不同的顺序、组合或排列来实现方法示例的各个步骤，包括附加步骤或排除特定步骤。
讨论的第一个创新是改进了Internet上搜索功能的统一输入搜索字段的概念。公开了一种系统、方法和计算机可读存储设备，其统一对多个网站或其他信息源的访问，使得用户仅需要访问一个位置，并利用一个输入搜索字段来实现许多不同的潜在结果，例如执行搜索或购买商品。该位置可以是网站、Web浏览器中的搜索栏、台式机、笔记本电脑、智能手机、平板电脑或其他移动设备上的应用程序等。用户可以导航到或打开通用搜索字段，而不是导航到网站以在该网站的上下文中执行搜索。搜索字段可以提供对大规模爬行和索引其他网站的搜索引擎的访问，例如GoogleTM、YahooTM或BingTM提供的搜索引擎。在一个示例中，“大规模”可能意味着对至少25,000个不同的域进行爬网和索引。搜索字段可以应用于更大或更小的爬网域。因此，通用搜索引擎可以提供响应搜索查询来提供结果的主要功能，同时提供识别搜索的辅助功能，该搜索可以指示用户进行购买的意图，并提供快速简便的访问权限以使用户根据该意图进行操作。
通过通用搜索字段，系统可以隐式或显式处理和分析来自用户的输入以及所生成的上下文。该系统还可以基于用户的现有上下文的语料库，例如最近查看或打开的网页以及用户在计算设备上执行的最近动作，来进行分析。最近的动作可以包括用户的日历信息、位置数据、最近的购买或其他交易、社交网络数据(包括帖子、发送给朋友的消息、朋友的生日、在YouTube上观看的视频等)。该系统可以将可以提供直接或间接上下文以理解或处理输入的任何信息作为数据源。例如，先前的搜索历史或购买历史可以提供直接的上下文，而用户朋友的社交媒体帖子可以提供间接的上下文。
因此，在输入搜索之后，用户第二次访问该网站。这种方法减少了从用户打开浏览器或应用程序开始到网页购买或搜索结果网页的交互次数。
在另一方面，下拉菜单或下拉“向上”菜单为处理诸如一键购买或使用文本输入作为搜索数据来搜索诸如
之类的特定网站的选项提供了更多得多的机会。这些下拉菜单或“向上”菜单可以基于搜索输入框，搜索按钮或用户界面中某些其他元素的位置。可以在用户输入输入后首先显示可选对象，并且可以在用户界面上的任何位置显示对象。在另一方面，广义搜索字段仍然可以提供来自一个或多个搜索源的“传统”搜索结果，但是除了传统搜索结果之外，还可以呈现用户可以使用的一键式操作，例如，直接从搜索结果列表中进行购买。
本公开通过提供使用户能够提供用户输入并在极少的步骤中实现一组目标之一(例如完成购买、执行搜索、执行程序或与在线服务进行交互)的统一搜索字段，克服了当前搜索实现中的上述缺陷。用户可以将用户输入作为文本或包括多模式输入、手势输入、语音输入等的任何其他适当形式来提供。当本公开内容涉及用户的“输入文本”或“文本”时，应理解为输入可以作为文本提供，也可以通过其他一些输入方式提供。该系统可以使用诸如网页搜索之类的传统选项来处理用户输入，但是另外，该系统可以处理用户输入以识别，呈现和/或执行其他网站上的购买选项或更集中的搜索选项。随着用户输入处理灵活性的提高，系统可以在标签云中显示这些选项，也可以显示下拉菜单，下拉菜单或横向菜单。
下面示出根据第一示例的基本概念。假设示例网站www.one-search.com包含带有输入字段或搜索字段的用户界面。输入字段可以是文本输入字段，或者可以是语音输入字段，例如，它利用语音识别功能将来自识别语音的文本填充到该字段中。该字段可以是浏览器搜索字段。该字段不仅是搜索字段，还是更通用的输入字段，可以基于用户提供的输入的确定意图从中执行多种功能。该搜索字段与其他搜索字段的不同之处在于www.one-search.com搜索字段如何处理输入。通常，一个人进入一个网页，然后搜索或选择一个搜索网站，然后以特定的网站上下文限制搜索字段进行搜索。在本公开中，当用户将数据输入到通用输入字段中时，搜索上下文是打开的。没有任何假设或设置是Google搜索还是Amazon搜索。结果上下文将取决于对输入的分析。用户界面可以包括多个不同的搜索或处理按钮，每个按钮都可以扩展要对输入文本执行的处理类型。按钮的不同类型可以包括Google搜索按钮、Amazon搜索按钮、Amazon一键式购买按钮和Apple.com购买按钮。系统可以预先建立并提供各种按钮类型。替代地，用户可以为用户期望或期望以某种规律性执行的任务设置个性化按钮的集合。系统可以基于用户、当前促销活动、为展示位置付费的广告客户等的一般搜索和活动趋势来生成并显示这些按钮。代替按钮或除了按钮之外，当用户在字段中输入内容时，系统可以将“窥视”呈现到各种网页中，这些网页可以是用户的目的地，无论是搜索结果、购买、拍卖还是其他任何形式其他网站目标。就这一点而言，本公开内容侧重于在一般的输入字段中输入数据，然后进入网站，或进行购买，以及不同的处理方式，而不是先去网站，然后在搜索字段中输入搜索内容。更好的输入。在一方面，仅在用户开始在输入字段中输入数据之后才呈现对象。在用户开始输入内容后，首先在下拉菜单中引入对象(例如，在下拉菜单中)可以减少用户界面上的混乱情况，并提供菜单中要选择的多个选项，这些选项在用户界面上不可行在用户输入输入之前。
假定(例如在亚马逊或拍卖网站的情况下)当用户导航到one-search.com时，用户信息，借记卡/信用卡信息，地址信息等将存储在用户个人资料中并可用，例如Amazon.com上的注册用户。例如，作为注册或注册过程的一部分，用户可以在one-search.com上建立一个帐户，并认证或提供凭据以将one-search.com帐户与其他网站上的帐户相关联。因此，作为使用one-search.com创建帐户的一部分，用户可以提供Google.com、Amazon.com、ebay.com、newegg.com、thinkgeek.com和cheaperthandirt.com的凭据。或者，用户可以在不提供凭据的情况下“链接”帐户。例如，用户可以授权Amazon共享与他或她的Amazon个人资料相关联的全部或部分用户信息，而无需向one-search.com提供Amazon凭证。
然后，当用户在one-search.com上执行搜索时，系统可以使用现有的链接帐户生成一键式操作或一种功能(语音、手势、多模式输入等)操作。例如，当用户与显示的购买选项进行交互时，one-search.com可以执行购买动作。然后，用户可以通过用户门户或用户管理界面管理链接的帐户，以链接其他帐户、更新凭证、删除链接的帐户或管理与one-search.com共享的链接帐户的哪些部分。某些网站可能不需要链接帐户，但仍可以合并到one-search.com搜索字段中。这可以通过经由one-search.com注册帐户处理与该商家关联的商品的支付并允许商家处理交货来实现。某些电子商务网站允许使用访客帐户进行购买，在这种情况下，one-search.com动作可以包括导航到电子商务网站，将所需商品添加到购物车，提供有关用户的足够信息，例如支付信息、送货地址等信息，来完成购买。在另一个示例中，某些网站(例如搜索引擎)在链接到帐户时可以得到增强，但不需要链接帐户。在这些情况下，用户可以决定是将现有帐户与搜索引擎相关联以处理购买交易，还是决定是否使用没有链接帐户的搜索引擎。
one-search.com网站可以检查和使用来自其他网站的浏览器cookie，以收集用户数据，收集搜索历史记录或存储在cookie中或通过cookie提供的任何其他信息。用户支付和地址信息，以及任何其他类型的数据，可以存储在浏览器中或可以被浏览器访问。该系统可以，例如，使用会话cookie来确定用户与特定网站之间有活动会话，或者可以使用该会话cookie中的信息来构造URL，以响应用户提供的输入实现一键式页面的购买。或者，系统可以使用实时会话浏览网站，将所需商品添加到购物车，代表用户填充支付和运送信息，并向用户显示结帐流程的最后阶段，因此用户只需单击“提交订单”按钮一次，或在one-search.com统一输入字段中单击“输入”即可完成购买。这样，从搜索到购买(或从搜索到执行其他操作)的步骤数大大减少了。尽管本文提供的许多示例讨论了购买，但本文公开的原理也可以应用于其他非购买交易。例如，与系统可以导航到网站，用商品填充购物车并代表用户填写运输和支付信息的方式几乎相同，系统还可以导航到某个其他网站，以获取需要提供一组信息的结果。如果用户在输入字段中输入文本“为什么我的信用评分为什么会下降？”，则系统可以识别主要信用报告局、第三方信用报告汇总服务或免费信用报告网站之一。系统可以代表用户自动提供必要的信息，以获取信用评分信息，并响应用户输入，将该页面显示为潜在结果或选项。另一个示例可以包括用户在输入字段中输入文本“血糖”。该系统可以自动登录到已建立的与医疗保健相关的用户帐户(例如MicrosoftHealthVault)，并响应用户输入，将最新实验室报告中的血糖水平作为潜在结果返回给用户。万维网上的许多类似任务都需要从一个页面导航到下一页，然后输入以回答各种问题。one-search.com系统可以缩短或自动化从用户浏览这些系列网页以获取所需信息、所需操作或所需结果所需的输入。
图1示出系统架构100，该系统架构使用户104能够将信息输入到一个搜索系统中，从而减少了用户浏览一系列网页以完成在线购买所需的时间。用户可以通过任何计算机或电子设备(例如智能手机106)与一个搜索服务器102或浏览器界面进行交互。一旦用户通过设备输入了用于搜索的信息，该信息就被发送108到一个搜索服务器。服务器然后可以将用户输入发送112到各种网站110，例如亚马逊、沃尔玛和塔吉特。每个源110可以执行查询或查找以搜索其网站内的用户输入，并且可以将与用户输入有关的信息(例如物品的价格)返回给服务器。以类似的方式，服务器可以将与输入有关的信息返回给用户，因此，例如，用户可以对要购买的特定商品做出更快、更明智的决定。
图2A描绘了示例搜索或输入字段。在此初始示例中，用户在one-search.com200的输入字段202中输入了一个术语，例如“iPhone 5S 32GB silver”。搜索字段可以在任何网站上，也可以是浏览器搜索字段。此时，用户可以单击任意数量的用于处理输入的选项，例如Google搜索204、Amazon.com一键式购买按钮206或Amazon.com搜索208按钮。在此示例中，用户单击Amazon.com一键式购买按钮206。因此，系统从该字段中接收该输入，处理该输入并可以执行购买，就像用户通过Amazon.com浏览到具有32GB存储空间和银色的iPhone5S一样，并且只需单击一键购买按钮。然而，在第一个示例中，用户无需导航到Amazon.com，而是能够从单独的网站(即one-search.com网站或浏览器界面)进行一键式购买。在一方面，用户甚至不需要单击特定按钮，而是可以像用户将执行常规搜索请求那样简单地点击“输入”。据此，系统可以分析文本输入以确定用户希望进行一次单击购买的可能性是否在确定性阈值之上，然后系统可以处理“输入”输入作为执行购买的请求。
系统可以根据单击的按钮来处理输入，就像用户直接在Amazon.com或Google.com上将文本输入到输入中一样，只需单击搜索即可。如果用户单击了Google搜索204，则系统将返回来自Google的搜索结果，但可以类似地提供来自Bing、Yahoo或某些其他搜索引擎的搜索结果。一方面，该系统可以将用户转移到Google.com，使用用户的搜索输入执行搜索，并像用户最初在Google.com上进行搜索一样显示结果。在另一方面，该系统可以在google.com上生成一个URL，就好像该用户已经使用该用户的搜索输入执行了搜索一样，并在google.com上为该用户打开该URL。如果用户选择一键购买206，则系统通过Amazon.com处理商品的购买和交付，就好像用户已通过Amazon.com导航到该商品并进行了购买一样。换句话说，可以基于对用户输入的分析来(动态地和多次)修改“输入”按钮的功能。基于多种因素，初始默认设置可能是购买上下文，但是在用户开始输入数据之后，上下文可能会变为网络搜索，然后最终当用户完成输入输入时，“输入”按钮可能会导致与映射或仅仅是购买上下文相关的处理。
如果用户选择Amazon.com搜索208，则系统返回在Amazon.com上针对该短语的搜索结果的视图。换句话说，用户可以被转移到Amazon.com，登录到其帐户或加入该帐户的现有会话，并显示与该状态等效(或本质上或功能上等效)的屏幕，就像用户在Amazon.com上搜索“iPhone 5S 32GB银”。另一方面，系统将访问存储在浏览器中的数据，以促进在深度链接状态下从搜索字段过渡到Amazon.com，这样用户就可以简单地单击“一键购买”按钮并购买商品。从这种状态下，用户可以仔细阅读商品的返回列表，然后可能选择商品，此时用户可以“一键式”购买一部iPhone。将用户深入过渡到已预处理为特定状态的单独网站可以称为深度链接。这是一个用户不会转移到顶层、或主页、一个网站(如www.amazon.com或www.merchant.com)。取而代之的是，对过渡过程进行预处理，以使用户被带到网站的较深部分，例如网站的第二层或第三层。www.merchant.com/products/hats/greenhat是一个过渡到较低级别或网站较深层的示例。用户将转换为网站内的第四级，而不是顶层或主页。在这种情况下，用户可以更快地完成购买。如图18A所示，可以将来自浏览器1806的数据(支付数据、用户数据、一键设置、地址数据、注册数据等)作为过渡的一部分来访问，以使得能够在深链接状态下登陆商家网站1816，使得下一次交互可以是单击交互。
确实，在一个示例中，系统可以将用户重定向到Amazon.com(或代表用户导航到Amazon.com)，就像用户已经从Amazon.com开始并输入搜索词一样。在这种情况下，one-search.com的算法将接收搜索输入，从用户处接收所需的指令(通过单击Amazon.com搜索按钮)，然后将用户转换为Amazon.com。存储在Cookie或其他位置或通过XML发送的用户注册信息或Web浏览状态信息也可以被读取或传输，以便在过渡期间将用户登录到其Amazon.com帐户。数据可以使用one-search.com或浏览器或应用程序进行存储。此过程的结果是，当用户打开浏览器以开始浏览Internet时，系统使用户可以通过单个统一的输入字段来发起任意数量的搜索，购买或其他操作，该字段只需较少的点击或用户输入即可获得搜索结果或进行购买。
此外，从浏览器上搜索字段的角度以及系统如何将用户从浏览器搜索字段转换到目标网站的角度来看，浏览器功能可以是浏览器本身的固有功能，或可以通过与目标网站相关的插件或扩展程序来增强或启用。例如，维基百科、eBay、亚马逊、搜索引擎等可能会与浏览器实体相关联地开发扩展，在扩展中，通过API或其他某种方式，浏览器会将数据传递到目标网站以促进转换。例如，Amazon.com可能提供AmazonAssistant的可安装扩展，当与浏览器一起安装时，使用户信息与Amazon.com的通信得以实现，从而可以实现本文所述的功能。该扩展增强了浏览器的功能，并成为浏览器的一部分。浏览器执行在输入字段中接收用户输入的过程，并基于用户输入，显示一个下拉菜单(或界面上某处的对象)，其中显示了可选对象的第一个实例，该对象与目标网站相关联。从用户处接收到与对象的交互后，用户将自动转换到目标网站。目标网站被预配置为与用户已经将用户输入输入到目标网站输入字段中的用户等效的状态。用户将在目标网站上转换为该状态。在某些情况下，例如与Amazon.com一样，如果用户也登录到目标网站，则可以将信息传达给目标网站；如果合适，可以配置状态，以便显示与用户输入关联的商品。用户可以单击“立即购买”按钮并进行购买，而不会中断用户与目标网站的交互。在另一方面，为了达到购买状态，可能需要一些交互。在此状态下的交互量少于手动转换到目标网站(如Amazon.com)，在amazon.com输入字段中输入用户输入，点击Enter并继续与网站互动以获取购买机会。
因此，一方面，本公开涉及一种浏览器或通过安装在浏览器上的扩展来增强的浏览器功能。此外，权利要求书可以从浏览器的观点以及从接收来自浏览器的转换的目的地网站的角度解决功能，并且预处理用户输入以便在适当状态下在目的地网站接收转换用户。
另一个示例进一步简化了该过程。通常，如上所述，网站(例如Google或Amazon)具有一个单一目的的条目，以便用户可以单击“输入”，并将文本作为GoogleWeb搜索或Amazon商品搜索进行处理。在第二个示例中，搜索字段具有多种处理输入字段中文本的可能方式。一种算法分析并处理输入，以确定或预测文本输入的含义或用户意图。通过这样的分析，系统确定用户想要什么类型的搜索或动作。因此，如果用户在one-search.com或浏览器上的搜索字段中键入“Olympics”，则系统可以通过算法确定用户不太可能希望在Amazon.com或eBay上搜索“Olympics”，因为Olympics不是可以购买的东西。但是，如果用户输入其他信息，例如“Olympics Windbreaker Sochi 2014”，则系统可以修改意图的确定，因为用户输入的附加信息现在指向特定的商品或类别。因此，系统可以基于提供的文本或数据连续评估或确定用户的意图。例如，当输入每个字符或单词时，系统可以立即重新评估意图。该系统可以基于用户的上下文信息和到目前为止提供的数据，针对许多预期的意图场景预期意图并缓存或预加载结果或动作。因此，如果预期意图(即Google搜索与Amazon购买与Amazon搜索)是正确的，则系统已经具有适当的组件或已提取页面以服务于该意图。在这种情况下，用户将更快地收到与其输入有关的结果。
系统可以使用任何类型的数据，例如用户个人资料数据、一键购买设置、社交媒体数据、历史数据、一年中的时间(假期、夏天、朋友或家人在一个星期内有生日等)来做出此确定。在该示例中，系统可以确定用户何时单击“输入”，表明用户打算对该输入进行Google搜索。例如，如果用户键入“Paul Revere American Revolution”，则系统可以检测到语义内容和文本结构与信息搜索(而不是商品搜索)更紧密地对齐，并且可以通过搜索引擎。在这种情况下，将显示用户输入了Google搜索的主要结果。如果用户实际想要Bing搜索或确实想要Amazon.com搜索，则one-search.com结果屏幕还可以提供替代项。如果用户将该信息输入到one-search.com的搜索字段中，则系统可以使浏览器在用户按Enter键时导航到google.com，就好像该用户最初是在Google上搜索该搜索字符串一样。或者，系统可以将相应的Google搜索页加载到iframe中或网页中的其他嵌入式机制中，也可以加载为新标签页或窗口。即使用户在one-search.com页面上发起了搜索，该系统也可以利用多种转换中的任何一种向用户展示Google搜索页面。
另一方面，如果用户输入“高档茶壶”，则系统可以分析输入文本以确定用户可能希望进行购买。因此，当用户点击“输入”时，系统可以将搜索路由到亚马逊或另一个合适的电子商务网站，或者可以基于搜索立即从亚马逊执行一键式购买。确定用户意图是购买后，系统可以对用户的购买习惯或其他与购买相关的信息(例如最低价格、最低价格加运费、可用性、运送时间或方法、购物俱乐部的用户成员资格、用户拥有在线商家的帐户，依此类推)进行分析或依赖于先前执行的分析。基于此分析，系统可以确定哪些零售商超过了意图阈值，并为用户提供了轻松访问这些零售商的方式。该系统可以按照用户期望的可能性的顺序对零售商进行分类，并且可以限制呈现给用户的零售商的列表。例如，可以基于价差，向用户呈现选项的可用屏幕空间或其他因素来限制列表。
在这些原则的示例中，用户将文本“大至尊比萨饼”输入到one-search.com输入字段中。该系统可以分析用户的浏览器历史记录、在one-search.com上的先前查询、各个比萨饼递送地点的用户帐户、用户和附近比萨饼递送地点的位置、比萨饼购买的信用卡交易数据等。根据此信息，在用户按下Enter键和/或进行中间查询之前，one-search.com可以确定附近的Domino、Papa Johns和Pizza Hut已打开，并且用户在过去六个月已在其中进行购买。然后，系统可以显示这些商家中的每个商家的预览，以便用户只需单击一次即可下达大的最高比萨饼的订单。可以通过浏览器支付请求API处理支付数据。one-search.com系统可以显示每个披萨商家的徽标，以及如果用户单击徽标将要下的订单和相关成本的摘要。例如，该系统可以在“多米诺骨牌”徽标下方显示“16”最大的比萨饼，价格为16.24美元，该比萨饼于下午6:15递送至俄亥俄州斯普林菲尔德的123Fake Street,然后，用户可以单击Dominos徽标下订单，或者可以直接与one-search.com页面或Dominos网页进行交互以修改订单的各个方面，然后再下订单。当用户在搜索字段中键入其他信息时，one-search.com系统可以动态更新预览。one-search.com系统还可以提供“默认”操作的指示，如果用户按下键盘上的“输入”，该操作将被执行。这样，当用户对默认结果感到满意时，或者在用户输入文本后仅剩下一个结果时，用户只需按“enter”(输入)，系统就可以执行操作，例如下订单订购披萨。
在另一个示例中，用户在one-search.com中输入术语“iPhone 5S 32GB银”(对“one-search.com”或类似网站的任何引用也可能表示浏览器用户界面或任何界面)。系统可以分析文本，以基于特定的详细信息量确定此搜索明确针对商品，以标识可以购买的一个或几个商品。此外，如果搜索是在12月8日执行的，则由于圣诞节或其他节假日的送礼气氛，可以特别调整系统使其更敏感地识别购买请求。该算法可以分析先前对各种iPhone的搜索，以确定基于运行该算法的iPhone，哪些将导致阈值被传递，表明用户极有可能希望购买该商品而不是仅仅搜索它。当用户单击“输入”时，系统会处理该输入，就好像用户正在Amazon.com上查看iPhone 5S 32GB银一样，可以选择“一键购买”。在这里，通过将该数据输入到one-search.com字段中并单击“输入”，系统可以代表用户在Amazon.com上执行步骤，就好像用户已经完成了该商品的购买一样。系统可以通过HTTP请求执行这些操作，就像用户已经导航到网站并自己输入信息一样，或者系统可以通过已建立的API与各种Web服务进行通信。系统可以通知用户已下订单，并向用户提供任何运输或订单详细信息。或者，系统可以将用户直接转换到Amazon.com环境，或显示用户界面，通知他们购买正在由网站处理，该网站通过用户配置文件数据处理商品的购买和交付，如在Amazon.com或Apple.com等上可以完成的那样。
在一个示例中，用户可以在系统代表用户下订单之前确认订单。在另一个示例中，系统自动为用户下订单，用户可以选择不进行任何操作来接受订单，或者通过提供一些输入(例如点击按钮或在新标签页或新窗口中打开订单页面)选择拒绝或修改订单。在一个示例中，系统可能已经订购了银色iPhone 5S，但是用户改变了主意，想订购金色iPhone 5S。用户可以直接在one-search.com上修改订单，或者one-search.com可以将用户重定向到Amazon.com以修改订单。卖方可以竞争处理此输入的业务，并且系统可以报告谁出价最低。该系统可以通过在一定时间内取消购买为用户提供“退出”服务。以类似的方式，系统可以检测到用户刚刚订购了iPhone5S，并实施了“冷静期”，在此期间，未经用户的其他或明确许可，系统不会代表用户自动订购其他iPhone。
系统可以限制或确认看似错误或无意的订单。例如，如果新用户不了解系统的工作方式，则他或她可能会多次搜索32GB的iPhone 5S银，而无意中订购了多部电话。该系统可以具有内置机制来检测这种潜在的无意购买模式，并在检测到此类模式时代表用户进行购买之前，结合一定程度的用户认可或确认。用户可以在帐户上建立安全措施或购买限制，以使孩子或未经授权的人无法进行超过特定支出限制的购买，或者超过阈值的购买需要通过电子邮件或短信或其他机制进行身份验证。如果系统检测到未经授权的购买，则系统可以暂时停止或阻止整个one-search.com帐户或特定登录位置的购买交易。
使用“输入”按钮并基于预测的意图处理输入可能会导致歧义。当用户通过Amazon.com搜索商品时，该用户导航到具有所需大小、颜色、载体等的正确模型。然后，当用户进行Amazon.com一键式购买时，用户会在购买前了解有关该商品的所有数据。在本文公开的模型中，系统还可以处理商品的歧义。假设用户在one-search.com上输入“iPhone 5S32GB”，并且可用颜色为黑色、银色和金色。该算法基于输入文本确定用户可能希望进行购买并相应地处理输入文本。系统可以选择最流行的颜色并相应地填写该未知参数。该系统不仅可以根据流行的大小和颜色选择最受欢迎的模型，而且系统可以合并人口统计数据以确定与用户相似的人的最受欢迎的模型。例如，如果用户输入“iPhone 5”，则系统可以为少女选择黄色的16GBiPhone 5C，或者为父亲选择黑色的64GB iPhone 5S。该系统可以进一步分析过去对类似或相关设备的购买，以确定该购买的可能的用户偏好。如果用户已经注册，并且可以通过浏览器、应用程序或网站进行注册，则系统知道谁在进行搜索，然后可以基于多个网站上的先前搜索结果使用用户首选项，历史记录和分类模型等来分析一键式输入字段。如果用户过去购买的电子商品都是白银，则系统可以假定用户可能想要白银iPhone5S，并相应地填充购物车。同样，如果用户在以前购买移动设备时始终购买最大的存储容量型号，则系统可以自动使用存储量最大的iPhone 5S填充购物车。
返回上面的示例，用户单击“输入”，系统显示一个用户界面屏幕，指出“您已经购买了黑色的iPhone 5S 32GB-如果要购买银色，请按Enter。”换句话说，系统可以选择最流行的颜色，并提供一个选项，可通过再次单击“输入”来更改颜色等参数。第二次点击“输入”将取消黑色iPhone的先前订单，并用银色的iPhone代替，否则系统可以简单地更新购买请求。在此过程中的那个时间点，就好像用户正在查看具有正确功能的银色iPhone并单击“一键购买”按钮一样，因此无需采取其他任何操作即可对其进行充电和交付。该系统可以通过API与商家集成，以保留特定商品，例如黑色iPhone 5S 32GB，同时等待一段时间以允许用户在提交或完成购买之前修改订单。
该过程也可以重复。系统可以向用户显示“您现在已经购买了32GB的银色iPhone5S–如果要购买金色的，请按Enter键。”这次单击Enter将取消银色iPhone的订单，并用金色iPhone替换它。如果用户在此阶段不执行任何其他操作，则系统将提交金色iPhone的订单，商家将执行该订单，以便用户将收到金色iPhone，商家将以正常方式向用户收取订单费用。当然，可以为用户提供按钮点击，以更改各种参数并更改顺序。界面上会显示“您已购买了iPhone 5S 32GB黑色-要更改任何这些参数，请单击此处。”系统可以显示各种选项来更改存储大小、型号、载体、颜色、运输选项等。但是，如果用户什么都不做，系统使用预测的参数代表用户安排并向商家下订单。可以理解，该过程使用户从打开浏览器或应用程序时起就能够以比以前所需的更少的交互作用或更少的步骤成功地购买所需商品。
在另一个示例中，该系统可以包括在一次搜索的上下文中或在Amazon.com、one-search.com或购买者已注册数据(例如，信用卡、地址等)的任何其他网站。网站搜索字段可以包含“自动完成”，这样，当用户键入搜索字词时，自动完成功能可以自动完成用户可能需要的概念，也可以根据当时输入的文字显示建议或推荐选项的列表。用户可以查看各种自动完成选项并选择一个，从而减轻了继续输入其余查询的需要。在此示例中，系统通过输入字段接收部分用户输入(或全部输入)，并且在分析用于生成自动完成选项的输入时，系统可以在自动完成选项列表中包括“一键式”购买选项。因此，选项可以从文本的第一部分的默认模式和文本的第二部分的第二模式改变。换句话说，如果用户输入文本“iPhone”作为部分用户输入，则在该阶段，系统可以识别并显示“iPhone 5S 16GB<一键式购买>”作为“自动完成”选项之一。在这种情况下，修改后的自动完成功能列表会减少点击次数和来自用户的文字数量，从而可以购买该商品。换句话说，下拉或下拉(或用户界面上的任何其他位置)功能不限于寻求标准自动完成功能的概念，而是将自动完成功能与购买选项或其他选项(例如跳转到其他网站)混合在一起。通常，用户会选择自动完成选项之一，这将使用户进入一个商品或一个商品列表，然后用户必须再次单击以缩小到一个特定的商品，然后用户可以“一键式”购买该商品。但是，如果用户单击自动完成列表中的“一键购买”变体，则系统可以立即下订单。可以在下拉菜单中显示一个对象，以过渡到另一个网站，例如Wikipedia.org。先前的方法要求用户在输入字段中键入更多数据以进行转换。例如，以前在Safari上使用的方法要求用户键入“amazon摄像机镜头”，这会向浏览器指示输入是为amazon.com进行的，并转换为amazon。但是，要求键入额外的字母以向浏览器提供指令，这可能需要更多的输入和步骤，然后才需要手动转换到第二个网站。因此，本公开提供了待呈现的对象，其可以作用于输入字段中的确切文本，而无需键入告诉浏览器过渡到哪里的关键词指令。这些对象可以显示在任何地方，并且可以动态显示，以使它们在输入字段中没有文本时不可见或呈现，但在用户开始键入后或在评估输入的第一部分后首先呈现。
系统可以通过输入字段列表显示各种一键式选项。例如，如果在输入“iPhone”的阶段中最受欢迎的iPhone是5S，32GB，银色，则系统可以将该选项(带有一键式购买选项)放在要购买的自动完成选项列表中的高位或第一位。下一个最受欢迎的型号可能是黑色的16GB iPhone，系统可以在自动完成列表中显示该型号。竞争对手还可以在自动完成列表中提供一键购买的报价。菜单中的位置还可以随着用户的输入以及一个选项变得更有可能成为所需选项而动态变化。输入字段下方的选项可以是用户单击“输入”键时提供的选项，即，无需单击任何对象。竞争者可以购买展示相关的自动完成一键购买选项的权利，但不包括搜索到的文本。例如，当用户搜索“iPhone”时，系统可以显示自动完成条目，以一键式购买“三星GalaxyS4”。系统可以在这些自动完成列表中进一步显示促销材料。但是，由于空间有限，促销材料可能会受到限制。此类促销活动的一个例子是在Amazon.com上自动完成的列表广告“三星Galaxy S4–20％的折扣(<一键式购买>)”。公司可以在自动完成列表下购买广告空间，也可以支付溢价以提升其在自动完成列表中的商品的特定关键字、特定商品、品牌等。但是，系统也可以使用商业情报或来自各种商家的反馈，在自动完成选项中包括基于人们最终搜索商品X最终购买商品的结果，即使自动完成选项不包括所搜索的文本也是如此。
同样，该系统可以跟踪用户的行为，并可以为广告商定价，从而吸引某些用户的注意力。例如，如果用户每天都在研究智能手机几周，那么旗舰智能手机的广告客户可能会支付更高的价格溢价，以自动完成选项形式投放广告来吸引感兴趣的订婚买家，因为用户最近花了很多时间研究智能手机，并且可能会在不久的将来进行购买。根据导航的历史记录，菜单可能会在菜单中显示较高的相关商品，因为它更有可能代表用户所需的操作。
系统可以在自动完成选项的下拉列表中提供“一键式”购买选项。此外，自动完成功能还可以包含一个列表，如果用户选择了该列表，则将用户置于在商家网站上的一键式购买之前的一个步骤中。换句话说，如果用户在类似Amazon.com的网站上输入“iPhone5S”，则Amazon.com会向用户显示许多商品清单。用户必须单击这些商品之一才能将结果缩小到单个商品，此时，点击计数是在“单次点击”购买的情况下开始的。在查看单个商品时，将为用户提供“一键式”购买选项。这样的上下文(包括用户成功登录Amazon.com)将被描述为“一键式”网页，其中用户已导航到识别商品的位置，并且上下文使用户可以一键式购买。问题在于，进入预点击页面需要太多的点击和互动。
因此，自动完成列表可以为用户提供一种简单的方法，使用户立即跳转到商家网站中的“预点击”阶段。自动完成列表不仅可以在该阶段包含“一键式”购买选项，还可以包括将用户带到“一键点击”购买页面的选项，此时通常会有关于商品的更多信息、更大的图片、评论、评分、商品详细信息等等，以便用户可以做出更明智的购买决定。对于知名商品，用户可以做出一键决定，直接从自动完成列表中进行购买，但是对于其他商品，用户可能希望验证该商品是否适合预期目的或与其他用户需求兼容。单击自动完成选项的先前结果是对该选项进行处理，就好像它是在输入字段中输入的搜索一样。但是，这将返回搜索结果列表，而不是带有准备购买的一项的“预单击”页面。因此，此替代功能减少了进入预点击购买页面所需的交互次数。
购买自动完成类型选项可以显示在下拉菜单中，搜索或传统自动完成选项可以显示在下拉菜单中。要选择的对象可以显示在用户界面上的任何位置。多模式交互也可能发生，包括音频、手势或其他可能的交互模式。换句话说，列表的方向性可以指示所列出的商品的功能。方向性可以是并排的，也可以是其他方向或角度的。例如，各种一键式购买和一键式自动完成列表都可以下拉菜单，但方向成45度角。该系统还可以在标签字段或标签云布置中显示选项，其中最可能的选项显示在最靠近输入字段的位置(从鼠标的角度来看，它们将是最快、最容易访问的位置)，并且具有最大的图标、文本、图形或其他可视提示以供选择。
如上所述，浏览器或搜索引擎还可以配置为将用户转换到任何第二网站，并对用户在输入字段中的输入进行预处理，就好像用户已经搜索了第二网站并按Enter来处理输入一样。本公开涵盖了在用户已经将用户输入输入到第二网站的输入字段中的状态下容易地将用户转换到第二网站。就这一点而言，图2B所示的示例方法包括：经由浏览器的用户界面和经由处理器来接收输入字段中的用户输入(210)；以及响应于用户输入而呈现对象(212)。一方面，当输入字段中没有输入时，该对象不呈现在界面上。对象的第一个实例可以在提供一些输入之后，或者在系统根据用户输入识别出应该显示对象时。这将减少界面上的混乱。配置对象，使得当用户与对象交互时，该方法包括将用户转换到与对象相关联的第二网站(214)，将用户输入填充到第二网站输入字段中(216)，并使用户输入在第二网站处被处理，就像用户在第二网站输入字段中输入了用户输入一样(218)。该对象可以显示有图像，该图像指示将在何处处理输入以及浏览器将用户转换到何处。界面可以呈现一个或多个对象，多个对象中的每个对象都包括一个不同的一键式搜索引擎，当用户与每个相关对象进行交互时，用户将转换到该引擎。在这方面，“一键式搜索引擎”可以包括用户将转换到的任何其他网站，例如yahoo.com、bing.com、amazon.com(即，任何商家网站)、ebay.com、Wikipedia.org等。可以根据此概念转换具有输入字段的任何其他网站。用户可以选择目标网站列表，这些列表将作为下拉菜单的一部分显示，或者是响应第一个网站输入字段中的用户输入而显示的商品。这些步骤可以包括转换、填充和引起步骤，以使用户转换为处于用户已将用户输入输入到第二网站输入字段中并且第二网站已经处理了用户输入的状态下的第二网站。为了区别于要求用户键入诸如“Wiki”或“amazon”之类的关键词以向浏览器发信号通知第二网站的现有方法，本发明的概念不需要这种发信号，而是提供用户可以单击或与之交互的对象，以处理第二个网站中确切的用户输入并转换到第二个网站。此外，在先前的方法中，如果希望进行常规搜索(例如，特别是在“amazon相机镜头”上)，则要求用户在输入字段中键入诸如“！”之类的符号。显然，此方法所需的额外步骤并不理想。本公开减少了进行过渡所需的击键次数和输入。每个减少的步骤或按键都非常有价值，尤其是在移动设备搜索中。确实，应用先前的方法会出现问题，因为如果精确地将amazon.com的搜索结果准确地应用于amazon.com的输入字段而不是用户期望的结果(即“cameralens”)，则使用精确术语“amazon相机镜头”的搜索可能会返回。
搜索引擎网站可以从浏览器搜索字段、应用程序、任何其他实体或具有输入字段的任何网站(例如，从amazon.com开始并过渡到google.com)来执行此过程的步骤。例如，浏览器通常在标题部分具有输入字段，可用于搜索Internet。用户可以选择该输入字段的默认搜索引擎是google.com、yahoo.com还是其他搜索引擎。但是，浏览器还可以提供一些选项，这些选项在显示时(如果是动态显示)，由用户单击或与用户交互时，会导致过渡到预先配置的第二个网站(具有其自己的第二个网站输入字段)，以便用户输入填充第二个网站输入字段，并且处于该用户输入已由第二个网站处理的状态。显然，这为用户提供了一种有效的方式来导航并从通用搜索引擎中获得他们想要的结果。
另一方面包括经由浏览器的用户界面接收输入字段中的用户输入，以及响应于用户输入而呈现对象。配置该对象，以便单击即可将用户转换为以某种方式进行预处理的另一个网站。用户输入被传递到第二网站，并且基本上自动地填充到第二网站输入字段中。后台过程涉及浏览器或系统，导致用户输入在第二输入字段中输入，从而第二网站处理输入并返回响应，从而第二网站基于用户输入处于已处理状态。然后，系统将用户转换到与处于处理状态的对象关联的第二个网站。这减少了用户从一个网站转换到另一个网站所必须进行的交互次数。呈现对象，以便在输入用户输入后，只需单击一下即可转换到处于处理状态的第二个网站。这与简单地在输入字段中用用户输入击中Enter并获取搜索结果不同，用户可以从中单击搜索结果并转换到另一个网站。
图3示出示例一个搜索字段和下拉菜单特征300。在该示例中，单个字段302(可以在网站或浏览器输入字段上)使用户能够提供输入，系统分析该输入以识别除可用搜索之外的其他选项。在该示例中，用户在字段302中输入“iPhone 5S”。算法分析该输入以识别出搜索针对的是商品。该系统可以访问当前商品、购买模式、商品受欢迎程度、用户或其他用户的购买历史、商品可用性等数据库。系统可以通过对一个或多个商家数据库的API调用来访问数据库。该算法可以使用该数据来更准确地确定用户是要搜索还是要购买特定商品。在这种情况下，输入“iPhone 5S”显然是商品，因此此知识将有助于驱动和控制下拉菜单选项的构建。
由于字段302中的用户输入是商品，因此示例下拉菜单选项可以包括标准的Google搜索304。尽管这是第一个选项，但如果算法确定用户不太可能希望进行Google搜索，则系统可以安排下拉菜单将该选项放低。例如，系统可以呈现更接近输入字段302或更接近鼠标光标的选项。如果用户选择该选项，则返回的结果就像该用户已输入“iPhone 5S”作为Google搜索一样。下拉菜单可以包含Amazon.com一键式购买选项306。如果用户选择此选项，则系统可以像处理用户正在使用Amazon.com上一样搜索iPhone5S，然后在用户可以选择“单击”的屏幕上为用户执行商品购买。在另一个变体中，系统可以直接从下拉菜单或下拉菜单在单次搜索页面上显示一键式选项。因此，用户可以单击按钮、图像或链接来向Amazon.com下订单，就好像用户已导航到Amazon.com上的一键式点并单击“立即订购”按钮一样。在这种情况下，图4A示出从选择选项306呈现给用户的结果屏幕400。屏幕400包括数据402，该数据通知用户已经通过Amazon.com购买了iPhone 5S。当未提供颜色时，系统可以为用户或相似用户选择最可能的颜色。在这种情况下，系统选择了银色。购买数据还显示了32GB的存储容量。
在由于人们可能按下错误的键或选择了错误的下拉菜单选项而进行的不必要的购买或意外购买的情况下，系统允许用户取消购买404或修改购买406。用户可以根据商品修改任何数量的不同选项。通过示例显示的选项包括将颜色从银色更改为金色或黑色。同样，系统可以显示将存储大小更改为16GB的选项。诸如“添加附件”之类的选项可将用户带到另一个交互式屏幕，以选择诸如充电器、手提箱和车载支架之类的附件。系统可以基于每个选项的置信度得分确定要显示的修改选项以及显示它们的顺序。统计置信度得分可以由系统使用过去的购买或用户偏好来确定。例如，系统可能对用户想要银色iPhone 5S的置信度得分为95％，并且可能不会显示用于修改颜色的选项，或者可能会以不太显眼的位置或方式显示该选项，或者可以提供通过菜单或其他“隐藏”位置更改颜色的选项。该方法可以允许系统向用户呈现购买或商品选项，使得用户仅关注并且可以容易地修改系统不太确定的选项。可以通过一个对象来呈现其他选项，该对象启动购买过程，但从用户那里收到有关商品功能的其他选择，或者与用户进行对话，然后在对话后完成购买(也许购买是在对话框应用程序中处理的，如下拉菜单或单独的对话框应用程序中)。系统可以显示选项，不仅可以修改有关实际商品本身的详细信息，还可以修改订单周围的详细信息，例如交货地址、账单地址、支付方式或交货方式。例如，如果用户无意中单击了下拉菜单中的错误菜单项，则系统甚至可以允许用户将订单从一个商家切换到另一商家。
如字段402所示，如果正在处理购买的实体是Amazon.com，则系统还可以提供一个通过Apple.com处理购买的选项。如果选择了这些选项中的任何一个，则用户选择修改按钮408，并且订单被修改并自动继续进行处理。当然，该系统具有用户资料、购买(信用卡/借记卡/PayPal等帐户)、地址和任何其他信息，并且可以轻松地在购买/处理实体之间无缝移动。当用户在网站上设置配置文件和帐户时，将建立并批准权限和可访问性功能。以这种方式，可以根据需要划分实体之间完成购买的操作。因此，在购买实体和处理实体之间无缝移动操作的示例可以包括通过允许在一个实体(例如Google)注册的支付帐户用于支付商品的系统来处理商品的购买和交付交易，而该系统与另一处理实体(例如商家或零售合作伙伴)协调以处理订单的处理。如下所示，在购买/处理实体之间的过渡还可以包括过渡到对话应用程序，该应用程序可以启用用户和商家之间的对话，然后在对话应用程序中完成购买。
图4A还示出关于过渡或使用对话框来解决购买者的担忧或使购买者能够通过附加交互而不是简单地“立即购买”选项来选择特定参数的另一方面。如导言所述，在某些情况下，与用户的个人互动可以帮助解决问题，并提供在完成购买之前选择特定参数的选项。本公开提供了用于容易地实现该输入然后有效地完成购买的多种解决方案。例如，图3还示出从输入字段到下拉菜单的过渡，该下拉菜单被配置为使得可以选择物品的参数，并且在过渡的位置(在这种情况下为下拉菜单)中构建购买交互。对于更详细的问题，用户可以过渡到一个对话框，该对话框也配置为与用户互动以接收或提供更多信息，然后可以通过对话框界面处理实际的购买。图4A表示更全面的对话框，用户也可以在其中选择其他选项。对话框可以是SMS应用程序、电子邮件应用程序、社交网络中的Messenger应用程序、以自然语言系统与用户交谈和交谈的化身等。因此，从“过渡”到可以进行最终购买的对话框可以包括一个下拉菜单项，该菜单项配置为接收有关该商品的更多参数，然后完成购买、发短信对话框、口语对话框、视频对话框等。浏览器API可用于处理到网站的支付数据，作为在消息传递应用程序或漫游器中进行交互的一部分。
提供以下示例，说明如何在社交网络中管理此类对话过程。在系统如何作为支付方法的一部分将用户转变为对话框的示例方法中，一种方法包括通过社交网站接收商品的发布，这样社交网站就可以将发布的商品从发布实体接收并传输到接收实体。当发布与商品数据库中的购买商品不相关时，该方法包括通过社交网站发送发布，而无需选择购买。当确定指示所述发布参考所述商品数据库中的商品，从而指示与销售有关的意图时，所述方法包括通过所述社交网站将所述发布与与所述商品相关联的支付方法发起对象一起发送，使得所述支付方法发起对象可以包括按钮、下拉菜单或超链接之一，并且接收与支付流程发起对象相关联的交互，该交互由用户执行。基于购买交互，该方法包括作为支付方法的一部分与用户进行关于该商品的对话，以使得在对话结束时，用户可以完成该商品的购买。
该方法可以包括作为对话框的一部分，从用户接收购买交互，并基于购买交互来处理商品的购买。处理购买发生在社交网站之一中，通过支付代理或通过社交网站与销售商品的商家网站之间的应用编程接口。购买也可以通过本文公开的浏览器支付请求应用程序编程接口进行。浏览器、社交网站、数字钱包、网络存储服务可以存储支付数据供用户处理购买。当通过社交网站和商家网站之间的应用程序编程接口进行购买时，社交网站可以通过应用程序编程接口传输支付数据，使得商家网站可以处理商品的购买。当通过浏览器和商家网站之间的浏览器应用程序编程接口进行购买时，浏览器可以通过应用程序编程接口传输支付数据，以便商家网站可以处理商品的购买。
该对话框可使用户选择与商品关联的参数。示例参数包括颜色、尺寸、形状、配置和技术特征中的一个或多个。可以在对话框中管理交货选项，解决任何其他问题、礼物问题、折扣、优惠券等。支付方法启动对象可以简单地包括购买按钮或通知“通过单击此处讨论并购买此商品”。可以通过对话框应用程序在用户和商家之间管理对话框。一方面，可以通过过渡到用于管理对话框和商品购买的对话框应用程序来实现参与对话框。
图3还示出其他概念。特征308表示Apple搜索。如果用户选择此选项，则返回的下一个字段就像用户在Apple.com上搜索iPhone 5S一样。苹果公司提供的有关该商品的信息将呈现给用户。(可选)系统可以提示用户提供或确认用于登录Apple.com的凭据。由于从one-search.com到Apple.com的转换是从one-search.com发生的，因此系统可以在新的Apple.com网页中显示一个选项，以使用户能够返回到one-search.com进行进一步搜索。例如，该系统可以在浏览器中提供框架，以在显示Apple.com网站时返回到one-search.com搜索。框架可以允许用户修改原始输入文本，从而可以动态更改与框架结合显示的Apple.com网站的各个方面。
图3中的特征310表示eBay出价选项。在这种情况下，如果用户选择此选项，则系统会将用户发送到eBay并显示一个屏幕410，如图4B的示例用户界面所示，就好像该用户访问了eBay.com，并在“iPhone5S”中输入了eBay搜索字段412。功能部件414代表iPhone 5S32GB的可选退回商品，当前出价为199美元。特征416是价格为175美元的iPhone 5S 16GB，特征418是价格为$150的iPhone 516GB。所有这些都是可能发生的处理类型的示例。如上所述，“返回到一次搜索”按钮420也可以包括在屏幕中，以便于容易地返回到一次搜索字段。系统可以过渡到指示的目标页面，例如iPhone 5S的Apple.com、eBay.com或Amazon.com购买页面作为覆盖页面，这样，返回单搜索字段涉及删除覆盖，而不是返回到上一页的后退导航命令。界面410可以是如图18A中所示的浏览器1806，其经由浏览器API 1818与商家网站1816交互，以交换请求和响应以如本文所公开的向商家提供支付信息。浏览器410还可以充当代理以利用浏览器1806和支付服务1810之间的第二API 1812来管理支付、授权支付、生成令牌等。可以从诸如搜索网站、社交媒体网站或任何其他网站之类的初始网站过渡到浏览器410，以进行进一步的交互并处理支付处理。
图3还显示了下拉菜单中的亚马逊搜索312。当用户选择此选项时，系统可以显示屏幕，就像用户在Amazon.com上搜索iPhone 5S一样。从那里，用户可以继续购物和搜索，就好像用户已经开始在Amazon.com上浏览一样。对象312可由用户选择，并且可以在用户将数据输入到输入字段302中之后向用户显示其首个对象。这减少了界面上的混乱。一方面，当用户将数据输入字段时，无需任何其他交互，下拉菜单会自动下拉。换一种说法，如图3所示，没有按钮可以单击以产生下拉菜单。这减少了使用输入字段302中的用户输入数据转换到amazon.com(或任何其他网站)所需的交互。另一方面，用户单击键盘上的“enter”键(即，未单击任何按钮)，这可能会导致系统处理输入并产生下拉菜单。菜单也可以简单地是呈现给用户以供选择的对象或字段。换句话说，它不一定非要是下拉菜单。例如，可以基于202中的用户输入或者用户敲击键盘上的“输入”以呈现选项来呈现图2A中的选项206。图3中的下拉菜单可以包括直接通过Apple.com314购买商品的选项。如果用户选择该选项，并假设Apple.com上没有“一键式”购买选项，则只需很少的互动，用户就可以完成购买。例如，系统可以将用户带到显示准备购买的商品的购物车。在一种选择中，该系统使用户可以看到商品并能够将商品(iPhone 5S)放入购物车。在另一方面，系统可以代表用户导航购物车模型并完成购买，从而使交易成为一键式购买。
图3还示出本公开的另一示例。在这种情况下，因为“下拉”菜单包含不同类型的数据，所以这些选项可以包括“下拉”菜单以及“下拉”菜单。如功能316和318所示，购买选项可以“向上”放置，而所有搜索选项或更传统的选项可以“向下”放置。系统可以根据需要在左侧、右侧、对角线或任何方向或角度显示菜单。将购买选项与搜索类型选项分开也可以减少无意购买的次数。在这个例子中，图3的下拉菜单只能包含特征304、308、310和312，因为这些特征需要进一步搜索。系统可以将商品306和314分别定位在“下拉”菜单318和316中。该算法可以预测是否最可能的搜索(如果用户希望进行搜索)以及最可能的购买(如果用户希望购买该商品并将其作为第一选项向下放置并且在菜单中向上放置第一选项)。用户可以使用键盘或触摸屏上的箭头按钮选择所需的选项。或者，下拉菜单或下拉菜单可以指示快捷键，用户可以按下这些快捷键来选择选项，而无需使用鼠标。例如，菜单可以指示用户可以按alt-1、alt-2或alt-3来选择各种下拉菜单选项，或ctrl-1、ctrl-2或ctrl-3或其他单键或组合键以选择各种下拉菜单选项。系统可以显示自动完成选项，用户可以使用类似的键盘快捷键来激活这些选项。例如，如果用户键入“iPhone”，则系统可以指示在“iPhone”之后按“S64”将自动完成为“iPhone 5S 64GB”。此类自动完成键盘快捷键的类型和数量可能会有所不同，具体取决于用户确定的意图以及系统可以理解的商品属性。语音活动或手势输入或任何其他类型的输入都可以使用户选择所需的选项。
在某些情况下，系统可以确定搜索字段中的数据不用于购买。例如，如果用户输入文本“South Dakota”，则系统可以识别出该用户不希望进行购买。在这种情况下，“下拉”菜单可以简单地列出传统的搜索选项，也可以列出选项以一键式购买与南达科他州有关的商品，例如南达科他州的T恤或拉什莫尔山的纪念品。在一方面，用户可以输入“研究南达科他州”，以向系统指示不希望购买，而是例如，用户的意图是在南达科他州进行商品研究。在此示例中，系统可以从具有各种可靠性等级的来源返回下拉菜单中显示的研究结果。例如，用户可以根据可靠性或受欢迎程度从下拉菜单中选择来源。
用户还可以在搜索字段中添加提示或速记说明，以指导one-search.com字段中显示的购买选项。例如，用户可以提供文本“buy amaz iPhone 5S”。这些提示告诉算法用户需要购买功能，并且期望的商家是亚马逊。该算法可以使用正则表达式搜索可用商家的数据库，以确定所需的商家是亚马逊，而不是用户想要购买精美的iPhone。为了解决商家的歧义，例如，该算法还可以基于存储在用户帐户中的先前搜索来做出决策。基于这些类型的提示，系统可以从图3所示的下拉菜单中消除特征304、308、310、312和314。在那种情况下，用户只需点击“退货”，最可能需要的商品将自动购买并处理以进行装运。当用户按下Enter键时，有关Enter功能的动态变化的信息可以显示在搜索字段中，例如，在用户键入的文本的右侧。可以呈现取消或修改课程的选项，例如图4A所示的取消购买按钮404和修改购买按钮408。
在一个示例中，统一输入字段是可下载或可安装在智能手机、平板电脑或其他移动计算设备上的应用程序的一部分。该功能还可以应用于网站上的统一搜索字段。该应用程序可以像此处公开的任何网站一样进行定制。该应用程序包括单个输入字段，该字段对于多种不同类型的处理都是通用的。例如，该应用程序可以为输入字段显示许多不同的选项，例如Skype或电话。因此，该字段可用于输入联系人搜索。用户可以在“妈妈”字段中键入内容，然后选择
视频会议选项或Face 
选项。系统通过扩展视频会议请求或拨打电话，根据适当的上下文处理输入字段。重要的是要注意，本文公开的统一领域概念不限于与网络搜索或购买有关的用户输入的处理。可以从统一领域实现其他功能。电话、视频会议、智能手机上任何传感器的触发、拍照、发送文本等。如果遵循以下功能，则举几个例子。在统一字段中，用户可以输入文本：“MarkS.，我们一起吃午饭吗？”然后，用户可以选择“发短信”，在在线聊天室中聊天或在社交媒体网站上发布评论等处理选项。
图4C示出使用语音对话和/或信使应用程序来购买商品的方法示例。也可以使用文本对话框。以下是同时具有语音输入和文本组件的语音对话框的示例，类似的方法仅适用于通过文本进行交互的用户。在这方面的示例方法包括经由信使应用程序并作为商家网站与用户之间的对话的一部分来接收来自用户的输入(430)，在对话器应用程序中呈现与输入相关联的用户文本，作为对话框的一部分并由商家网站对输入进行响应(432)，在信使应用程序中呈现与响应相关联的文本(434)，以及通过对话框识别用户希望从商家网站购买的商品(436)。基于用户通过对话框进行的购买交互，该方法包括在浏览器上并通过浏览器的支付请求应用程序编程接口接收来自商家网站的支付请求、用于购买商品的用户的支付数据的支付请求(438)，并响应于该支付请求，从浏览器并通过浏览器支付请求应用程序编程接口传达用户的支付信息，其中商家网站使用该支付信息来处理商品的支付(440)。
该方法可以包括在浏览器处并且经由浏览器支付请求应用程序编程接口从商家网站接收地址请求，以获取用户的地址数据。响应于该地址请求，该方法可以包括：从浏览器并且经由浏览器支付请求应用程序编程接口将用户的地址数据传送到商家网站。商家网站使用支付信息处理支付。支付可以包括商家网站可以用来处理商品支付的用户支付账户信息。浏览器可以将Messenger应用程序呈现给用户。该方法也可以通过没有语音输入的文本对话框进行。
从商家网站的观点来看，一种方法可以包括经由信使应用程序并且作为商家网站与用户之间的对话的一部分，从商家网站向用户发送提示，作为对话框的一部分并且在商家网站处，接收用户输入，并基于用户输入来识别用户希望通过对话框从商家网站购买的商品。基于用户经由对话框的购买交互，该方法可以包括：经由商户网站向浏览器以及经由浏览器支付请求应用程序编程接口传输对用户的支付数据的支付请求，以用于购买商品，并响应于支付请求，从浏览器并通过浏览器支付请求应用程序编程接口接收用户的支付信息。使用支付信息，商家可以处理商品的支付。当然，从商家的角度来看，此方面可以包括仅文本或仅口头对话的方法，加上用户讲话和商家也讲话的方法，但对话框的文本版本会呈现给用户，以便跟进和进行用户交互，例如视频或图像以选择购买选项。
已经公开了一些基本的系统组件和概念，本公开现在转向图5中所示的示例性方法示例。为了清楚起见，根据如图7所示的示例性系统700来描述该方法，该系统700被配置为实践该方法。本文概述的步骤是示例性的，并且可以以其任何组合来实施，包括排除、添加或修改某些步骤的组合。
图5示出一般方法示例。系统接收用户输入(502)。系统在处理用户输入时访问商品数据库(504)。例如，如果新商品刚问世并且可以在线购买，则系统可以访问该信息，以便当用户输入“iPhone 5S”时，系统可以将该输入与商品进行匹配。系统分析输入(506)以确定用户意图。例如，如果用户输入“罗德岛”，则系统可以计算出用户希望购买罗德岛的可能性很小。该算法可以使用用户配置文件、用户搜索和购买历史记录以及任何其他数据来确定如何构建可扩展菜单，以使用户能够快速选择所需的内容。但是，随着用户输入其他文本，系统可以相应地更新自动完成选项。例如，如果用户输入“罗德岛食谱”，则系统可以在某个时刻确定用户不太可能对状态感兴趣，而对可能是可购买物品的食谱感兴趣。然后，当用户继续输入其他文本时，系统可以立即自动自动调整自动完成选项。
接下来，图5示出系统在用户界面中的任何位置处构造下拉菜单(508)或各种选项或对象的表示。这种结构还可以包括市场营销方面的内容，因为公司可能会为如何显示期权付费。如果用户似乎希望购买该商品，则Amazon.com或商品制造商可以支付少量费用来展示其带有图形或多媒体内容的商品，以鼓励用户选择该选项来购买商品。系统呈现菜单或选项的其他结构化表示，以供用户选择(510)。当用户输入通过算法指示可能期望购买时，这些选项包括一个或多个购买选项(512)。
在另一方面，分类器可以处理一般的统一搜索字段中的用户输入。可以训练分类器以确定用户的意图并响应于输入来选择提供哪些网站或应用程序。分类算法通常用于处理语音或电话呼叫。例如，某些分类功能可以处理和分类各种呼叫类型的呼叫，例如本地、国际、语音邮件、会议等。在某些情况下，当用户呼叫交互式语音响应系统时，可以使用先前的呼叫来训练分类器，以处理用户输入，从而得出结论，该用户希望进行会计核算或支付。例如，用户可以在呼叫中说“我想付账单”或“我需要我的帐户帮助”。通过对输入进行分类，系统可以将呼叫路由到正确的人、目的地或实体。
用于分类的技术包括统计、数据挖掘、模式识别、机器学习、在某些情况下还包括神经计算和人工智能。通用分类系统方法包括接收输入、对输入进行预处理、对输入进行分段和标记、从输入中提取特征、进行后处理、并最终对输入进行分类以得出决策。尽管这些原理已应用于许多领域，但这些技术可以应用于新的分类领域。新的分类域是统一输入字段的上下文或意图，例如在用户提供输入的浏览器上，并且该输入可以应用于许多不同的网站，应用程序或操作。现在，当某人访问Google.com时，就假定用户想要搜索互联网。当用户访问Amazon.com时，该用户想购买商品。用户必须访问不同的网站才能实现这些不同的功能，从而需要其他不必要的鼠标单击。一方面，本公开提供了分类器的引入，该分类器处理网站上的字段中的用户输入，在该字段中没有假设用户想要搜索或购买商品。分类器将通过分类决策来确定用户的意图。
为了训练分类器(在此称为“意图分类器”)，系统可以在一段时间内监视用户的网络使用情况。分类器可以利用一个用户或多个用户的数据。例如，与amazon.com输入字段中的输入相比，针对特定人群(例如20-30岁的男性、女性或特定少数群体或宗教团体)的人，可以在Google输入字段中生成输入的训练数据。训练数据在某些方面优选地对于个体用户而言是特定的。如果用户登录到浏览器后可以连接到该用户的训练数据或相关训练数据，则系统可以更有效地处理统一输入字段中的用户输入。系统可以使用监督学习(或无监督或半监督学习)来标记训练集，以便训练数据可以提供输入所属的类(即搜索、购买、维基百科等)。训练数据涉及通过搜索字段而不是购买字段提供的输入。也可以应用其他领域，例如拍卖、医疗建议、Twitter输入文本、Facebook输入文本或任何其他社交网络输入文本等等。一般的概念是，当用户将有关所需功能的数据输入到字段中时，没有任何假设。
对于培训模型有用的其他数据是个人用户信息。例如，如果用户在amazon.com上注册进行一键购买，那么当用户键入“Android 4.4Kit Kat”时，系统会知道，该人通过Amazon.com可以完成购买最流行的Android4.4智能手机所需的最短的点击次数和计算机交互次数。否则，用户可能会被转到另一个网站，必须经过购物车模型，输入他们的信用卡，并花费大量额外的时间和精力来完成购买。因此，知道用户已在一个或两个购买网站上注册(从而实现了快速的“一键式”购买)可以驱动分类的结果。
在另一个示例中，分类器在这种情况下可以具有搜索、浏览、立即购买、玩游戏、更新软件、发送电子邮件、发送推文、检查Facebook、通过Skype拨打电话等分类类型。可以从google.com、amazon.com、Wikipedia.com等之间的输入字段中使用的不同类型的输入中提取训练模型的一些分类数据。用于训练分类器的系统可以查看与正在使用的网站有关的不同类型的输入，并开发训练数据。在其他情况下，如果用户键入“呼叫妈妈”，则不会在输入字段中提供此类输入，因为通常用户会转到Skype应用程序或其他呼叫应用程序并选择他的母亲进行呼叫。因此，在其他情况下，可能会以不同的方式进行训练以捕获该“命令”类型的输入。然而，由于在开始时没有假设输入的期望意图，因此可以使用这种训练来使用户能够从一个输入字段开始执行一系列功能。
在这种情况下，用户还可以提供有关所需输入的提示。用户在“iPhone5S”之前键入“buy”可能会更快，因此整个输入就是“buy iPhone 5S”，而不是将手移至鼠标并移动鼠标以单击浏览器中的amazon.com选项卡或图标，或在网址的输入字段中输入“www.amazon.com”。显然，购买建议告诉分类者购买是意图。当前，仍通过提供搜索结果的搜索算法来考虑输入“购买iPhone 5S”。该系统可以显示赞助广告，使用户可以转到iPhone5S的广告或促销页面，但是这些广告仍然需要额外的点击才能达到实际购买的目的。此外，系统仍可以将结果显示在网页(google.com)上，该网页无法使用户一键完成购买/交付。
因此，根据本公开的分类算法可以利用训练数据，该训练数据包括用户或相似用户经由各种网页上的输入字段提供的不同种类的输入，以确定描述用户希望打开哪个网页或用户希望对该网页执行哪个动作的意图。系统可以使用其他数据进行确定，例如一天中的时间、一年中的时间、社交媒体数据(例如朋友的生日、假期、天气信息)、用户在哪个网站上进行了购买以及用户先前在哪个网站上进行了注册等。
例如，分类器可以确定用户想要购买。分类器可以对搜索意图或购买意图做出基本确定。然后，分类器可以采取第二步，根据历史记录、用户个人资料、注册、最优惠的价格、离用户地址最近的出口等来确定用户可能希望在哪个商家处进行购买。如果用户在amazon.com上设置了帐户，则系统可以选择Amazon作为主要的可能目的地，并采取适当的步骤。例如，系统可以使用在amazon.com上预先输入的输入术语来创建一个新标签，或者用户可以在其中打开标签并处于amazon.com网站上的状态，在该状态下，用户只需点击“一键购买”按钮即可完成购买。系统可以在新选项卡中，与统一输入字段位于同一页面中或以其他某种方式来显示新页面。
该系统可以代替完全传统的菜单，而以完全不同的形式显示选项，例如标签字段。图6示出其中基于相关性选择与每个可选选项相关联的参数的选项。例如，系统可以为各种选项选择和修改标签字段中商品的位置、大小、形状、颜色、细节。功能602是Amazon一键式购买。功能604是Google搜索，功能606是eBay搜索。在标签云或词云中，商品的大小、形状、颜色和其他详细信息可以提供有关商品的信息。在该示例中，亚马逊一键式购买602以大字体，粗体且紧邻搜索字段302列出。大字体可以指示系统已确定它与在搜索字段中输入的文本高度相关。粗体字体可以表明单击该商品将触发购买。eBay搜索606同样也很大，可能表明它也非常相关，但并不大胆，因为没有与该商品606相关的一键式购买。Google搜索604以较小的字体显示在侧面，表明它可能不太重要或不重要。当用户在搜索字段302中输入其他信息时，这些商品的各种详细信息可以以平滑、动画的方式变化。例如，当用户输入有关特定所需iPhone的更多信息时，系统可以调整用户界面上的Amazon 602选项以逐渐增大尺寸、移近搜索范围、用粗线绘制等等。该系统可以将这些细节作为动画提供给用户，以便在越来越可发现的地方或越来越显眼地呈现越来越相关的商品。
图6示出如何构造和呈现来自一次搜索输入字段的可选选项的各种选项。一方面，传统的下拉选项可以按常规方式呈现，而购买选项则如图6中的功能602所示，从而进一步区分哪些商品是标准下拉菜单，自动完成类型选项以及哪些是一键式购买类型选项。该系统可以在标签字段或其他示例中呈现目标广告。例如，在图6中，用户可能已经输入“购买Amazon iPhone 5S”。这将导致用户想要通过亚马逊购买该商品的可能性或可能性很高，从而使系统呈现特征602，以大字体显示该选项并靠近输入字段302。换句话说，例如标签云，这些标签使更大的单词具有更高的使用率或对故事或来自云输入的兴趣。特征604可以代表来自竞争对手的付费广告，该竞争对手可以为同一商品提供更便宜的价格。这样的信息可以被呈现为表示为特征604的图标或广告的一部分。
图7中的基本通用系统或计算设备的描述示出可用于实践所公开的概念、方法和技术。参考图7，示例性系统和/或计算设备700包括处理单元(CPU或处理器)720和系统总线710，该系统总线710耦合各种系统组件，包括诸如处理器720之类的系统存储器730，例如只读存储器(ROM)740和随机存取存储器(RAM)750。系统700可以包括高速存储器的高速缓存722，高速缓存的高速缓存722与处理器720直接连接，紧密相邻或作为处理器720的一部分而集成。系统700将数据从存储器730和/或存储设备760复制到高速缓存722，以供处理器720快速访问。以这种方式，高速缓存提供了性能提升，避免了处理器720等待数据时的延迟。这些模块和其他模块可以控制或配置为控制处理器720执行各种操作或动作。其他系统存储器730也可以可用。存储器730可以包括具有不同性能特征的多种不同类型的存储器。可以理解的是，本公开可以在具有一个以上处理器720的计算设备700上或在联网在一起以提供更大处理能力的一组计算设备上或集群上操作。处理器720可以包括任何通用处理器和硬件模块或软件模块，例如存储在存储设备760中的模块1762、模块2764和模块3766，其被配置为控制处理器720以及专用处理器，在该专用处理器中将软件指令合并到处理器中。处理器720可以是包含多个核或处理器、总线、存储器控制器、高速缓存等的独立的计算系统。多核处理器可以是对称的或非对称的。处理器720可以包括多个处理器，例如在不同插槽中具有多个物理上分开的处理器的系统，或在单个物理芯片上具有多个处理器核的系统。类似地，处理器720可以包括位于多个单独的计算设备中但是例如经由通信网络一起工作的多个分布式处理器。多个处理器或处理器核可以共享诸如存储器730或高速缓存722之类的资源，或者可以使用独立的资源进行操作。处理器720可以包括状态机、专用集成电路(ASIC)或包括现场PGA的可编程门阵列(PGA)中的一个或多个。
系统总线710可以是几种类型的总线结构中的任何一种，包括使用各种总线架构中的任何一种的存储器总线或存储器控制器、外围总线和局部总线。存储在ROM 740等中的基本输入/输出(BIOS)可以提供诸如在启动期间帮助在计算设备700内的元件之间传递信息的基本例程。计算设备700还包括存储设备760或计算机可读存储介质，例如硬盘驱动器、磁盘驱动器、光盘驱动器、磁带驱动器、固态驱动器、RAM驱动器、可移动存储设备、廉价磁盘(RAID)、混合存储设备等的冗余阵列。存储设备760可以包括用于控制处理器720的软件模块762、764、766。系统700可以包括其他硬件或软件模块。存储设备760通过驱动器接口连接到系统总线710。驱动器和相关联的计算机可读存储设备为计算设备700提供了计算机可读指令、数据结构、程序模块和其他数据的非易失性存储。一方面，执行特定功能的硬件模块包括与必要的硬件组件(诸如处理器720、总线710、显示器770等)相关联地存储在有形计算机可读存储设备中的软件组件，以执行特定功能。在另一方面，系统可以使用处理器和计算机可读存储设备来存储指令，这些指令在由处理器执行时使处理器执行操作、方法或其他特定动作。可以根据设备的类型，例如设备700是小型的手持计算设备、台式计算机还是计算机服务器，来修改基本组件和适当的变化。当处理器720执行指令以执行“操作”时，处理器720可以直接执行操作和/或促进，指导或与另一设备或组件协作以执行操作。
尽管本文所述的示例性示例使用了硬盘760，但是其他类型的计算机可读存储设备也可以存储可由计算机访问的数据，例如磁带、闪存卡、数字通用磁盘(DVD)、盒、随机存取存储器(RAM)750、只读存储器(ROM)740、包含比特流的电缆等也可以在示例性操作环境中使用。有形的计算机可读存储介质、计算机可读存储设备或计算机可读存储设备明确排除诸如瞬时波、能量、载波信号、电磁波和信号本身之类的介质。
为了使用户能够与计算设备700交互，输入设备790代表任何数量的输入机制，例如用于语音的麦克风、用于手势或图形输入的触敏屏幕、键盘、鼠标、运动输入、语音等。输出设备770也可以是本领域技术人员已知的许多输出机构中的一个或多个。在一些情况下，多模式系统使用户能够提供多种类型的输入以与计算设备700通信。通信接口780通常支配和管理用户输入和系统输出。对于在任何特定硬件装置上的操作没有限制，因此，随着所开发的硬件或固件装置的改进，所描述的基本硬件可以轻松地替代它们。
为了解释清楚，将示例性系统示例呈现为包括各个功能块，这些功能块包括标记为“处理器”或处理器720的功能块。这些框代表的功能可以通过使用共享的或专用的硬件来提供，包括但不限于能够执行软件的硬件和旨在与在通用处理器上执行的软件等效的目的而构建的硬件，例如处理器720。例如，图7所示的一个或多个处理器的功能可以由单个共享处理器或多个处理器提供。(术语“处理器”的使用不应解释为专门指能够执行软件的硬件。)说明性示例可以包括微处理器和/或数字信号处理器(DSP)硬件；只读存储器(ROM)740，用于存储执行以下所述操作的软件；随机存取存储器(RAM)750，用于存储结果。也可以提供超大规模集成(VLSI)硬件示例，以及与通用DSP电路结合的定制VLSI电路。
各种示例的逻辑操作被实现为：(1)在通用计算机内的可编程电路上运行的一系列计算机实现的步骤、操作或过程，(2)在特定用途的可编程电路上运行的一系列计算机实现的步骤、操作或过程；和/或(3)可编程电路内相互连接的机器模块或程序引擎。图7中所示的系统700可以实践全部或部分所述方法，可以是所述系统的一部分，和/或可以根据所述有形计算机可读存储设备中的指令进行操作。这样的逻辑操作可以被实现为被配置为根据模块的编程来控制处理器720执行特定功能的模块。例如，图7示出被配置为控制处理器720的模块的三个模块Mod1762、Mod2764和Mod3766。这些模块可以存储在存储设备760上，并在运行时加载到RAM 750或存储器730中，或者可以存储在其他计算机可读存储位置中。
可以虚拟示例计算设备700的一个或多个部分，直到整个计算设备700，包括整个计算设备700。例如，即使在与虚拟处理器相同类型的物理处理器不可用时，虚拟处理器也可以是根据特定指令集执行的软件对象。虚拟化层或虚拟“主机”可以通过将虚拟化操作转换为实际操作来启用一个或多个不同计算设备或设备类型的虚拟化组件。但是，最终，每种类型的虚拟化硬件都是由某些基础物理硬件实现或执行的。因此，虚拟化计算层可以在物理计算层之上运行。虚拟化计算层可以包括虚拟机、覆盖网络、虚拟机监控程序、虚拟交换和任何其他虚拟化应用程序中的一个或多个。
处理器720可以包括本文公开的所有类型的处理器，包括虚拟处理器。然而，当提及虚拟处理器时，处理器720包括与在虚拟化层中执行虚拟处理器相关联的软件组件以及执行虚拟化层所需的底层硬件。系统700可以包括物理或虚拟处理器720，该物理或虚拟处理器720接收存储在计算机可读存储设备中的指令，这些指令使处理器720执行某些操作。当引用虚拟处理器720时，系统还包括执行虚拟处理器720的底层物理硬件。
在本公开内容的每种情况下，对“Amazon”或Amazon.com的引用都足够广泛，以涵盖任何购买/交付或电子商务网站，以及提供商品或服务的传统实体企业网站。对“Google”网站或搜索的引用指的是任何通用搜索引擎。在许多情况下，本文阐述的原理可以适用于系统可以操纵或遍历的其他非搜索和非商业网站，以代表用户完成特定的预期动作。
图7的系统也可以代表虚拟现实设备。该设备可以是完全包含的耳机，也可以包括接收诸如三星设备或iPhone或其他移动设备之类的移动设备的耳机。在这方面，图7的特征可以包括这种头戴式耳机的组件。输入设备790可以代表一种或多种不同类型的输入设备，例如用于拍摄静止图像或视频的相机，指纹读取器，可以将其配置在耳机的侧面，以便在虚拟现实环境中轻松确认用户的购买。输出设备770可以表示用户通过其观看图像的屏幕。通信接口780可以向其他设备、接入点、基站等提供Wi-Fi或蜂窝或其他无线通信方式。裁决接口780还可以表示可移动设备与头戴式耳机之间的接口，用于在两个组件之间传递数据。存储器730可以代表本领域中使用的任何标准存储器，以及可以用于以安全方式存储支付信息和/或其他用户信息以用于诸如Apple Pay的支付方法的安全元件。
在一个示例中，虚拟现实耳机包括电子组件，使得指纹读取器可以被配置在耳机的顶部或侧面。指纹读取器组件可以内置在头戴式耳机中，并配置在用户在虚拟现实环境中时易于访问的位置。在这种情况下，如果用户在虚拟现实环境中进行购买，则使用需要指纹授权的支付方法，用户可以在耳机侧面提供指纹以完成购买。可以在屏幕上向用户提供虚拟现实环境的指令，该指令甚至可以指向耳机上指纹读取器所处的区域。虚拟现实耳机还可以包括浏览器软件或具有类似功能的软件或固件，其被配置为能够经由浏览器支付请求应用程序编程接口与商家网站进行通信。因此，呈现虚拟环境的应用程序可以充当浏览器。在这方面并且用浏览器API协议编程，或者存储必要的支付和其他用户数据，或者具有访问外部支付和/或其他用户数据的通信能力，可以从用户的移动设备进行无线访问，该用户的移动设备将此类数据存储在例如Microsoft钱包和android钱包、当前的加密货币钱包和Apple支付的钱包等中。一方面，将使浏览器API能够一次处理两次购买，其中浏览器API的单独实例可以同时在两个单独网站上参与浏览器API界面支付对话框。如果用户尝试同时执行两个操作，则系统可以将一个接口标识为第一接口，将第二接口标识为第二接口，并同时分别管理两个单独网站的支付。
一些虚拟现实设备还包括手持组件，这些组件可用于呈现虚拟现实环境中的物品，例如棒球棍或钓鱼竿。它们与头戴式耳机进行无线通信，并监视每个单元的位置和移动，以便如果用户挥动蝙蝠，则该蝙蝠会出现在虚拟世界中。这些手持组件还可以在其上具有指纹识别，以便用户可以用左手握住手持单元并在虚拟环境中进行购买。然后，用户可以用右手食指触摸传感器以提供确认指纹。数据可以通过蓝牙或其他协议进行通信，或者通过有线方式连接到用户设备或头戴式耳机，后者可以利用此处公开的信息进行购买。
图8示出示例方法。在每种情况下，无论何时提到“网站”，也都可以应用程序或网站，例如在使用移动应用程序访问数据时。系统将执行该方法的步骤。该系统在网站的用户界面上呈现输入字段(802)，并在输入字段中接收来自用户的用户输入(804)。该系统分析输入以确定用户是否想要搜索，进行购买，执行某些其他功能(例如拨打电话或观看视频等)。系统呈现一组选项，该组选项中的每个选项在输入字段之外呈现，并且与处理用户输入相关联，就好像用户已经将用户输入输入到第三方网站输入字段中一样(806)。当然也可以提出一种选择。图2和图3提供了展示处理选项集的示例。这种方法的一个组成部分是，输入字段没有预先指定或预先设计为在一个特定的上下文中处理输入，但是输入字段可以通过多种方式处理输入，从而减少从一个网站导航到另一个网站以输入数据所需的点击次数。系统接收用户对选项组中的所选选项的选择(808)，并根据所选选项处理用户输入(810)。
选项组中的第一选项可以与搜索引擎相关联，选项组中的第二选项可以与购买处理引擎相关联。如果所选择的选项是第二选项并且与购买处理引擎相关联，则系统将识别与用户输入相关联的商品，并处理该商品的购买以及该商品向用户的交付。如果选择的选项是第一个选项并与搜索引擎关联，则系统处理用户输入以执行与用户输入关联的搜索并返回搜索结果。该方法还可以包括：识别选项组的各个类型，以及基于各个类型将这些选项组呈现在组中。
用户输入可以包括文本输入、多模式输入、手势输入或语音输入中的至少一种，或其任意组合。用户可以具有一个预先存储的帐户，该帐户存储用于控制如何显示选项集的首选项。浏览器API也可以在任何类型的界面中工作，例如电视界面，如果该界面被视为浏览器界面，则可以使用户能够购买商品。
基于从另一个源集成到用户界面的输入执行操作
图9示出与从输入字段到目的地网站的转变的示例相关联的用户界面。在该示例用户界面中，用户将文本“iPhone 5S”输入到统一的输入字段902中。浏览器将文本传递给返回导航目的地的单搜索服务器。网络浏览器可以在页面中呈现“泪水”904、908，该“泪水”904、908看起来是界面中窥视到底层其他页面的漏洞。泪水有两个位置考虑因素，即泪水在宿主页面中的位置，以及泪水在目标页面上的视图。当确定要出现的眼泪的位置和大小时，系统可以考虑这两个位置。用户可以单击该图标以导航到该目标网站。在那种情况下，撕裂可以以与单击链接的相同方式过渡到另一个页面，或者可以呈现动画过渡，例如扩展撕裂的边界，直到撕裂完全替换上一页。眼泪可以包括沿着各个眼泪的边缘装配的各种控件906、910、914，以便用户可以操纵眼泪来移动、最大化906a、扩展906b、910b、预览910c、906d、关闭910a、转到页面906c，或对泪液执行其他操作。此外，用户可以直接操纵如泪中所示的暴露的用户界面元素，例如一键购买按钮905或查看购物车按钮907。有些眼泪可以显示其他非Web操作，例如，查看Skype应用程序以进行呼叫。系统可以将泪水定位成与根据在统一输入字段中输入的文本确定的意图更匹配的泪水，因此，例如，更重要的泪水更靠近鼠标光标916或统一输入字段。该系统可以在鼠标916移近眼泪时动态扩展眼泪，并在鼠标916移远时使眼泪收缩。撕裂边缘可以是任何形状，包括标准的几何形状，也可以具有更复杂的边缘，这些边缘是尖锐的或光滑的，或者是动态的并且可以基于各种因素而变化。
在基于触摸的界面中，用户可以使用触摸手势来操纵眼泪。例如，用户可以点击并按住眼泪以开始在页面上四处移动眼泪。用户可以滑动以在泪水中移动页面视图，或捏以放大在泪水中显示的页面。用户可以双击泪水以导航到泪水中显示的页面。该系统可以以与主机页面相同的缩放因子在泪液中显示内容，或者可以收缩在泪液中显示的内容以显示内容的较宽视图。
图10示出用于基于指向从另一源集成的用户界面的输入来执行动作的示例方法。在该示例中，执行该方法的系统在统一的输入字段中接收用户输入(1002)。系统分析用户输入以产生分析(1004)。基于该分析，该系统动态地呈现至少一滴眼泪，以揭示来自单独网站或应用程序的基础用户界面的至少一部分，基础用户界面集成了用户输入(1006)。该系统从用户接收用于执行与泪液相关联的功能的控制输入(1008)。系统然后可以执行功能(1010)。
可修改的输入按钮
公开了一种系统、方法和计算机可读存储设备，其基于经由分类器确定的意图并基于提供给统一输入字段的文本来动态地使与统一输入字段相关联的搜索按钮变形或适配。通常，统一输入字段具有两个主要组成部分：文本输入字段和搜索按钮，用于基于通过文本输入字段提供的输入执行搜索。搜索按钮通常标有文本“搜索”或“开始”或类似的通用名称。但是，当用户输入搜索词时，系统可以识别其他一些更具体的操作，并且可以修改搜索按钮以不仅动态显示不同的文本或图形标签，还可以相应地修改与该按钮关联的操作。此外，系统可以将单个搜索按钮扩展为多个按钮。
例如，用户输入文本“Apple”。此时，分类器无法确定文本字符串“Apple”是否已充分绑定到特定操作或商品以修改搜索按钮上的标签。因此搜索按钮保持不变。用户继续输入文本“Apple iPhone”。在这一点上，分类器基于附加文本识别出可能有几个特定的商品或动作，但是太多的商品或动作可用，或者没有一个超过确定性阈值来修改搜索按钮。用户继续输入文本“Apple iPhone 5S”，此时分类器将识别iPhone的型号5S。然后，基于用户偏好或其他可用数据，分类器可以识别iPhone5S的特定变体，例如64GB的金色iPhone 5S。因此，系统可以将搜索按钮的标签修改为不再显示“搜索”，而改为显示“购买iPhone 5S，64GB，金色”。此时，用户只需按键盘上的Enter键即可执行该操作并购买指定的iPhone 5S。因此，enter函数是动态的，并且在用户开始键入搜索查询后从默认模式下的第一次更改为第二次第二功能。
作为修改搜索按钮的替代方法，系统可以在搜索按钮或下拉菜单或下拉菜单或任何其他界面旁边生成并显示其他按钮。系统可以提供不同的按键或组合键将激活不同的按钮的指示。例如，按Enter键将激活与“搜索”按钮相关的功能，而按ctrl-enter键将激活“购买iPhone 5S，64GB，金色”按钮的功能。将光标移到对象上可以触发或激活用户单击“输入”时执行的功能更改。当系统显示其他按钮时，用户也可以单击其他按钮来激活其各种相关操作。
在某些情况下，修改后的按钮仍可能需要一些其他歧义。例如，修改后的按钮可以标记为“购买iPhone 5S，64GB”。当用户按下Enter键以激活修改后的按钮时，系统会显示其他对话框或按钮修改，例如将按钮修改为“按Enter一次，金色，两次或三次Black”。在用户提供了输入之后，系统可以将按钮标签修改为“按一次Enter可以从Apple购买，两次按可以从Amazon购买”。系统可以使用这些附加消息来修改按钮标签，或者可以将它们显示在页面上的其他位置。这样，用户可以快速输入与所需动作或购买相关的文本，并轻松地选择各种选项，而无需在键盘和鼠标之间来回移动他或她的手，并且可以使用非常简单和熟悉的输入在消歧决策树之间导航。
如果用户犯了错误或想要取消选择，则用户可以简单地按退格键删除输入的文本中的字符，这可能会更改上下文，并触发已修改按钮和一个或多个相应动作的重置。如果用户犯了一个错误并且想要退出选择，则他或她可以简单地按下退出键或提供一些键盘、鼠标或其他指示系统返回的输入。
该系统可以了解用户的行为模式和偏好并进行相应调整，以便随着时间的流逝，系统可能需要越来越少的用户输入，才能准确地确定或分类用户的意图。例如，系统可以知道用户已经购买了哪些商品，用户与朋友或家人讨论了哪些商品，即将发生哪些送礼事件等等。基于所有这些数据点，分类器可以对用户的可能或可能的意图做出更准确的猜测。
在不具有鼠标和键盘，而是通常配备有触敏屏幕或触控笔的移动设备中，可以修改上述方法。例如，代替在传统的桌面样式搜索字段和搜索按钮对中修改按钮，该系统的移动版本可以为用户提供搜索字段，以供用户通过屏幕上的虚拟键盘、语音输入或其他一些输入方法输入文本。当用户输入文本时，系统可以从搜索字段中以下拉方式显示一键式操作列表。虽然某些一键式操作可能以传统方式实现搜索，但其他一键式操作可能包括导航到网站中的特定阶段，例如在Amazon.com中，用户已经登录并且仅需执行“一键购买”或在eBay上出价的阶段，或在在线商家的购物车的最后结帐阶段已将所需商品添加到购物车中。用户可以通过将其从屏幕上滑动下来来消除列表中的一键式操作。
用户输入时可调节的输入功能
本文公开的另一概念涉及用于动态修改将在用户输入输入时处理用户输入的输入功能的方法。例如，当用户开始在输入字段中键入文本时，默认功能可能是对文本进行Google搜索。但是，当用户键入文本的第二部分时，可以将用户按下Enter键时出现的功能修改为对文本进行Amazon.com搜索。可以在菜单系统中或通过可选对象显示Enter功能更改的视觉指示。图11示出方法示例。方法示例中的步骤可以以任何顺序执行，可以以包括附加步骤或排除所描述步骤中的某些步骤的全部或一部分的其他组合或排列来执行。该系统可以在用户界面中显示一个输入字段和一个按钮，该按钮根据在输入字段中来自用户的输入，在搜索的第一模式和执行一键式购买和交付的第二模式之间变化，该按钮基于用户按下回车键来执行其各自的功能(1102)。用户界面在接收输入的同时可以呈现消歧信息，该消歧信息向用户指示需要什么按键输入来消歧待购买的物品，并且其中在从用户接收到按键输入时，使得期望的物品的置信度为：如果购买的商品达到阈值，则按钮可以变为第二种模式。按钮的第一模式可以是按钮的默认模式。
系统可以分析来自用户的输入字段中的输入，以确定用户是否希望执行搜索或进行购买以做出确定(1104)。如果确定指示用户希望进行购买，则系统可以将按钮设置为第二模式，并根据用户的注册帐户显示关于将要购买和交付的商品的数据，而无需按下用户输入键(1106)，而无需用户进一步输入。该系统可以通过处理来自与输入字段实体相关联的注册帐户中的商品支付并协调通过业务合作伙伴商家的商品交付来管理商品购买和交付的整个过程。该商品可以是商品或服务。系统可以基于输入基于商品是用户希望购买的最可能商品的概率来选择将要购买和交付的商品。例如，分类器可以基于购买的用户历史记录、搜索的用户历史记录、一天中的时间、一年中的时间、社交媒体数据、有关假期的信息、用户个人资料数据和/或用户帐户余额信息来确定概率和商品。可以通过本文公开的浏览器API在目的地商家网站和用户的浏览器之间检索购买和交付数据。第二模式还可以包括基于用户输入以搜索状态转换到第二目标网站(例如Amazon.com)，就像用户已经导航到Amazon.com(或任何其他辅助网站)并输入用户输入并单击搜索一样。
图12A示出具有通用输入字段1202和可变形搜索按钮1204的用户界面1200。搜索按钮1204实际上是通用功能按钮。系统可以指示用户1206输入查询或其他输入。这种方法的区别在于，通过单击“搜索”按钮执行的功能将根据用户输入而有所不同。在逐步浏览附图时将对此进行解释。图12B示出界面1210中的输入开始被输入到单词“Apple”1212的字段1202中。系统处理该输入以确定是否更改或修改当用户单击“搜索”1204或单击输入按钮时执行的功能。图12C示出用户界面1220中的附加输入“AppleiPhone”1222。该系统将继续处理该输入，并将开始确定也许用户希望执行购买功能，而不仅仅是Google类型的搜索。图12D示出界面1230，其中输入继续更加具体地包括“Apple iPhone 5s”1232。在分析用户输入的阈值点，系统达到足够高的置信度，即需要特定功能。这可以基于历史搜索数据或与历史无关的文本本身。在此，系统将按钮1204从“搜索”更改为“购买iPhone 5s，64GB，金色”1234。用户输入中未标识的选项可以插入文本中，从而也可以消除歧义。但是在这种情况下，该系统从统一的通用输入字段(可以从中进行搜索和购买)中使用户能够简单地按下“输入”或单击图12D中的按钮1204并完成购买的处理和交付。
可以理解的是，该方法使得能够动态修改在用户点击输入或点击图标1204时执行的功能。在某些界面中，例如图3所示，默认过程304被正确显示在输入字段302下方。因此，给定图3界面的状态，如果用户按下Enter键，则将对单词“iphone 5s”进行Google搜索。当按下回车键时，针对动态变化结果应用所描述的原理是用户键入他们的输入，在一个示例中，如果用户要继续在输入字段302“Apple iphone 5s”中输入，则可以修改菜单中商品的顺序，以便将Amazon搜索选项312移动到默认Google搜索304选项为。就像图12D中的更改按钮一样，这将是向用户的指示，即按回车将执行与用户开始键入时将执行的处理不同的处理。
另一个界面可以包括呈现哪些按钮以供用户点击。按钮可以向用户显示不同的选项，使用户可以通过“一键式”进行购买。如果仍然有用户可能只想搜索的可能性，那么也可以使搜索按钮可用。可以通过某种方式突出显示其中之一，以标识如果用户在键盘上按了“输入”，则该特定突出显示的按钮将是将输入作为购买或搜索进行处理的按钮。以这种方式，用户可以先输入输入数据，然后执行功能，而不是先导航到网站(例如Google或Amazon.com)，然后输入用户输入数据。另一个界面允许用户输入“购买iPhone 5S，64GB，金”来直接提示。在这种情况下，系统可以为用户提供选择，以便通过Apple附带运输信息购买，或通过Amazon价格和运输信息1256或通过承运商购买，以便在商店提货。系统与各个网站协商必要的购买信息(信用卡、借记卡、收货地址等)，以便在界面中以一键式购买的形式将其呈现给用户。用户当前无法使用此功能，他们必须导航到单独的网站(例如Amazon.com)，并在该网站上注册此类信息。
在如何更改搜索按钮的格式的另一个示例中，在某些浏览器中，顶部的输入字段可用于输入URL或输入Google搜索。从搜索开始时，您输入的右侧会显示一个标签，指示正在发生的事情。例如，如下所示：“马里兰州的敦刻尔克牙医–谷歌搜索”。“谷歌搜索”语言不是用户键入的语言，而是表示浏览器将文本视为Google搜索。当然，该文本也可以变形，以使得在分析所键入的文本时，可以改变向用户指示当“输入”被击中时将发生什么的指示。例如，用户可能开始输入并看到以下内容：“苹果–谷歌搜索”。但是，随着用户继续输入，它可能会发生如下变化：“苹果iPhone 5s–亚马逊搜索”。随着用户继续输入并造成歧义，这可能导致以下结果：“Apple iPhone 5s 64GB银–亚马逊一键式购买。”此时，用户可以单击“输入”，系统会协调识别商品所需的信息、购买帐户信息(可以与一个实体一起使用)和交货信息，以便可以购买所需商品并将其交付给用户。可以由处理支付处理的一个实体的第二个商家实体管理交付。
图12E示出解决从用户输入到第一目标网站(例如基于用户输入的默认Google搜索)的默认处理到第二目标网站(诸如Amazon.com，Wikipedia或任何网站)的改变的过程的示例方法。该方法包括在浏览器上呈现输入字段，其中浏览器被配置为根据默认目的网站，根据向浏览器指示处理输入的用户交互，通常处理输入字段内的输入(1240)，并将用户输入接收到输入字段中(1242)。在一种情况下，用户输入可以是搜索词，而不是特定网站的URL。基于用户输入，该方法包括动态地呈现对象，该对象指示如果用户在输入字段中输入了用户输入则用户将过渡到的第二目的地网站(1244)，从用户接收向浏览器指示的处理交互处理对象所指示的用户输入(1246)，并基于处理交互，从默认目标网站更改为第二目标网站(1248)，并根据用户输入将用户转换为处于已处理状态的第二目标网站(1250)。
作为图12E所示的处理的示例，假设浏览器将设置谷歌搜索作为其默认处理。如果用户在键盘上的输入中输入“北达科他州”或单击指示进行处理的对象，则呈现给用户的结果将是Google搜索结果中的单词“北达科他州”。但是，基于不同的用户输入，并且在受先前的搜索历史记录或浏览器导航的引导下，浏览器可以通过按钮、对象、在输入字段中自动显示的其他文本或菜单中的项来指示：如果用户敲击键盘上的Enter或单击对象，则默认方法将不会处理用户输入，但会发生更改或过渡，以便当用户单击Enter时将执行其他目标网站或搜索。用户可能会键入“apple iphone 5s”并按回车键，并且基于在用户键入时对用户输入的分析，系统可以从默认过程更改为处理输入，并将用户转换为www.apple.com或www.amazon.com，或任何网站。因此，基于用户敲击回车等而发生的处理在用户键入时动态地改变。如果用户输入的内容与Amazon.com上的商品无关，则系统将根据用户按下Enter的方式处理正常的默认Google搜索，或者如果输入的分析表明该内容可能与商品相关，则系统会更改用户点击Enter进入Amazon.com搜索或其他商家网站搜索并转换到目标网站的结果。
图12F示出动态改变用户输入的处理的另一方面。该方法包括：呈现根据默认目的地网站处理输入的用户输入字段(1260)，基于用户输入，在输入字段中接收用户输入(1262)，自动呈现一个对象，该对象指示如果用户在输入字段中输入了用户输入，则该用户将转换到与默认目标网站不同的第二个目标网站(1264)，并从用户接收确认以处理用户输入(1266)。该方法还包括基于该确认，将用户转换到第二目的地网站(1268)。确认可以是用户按下回车按钮，提供其他某种类型的输入，指示应处理该用户输入，或者按键盘上的回车键。菜单中商品的顺序也可以根据用户类型动态调整，以便在键入时更改默认网站。用户可以在键入时监视这些更改，并获得一键式转换到所选目标网站的机会。一键单击可以是键盘上的输入按钮，也可以是用于处理用户输入的单击对象。注意，不需要其他输入。对象的显示基于在用户输入字段中输入的类型，而无需用户进行任何其他手动交互。注意，用户不必触摸输入按钮，因为对象随着用户类型而动态地呈现，并且基于对用户类型的输入的分析而呈现。因此，目标网站过程的更改可以随着用户的输入而动态发生。
基于上面的讨论，另一个示例可能是从目标网站的角度来看。因此，作为实施方案，将包括任何必要的数据协调或通信，以使得诸如Amazon.com、eBay或Wikipedia的目的地网站或任何其他网站可以从输入字段中的用户输入接收转换，这样就可以将默认目标网站修改为辅助目标网站。该实施方案将包括在目的地网站处接收到这样的转变，其中通过上述过程在其中启用了转变。
本公开的另一方面涉及过程的定时。可以将第一时间确定为用户在将数据输入到输入字段中之前的时间和/或用户开始在输入字段中输入输入时的一部分时间。第一次，当用户键入输入并按下回车键时，回车功能将作为默认操作建立。例如，如果默认输入功能是Google搜索，那么当用户开始在输入字段中输入文本时，默认输入功能就是Google搜索，这意味着如果用户在输入字段中按回车键输入文本，则将对该文本执行Google搜索。在第二次，即第一次之后，即在用户开始输入输入之后，系统可以更改回车功能。例如，在用户键入一个单词或两个单词(如果用户在第一个单词或第二个单词之后点击回车，则将执行第一个默认功能)并键入第三个单词之后，基于整个输入或部分输入，系统确定当用户在第三个单词之后单击回车时应执行不同的功能。然后，系统将输入功能从默认功能更改为新的输入功能。该系统可以确定商品被输入领域而不是地点或其他查询，其指示更多的搜索意图而不是购买意图。图形对象也可以在第二次更改，以通知用户输入功能已更改。该对象可以是按钮、下拉菜单或其他菜单中的商品，也可以是菜单的重新排列，以使菜单中标识的输入功能发生变化。更改可能是自动的，无需任何用户输入，或者用户可以通过与触发更改的菜单项或其他对象进行交互来触发输入功能中一个或多个的更改或输入功能中的更改的图形指示，例如将光标移到建议的新输入功能的标识上，这可能导致更改发生。还应注意，一方面，用户的输入与搜索词有关，而不与网站的URL有关。浏览器上的某些输入字段使用户可以输入默认的Google搜索或www.website.comURL，在这种情况下，当他们单击“输入”时，它们将转换为www.website.com。因此，在一种情况下的输入不同于URL或网站标识符。
在另一方面，用户输入可以被表征为第一部分和第二部分。图12A至图12C示出没有数据的输入字段或搜索查询的开始，诸如单词“苹果”和“iphone”。该文本可以表示用户输入的第一部分。当用户输入第一部分时，默认输入功能1204是可操作的。如果用户单击搜索按钮或按键盘上的Enter键，则将执行默认搜索功能。随着用户输入用户输入的第一部分，设置输入功能，使得如果用户在输入用户输入的第一部分的至少一部分的同时与输入按钮进行交互，则该方法包括根据默认目的地网站处理用户输入的第一部分。图12D示出附加文本“5s”，其可以代表用户输入的第二部分。当用户开始输入用户输入的第二部分时，更改或设置输入功能，使得如果用户在输入用户输入的第二部分的至少一部分时与输入按钮交互，则该方法包括根据第二目标网站处理用户输入，在图12D中显示为购买功能1234，但可以包括到第二目标网站(例如Amazon.com)的转换，并处理了用户输入，就像用户已在用户输入中输入第二个目标网站的搜索字段一样。可以根据键入自动将输入功能从默认功能转换为辅助功能，并且可以显示在输入字段旁边的对象中，或者可以对下拉菜单或下拉菜单进行调整，也可以通过某些用户交互来触发。
图13示出用户界面1300的智能手机版本，其中输入字段1302具有数据1304，该数据1304导致所呈现的各种选项1308。还示出移动键盘1306。在此，“一键式”输入字段1302使用户能够输入通用输入，并具有各种“一键式”选项1308来滚动浏览以处理输入。当然，其他用户界面1300也可以考虑用于移动设备或计算机。与接口1300相关联的应用和/或后端可以与各种网站，供应商等一起预处理购买和交付信息，以使用户能够浏览来自不同来源的选项1308，并且仅从所选择的来源“单击”即可。此外，该系统可以将预处理的输入呈现给一个阶段，而不仅仅是在“单击”阶段，而是在搜索结果阶段，以便用户可以在购买前浏览和学习更多内容。例如，结果1308可以指示该广告与“立即购买”选项相关联，并且将根据此处公开的原理进行处理，例如搜索实体已存储用于处理支付的支付信息，并且正在与要处理送货的商家进行通信。如在图13中可见，可以在响应中提供各种商家品牌，以使得商家可以维持与买方的关系，但是使用本文公开的购买选项特征和API简化了购买过程。
一方面，随着用户在查询中键入，各种目的地选项1308可以切换位置。例如，当用户在第一时间开始键入用户输入的第一部分时，顶层选项可能是搜索引擎，该搜索引擎指示在用户点击输入时将执行哪个功能。随着用户继续键入用户输入的第二部分(例如“5s”)，如图13所示，目标功能可以基于该输入进行调整，以便呈现不同的顶级目标功能。因此，如果在键入用户输入的第二部分中的至少一些之后用户按下回车键，则用户输入将根据通过位于菜单项1308的顶层上而被用户识别的辅助功能来处理。通用搜索应用程序编程接口(API)
公开了一种系统、方法和计算机可读存储设备，其基于由分类器确定的意图来替换URL，该分类器处理提供给统一输入字段的输入。在典型的Web搜索中，用户单击以选择一个搜索字段，输入文本，等待结果页面加载，在结果页面中单击所需的链接，并在等待加载后最终到达所需的链接。此过程需要很多步骤。统一的输入字段可以简化此过程。
例如，one-search.com可以提供统一的输入字段。用户通过统一的输入字段提供输入，例如搜索“iPhone 5S”。系统可以基于用户配置文件和输入的文本来识别最可能的所需页面，例如搜索结果列表中排名靠前的页面。系统可以修改与统一输入字段关联的“搜索”按钮，以指示按下Enter或单击按钮将使用户从搜索结果过渡到排名靠前的页面，而无需上面概述的中间步骤。但是，如果用户输入其他信息，例如“iPhone 5S 32GB银色”，则分类器可以基于文本并结合用户个人资料或搜索历史来确定用户的意图是购买所指示的iPhone。在这种情况下，系统可以修改搜索按钮以直接链接到Amazon.com或Apple.com页面，就好像用户已经导航到那里一样，选择了iPhone 5S，32GB，银色，并将iPhone添加到购物车中，并且处于结帐流程的高级阶段或潜在的最后阶段。在Amazon.com的情况下，系统可以修改按钮以将用户切换到页面，以供用户一键购买指示的iPhone。或者，系统可以将按钮修改为还包括单击“一键购买”按钮的操作，以便用户可以访问one-search.com，在统一输入字段中输入文字，然后按Enter键即可通过亚马逊购买。在这种情况下，在统一输入字段中输入文本后按回车键可能会导致刚刚执行的订单的购买摘要，从而可能使用户修改运输选项、商品选项、开票信息或其他订单详细信息。在另一个变体中，系统可以基于用户在统一输入字段中按回车键，或者基于与社交媒体网站或任何网站的交互来自动下订单，并将用户转移到用于购买配件、与所购买物品有关的服务、技术支持页面或某些其他相关Web资源的网页。
因此，系统可以立即将用户从one-search.com统一输入字段或任何网站转换到Amazon上的一键式购买页面，例如，当用户点击统一输入字段中的Enter或处理任何网站上的输入或交互时。该系统还可以将购买包括在过渡动作中，以便基于用户在统一输入字段中按Enter键来完成购买。在这方面，one-search.com将处理购买事宜，然后与第二个实体(例如Amazon.com)或商家进行协调，以完成商品的交付。
系统可以根据用户输入显示不同的选项或不同的目的地。例如，系统可以显示一条消息或指示，表明按下“输入”本身会将用户转换到Amazon.com上所需商品的一键式购买页面，而按“alt-enter”将自动在Amazon.com上进行购买。系统可以向用户显示一条消息，说明按下“shift-enter”将使用户过渡到Apple.com上预先填充的购物车页面，以供用户单击“提交订单”。多个不同的键和/或组合键可以基于统一输入字段中的输入触发不同的行为。此外，当用户在统一输入字段中输入其他文本或修改统一输入字段中的文本时，触发这些动作的各种动作和组合键可以更改。
用户可以在系统上建立首选项，例如，指示所有购买均默认为Amazon.com，除非该用户拥有现有帐户的另一家零售商的价格差异大于20％，或用户没有现有帐户的其他零售商的价格差异大于30％。以这种方式，系统可以基于用户建立的规则或策略来智能地行动。
一方面，该系统可以基于用户建立的财务策略来智能地行动。该系统可以将不同零售商处的潜在购买价格与用户建立的财务政策进行比较，并据此做出确定。例如，现有策略可以规定用户每月只能在一定数量的网上花钱，例如500美元。当用户达到在线消费限额时，系统可以通知用户特定的购买将完全耗尽该用户本月的更多消费。然后，用户可以使用此附加信息做出购买决定。例如，由于资金限制，用户可能选择购买价格适中的iPhone而不是购买最昂贵的iPhone。或者，当用户有更多在线消费时，用户可以选择等到下个月购买最昂贵的iPhone。尽管这违反了既定的财务政策，因为用户认为这是当务之急，例如工作中的电话，但用户仍可能决定继续进行购买。考虑了其他规则或策略，这些规则或策略将使系统能够代表用户进行智能操作。该方法还可以应用于图17I所示的场景，其中浏览器购物车可以应用于多个购买网站。可以从各个网站将多个物品放入购物车中，然后再进行购买，可以应用一项策略，在最终完成购买之前，该策略将分析用户的财务状况，就像用户进行了购买并提出建议一样。推荐可以包括不进行任何购买，仅购买购物车中的一项和/或进行任何其他组合。建议根据应用的算法将用户的财务状况维持在适当的状态。2013年10月2日提交的申请号14/046,444包含许多概念，这些概念可以应用于此处公开的浏览器购物车模型。该申请通过引用并入本文。
用户单击Enter后，系统可以立即转换到新的URL或目标网站，就像用户单击并浏览了购物车中的一系列页面一样，依次加载每个页面并在浏览器端自动输入数据，或者系统可以直接与目标网站进行通信，以完成与选择商品、将该商品添加到购物车、输入或选择运输和支付信息等相关的各种子任务，直到用户只需单击“提交订单”即可的最终阶段。浏览器API可用于管理支付方法。此类子任务的一个示例是，一个搜索实体可以处理支付信息并协调向要交付商品的商家的交付数据。在用户点击统一输入字段中的输入后，系统可以在向用户展示页面之前预先执行所有这些步骤。
图14A示出方法示例。方法示例中的步骤可以以任何顺序执行，可以以包括附加步骤或排除所描述步骤中的某些步骤的全部或一部分的其他组合或排列来执行。该系统可以在第一用户界面中呈现与第一网站相关联的第一输入字段(1402)。系统可以分析来自用户的输入到第一输入字段中，以确定用户是否希望执行搜索或进行购买以做出确定(1404)。该确定可以指示用户期望进行购买的置信度已经超过阈值。
如果确定指示用户希望进行购买，并且除了输入和/或可能是Enter键之外，没有其他用户输入，则系统可以自动将用户界面转换为第二个网站，其中第二个用户接口具有第二输入字段(1406)。系统可以使用输入来预填充与第二网站相关联的第二输入字段(1408)。系统可以使用第二输入字段中的输入对第二网站进行预处理，以使用户处于自动转换后的状态，在该状态下，可以通过用户的一键式操作来处理与输入关联的商品以进行购买和交付(1410)。该系统例如可以通过API将用户数据从第一网站和/或浏览器中的一个通过API传输到第二网站，或者自动浏览第二个网站的购物车模型，以产生一种状态，在该状态下，可以通过单击操作来处理要购买和交付的商品。通过将浏览器的统一资源定位符字段中的第一网站替换为浏览器的统一资源定位符字段中的第二网站，系统可以自动将用户界面转换为第二网站。该系统可以进一步准备具有使用输入进行预处理的第三输入字段的第三网站，其中用户可以提供切换输入以指示应该呈现第三网站而不是第二网站。在另一个示例中，第一网站可以处理物品的支付并与第二网站进行协调，以提供用于物品交付的必要信息。
图14B从搜索引擎的角度示出经由API在搜索引擎和商家之间进行处理的示例。该方法包括在通用搜索实体的用户界面上呈现输入字段，其中该通用搜索实体使用通用搜索引擎处理数据，该通用搜索引擎索引并搜索商家网站和非商家网站两者(1412)，在输入字段中接收查询(1414)，并将该查询与来自商家的待售商品的商品数据库相关联以产生相关性(1416)。该方法包括至少部分地基于相关性来确定查询与搜索意图和购买意图之一相关联以产生确定(1418)。当确定指示搜索意图时，该方法包括呈现包括非商家网站的搜索结果，接收与非商家网站相关联的搜索交互，并基于该搜索交互而过渡到非商家网站(1420)。当确定指示购买意图时，该方法包括呈现包括与查询相关联的购买选项的购买相关搜索结果，使得购买相关搜索结果被配置为使得当用户与购买相关搜索结果交互时并且通过与购买选项交互来确认购买，通用搜索实体启动对物品的购买的处理(1422)。通用搜索实体存储支付信息，或者第三方支付处理服务存储支付信息，浏览器可以存储支付数据，并且这些实体中的一个或两个都通过诸如API的通信接口与商家网站进行通信，以交换商品数据库中商品的广告信息和支付信息。任何信息处理都可以在浏览器、非商业网站和/或商业网站之间的API的任何一侧发生。
图14C示出与图14B类似的过程，但是从商家的角度来看。一种方法包括从商家网站经由通信接口在商家网站与广义搜索实体之间建立通信(1424)。在这种情况下，广义搜索实体执行上述操作。也就是说，广义搜索实体在广义搜索实体的用户界面上显示输入字段，其中，广义搜索实体使用广义搜索引擎处理数据，该引擎对商户网站和非商户网站进行索引和搜索(1426)，在输入字段中接收查询(1428)，将查询与商家销售商品的商品数据库相关联以产生相关性(1430)，至少部分地基于相关性，确定查询与搜索意图和购买意图之一相关联以产生确定(1432)。当确定指示搜索意图时，广义搜索实体会提供包括非商家网站的搜索结果，接收与非商家网站相关联的搜索互动，并根据搜索互动转换为非商家网站(1434)。当确定指示购买意图时，广义搜索实体呈现与购买相关的搜索结果，该搜索结果可以包括与查询相关联的购买选项，其中，购买相关的搜索结果被配置为使得当用户与购买相关的搜索结果进行交互并通过与购买选项进行交互来确认购买时，广义搜索实体启动商品购买的处理(1436)。然后，商家网站可以通过通信接口接收有关完成购买的数据以及管理向买方交付商品的必要信息(1438)。
图15示出示例场景1500，该场景示出经由应用程序编程接口(API)1502的通信。一个搜索服务器、网络服务器、社交媒体网站、支付服务或某些其他计算设备可以提供经由API 1502可访问的服务。可以从服务页面的Web服务器访问Web浏览器或其他Web客户端、移动设备的应用程序或从Web浏览器访问API 1502提供的服务，例如通过对API 1502的JavaScript调用。在该示例中，浏览器导航到第一网站1504，并且在不依赖于API 1502的情况下从第一网站服务器1506检索第一网站的数据，例如HTML、CSS、JavaScript、图像、元数据或其他数据。然后，当浏览器解析第一网站1504的数据，呈现页面并加载该网站的脚本或其他可执行指令时，数据的一个或多个部分链接到或引用API 1502。例如，与文本字段关联的属性或指令可以指示浏览器通过API 1502请求搜索数据。API1502处理如何管理请求的复杂性，以使浏览器1504不必知道或关心哪个服务器正在处理该请求、如何处理数据以获得结果，等等。从网络浏览器1504的角度来看，数据被提交给API 1502，并且API提供结果数据或执行结果动作。示例动作可以包括在网站1504处提供用于处理支付的支付数据或在第二网站1508处与支付服务进行通信。在这种情况下，文本字段可以指示浏览器基于在文本字段中输入的文本向API 1502提交请求。因此，当用户输入文本“购买iPhone 5S 64gb”时，已经加载了第一网站的浏览器1504可以逐个字符，逐个单词或以某个时间间隔(例如250毫秒)将文本字符串提交给API 1502。此外，作为页面加载和呈现过程的一部分，浏览器1504可以为用户提交用户数据，或者可以使用API 1502建立，重新建立或链接到现有会话，因此API 1502具有有关用户的足够上下文数据，可以做出适当的决定。响应于从网络浏览器1504接收到文本，API 1502可以分析数据、确定一个或多个动作、网络浏览目的地、想要购买的物品等的响应。然后，API 1502可以将一个或多个动作的列表选为N最佳列表，该列表可以基于用户正在使用的设备或浏览器的类型。例如，在屏幕空间有限的移动设备上，N最佳列表可以限制为3个动作或目的地，而在屏幕空间更大的台式机或便携式计算机上，N最佳列表可以限制为10个动作或目的地。作为确定最佳动作或目的地的一部分，API 1502可以与第二网站1508进行通信，该第二网站可以提供支付服务或任何其他服务或数据。如果该动作是第二网站1508的一键购买动作，则API 1502可以代表用户或浏览器1504与第二个网站1508进行协商，以导航到第二个网站1508上的适当位置，自动填充适当的数据字段，创建一个帐户(如有必要)或登录到该用户的帐户，当用户单击购买按钮时通过第二个网站通过API接收支付请求，并用支付数据进行响应，依此类推。API 1502可以响应于API请求自动处理所有这些任务，并将该信息传递回第一网站1510的浏览器，该网站向用户呈现这些可能的目的地或动作。如果用户选择与第二网站相关联的目的地或动作，则浏览器然后可以直接继续与API 1502创建或修改的第二网站1508的会话。这样，API 1502可以在网站之间进行协调，并响应于API调用自动输入用户数据，并代表用户预先导航到各种动作或目的地，以便为用户选择和打开做好准备。登陆第二个网站后，如果出现购买按钮并且用户单击购买按钮，则第二个网站可以通过浏览器API请求支付信息，并通过浏览器API接收支付数据，例如帐户和地址或用于处理支付的令牌。注意，还可以与图18A协同使用图15，并且使用两个API 1818、1812来管理浏览器1806在商家网站1816和支付服务1810之间进行协调。换句话说，图15和图18A示出，在一个方面，如何使用API管理第一网站和第二网站或支付处理器之间的支付数据和支付处理。
应用API的示例方法如下。一种方法包括在用户界面上呈现输入字段，其中使用通用搜索引擎将该输入字段与处理数据相关联，该通用搜索引擎索引并搜索商家网站和非商家网站(或任何其他网站，例如社交媒体网站或Messenger应用程序)，在输入字段中接收来自用户的输入以产生用户输入(除了输入字段输入以外，还可以是其他类型的输入，基于各自网站的功能)，并接收与用户输入相关联的交互，该交互指示通用搜索引擎应处理用户输入。当确定用户输入以指示搜索意图时，该方法包括：呈现可以包括非商家网站的搜索结果；以及接收与该非商家网站相关联的搜索交互，以及将用户转变为非商家网站。当确定用户输入指示购买意图时，该方法包括经由应用程序编程接口从商家网站接收与物品相关联的数据，该物品基于用户输入被选择，呈现与购买相关的搜索结果，该结果可以包括与该商品相关联的“立即购买”选项，接收与该“立即购买”选项相关联的用户交互，并基于用户交互，通过在通用搜索引擎或浏览器中为用户存储的支付信息处理商品的支付，以产生购买数据。然后，该方法可以包括经由应用编程接口将购买数据传送到商家网站，由此商家网站可以管理物品向用户的交付。
从商家方面，该过程如下：一种方法包括从商家网站经由通信接口或应用程序编程接口在商家网站和广义搜索实体(或任何网站，例如社交媒体网站或任何其他应用程序)之间建立通信。通用搜索实体用于在用户界面上显示输入字段(或基于相应网站的其他功能)，其中使用通用搜索引擎将输入字段与处理数据相关联，该通用搜索引擎对商家网站和非商家网站进行索引和搜索。广义搜索实体在输入字段中接收用户输入。当用户输入指示搜索意图时，广义搜索实体呈现搜索结果可以包括非商家网站，接收与非商家网站相关联的搜索交互并将用户转换为非商家网站。当用户输入指示购买意图时，广义搜索实体呈现与购买相关的搜索结果，该搜索相关搜索结果包括与用户输入相关联的购买选项，搜索结果包括从商家网站提供的商品。通用搜索实体接收与购买选项关联的购买交互。该过程的商家方如下。当用户输入指示购买意图时，该方法包括经由通信接口并且在商家网站处从通用搜索实体或浏览器接收支付信息，该支付信息与针对该物品的购买交互相关联的支付信息以及经由商家网站处理该物品的交付。以这种方式，商家网站或应用程序可以通过应用程序编程接口或通信接口进行通信和接收通信，以实现其商品之一的展示和销售。
还应注意，尽管图15示出经由API进行通信的网站，但是该API还可以实现设备上的两个应用之间的通信，或者可以引起网站与设备上的应用之间的通信。该API也可以位于浏览器和网站之间。该API旨在成为两个不同实体的工具，每个实体具有不同的目的或与用户接口的方法，以便可以促进两个实体之间的协调。
社交网络应用
推特
该示例的另一方面是这些概念如何应用于上述社交网络应用程序，例如Twitter。Twitter是一种社交网络应用程序或服务，用户可以在其中发送和阅读通常等于或少于140个字符的短信。注册用户可以发布“推文”，这些推文通过网络传输给关注者。用户也可以发布图像和视频。未注册的用户可以阅读推文。用户通过网站、移动设备应用程序或某些其他应用程序访问服务。本文公开的应用于诸如Twitter的社交网络的概念的示例如下。一种方法可以包括在社交网站的用户界面上呈现输入字段，其中，该输入字段与处理社交网站内的社交网络的数据相关联。对于Twitter，该社交网站可以将简短的140个字符或更少的基于文本的消息从发件人发送给关注者。图片或视频也可以通过此网站进行传输，并带有指向或引用商品的元数据。在图像或视频的情况下，元数据可以与引用商品数据库并触发购买选项的处理和表示的图像或视频相关联。这将适用于Twitter帐户、Facebook、Instagram、Pinterest等。这些示例中的一般方法在下面的图30及其相关讨论中进行描述。
通常，用户将数据输入到输入字段中，并将数据(文字、图片和/或视频等)发送给该用户的关注者。该方法可以包括：通过社交网站呈现输入字段或机制；以及在输入字段中接收基于文本的用户输入；以及使用基于文本的用户输入来产生第一确定，来确定基于文本的用户输入是否与商家销售商品的商品数据库相关联。这可以通过链接或用户输入分析来完成。在这方面，例如，推特用户可以将文本输入到推文中，并且系统将分析该文本以确定输入是否引用了商品数据库，从而可以与销售、广告、购买或其他意图相关联。如果用户输入没有引用商品数据库，则系统可以确定用户输入与销售无关，而仅仅是通过社交网络系统传输。换句话说，用户可能只是向根据第一意图(与关注者共享信息的正常推文意图)通过社交网站以正常方式分发或传输的系统提供正常推文。
然而，当确定指示用户已经参考了特定商品数据库并且因此参考了与销售有关的意图时，该方法包括通过社交网站传输基于文本的用户输入以及与基于文本的用户输入相关联的购买选项。在这种情况下，例如，文本输入可以提供指向商品数据库或服务的链接，该链接指示发送广告、购买商品或销售商品的意图。如果意图是与销售或购买相关的意图，则除了仅通过社交网络传输推文之外，系统还可以协调并显示与文本输入关联的购买按钮。与本文公开的Google示例非常相似，该社交网站或与该社交网站相关联的服务可以存储用户支付处理信息，因此仅需要用户输入一次此类信息。因此，该推文的接收者不仅将至少看到该推文的某些文本，而且还将看到购买按钮，并且系统可以接收与购买选项相关联的购买交互。然后，系统将处理与推文关联的商品的购买。如此处所指出的，通过API，可以处理交易(通过社交网站)，并且可以由商家通过API进行协调来管理交货。此过程将通过社交网络提高销售转化率。在本文提到“基于文本的输入”的每种情况下，一种替代方法可以是接收具有元数据的图像或视频，该元数据提供访问商品数据库所需的信息，并且处理以类似的方式继续。当然，可以通过任何社交网站(如Facebook等)使用类似的方法。
另一方面是从销售商品的商家的角度通过社交网站处理购买选项。在这个方面，一种方法可以包括从商家建立商家与社交网站之间的通信，该通信在社交网站内处理和发送140个字符或更少的短消息。可以建立通过其可以发生这种通信的API。社交网站在用户界面上显示输入字段，在输入字段中接收文本用户输入，并使用基于文本的用户输入来确定文本用户输入是否与商家销售的商品数据库相关联。例如，可以将URL放置在访问商品数据库的推文中，而商家可以通过该数据库提供商品。
当确定指示在文本用户输入中没有参考到商品数据库时，社交网站以正常方式通过社交网站发送文本用户输入，例如发送推文或发布Facebook帖子。当确定指示文本用户输入参考待售商品的商品数据库，从而指示与销售有关的意图，网站通过社交网站发送文本用户输入，以及与文本用户输入关联的商品的购买选项。因此，那些阅读或接收推文或发布的人将看到与该商品关联的购买选项。收件人可以通过社交网站或其他服务(如ApplePay或Paypal)存储他们的支付信息，从而可以购买通过此服务提供的所有不同商家的商品，而无需将其转移到该商家以输入支付信息，等等。然后，商家接收到表示接收到与购买选项相关联的购买交互的指示(即收件人点击了购买按钮)，并处理向提供购买交互或基于购买交互处理交付的人的物品的交付。社交网站然后可以向商家支付该物品。社交网站或其代理商也可能会收取少量费用以处理销售。使用文本用户输入来确定文本用户输入是否与来自商家的待售商品的商品数据库相关联，可以包括通过应用程序编程接口在社交网站和商品数据库之间进行通信或相关联。处理物品的交付可以包括：从社交网站接收关于物品的支付已完成的信息；以及接收关于通过应用程序编程接口出售该物品的商家要将物品运送给人的信息。
从商家的角度来看，Twitter示例与处理有关。在这种情况下，商家在社交网站的用户界面上的输入字段内发布140个字符或更少的短消息。社交网站在输入字段中接收基于文本的用户输入，并使用基于文本的用户输入来确定是否将基于文本的用户输入与来自商家的待售商品的商品数据库相关联。当确定指示没有对商品数据库的引用时，社交网站通过社交网站发送基于文本的用户输入。当确定指示基于文本的用户输入引用了待售商品的商品数据库，从而指示销售相关的意图，社交网站通过社交网站将基于文本的用户输入与与基于文本的用户输入相关联的购买选项一起发送，接收与购买选项相关联的购买交互，并基于购买交互来处理商品的购买。然后，商家在发布实体处接收指示该物品已被购买的购买数据。因此，商家将通过API接收到有关收件人已购买商品的通知，并且商家应发货。
在另一方面，该方法可以包括在社交网站的用户界面上呈现输入字段，其中该输入字段与在社交网站内处理和发送140个字符或更少的短消息相关联，接收在输入字段中至少包括用户文本的用户输入，并基于该用户输入确定文本是否与商家销售的商品数据库中的商品相关以产生相关性。当没有与文本相关的商品时，该方法包括通过社交网站传输用户输入。当存在与文本相关并因此指示与销售相关的意图的商品时，该方法包括通过社交网站向用户发送带有与用户输入相关联的购买选项的用户输入，接收与购买选项相关联的购买交互，并基于购买交互来处理商品的购买。
在另一方面，单击社交媒体网站上的商店按钮可以将用户转变为与商品相关联的商家网站。过渡可以以一键购买状态从浏览器访问数据以过渡到商家网站，以便用户可以从商家网站购买商品。浏览器API可用于请求和接收用户的支付数据。
在支付方法中使用社交网络对话
以下讨论将本文公开的几个特征组合在一起。社交网络购买按钮的概念与图3和4中引用的对话框功能结合在一起，其中用户可以转换到对话框以缩小范围并选择更多功能。可以在对话框元素中合并购买选项。以下讨论还包括以下概念：将对话从远程网站转换为具有对话应用程序的社交网站，该对话应用程序使用户能够进行通信，并且其中将远程网站上查看的商品的支付方法和数据将转换到对话框中，以便可以通过对话框完成购买。
如上所述，本申请中的权利要求书集中于支付交易的对话组件。本公开解决了使得用户能够在完成购买之前学习关于商品的更多信息并询问关于商品的更多问题的问题。在某些情况下，一键购买选项或购买选项可能适用于需要一些其他数据(例如尺寸或颜色或其他参数)的商品。用户可能还有其他有关交付、不良宣传、不良评论等的担忧。在这种情况下，可以在购买商品的过程的某个阶段显示对象，该商品可以将用户转换为对话应用程序或交互。从对话框中，用户可以完成信息并确认购买。过渡可以来自单个网站(例如从新闻提要中的广告到Messenger应用程序的Facebook)，也可以跨多个网站。例如，如果用户有疑问或需要对商品做出其他选择，则过渡到Facebook Messenger应用程序(或任何对话框应用程序)可以帮助完成购买。因此，可以在该过程的任何阶段的任何网站上转换到对话应用程序，以帮助提供进一步的数据。对话框应用程序可以在Webview界面中显示，该界面可以是浏览器的简化版本。一种示例方法可以包括向广告呈现支付方法发起对象。支付方法发起对象可以包括对话应用程序的链接或过渡，在对话应用程序中，用户参与有关讨论商品/商品的对话并完成购买。过渡和讨论配置为，一旦问题得到回答或收集了信息，便可以轻松支付。过渡可以是在下拉菜单中向下滑动商品列表，然后选择功能部件并通过配置为完成购买交易的下拉菜单中的商品进行购买。
就这一点而言，示例方法包括通过社交网站接收物品的发布，其中，社交网站接收发布物品并将其从发布实体发送到接收实体。当发布与商品数据库中的要购买的商品不相关联时，该方法包括通过社交网站传输发布，而没有购买选项或某些其他交互式号召性用语。可选地，当所述确定指示所述发布参考所述商品数据库中的所述商品，并且因此指示与销售相关的意图时，所述方法包括通过所述社交网站传送所述发布以及与所述商品相关联的支付方法发起对象，其中，支付方法发起对象包括按钮、下拉菜单或超链接之一，并接收与支付方法发起对象相关的交互，该交互由用户执行。发布实体还可以在诸如用户的新闻源的社交媒体网站上直接使用购买按钮发布基于商品或基于广告的发布。基于购买交互，该方法包括作为支付方法的一部分与用户进行关于该商品的对话，以使得在对话结束时，用户可以完成该商品的购买。该对话框可以经由诸如webview浏览器之类的浏览器来呈现，使得浏览器API可以被用来在商家和浏览器之间进行通信，以使商家能够接收支付数据。因此，可以从社交网站上的任何交互状态，新闻源或广告或其他方式，将用户转换为浏览器界面，例如配置了浏览器支付请求API功能的MessengerWebview，并通过浏览器与商家网站进行交互，当需要支付时，商家可以通过浏览器API与浏览器界面进行通信，以请求支付数据并接收用于处理商品支付的支付数据。
作为对话框的一部分，该方法可以包括：从用户接收购买交互并基于购买交互来处理商品的购买，其中，处理购买发生在社交网站之一中，通过支付代理或通过社交网站或浏览器与销售商品的商家网站之间的应用程序编程接口进行。社交网站或浏览器可以存储支付数据，以供用户处理购买。当经由社交网站或浏览器与商家网站之间的应用编程接口发生购买时，社交网站或浏览器可以通过应用编程接口传输支付数据，使得商家网站可以处理商品的购买。
该对话框可使用户选择与商品关联的参数。示例参数包括颜色、尺寸、形状、配置和技术特征中的一个或多个。可以在对话框中管理交货选项，解决任何其他问题、礼物问题、折扣、优惠券等。支付方法启动对象可以简单地包括购买按钮或通知“通过单击此处讨论并购买此商品”。可以通过对话框应用程序在用户和商家之间管理对话框。一方面，可以通过过渡到用于管理对话框和商品购买的对话框应用程序来实现参与对话框。
如果site.com(或应用程序)上的状态包括购买按钮，则可以结合浏览器API或其他通过浏览器、代理或其他方式(例如将支付信息从浏览器传递到网站以进行最终支付处理)处理支付的API来显示这种购买按钮。
下面是从任何网站或应用程序转换为配置为允许从用户向商家支付的对话应用程序的一个示例。假设用户在网站或应用程序(例如site.com)上。通常，该网站处于接近能够购买商品或服务或提供某种支付方式的用户的状态。在购买或支付的现阶段，网站可以通过API进行交互，以获取有关用户以及用户通过对话应用程序(例如Facebook Messenger或SMS应用程序、电子邮件应用程序或用户可以在其中进行交互以获取有关商品或服务的更多信息或提出问题的任何其他应用程序)进行支付的信息。该网站可以通过发出请求并接收进行传输所需的数据来进行交互。例如，该网站可以发出数据请求，询问用户是否具有Facebook帐户，以及用户是否配置为通过Facebook进行支付，或者他们是否具有与浏览器有关的数据存储在Facebook上以启用购买。其他数据可能是使用PayPal、Apple Pay或Android Pay开设的帐户，或需要的任何其他类型的数据。然后，该信息可用于实现商品支付。
如果通过API或其他方式提供了可以通过对话应用程序进行支付的确认，则网站可以在购买对象的路径上的任何阶段出现在用户界面上。该对象可以是“聊天并支付”或“对话/询问问题”，也可以是“有关此商品的Facebook Messenger”。通常，将对对象进行配置，以便与该对象的用户交互将导致过渡到可以与site.com分开的对话框应用程序。例如，过渡可以到Facebook Messenger进行讨论。此阶段的一个问题是site.com是否知道用户是谁。在此阶段，假定网站要么知道用户是谁，要么可以通过API进行访问，否则假定用户名，以便转换可以传达必要的数据以登录到用户的对话框应用程序和/或Facebook。用户信息可以来自google.com之类的网站、搜索引擎、浏览器或其他服务。因此，交换了所有必要的信息、密码、加密、安全性、名称等，以便响应与网站上对象的交互，向用户显示一个对话框，该对话框配置为使用户可以开始与网站进行有关该商品的消息传递。提供了诸如图像、价格、大小、数量或其他数据之类的商品。如果用户在网站上选择了商品并输入了折扣或优惠券等数据，则可以将其中一个或多个参数传递给对话框应用程序。因此，对话应用程序中的视图可以包括商品/服务的图片、价格、运输费用(可以通过用户的位置来确认交付或地址数据)、折扣、交货地址、运输说明等中的一个或多个。然后，用户可以询问更多详细信息，例如他们想要的尺寸或颜色。他们可以问商家的问题。该网站可以提供必要的过渡，以便员工或机器人或对话应用程序可以与用户进行交互。用户可以通过对话框应用程序询问任何自然语言的问题，例如“等级是多少、等级是否大、或者我是否可以用红色表示。”
为了促进对话，如果系统具有自然语言界面，则可以针对商品量身定制的对话模型(例如语音识别模型、口语理解模型、发音模型、语音生成模型等)以及围绕商品的讨论。可以加载存储商品所有特征的字典(颜色、尺寸、技术特征等)，以提高识别、理解和语音生成。可以提供社交信息，例如有关通过Facebook购买了该商品或类似商品的朋友的详细信息。该对话框可能包括“您的朋友约翰在两周前购买了该商品，并给它4/5的评分。”无论该对话框是与真人一起使用还是与自动化系统一起使用，都可以使用此类信息。例如，本文公开的跟踪和管理跨多个渠道的用户购买的购买管理系统可以通过API或通过某些其他方式将其数据传达给对话管理系统，这样您的社交网络中朋友的购买历史和/或经历。该信息可以提供给对话框应用程序，用于回答问题并与用户进行交互。如果对话应用程序是基于语音的，则可以使用此类数据动态或预先更新语音识别模型、口语理解模型、语音生成模型等中的一个或多个，以改善对话体验。例如，某些音素、单词、短语、名称、商品名称等可以加载到这些语音处理模型中，以将对话应用程序聚焦于该特定用户。还可以生成动画角色来与买家互动并接收问题并提供答案。可以至少部分地基于诸如朋友、家人、喜欢的演员等等的特征来选择角色。获得的有关购买者的社交网络数据可用于选择动画实体的声音、性别、政治倾向、种族等，这些动画实体将使用户参与有关商品的对话。可以收集有关该商品和购买该商品的朋友的预合成语音单元。个人信息也可以合并到对话框中。例如，实体可以说：“珍妮明天生日快乐，我如何帮助您购买这张椅子，您想要黑色吗？”因此，当用户点击将其转换为对话框的购买过程发起对象时，对话框管理系统可以从各个位置(例如关于商品数据的商家、商品评论数据、与该商品相关联的朋友/家人数据、关于用户的社交媒体数据等等)获取文本和数据，以在围绕该特定商品的对话框中生成特定领域的体验。因此，提出的方面可以使用户在舒适的环境中感到更舒适。可以为特定用户量身定制口音、个性、笑话、视觉特征、对话响应、时间安排等，以便即使他们只想选择红色作为椅子的颜色，在与该商家交流时，他们也可以拥有更加社交愉悦的体验。
如上所述，过渡对象可以例如作为广告的一部分来呈现，该广告是在搜索引擎上搜索的结果。因此，尽管本文中公开了“购买按钮”作为该广告的一部分，但是购买按钮可以带有“使者”或“对话”或过渡按钮上的其他标签，使用户可以与商家就商品进行对话。当然，广告只能只包含过渡按钮。当系统将用户转换为付费对话系统时，商家或网站的工作人员会收到有关对话即将开始的通知。可以向该人展示商品。可以组织提供给有生命的人的数据，以便最相关的数据可以帮助他们在对话框中快速回答问题并促成销售。如果朋友购买了该商品，则会提供该信息。如果潜在买家刚刚去过意大利(通过其Facebook帖子知道)，并且如果他们回到意大利，那么该商品可能是有意义的，则可以将该信息提供给工人。因此，可以对用户在一个或多个社交媒体网站上的社交媒体活动、他们的朋友和联系人数据和/或可能与该商品相关并汇总并提供给工人以供与当前买家的对话中使用的任何其他可用数据进行分析。由于工作人员一次只能显示这么多的信息，因此该信息可以动态更改，以使当买方与对话系统进行交互时，该信息可以更改和修改。例如，买家可能会问：“我的朋友有没有买过？”，系统可以自动处理该数据并提供给工人，或自动提供信息以回答该问题。随着用户通过社交媒体网站进行购买，此类信息将变得更加可用。也可以为API提供该信息。例如，如果买家的5个朋友通过Google搜索或直接从site.com等购买了该商品，则可以像共享Facebook朋友数据那样共享该信息。假设有适当的权限，并且朋友允许共享这些信息，则可以使用API启用网站，以回答“我的任何一个朋友都买过”这个问题，从而对买家的Facebook朋友进行查询，以确定是谁购买了该商品或类似商品，即使该商品不在Facebook上，也没有直接在该数据库中。API可能会做出回应：“约翰在Amazon.com上购买了此商品，简在弗吉尼亚州阿灵顿的百思买购买了此商品，弗雷德上周通过Facebook购买了类似商品。”还可以提供购买时间，获得折扣，使用优惠券，使用礼品卡(弗雷德使用Jane Smith的礼品卡)。可以在信息数据库中识别和汇总个人的购买数据，然后可以在上述情况下访问该数据库，以便以对话方式向购买者提供有关特定商品的信息。
当然，其他信息也可供用户使用-例如商家评级、商品评级、商品的客户评级、退货率、投诉等。当系统从广告或网站过渡到对话应用程序时，可以自动提供该信息的摘要。这很重要，因为在某些情况下，通过一键式购买，用户希望在购买前了解有关商家和商品的此类评级。通过跳入对话框应用程序，他们可以快速找到更多的信息来解决他们可能遇到的任何问题，并在对话框应用程序内完成购买。
如果系统是自动的或作为口语对话系统的一部分，则可以汇总该信息，并可以为对话框编译和生成更新的语言模型、识别模型、口语理解模型等。因此，朋友名称、商品名称、位置、商品特征等等都可以被组合，使得可以提供非常定制的语音处理系统，使得与口头对话系统的交互尽可能干净和正常。
当提出问题并回答问题或提供其他参数时，对话框中的交互将达到适当地展示购买对象的地步。用户/买方可以写或说“我准备购买”，并且通过对话使者从网站的响应，用户可以看到诸如“立即购买”之类的对象。
此时，用户可以与“立即购买”按钮进行交互，并且可以通过对话框应用程序使支付如此处公开的那样进行。通过API，对话应用程序了解有关商品的所有支付信息，便可以使用该数据来管理支付方法。对话应用程序可以在本地处理支付，将支付信息数据传达到网站或使用其他支付服务。该网站还可以提供加密货币选项来支付。可以提供优惠券、折扣等。该网站还可以利用浏览器支付请求API来请求支付数据，并通过浏览器API接收必要的信息来处理支付。如果该网站有可用的优惠券，则可以将有关优惠券的信息作为API通信的一部分进行传输，以使浏览器管理的界面可以显示优惠券代码的选项或插入或提供优惠券数据。因此，浏览器API接口可以接收优惠券信息，并将该信息发送回网站以用于销售。可以将参数或编码作为API的一部分来实现，以打开或关闭接收优惠券并将其应用于特定销售的功能。用户还可以在进行销售或点击“购买”按钮之前提供优惠券信息，以便定价可以在用户与购买按钮交互或在对话框中进行购买之前合并优惠券减少。如果对话框是通过与设备上的主浏览器分开的Web视图或其他浏览器管理的，则显示该对话框的浏览器可以与主浏览器(Chrome、Safari、Firefox、Microsoft Edge等)进行通信以检索支付数据。请求支付数据的触发点可以是单击按钮、口头指示“我现在要购买”、手势或任何其他购买意向指示。
支付后，在此阶段的用户在对话应用程序中时，可能想返回该网站或继续留在社交媒体应用程序中。可以在对话框应用程序中显示其他对象，以使用户返回该网站或其他位置。例如，如果用户返回该网站，则该网站可能以用户刚刚购买商品的状态返回网站。然后，用户可以继续监视交付、处理退货等，就好像他们是在现场购买商品一样。该网站以常规方式管理商品的交付。以这种方式，该过程可以导致从处于任何状态的任何网站或应用程序过渡到作为社交网络或其他方面的一部分的支付启用对话应用程序。这种方法的一个有益结果是，对话应用程序可以实现直接作为商品购买的一部分的商家与购买者之间的个人交互。因此，该方法可以将对启用支付的对话应用程序的访问扩展到对话应用程序或与之关联的社交网站之外。解决买家可能快速而轻松地解决的任何问题的能力将增加转化次数，并为更快乐的客户提供服务。
此外，在某些情况下，商家或site.com并不想失去对其与客户互动的控制权。因此，从他们的网站过渡可能不是那么理想。但是，向对话框应用程序(如FacebookMessenger)的这种转换将交互转换为一种社交媒体，该交互是用户登录到其Facebook帐户或Messenger帐户后与商家登录到其社交媒体帐户之间的交互。因此，这种过渡实际上仍然保持了购买者和商家之间的直接联系，只是通过他们的社交媒体应用程序。因此，商家不会失去对交互的控制，而是可以通过社交媒体改善与买方的直接个人联系，这是非常可取的结果。
实际上，为了进一步增强体验，可以将其他商家品牌整合到体验中，例如对话应用程序的媒体品牌背景。与买家进行个人交流的机会非常重要。通常在对话应用程序中，用户输入问题和回答是由商家提供的。除了可能正在讨论的商品图片以外，没有针对商家的一般品牌。对话应用程序可以为商户提供品牌包装的机会。因此，在用户和商家之间的对话中，可以提供瀑布的背景图像，可以提供视频，或者可以播放设置特定音调的音乐。颜色、边框、标题、对象、字体、字体大小、合成声音等都可以为该商家量身定制。通常，对话应用程序很小，因为它只需要提供与商户对话的空间即可。但是，在这种情况下，除了仅接收问题和回答问题外，还需要品牌推广工作，对话应用程序的大小(如果在台式机，笔记本电脑或任何具有更大屏幕的设备上)可以扩展和修改，以便在与商家直接互动时为用户提供更丰富的体验。这很重要，因为它可以加深与商家的关系，而不仅仅是快速的对话和支付。
作为如何实现此功能的一个示例，假设买家点击了广告上的过渡对象。这可以称为信息收集和购买交互对象或购买交互对象，因为它会启动导致购买的信息收集交互。因此，尽管它不提供对购买的立即确认，但是它发起对话或交互，该对话或交互提供从用户收集信息和/或向用户提供附加信息之一。用户将过渡到Messenger应用程序，该应用程序已扩展为包括带有商户店面图像的较大窗口。用户可以说/写“我想要类似于此小部件的东西，但大小和颜色不同”。系统可以在较大的窗口甚至是相同大小的窗口中显示不同大小和颜色的替代相似小部件。用户可以滚动浏览那些内容并选择所需的内容进行购买。可以显示一个屏幕，用户可以在其中浏览商店中的虚拟空间，该屏幕可以配置为将替代项放置在商店中的架子上，用户可以浏览这些架子，就好像它们确实在那儿一样。
在另一方面，到对话应用程序的过渡还可以涉及任何其他商品，例如流音频或视频。例如，某个用户可能在Netflix.com上并想要获取有关电影的更多信息，则该用户可以单击过渡对象，然后转到对话应用程序，并与商家讨论该电影。对话应用程序可以配置为确认购买(使用浏览器API)和/或媒体下载。因此，对话应用程序不仅可以用于商品购买，还可以用于其他数字媒体分发。可以将媒体下载到当前设备(在该设备上进行对话)，也可以下载到其他设备或帐户以供以后观看。因此，从网站到对话应用程序的转换过程的另一个要素，除了购买东西之外，还可以提供其他结果。在关于其服务、媒体分发和/或购买、购买体育赛事门票、取消订单、管理订单、客户投诉等的对话之后，可以为医生、牙医或其他专业人员进行约会。在许多情况下，与另一方进行对话对于完成某些结果将非常有帮助。在此过程中，可以过渡到对话框应用程序，该应用程序配置为启用有关该问题的富有成效的对话框，并具有“单击一下”结果的功能。因此，除了购买商品之外，用户还可以与律师事务所就问题进行对话，并确认预约以见律师，或者确认或改变牙科预约时间。因此，过渡对象可以呈现在日历、媒体分发系统或网站上、Outlook中、电子邮件或文本消息中、或者存在用户有理由与另一方进行对话的任何其他位置。例如，用户可能在下周二的日历上看到与牙医的约会。如果已知此类约会与企业有关，则可以在您的日历上显示过渡对象。单击该对象可将用户转换为与牙医对话的应用程序。然后，用户可以键入或说“我们可以将其移到下午3点的星期四吗？”。如果牙医的回答是“是”，那么最终的操作(而不是购买)可以是日历更新。对话框应用程序可以通过API或其他机制与日历应用程序或其他应用程序集成，以进行此类更改。
就这一点而言，对话框应用程序还可用于基于对话框启动电子邮件或电话呼叫。可以启动其他应用程序(例如MSWord)或检索文档。因此，向对话应用程序的转换可以来自任何原始来源，并且除了进行购买以外，还可以采取任何数量的生产性结果性动作。用户在使用对话框应用程序后转换到的最终位置可能取决于所采取的特定操作以及用户可能希望终止的位置。
对话应用程序不必是社交媒体对话应用程序。例如，如果像Google这样的搜索引擎要启用注册用户之间的消息传递或Google和Facebook之间的消息传递，则任何对话框应用程序都可以实现这些想法。
现在，在广告或其他界面上放置过渡按钮的决定可能是动态的。该系统可以分析商品，并且在商品更复杂或价格更高的地方，消费者可能希望在购买前先谈谈它们。该商品可能受到一些不良评论或不良新闻。人们可能一直在社交媒体网站上发布不良信息或发表不良评论。在这种情况下，可能需要进行损坏控制，以便在一段时间内将过渡对象放置在商品说明和界面上，以便进行说明。过渡对象可能会呈现给历史不快或希望移动到另一个网站(例如Amazon.com)来研究评论的个人用户。与用户互动(通常导致购买)的时机可以发挥作用。例如，如果用户在购买之前暂停了很长时间，则系统可以在这段时间内显示一个转换按钮来回答任何问题。也许商品是新商品，并且互动可以帮助增加购买并使人们在Amazon.com等网站上发表评论，以提供有关购买的正面反馈。也许有一个短促的销售期，并且使用“转换”按钮与潜在买家讨论了该销售。该按钮可以提供更多信息，例如“谈论最近的不良评论和原因”。其他参数，例如天气、假期、潜在买家的即将到来的生日或周年纪念日、买家朋友的购买选择等等可以被分析并用作是否和/或如何向对话框应用程序显示过渡按钮的基础。关键是使转换按钮的呈现策略化并针对用户或商品量身定制，以便可以回答有关商品的实际问题(是否如Opinions.com所说的那样糟糕？)，并可以解决购买者的疑虑。
本文公开的任何特征可以与任何其他特征混合并匹配。作为示例，此处公开的“撕裂”特征可以是从一个网站到过渡到Messenger的Facebook Messenger。此外，只有Messenger可能会显示-主网站周围。然后，整个用户界面可以包括一个叠加在网站视图上的Messenger/对话框。叠加的Messenger/对话图形可以由第二个网站(Facebook或其他网站)呈现和运行，以便通过对话框进行的购买或其他操作将由第二个网站进行管理。或Messenger/对话图形可以将用户转换回可以进行最终“购买”交互的主网站。API可以与对话框/信使应用程序之间来回转换，以便买方以更高级的状态返回到购买(或其他目标)状态的网站，然后才是他们从网站转换过来的状态。浏览器API可以在任何购买方案中以及导航和购买过程的任何阶段使用。换句话说，当他们离开网站前往Messenger/Dialog时，他们可能不会处于呈现最终“购买”对象的状态。他们可能刚刚拉起商品。因此，如果对话框指示他们准备购买，则可以将数据传递回网站，以便在他们返回时可以显示更高级的状态，并且他们可以一键购买商品，也可以向他们的支付信息显示其他可选信息，例如送货地点、价格等。然后该状态可以处于用于支付的最终确认状态。状态也可以是最终状态之前的一个或多个步骤。例如，对话框可以确认他们要使用签证或比特币。该对话框可能无法确认此类信息。当他们返回时，site.com的状态可以容纳该状态。在这种情况下，可以使用该对话框，不仅帮助他们做出诸如蓝色或大号之类的选择，还可以确认他们要使用其借记帐户或签证。如果每条信息返回以最终确认支付，则可以提高site.com的状态。
信使应用程序中的团体支付
本公开进一步扩展了信使支付申请过程。FacebookMessenger支持从一个人到另一个人，以及现在从一个人到一家企业的支付。未启用的功能是在Messenger中进行小组支付或支付共享。这解决了以Internet为中心的问题，因为Messenger应用程序本身是基于Internet的，并且该问题目前仅限于一个人支付。
例如，如果您在群聊中并且想要购买礼物，则系统可以识别群聊中的每一方并配置可以在聊天中购买的广告或商品，但费用将在各组之间分配。团体预订也可以通过这样的应用程序进行。群聊的每个成员都可以看到相同的商品。出现的“立即购买”选项可以由第一人单击来支付，或者可以显示“均摊”选项，其中成本将在组成员之间平均(或不平均)分担。可以将系统设置为要求每个组成员承诺共享支付或不进行支付。在群聊中，可以提供进度信息(“简，约翰和吉尔已承诺，乔治，马蒂，您在吗？)。可以通过诸如“团体支付聊天机器人，我们要分摊这顶帽子的成本”之类的标注在“通讯程序”应用中“调用”团体支付互动。可选对象或下拉菜单项还可以将系统配置为显示可以作为一组进行处理/支付的支付选项。浏览器API可用于每个单独的成员，以交换消息/请求和支付信息。
任何组功能都可以通过类似的方式来完成，例如预订、安排事件、发送消息、进行慈善捐赠等。可以为组配置交互，也可以为组定制交互。在大多数情况下，组将看到相同的交互式对象，但是不同的成员可能会看到不同的功能。
在一方面，如果在信使应用程序中显示了购买按钮，并且它是与两个以上的人进行的群聊，则系统可以修改显示方式，以便启动针对团体支付的选项。在这种情况下，用户可能正在与商家进行讨论，并希望在对话中添加他的妹妹。她可以跳进去看看商品(也许是给妈妈的礼物)，然后在显示“立即购买”选项时，它可以为每个用户包括单独的对象，例如对于Jim：“您支付15美元，Jane支付15美元”，对于Jane：“您支付15美元，Jim支付15美元”。用户也可以在聊天中调整金额，以便一个人支付更多费用-这可以通过对话框“吉姆，我这个月很少，您可以支付20美元，我将支付10美元”来完成。系统可以分析文本并自动调整金额和对象以反映聊天中达成的协议。
或者，可以在3个朋友中聊天，希望在寻找结婚礼物时加入一个商家。在Messenger应用程序中，他们可以与Amazon.com或Target.com进行聊天(假设这对夫妇已在Target中注册)。这可以在应用程序内或通过单独的界面完成。在该应用程序中，用户可能会说“嘿target.com，请登录”，并且分析用户输入的系统将连接到目标的实时代表或自动化系统。决策点可能是，如果是群聊，则连接了实时用户，否则，它是自动化的，至少要启动。
然后，通过聊天，他们可以与可以介绍各种待售物品并回答问题的商家互动。在与商品进行交互并达成一致后，可以在聊天中显示“立即购买”对象，并且每个用户可以支付他们相等的部分或不相等的部分，并且可以按照此处公开的那样处理支付。以这种方式，该问题的解决方案是使得能够在参与群组聊天的个人之间分配支付，在群组聊天中，使得能够在聊天中完成支付机制。服务或浏览器的通信和协调可以解决由哪个人支付多少金额的任何歧义。
用户可以像在群聊“至”字段中的任何其他用户一样，通过列出商家来发起商家聊天。用户可以输入“janedoe，johnroe，target.com”，也可以与目标用户开始群聊。在这种情况下，商家可以在社交网络中被列为“朋友”，以便可以交换聊天或消息并购买商品。目标用户可以在屏幕上显示有关群聊中每个人的信息、浏览历史记录以及任何其他可用来帮助使该人集中于他们(该组)可能感兴趣的东西的数据。也可以显示该组共有的信息，例如他们都有一个即将结婚的朋友，并且该朋友已在Target处注册。因此，目标用户可以说“大家好，这是弗雷德的婚礼吗？他还没有银器套装”。然后，该小组可以看到该商品的图片，并作为一个小组支付。
如上所述，可以接收和分析有关组中每个人的数据，以指导商家和用户组之间的交互。可以基于分析来决定要呈现哪些可选对象、如何标记那些对象、与相应对象关联的功能、是否向不同用户呈现不同的界面等等。
如果John使用的是一种浏览器(例如Chrome)，而Mary使用的是另一种浏览器(例如Mozilla)，则系统可以与不同的浏览器进行通信，以识别用户可以使用哪种帐户进行支付，并可以交换请求、响应、数据和任何类型的信息，以改善在组消息中找到的通信类型。API可以在个人使用的各个应用程序或浏览器与商家网站或网站、其他支付提供商、服务实体等之间传递数据，以最终允许用户分担购买费用。
利用FACEBOOK、INSTAGRAM、PESTEST、YOUTUBE进行确定发布意图
当然，可以通过Facebook、Instagram、Pinterest、Youtube等其他社交网站使用类似的方法。在每种情况下，确定与销售或购买相关的意图是否与过帐相关联可以涉及分析输入(通常是文本，但不一定需要文本，并且可以包含Pinterest中的图片)，以供对过帐的接收者可以通过相应网站购买的商品或服务的参考。如果分析没有找到通常在商品/服务数据库中找到的对此类商品或服务的任何引用，则相应网站仅通过社交网站发送或发布发件人数据(推文、Facebook发布、Instagram上的图片、Pinterest等)，而无需立即购买选项。在这种情况下，网站将以常规方式处理输入。换句话说，确定不一定需要设置参数或将特定结果存储在存储器中。例如，如果该推文不包含指向商品数据库的URL，并且系统正在分析此类数据的输入，则缺少对商品数据库的引用本身就可以确定将不会通过社交网站为该发布提供立即购买选项。当输入中包含对商品数据库的引用时，网站可以执行非常规处理，其中通过处理用户输入，向网站的接收者或查看者显示购买按钮，以显示网站呈现的任何结果。该网站包括其他编码和处理，以使用户可以在仍在网站中的同时购买商品，或轻松地通过深层链接过渡到商家网站，从而可以快速轻松地购买商品，或者继续在商家网站购物。例如，如果为红色锤子的图片显示了相关的购买按钮，则当用户单击红色锤子图片时，该网站可以转换为与商家网站的深层链接，就像用户搜索了一把红色锤子并准备购买一样。在转换到深层链接后，用户在这种情况下可以轻松地购买锤子或将其放入购物车中，然后继续购物或继续在商家网站上处理购买。深层链接也可以是到对话应用程序的过渡，该对话应用程序接收有关用户、商家、商品、社交媒体数据等的数据，以提供到Messenger应用程序的高效过渡，使之能够先提出问题然后回答，然后再在Messenger应用程序中进行购买。
使用配置为目标网站状态的深层链接，就好像用户已经搜索商品、登录和/或输入支付信息一样，从而用户无需输入支付信息或登录即可完成购买过程。这可以通过在浏览器中访问过渡数据来完成，例如支付数据、一键购买设置、地址信息、登录信息等。例如，如果一键设置被访问并设置为“on”，则用户可以一键式购买状态登陆目标网站。当类似amazon.com的网站向社交网站上的收件人提交帖子时，它会包含有关收件人身份的信息。如果该收件人已在amazon.com上注册，并将其支付信息提供给amazon.com，则当收件人单击立即购买对象或表示希望进行购买的对象时，收件人可以从社交网络过渡与商品相关联的网站发布到发布网站(例如amazon.com)的“深层链接”，其中用户以某种状态转换到该网站，就像用户搜索了该商品并且该网站处于说明用户可以“一键式”购买商品的位置。这是可能的，因为从社交网络发布到网站的过渡包括使用户能够登录到网站并为用户提供一个界面，使他们可以用最少的点击就可以购买商品。过渡过程可以包括从浏览器访问用户数据。数据可以是支付数据、登录数据、一键式授权设置、参数设置、支付数据、地址数据等。
在诸如Instagram或Pinterest之类的社交网络案例中，图像从发布实体发布到一组收件人，该过程可以如下操作。一种方法，包括通过社交网站接收图像的发布，其中，社交网站接收来自发布实体的发布图像并将其发送到接收实体。系统可以分析图像以获取关联的基于文本的数据或元数据。文本数据可以是提供有关图像的信息的元数据或其他数据，并且可以引用与图像中的商品相关联的商品数据库，例如库存数据库。系统确定相关联的基于文本的数据是否标识了商品数据库中的商品，该商品要从发布实体进行销售以产生确定结果。例如，系统可以确定商品数据库中存在该物料的库存。当确定指示在商品数据库中没有对商品的引用时，系统通过社交网站发送输入的图像而没有立即购买按钮。以这种方式，图像的发布将以常规的常规方式通过社交网站进行。当确定指示图像参考商品数据库中的商品，并因此指示与购买或销售有关的意图时，系统通过具有与图像相关联的购买选项的社交网站来发送图像。当系统收到与购买选项关联的购买交互时，系统会根据购买交互来处理商品的购买。这涉及实现其他代码，以为社交网站提供一系列非常规的步骤。
从发布实体确定图像是否与商品数据库中的商品相关联可以包括通过应用程序编程接口在社交网站和商品数据库之间进行通信。社交网站可以处理支付并将销售传达给发布实体，例如商家。然后商家可以交付物品。如本文其他地方所述，系统还可以将用户从向购买过程转变为对话应用程序的状态，该对话应用程序被配置为启用用户和商家之间的对话，然后在对话应用程序中处理支付。API用于在原始网站、Messenger应用程序、商家网站、用户、支付代理等之间进行数据通信，以在通过Messenger应用程序进行对话后启用“一键式”购买(作为对话框的一部分或在对话框应用程序中)。
处理商品的交付可以包括管理商品的支付，并通过应用程序编程接口通知出售该商品的过帐实体以运送该商品。用户或商家可以具有一个预先存在的帐户，该帐户存储用于控制如何显示图像和购买选项的首选项。购买选项可以包括一键购买选项，由于社交网站存储了进行购买的收件人的购买数据，因此可以一键完成，而无需从社交网站移动或过渡到商家网站来完成销售。
一个示例还从商家的角度涵盖了用于图像共享网站的上述过程，该商家可以将图像发布在如上所述操作的社交网站上。在这种情况下，商家发布带有指向或访问商品数据库的文本数据的图像，以便在确认要销售的商品数据库中的商品时，社交网站为您提供带有购买按钮的图像，并在确认购买后，将交易通知商家，以便商家可以处理交货。
关于针对社交网站中的购买选项从商家方进行的处理，该方法可以包括由诸如商家的发布实体通过用户共享图片、文字或视频的社交网站来发布图像、文本或视频。社交网站通常被构造为从发布实体接收发布的图像、文本或视频并将其传输到接收实体。社交网站使用与图像或视频相关联的文本数据或元数据来确定商品数据库中是否存在要从发布实体出售的商品以产生确定结果。社交网站可以经由社交网站和商品数据库之间的应用编程接口来确定图像或视频是否与来自发布实体的商品数据库中的商品相关联。
当确定指示在商品数据库中没有对商品的引用时，网站通过社交网站将图像或视频发送到接收实体，而没有选择购买商品的选择，而是以常规方式执行。当确定指示图像或视频引用商品数据库中的商品，从而指示与销售有关的意图，网站通过带有购买选项的社交网站发送图像或视频，并接收社交网站的用户与购买选项进行交互以产生购买交互的数据。然后，商家(过帐实体)基于购买交互来处理物品的交付。社交网站可以通过其自身的机制处理商品的支付，也可以使用ApplePay等服务。在社交网站处理商品的支付之后，发布实体可以从社交网站接收支付数据。当社交网站的用户与购买交互进行交互时，商家可以在发布实体的网站上的深层链接处从社交网站接收社交网站的用户的转变。这是一种可选的方法，其中支付处理可以在社交媒体网站之外并由商家进行。社交网站可以在发布实体的网站中的状态下将用户转换到发布实体的网站内的深层链接，社交网站的用户可以在其中购买商品。在这种情况下，发布实体可以从社交网站的用户接收物品的支付。
例如，从商家的角度来看，该方法可以包括从诸如商家的发布实体在社交网站上发布图像、文本或视频。社交网站可以从发布实体接收发布的商品并将其发送到接收实体，其中，发布的商品可以包括文本、图像和视频中的至少之一。社交网站分析图像、文本或视频以获取相关联的基于文本的数据或元数据，并确定相关联的基于文本的数据或元数据是否标识了商品数据库中的商品以从发布实体进行销售以做出确定。当确定指示在商品数据库中没有对商品的引用时，社交网站通过社交网站发送图像、文本或视频而没有购买选择，换句话说以常规方式。当确定指示图像、文本或视频引用了商品数据库中的商品时，因此，社交网站通过社交网站发送图像、文本或视频以及与该图像或视频相关联的购买选项，并指示与销售相关的意图，并从与购买选项相关联的买方那里接收购买互动。购买选项还可以包括一个对象，当与之交互时，该对象会导致切换到对话框应用程序，该对话框应用程序被配置为参与有关商品的对话框，然后在该对话框应用程序内处理该商品的支付，从而更容易、更轻松地解决买方的疑虑并处理支付。发布实体还可以仅通过购买按钮将基于商品的发布发布到社交媒体网站上。
一旦社交网站接收到购买商品的交互，就有必要完成商品的销售。从商家的角度来看，商家然后接收买家从社交网站到由发布实体运营的网站中的深层链接的转变。商户处理来自过帐实体的商品的购买和交付。一方面，商家在过渡之后以发布实体网站内的状态向用户呈现发布实体网站内的深层链接，社交网站的用户可以在其中购买商品。在社交网站上发布的图像，文本或视频中显示的商品可以与购买的商品相同。一旦用户登陆商家网站，就可以在商家与浏览器之间使用浏览器API来管理支付数据。商家网站可能已经存储了支付和地址信息，并且转换可能只需要在浏览器中设置一键式参数即可。一方面，经由社交网站和商品数据库之间的应用编程接口来执行对相关联的基于文本的数据是否标识了商品数据库中的商品以从发布实体进行销售以产生确定的确定。
在另一方面，该方法包括：通过包括Facebook的社交网站来接收图像或视频的发布；识别与图像或视频相关联的数据；以及确定数据是否标识了来自发布实体的待售商品数据库中的商品以产生确定。当确定指示在商品数据库中没有对该商品的引用时，该方法包括通过社交网站发送图像或视频而没有“立即购买”按钮。当确定指示图像或视频引用商品数据库中的商品，从而指示与销售有关的意图时，该方法包括通过具有与图像或视频相关联的购买选项的社交网站发送图像或视频，以购买商品，接收与购买选项相关的购买交互，并根据购买互动处理商品购买，其中处理购买发生在Facebook内。
Facebook、Twitter和任何其他社交网站都可以处理用户输入，包括文本以及可选的其他输入(例如视频、图像)或与发布相关的其他用户输入。用户输入的组合可以取决于特定非商业网站的结构。例如，Twitter的用户输入与Facebook的用户输入不同。两者都涉及可单独包含文本或文本以及其他用户输入的帖子。各个社交网站将根据其功能来处理用户输入。可以输入图像以及描述商品数据库中某个位置或商品的某些描述或元数据。在这种情况下，用户输入可以包括根据非商业网站的用户输入的任何组合，该非商业网站包括对商品数据库中商品的引用，该引用指示通过社交网站处理帖子时，社交媒体上的帖子应包含“购买”按钮。可以由单个用户或自动化系统准备和发布发布，具体取决于非商业网站的处理。
基于TABS的修改后的浏览器界面
公开了一种系统、方法和计算机可读存储设备，其基于分类器确定的意图来预填充标签，分类器处理提供给统一输入字段的输入。在典型的Web搜索中，用户单击以选择一个搜索字段，输入文本，等待结果页面加载，在结果页面中单击所需的链接，并在等待加载后最终到达所需的链接。此过程需要很多步骤。在浏览器中预填充标签的统一输入字段可以简化此过程。
例如，one-search.com可以提供统一的输入字段。用户通过统一的输入字段提供输入，例如搜索“iPhone 5S”。系统可以根据用户个人资料和输入的文本，标识n个最可能需要的页面，例如从搜索结果列表中识别出用户是否要使用输入到该点的文本执行搜索。然后，系统可以指示用户的浏览器使用n个最可能需要的页面来创建并填充浏览器中的新标签。n的值可能会因用户首选项、已经打开的选项卡、超过置信度阈值的页面数、可用内存、网络带宽、准备加载的页面、要在选项卡中填充的页面的多样性等而异。在一种变型中，系统可以响应于通过统一输入字段提供的输入，在浏览器中自动创建并填充三个新选项卡，每个选项卡具有不同的可能期望结果。一个选项卡可以是Amazon一键式购买页面，一个选项卡可以是Apple.com上已填充购物车的最后一页，一个选项卡可以是通过AT&T购买带有2年服务合同的iPhone 5S的服务合同的最后一页。这样，用户可以自动选择，浏览和比较选项卡以确定他或她想要的选项卡。但是，在此阶段，输入数据不一定提供足够的信息以促成特定购买。因此，系统可以选择一些页面，例如关于iPhone 5S的Apple信息页面、关于iPhone5S的Wikipedia页面或关于iPhone 5S的流行视频评论。
但是，如果用户输入其他信息，例如“iPhone 5S 32GB银色”，则分类器可以基于文本并结合用户个人资料或搜索历史来确定用户的意图是购买所指示的iPhone。在这种情况下，系统可以在浏览器中加载特定于购买的标签。例如，系统可以将选项卡直接加载到Amazon.com或Apple.com页面，就像用户已经在其中导航、选择iPhone 5S，32GB，银色、已将iPhone添加到购物车、并且处于结帐流程的高级阶段或可能是最后阶段一样。对于Amazon.com，系统可以加载一个选项卡，用户可以通过该选项卡一键式购买指定的iPhone。或者，系统可以加载一个选项卡，该选项卡将自动执行单击“一键购买”按钮的操作，以便用户可以访问one-search.com，在统一输入字段中输入文本，然后按Enter键以通过Amazon购买，结果购买页面将自动为用户加载到新标签中。在这种情况下，在统一输入字段中输入文本后按回车键可能会导致新选项卡中加载刚刚执行的订单的购买摘要，从而可能允许用户修改运输选项、商品选项、账单信息或其他订单详细信息。在另一种变型中，系统可以根据用户在统一输入字段中按Enter键自动下订单，并将用户转换到网页的新标签上，以用于购买配件，与所购买商品有关的服务、技术支持页面或其他一些相关的网络资源。
当用户在统一输入字段中输入第一部分输入字符串时，用户可以在一个或多个选项卡之间来回单击以预览结果。然后，用户可以返回到具有统一输入字段的选项卡，并修改或添加到输入字符串。系统可以删除先前生成的选项卡并填充新的选项卡，或者系统可以保留用户打开、查看、操作或单击的选项卡，例如，同时消除其他先前生成的选项卡。这样，用户可以根据更新的输入字符串选择保留哪些标签以及系统可以自由删除或替换的标签。
系统可以根据用户键入的内容预测性地检索和缓存潜在的匹配页面，以插入到新选项卡中。例如，如果用户在统一搜索字段中键入“Apple”，则系统可以检索三种最受欢迎的Apple商品或用户最可能感兴趣的三种Apple商品的页面。然后，当用户键入“Apple iP”时，系统可以将搜索范围缩小到匹配部分字符串的商品，例如Apple iPod、iPhone和iPad。不会包括MacBookAir或Apple TV之类的商品，因为它们与统一输入字段中的部分输入字符串不匹配。该过程可以继续优化缓存的页面，从而节省时间，以便在发生特定事件或达到阈值时可以将页面呈现给用户。例如，在一种变型中，即使系统在用户按下Enter键之前准备、检索和缓存页面，系统也可以等待用户在统一输入字段中按下Enter键以填充新标签。这样，当用户在统一搜索字段中按Enter键时，系统可以非常快速地创建新标签，并使用检索到的页面填充新标签。如果尚未预测或检索到任何其他页面，则可以正常加载这些页面的选项卡，而其他页面则可供用户查看。
在一种变型中，系统可以立即将用户从显示统一输入字段的选项卡转换为响应于经由统一输入字段提供的输入而创建的不同选项卡。虽然大多数浏览器允许用户使用鼠标单击选项卡，或按键盘快捷键(例如ctrl-tab、ctrl-shift-tab、ctrl-pgup或ctrl-pgdn)在选项卡之间导航，但统一输入字段可以允许用户在通过统一输入字段提供输入的最后按Enter或其他一些键，以自动切换到响应于输入而填充的新创建的标签。例如，当用户在统一输入字段中按Enter键时，系统可以切换到Amazon一键式购买页面的选项卡。该系统还可以将购买包括在过渡操作中，以便根据用户在统一输入字段中按Enter以及将用户切换到该新选项卡，在Amazon处完成购买。
系统可以根据用户输入显示不同的选项或不同的目的地。例如，系统可以显示一条消息或指示，一次按一次“输入”将使用户过渡到第一个新选项卡，而两次按一次“输入”将自动使用户过渡到第二个新选项卡，然后三次按“输入”将自动将用户转换到第三个新选项卡，依此类推。经由统一输入字段提供的多个不同的键和/或键组合可以基于在统一输入字段中提供的输入来触发用于管理或导航选项卡的不同行为。此外，当用户在统一输入字段中输入其他文本或修改统一输入字段中的文本时，触发这些动作的各种动作和组合键可以更改。
图16示出方法示例。方法示例中的步骤可以以任何顺序执行，可以以包括附加步骤或排除所描述步骤中的某些步骤的全部或一部分的其他组合或排列来执行。该系统可以在第一用户界面中呈现与经由浏览器处理的第一网站相关联的第一输入字段(1602)。
系统可以分析来自用户的输入到第一输入字段中，以确定用户是否希望执行搜索或进行购买以做出确定(1604)。如果确定指示用户希望进行购买，并且除了输入之外没有来自用户的任何其他输入，则系统可以使用该输入来预填充与第二网站相关联的第二输入字段(1606)。系统可以使用第二输入字段中的输入对第二网站进行预处理，以使用户处于自动转换后的状态，在该状态下，可以通过用户的一键式操作处理与输入关联的商品以进行购买和交付(1608)。该系统可以通过将用户数据从第一网站和浏览器中的一个传输到第二网站来预处理第二网站。可以在浏览器和网站之间传递支付数据，以简化用户的过程。该系统可以通过自动浏览第二网站的购物车模型来预处理第二网站，以产生一种状态，在该状态下，可以通过单击操作来处理要购买和交付的商品。该处理可以包括：当用户与界面交互以进行购买时，与输入字段相关联的实体处理商品的支付并与单独的商家协调以进行交付。
系统可以在浏览器的标签中显示第二网站(1610)。该系统可以向与该标签相关联的用户呈现视觉通知，即在该标签上单击将向用户呈现第二网站，在该状态下用户可以通过单击操作来处理购买和交付商品。视觉通知可以是弹出窗口、在第一个网站上的指示、与选项卡相关联的特定于浏览器的通知、或者在用户界面中的某些其他位置。该系统可以在浏览器的其他选项卡中显示多个其他网站，并且可以通过统一的输入字段提供一种机制，以独立于浏览器固有的已建立键盘快捷键和鼠标单击来操纵或浏览这些选项卡。例如，系统可以使用第三输入字段中的输入对第三网站进行预处理，以使用户处于自动转换之后的状态，在该状态下，与输入相关联的商品可以通过用户的一键式操作进行处理，以进行购买和交付，并将第三个网站显示在浏览器的第二个标签中。
图17A示出具有带有输入字段1704和用户输入1708的选项卡1702的界面1700。该输入字段1704是开放式或开放式的，因为它不会自动将用户输入作为搜索处理，但可以处理输入以执行许多不同的功能。假设用户输入“iPhone 5S”。该系统分析该输入，并确定用户希望进行购买的可能性很高。然后，系统会预处理一个或多个网站(例如Amazon.com和Apple.com)上的输入，这样，这些备用网站中的每个网站都处于与导航到该网站并进入“iPhone 5S”的用户等效的状态，并继续浏览并导航到一种状态，在该状态下，再次单击即可购买和交付商品。因此，在图17B中，系统可以呈现用于亚马逊的标签1710和用于苹果的标签1712。用户可以继续键入其他文本，例如“32GB Silver”1708。系统继续完善备用网站的预处理。因此，在用户完成操作之后，如果用户单击“亚马逊”选项卡1710，则该选项卡将显示处于“单击”状态的预处理搜索，以便下次单击可使用户购买并交付该商品。在像Apple这样的网站没有类似的“一键式”选项的地方，系统可以导航和预处理购物车模型，从而实质上使标签1712呈现购物车，在用户仅需再点击一下即可进行购买的状态下就可以准备就绪。浏览器或one-search.com应用程序可以通过与备用网站进行通讯的API提供购买帐户数据、收货地址、密码等，以便在没有一键购买功能的网站的购买页面中在后台浏览时所必需的。如果one-search.com处理商品支付处理，则API可能仅需要传达必要的数据以完成交易。通过这种方式，商家可以轻松地通过API与one-search.com进行交流以进行投放。
选项卡的位置可以基于历史记录、个人喜好、意图可能性等。例如，如果用户通常通过Amazon.com购买商品，则该选项卡将在当前选项卡1702旁边显示1710。搜索意图超过购买意图的可能性可以是相等的，因此是Google或Yahoo！。搜索可能会显示在购买选项旁边的标签中。这些选项卡还可以提示预处理的深度。例如，一个选项卡可能会说“亚马逊搜索”，而另一个选项卡可能会说“亚马逊一键式”，向用户表明，单击“亚马逊搜索”选项卡意味着该选项卡的“状态”是指用户输入已经过预处理，就像在常规的Amazon搜索中一样，将返回商品列表以供浏览，但该状态不是“一键式”状态，在该状态中，用户可以再单击一次以完成购买和交付。预处理的深度也可以基于需要多少消歧来执行。如果用户没有提供足够的数据，则仅可以提供搜索级别状态。如果只有两个选项(例如，在一个商品上可以选择两种颜色)，并且用户未指定颜色，则系统可以在选项卡中显示两个不同的商品，每个商品都有一个“单击”购买按钮，这样选项卡仍处于一键购买状态，但是页面上显示了两个商品，因此无需进一步导航。系统可能会显示一个金色的“一键式”选项和一个银色的“一键式”选项供您购买。
在典型的Web搜索中，用户单击以选择一个搜索字段，输入文本，等待结果页面加载，在结果页面中单击所需的链接，并在等待加载后最终到达所需的链接。如果用户希望继续并进行购买，则用户必须使用现有帐户登录或使用网站创建新帐户、将商品放入虚拟购物车中、结帐、提供运输信息，等等。此过程需要很多步骤。为用户预填充购物车的统一输入字段可以大大简化此过程。
浏览器/代理商品网站API之间的信息交换
一方面，本公开内容涵盖具有API的新颖浏览器，如图17B所示，通过该API在浏览器和一个或多个商家网站之间交换信息以简化支付方法。这种浏览器解决了先前的问题，试图解决要求用户将其所有支付信息输入许多输入字段的复杂性和不足。一些浏览器具有表单填写功能，该功能使用存储的支付信息在浏览器端填写表单。但是，这些表格填充功能从未流行，而且仍然太麻烦。从商家网站提供的表单没有得到协调，用户仍然必须查看所有输入的数据，然后通过表单发送回商家网站。此外，不同的地点具有不同的结构来填充使该过程混乱的所有领域。需要进行更全面、更协调的工作，以简化未使用购买的支付数据注册购买的网站的支付和结帐流程。本文公开的浏览器API以更全面的方式解决了该问题，使得支付方法可以以以前无法实现的方式真正简化为其基本要素。例如，与旧的表格填写方法相比，网站和浏览器可以以更具体、更具战略性和量身定制的方式来回交换更多数据。能够通过API交换更多的信息可以实现更有效的方法，这对用户而言将更加容易。
浏览器或Web浏览器是用于检索，呈现和遍历万维网上的信息资源的软件应用程序。信息资源由统一资源标识符(URI/URL)标识，并且可以是网页、图像、视频或其他内容。资源中存在的超链接使用户可以轻松地将其浏览器导航到相关资源。示例网络浏览器为Firefox、Internet Explorer/Microsoft Edge、Google Chrome、Opera和Safari。它们可以在服务器、台式计算机、便携式计算机、移动设备以及配置为运行该软件的任何其他设备上运行。Web浏览器通常包括用户界面、布局引擎、渲染引擎、JavaScript解释器、用户界面后端、网络组件和数据持久性组件。
Web浏览器的主要目的是为用户带来信息资源(“检索”或“获取”)，允许他们查看信息(“显示”，“呈现”)，然后访问其他信息(“导航”，“以下链接”)。
当用户在浏览器中输入统一资源定位符(URL)(例如http://en.wikipedia.org/)时，该过程开始。URL的前缀(统一资源标识符或URI)决定了如何解释URL。URL的最常用类型以“http：”开头，并标识要通过超文本传输协议(HTTP)检索的资源。
对于http、https、文件等和其他，一旦检索到资源，Web浏览器就会显示它。HTML和相关内容(图像文件、格式信息，例如CSS等)被传递到浏览器的布局引擎，以从标记转换为交互式文档，此过程称为“渲染”。除HTML外，网络浏览器通常可以显示可以属于网页的任何类型的内容。大多数浏览器可以显示图像、音频、视频和XML文件，并且通常具有用于支持Flash应用程序和Java小程序的插件。
信息资源可能包含指向其他信息资源的超链接。每个链接都包含要访问的资源的URI。单击链接后，浏览器将导航到该链接的目标URI所指示的资源，然后将内容带给用户的过程再次开始。浏览器可以存储用户数据，例如支付数据，一键式参数或设置，如本文所公开。其他支付服务(例如Android Pay和Apple Pay)可以与浏览器通信以实现支付功能。例如，设备上的安全元素可以存储Apple Pay的支付数据，并与浏览器协调对网站上用于支付的数据的访问。此外，可以修改浏览器功能以通过API传达必要的数据，以简化购买过程。
因此，该实施方案涵盖了浏览器与商家(例如http://www.merchant.com)之间通过API进行的交互，以管理该API的支付数据的请求和传输，从而使网站可以根据其正常的支付处理结构来处理商品的购买。如果使用单独的支付服务，则API可以以有组织的方式来处理支付服务对支付的管理，并将支付数据传达给网站。在这方面，浏览器(或任何其他代理)可以在商家、购买者与支付方式或支付账户之间提供数据的中间通信。浏览器可以存储支付信息，或者可以与存储该支付信息的另一个本地应用程序进行通信，或者可以与诸如Android Pay或Apple Pay之类的支付服务进行通信。例如，对于Apple Pay，数据存储在安全元素中，当通过浏览器API收到支付请求时，浏览器可以访问该元素。访问另一个服务器并生成支付令牌，该令牌通过浏览器API传递到商家网站进行处理。通过API通信的参数和数据有一个标准化的规范，以实现启用支付方法的总体目标，该过程不需要用户手动输入信用卡数据、地址等。该过程可以使网站接收或创建一个支付按钮(功能与本地使用的支付按钮不同，后者不通过API与浏览器进行接口)，请求和接收有关用户的支付数据，例如地址和支付帐户数据，其可以加密，使用户能够更新任何支付数据，然后使用接收到的支付数据在本地处理支付。浏览器可以通过多种机制将支付信息传递到网站。例如，浏览器可以存储信用卡和/或可以通过Chrome与Android Pay集成或通过Safari与Apple Pay集成。在这方面，可能有单独的应用程序或软件(例如AndroidPay或Apple Pay)与浏览器进行通信，以提供传递到网站进行支付处理所需的一个或多个数据。单独的应用程序还可以处理支付，并通过API向网站报告支付已经完成。可以提供与支付相关的所有出席信息。
一方面，该过程可以如下进行。计算机可读存储设备存储浏览器指令，该浏览器指令在由处理器执行时使处理器执行浏览器操作，以检索内容，在用户界面中呈现内容以及遍历全球网络上的信息资源。修改和扩展浏览器指令，以便在由处理器执行时，这些指令使处理器执行进一步的操作，包括经由用户界面并从用户接收与与网站相关联的对象的交互，这可能导致购买。该对象可能是网站或信息亭上的按钮、游戏中可能导致需要支付的按钮、虚拟现实环境中导致购买意图的任何交互或与商品或服务相关的购买按钮。操作包括基于交互作用并经由应用程序编程接口接收来自网站的与购买有关的用户的支付数据的请求，并经由应用程序编程接口向网站传输支付数据(或出于安全目的的支付数据的标记化版本)，其中支付数据可用于处理网站上的购买。在一个方面，另一代理商、搜索引擎或实体处理支付并如本文所述向网站报告。
另一个实施方案从商家的角度涵盖了该过程，该商家接收与对象的支付交互或任何支付交互指示，并将支付请求发送到浏览器支付请求API，并从浏览器API接收回用于处理支付的支付数据。
通过浏览器支付请求API使用信息亭
本公开的另一方面解决了人们将如何使用带有浏览器支付请求API的自助服务终端。信息亭可以是具有浏览器的任何设备，用户可以通过该设备与商家或其他服务提供商进行交互以进行支付。它可以用于支付通行费、购买食物、通过设备在餐具室中订购替换纸巾等。在许多情况下，这些信息亭将是公开的，这样就不会在浏览器中存储或通过配对设备提供的用于通过浏览器支付请求API响应请求的单个支付信息集合。
问题在于，如果某人上了可用于购买任何物品的公共信息亭，则该信息亭上的浏览器不是他们的个人浏览器。它不包含其支付信息。但是，该用户可能拥有其Android设备、iPhone或其他具有浏览器的移动应用程序，该浏览器支持浏览器支付请求API，因此可以存储必要的支付信息或启用对基于网络的信息的访问。以下提供了一种机制，该机制使用户可以将自助服务终端浏览器临时转换为个性化浏览器，以使功能相同(即单击一次或简化购买)。信息亭和移动设备可以交换信息，以便信息亭浏览器可以是该用户的临时代理。通过蓝牙、WiFi、近距离通信、蜂窝、5G或任何其他方法或协议，甚至是有线方法，自助服务终端浏览器可以安全地访问移动设备浏览器可用的支付数据(信用卡帐户、Android Pay、Samsung Pay、Apple Pay、MicrosoftWallet、其他金融机构信息、借记帐户、PayPal帐户等)。
在某些情况下，设备将以正常的无线方式使用Apple Pay或Android Pay。本公开实现了一种新的方法，该方法利用了支付请求API基础结构，该基础结构是用于进行支付的标准化方法。因此，当许多商家朝着使用支付请求API的方向发展时，自助服务终端类型的设备也可以利用相同的支付机制。
在笔记本电脑上使用Apple Pay时，Safari浏览器将通过API(专有的Apple支付请求API)从商家网站收到支付请求，并且在一方面，用户将通过指纹确认在笔记本电脑上而不是在iPhone上确认购买。笔记本电脑和iPhone将进行无线通信以完成交易。提议的方法在几个方面有所不同。在这种情况下，信息亭(或具有浏览器的任何设备)首先不会为用户提供任何支付信息，因为它是公共信息亭。可以修改浏览器支付请求API，以包括以下通知：正在使用的浏览器是公共浏览器还是没有支付信息的浏览器。因此，如果用户开始支付停车收费站，并且他们与“支付”按钮进行交互，则后端商家应用程序可以通过API发送支付请求，以查看这是否是可用的支付选项。信息亭可以无线(或使用有线连接)查询以查看用户的移动设备是否具有包含用户支付信息的浏览器和/或是否存在连接和利用该信息的授权。如果是这样，则自助服务终端的用户体验可以与使用浏览器API的正常购买体验相同或非常相似(通过指纹确认、CVC代码输入、交付地址或支付帐户确认等)。自助服务终端浏览器API之间的通信可以通过自助服务终端浏览器与用户的移动设备浏览器之间的连接进行协调。信息亭浏览器和移动设备浏览器之间可以使用单独的API进行通信、请求、答复等。当适当的时间将支付信息传递到商家网站时，可以将数据从移动浏览器传递到自助服务终端浏览器，再传递到商家网站。为了安全起见，可以以任何方式对数据进行标记或加密。商家网站然后接收支付数据，就像它将通过支付请求API从普通浏览器接收数据一样。信息亭浏览器不会存储支付数据，而只会将其传递给商家。
一方面，为了在售货亭浏览器实际上没有存储用户的支付信息的情况下，售货亭浏览器能够经由浏览器API与商家适当地通信，可以设置参数或提供虚假信息以使信息亭浏览器做出响应。例如，如果商家请求指示商家接受VISA和MASTER CARD支付，并且移动设备用户在移动设备浏览器中存储了VISA帐户，则移动设备和自助服务终端之间的通信可以使信息亭浏览器有足够的信息来响应商家要求使用VISA进行支付的请求(尽管信息亭可能实际上未存储VISA帐号)。可以传输任何数量或类型的数据，以使自助服务终端浏览器能够通过浏览器API与商家成功进行通信，同时保持用户私人信息的安全性。例如，在一种情况下，伪信息可以在自助服务终端浏览器(一个或多个虚拟信用卡号、用户名、地址等)中填充数据，以便自助服务终端浏览器认为其具有必要的数据来处理支付。然后，当需要实际提供支付信息时，移动设备可以将令牌发送或将必要的实际信息发送给自助服务终端，自助服务终端可以将信息转发给商家以处理支付。在另一方面，可以修改浏览器API，使得可以在自助服务终端浏览器中设置自助服务终端参数，以指示其与移动设备(或其他设备)通信，并且尽管它没有实际数据，但是移动设备会注册，并且用户拥有一个VISA帐户。因此，售货亭浏览器可以继续进行在支付方法中交换数据的过程。例如，自助服务终端浏览器可以确认可以使用VISA进行支付，可以接收费用总额和运输费用，并且可以将该信息转发到移动设备浏览器，并在此过程中的适当时间接收最终支付和/或地址或任何其他信息，并将其传递给商家网站。
信息亭可以检测到可能与用户相关联的多个移动设备。(在用户处理支付时，每个拥有设备的三个不同的人可能都足够靠近自助服务亭)。因此，可能需要消歧技术来确定使用哪个设备(哪个移动浏览器)。可能需要实现额外的安全层，例如信息亭上的指纹确认，CVC代码、对话、说话者验证等。确认可能很简单，例如“这是Tom还是Mary”或“您的CVC代码是什么？”用户可能需要在其移动设备上提供指纹确认(“通过iPhone上的指纹确认来确认这是Mary”)。任何此类安全措施均被视为本公开的一部分。
假设安全措施已经到位，所公开的过程是移动设备将通过其浏览器将针对用户的支付信息传递给信息亭浏览器，信息亭浏览器随后将把支付信息传递给商家以进行处理。支付信息可以存储在移动浏览器中，或者可以由移动浏览器从另一个实体访问。结果将是，用户将在自助终端获得相同或相似的购买体验。无需刷卡或使用信用卡。信息亭浏览器可以充当用户的代理或代理浏览器，以为用户启用简化的购买交易。即使在公共信息亭中，支付方法也将是熟悉的浏览器支付请求API程序。
移动设备和信息亭之间的交换可以通过API或任何其他方式进行，其中可以与购买交易相关地进行请求、响应、数据通信等。信息亭浏览器在一方面不会存储该人的支付信息、送货信息或有关用户的任何其他信息。实际上，一种方法可以使得能够通过与商家的小区连接或其他连接来从移动设备单独递送支付信息，以使得自助服务终端浏览器甚至从未看到支付信息的令牌化版本。在另一方面，信息亭可以将关于用户的数据传达给商家网站，并且商家网站可以直接执行浏览器API请求给用户移动设备并通过该通信信道传达支付数据。
一方面，在售货亭进行的购买的支付交互实际上可以在移动设备上发生。例如，用户可以在自助服务终端上单击“支付”对象，然后将其转换到其移动设备以查看支付界面并与之交互。接口的任何划分、数据的通信等等可以在移动设备、信息亭和/或其他设备之间发生，以实现简化的交互，以使用户实现对任何商品或服务的支付。
此替代过程可以如下进行：
(1)用户使用其移动设备通过浏览器接近信息亭
(2)在用户启动自助服务终端之前或在与自助服务终端进行交互时，在移动设备和自助服务终端之间建立了无线通信，这样一来，在移动设备(或信息亭)上会显示一个预授权对象，例如“玛丽，授权您通过3号信息亭对您购买的支付信息进行通信”。通过与对象、指纹、代码、面部识别或任何其他方法的简单授权交互，可以提供授权。
(3)一方面，将支付信息(信用卡、地址、有效期、姓名等)传送到自助服务终端浏览器，从而用该信息填充适当的存储器。一次性支付令牌也可以从移动设备传输到自助服务机。
(4)玛丽使用信息亭浏览商品，做出决策并最终与“购买”对象进行交互。
(5)商家网站接收交互，并通过浏览器API向自助服务终端浏览器发起支付请求，而Mary与自助服务终端浏览器进行交互，以标准方式确认购买。
(6)自助服务终端浏览器在最终确认之后，从其内存中删除了Mary的支付信息，并可以确认删除。
(3a)在另一方面，支付信息在Mary的移动设备上维护。
(4a)玛丽使用信息亭浏览商品，做出决策并最终与“购买”对象进行互动。
(5a)商家网站接收交互，并通过浏览器API向自助服务终端浏览器发起支付请求。
(6a)售货亭浏览器与移动浏览器通信以从移动浏览器接收支付信息。支付信息可以是一次性使用令牌，该信息由自助服务终端浏览器接收并通过API传递到商家网站。自助服务终端浏览器的行为就像用户的移动浏览器在笔记本电脑上说的那样，并与用户的iPhone通信以确认Apple Pay支付。
(7a)Mary与信息亭浏览器进行交互，以标准方式确认购买。
所有必需的数据、通信、请求和响应以及确认都可以在尽可能少的交互中在各种设备之间发生，以使具有支付信息的用户移动设备与自助服务终端设备建立链接，这样一来，用户便可以按照在自己的移动设备、台式设备、平板电脑或笔记本电脑上使用浏览器的方式来使用信息亭浏览器。最终目标是通过自助服务台或使用浏览器API来管理购买过程但不存储或不了解特定用户的任何设备，为用户提供相同的舒适购买体验。
点对点浏览器API应用
在另一方面，浏览器API可以被用于对等支付。在这种情况下，“商家”网站可以只是发起支付数据请求的对等网站。在点对点方案中，例如，每个用户都有一个移动设备或任何类型的设备，假定每个设备都有一个浏览器，该浏览器配置为通过浏览器API进行数据通信。服务可以操作以执行商家通常如本文所公开的那样操作的特定功能。例如，当第一设备在对等环境中通过应用程序与第二设备通信时，如果发出一条指令要求第一对等方向第二对等方传输20美元，则服务可以生成必要的支付请求通过与第一对等方的浏览器API以及通过与第二对等方的浏览器API的支付请求。在这种情况下，将修改浏览器API，以便第二个对等方不在支付，而是在支付。在这方面，将修改浏览器API以检索第二对等方的账户数据，从而可以向该账户支付资金。对于退款，通常会以相同的方式处理，这是一个类似的过程。这种方法也可以用于退款给用户。例如，用户可以通过浏览器API接收令牌化的支付数据包。通过浏览器API接收到设备后，设备便可以将该令牌传达给支付处理系统，以接收退款至其帐户。
因此，在对等环境中，该方法可以包括使得能够在第一对等体与第二对等体之间进行对等通信，并且接收期望转移诸如金钱之类的利益的指示，但是该利益可能是从第一个对等点到第二个对等点的积分、媒体或任何有价值的物品。该方法将包括如本文所公开的通过浏览器API向第一对等方发起第一支付请求，其中具有必要信息以检索支付数据和/或其他数据以完成支付。服务。向第一个对等方的支付帐户收费。可以通过浏览器API向第二个对等方提交信用请求。类似于本文公开的支付请求API，信息交换可以协调服务可用的可用支付方式以提供信用和第二个对等方可用于接收信用的帐户类型。然后，该服务可以基于通过浏览器API接收的数据从第一对等方收取费用，并根据从第二对等方接收到的帐户数据向第二对等方的帐户提供信用。在一方面，第二对等方提供一次性使用令牌，该一次性令牌与支付令牌不同地配置，因为它将是信用收据令牌。该服务可以利用来自第二对等方的支付收据令牌，并向第二对等方的帐户提供一次性支付，而无需实际查看支付数据。加密货币或其他支付方式也可以是真正的对等网络，而无需介入服务，因此可以通过相应的API交换相应的密钥或令牌或支付数据，并在不同设备上的浏览器之间进行管理。此外，还可以以类似的方式来提供对等商品的购买和交付，其中地址信息也可以经由商品购买者的浏览器API进行通信，从而使得对等通信中的卖方可以接收支付以及用于运送物品的运送信息。可以在修改的浏览器API中实现希望在对等环境中进行通信的任何其他数据或信息，以便启用对等通信、销售、汇款等。在另一方面，API可以用于在服务处接收支付，并且接收者借记卡可以用于将支付记入对等接收者。
使用API进行注册
浏览器或其他代理(例如amazon.com)可以存储地址、名称、信用卡等。除了用于支付之外，还可以出于任何其他目的从任何其他网站调用该API。例如，如果用户正在注册会议，则注册网站可以向代理(浏览器、服务、amazon.com或任何其他存储信息并通过API进行交互的实体)生成API请求，该API请求仅询问用户名和电子邮件地址，或注册所需的任何信息组合。任何网站上请求一个或多个信息的任何输入字段都可以通过API对该信息提交请求。普通的支付请求API包括诸如该网站批准的支付类型(VISA、万事达卡等)之类的信息，但是可以修改该API以仅询问姓名、姓名和地址、姓名和电子邮件地址，等等。
因此，通过扩展API的使用，使用具有任何输入字段甚至要求离散信息的任何网站或应用程序的人可能不必手动输入该信息，因为可以对浏览器进行API调用来填充数据。因此，超出支付方法或完全独立于支付方法的使用可以利用信息字段API来填充信息。在这方面，浏览器还可以存储除支付数据或与支付相关的数据之外的其他信息，例如偏好、食物限制、房间要求、基于位置的信息、生日或对任何网站输入字段可能有用的任何信息。可以通过浏览器API接收任何此类信息。这也可以为人们提供标准化的网络流程，例如，注册会议或提供其电子邮件地址以获得对网站或内容的访问权限、预订酒店房间、注册课程、请求白皮书等。
商户和浏览器之间的交互利用交换支付数据的对象
在另一方面，如图17C所示，本公开涵盖浏览器经由用户界面接收用户与与网站相关联的对象的交互(1720)，该交互指示用户意图进行购买，基于交互并且经由应用程序编程接口，接收来自网站的与购买有关的支付数据的请求(1722)，并且经由应用程序编程接口向网站发送支付数据(1724)，其中支付数据可用于处理支付或交付与购买相关的商品。
该过程可以如下更详细地执行。用户与对象进行交互之后，网站可以通过浏览器和网站之间的浏览器支付请求API进行支付请求的JavaScript API调用。API请求可以包含数据，例如网站可接受的支付方式(签证、万事达卡、比特币等)、要收取的金额、他们期望的货币、其他数据(取决于购买背景)，等等。API请求还可以包含有关交易的详细信息，例如总金额、货币、金额计算方式、税金、折扣、运输成本等。然后，浏览器可以通过存储的信用卡信息、用户的altcoin钱包、Apple Pay、Android Pay PayPal或任何其他类型的支付服务，来确定可接受的支付与可用支付之间的匹配。该系统可以向用户呈现当前信息以及添加送货地址、正确数据或改变用于交易的任何必要数据的机会。系统接收并更新任何更改的数据。如果向用户提供了选项，则用户可以选择用于处理交易的支付选项。
接下来，用户可以根据用户使用的支付帐户的类型来授权交易。可能会交换收货地址或将收货地址用于总额中。可以向用户呈现界面，以确认支付方式、支付金额、送货地址等中的一种或多种。支付方式可能是通过存储的信用卡，其中可能显示最后4位数字以进行确认。如果使用了信用卡，则信用卡信息(卡号、有效期、姓名、CVC)将通过API传输到网站，以使用网站的支付处理系统进行处理。这可以是加密的传输，也可以是某种安全机制来维护安全性，例如生成的一次性令牌。如果通过Google电子钱包、AndroidPay或Apple Pay之类的服务选择了本地支付，则所选服务可以处理支付，并且可以通过API向该网站提供报告。关于用户的其他信息也可以发送到商家，例如电子邮件地址、地址、支付人电话、社交媒体数据、社交媒体中的联系人等。商家然后可以继续与买方的关系。
从商家的角度来看，该方法通常可以如下进行并且如图17D所示。该方法包括在网站(商家)和浏览器之间传递数据(1730)。该方法包括：通过浏览器的用户界面传输以呈现用户可以与之交互的对象(1732)，接收用户与与网站相关联的对象的交互(1734)，该交互指示用户购买意图的互动，基于交互并通过网站与浏览器之间的应用程序编程接口传输网站对与购买有关的支付数据的请求(1736)，以及在现场并通过应用程序编程接口接收支付数据(1738)，其中支付数据确认支付或可用于处理商品的支付或交付与购买相关的商品。如上所述，取决于用户注册了什么服务或用户的偏好，支付处理可以在API的任一侧上进行。当网站处理商品的支付时，支付数据可以至少包括用户支付帐户数据，例如一次性使用令牌。该方法可以进一步包括网站基于经由应用程序编程接口从浏览器接收到的支付账户数据来处理商品的支付。当支付服务处理商品的支付时，支付数据可以包括对支付服务已经发生的商品支付的确认，使得网站可以将商品交付给用户。或者，如果选择了替代币方法，则API协议可以包含一种功能，用于以加密方式交换信息或个人密钥、地址、金额、货币和替代币值之间的转换数据以及以及使山寨币钱包或支付服务能够向商家网站进行山寨币支付并报告支付成功所必需的任何其他数据。在这方面，API协议的结构使得用户可以选择支付方式，包括通过针对Visa、Mastercard、Debit卡、PayPal等支付系统的商户标准支付处理结构，在API的浏览器端(通过与该浏览器关联的浏览器或支付服务，或与该浏览器进行通信，或通过币币系统)或API的商户端进行的支付。因此，在用户接近购买的一个用户界面中，用户可以看到诸如“Visa********1234”或“Android-Pay”之类的支付选项。选择Visa支付方式将导致商家和浏览器之间的后端处理将Visa支付信息、帐号、安全码、用户名、地址等传输到商家网站，以便商家可以处理支付。选择Android Pay将导致通过API传输购买金额、税金、运费和/或任何其他必要的数据，以便AndroidPay服务可以处理支付并向您报告已完成支付的确认，以便商家可以交付商品。
以上方法也可以应用于下拉菜单或下拉菜单。使用适当的API，可以提高通过下拉/上拉菜单选项进行购买的效率。例如，可以存储用户信息，例如帽子尺寸、鞋子尺寸、衬衫尺寸、裤子尺寸等。可以存储用户对颜色、样式等的偏好，并且还可以通过社交媒体网站或联系信息访问此类信息。此数据可用于帮助自动完成或选择要在下拉菜单中列出的商品。此类信息可以通过浏览器API与销售带有可以通过此类用户数据填写的参数的商品的商家进行通信。如果用户开始输入“绿色棒球帽”，则下拉菜单项可能显示“78/5英寸绿色棒球帽，现在以11美元的Visa价购买，由沃尔玛于周二交付”。当用户键入单词时，与商家网站处的商品数据库的相关性可能导致商家交换商品信息或通过支付请求API提出对支付请求的请求。可以利用用户的地址来快速确定运输成本、税金等，以便下拉菜单可以包含一项或多项费用、支付方式、送货信息、商品说明、尺寸信息、个人用户对颜色或样式的偏好等。用户只需单击该选项即可支付(取决于商家的功能、用户支付帐户等，在API的任何一侧)，然后交付商品。如果有多个支付选项(Visa、AndroidPay、比特币)，则下拉菜单中的商品可能会具有多个子选项，可能以从左到右的方式进行选择。这将是一个更具动态性的下拉菜单，用户可以在其中下拉菜单以选择行，然后向右或向左滑动，直到光标位于Android Pay选项上方。释放光标可能导致系统继续通过API交换信息，并通过Android Pay选项处理支付并将该支付报告给商家。菜单选项可以报告商品的任何数量的不同信息，例如提货地点(在敦刻尔克的沃尔玛取货)等。当前的下拉菜单提供了一些选项，例如在Amazon.com或Yahoo.com上搜索商品，但是它们不能提供购买的简便性，而可以通过在浏览器和商家网站之间使用浏览器API来定制下拉/上拉选项来实现购买的简便性。用户可以与之交互的对象可以显示在用户界面的任何位置，而不仅仅是下拉菜单。
这种方法的另一个好处是，当用户在搜索字段中输入商品信息时，用户可以查看下拉/上载结果并随其范围缩小范围。例如，如果用户键入“棒球帽”，则下拉/上拉项可能包括诸如以下商品：从“W”almart或“C”osco出售的“G”reen棒球帽。用户可以继续输入：“棒球帽GC”，它可以利用下拉菜单中的提示将其变为绿色，并通过Cosco进行提示。也许两个价格可能显示为“11美元或20美元”，并且用户继续在输入字段中键入“11”。来自下拉菜单项的键入和反馈的动态交换还可以指示用户正在与多个不同的下拉菜单项中的哪一个进行交互，并继续将搜索和结果集中在用户正在寻找的内容上。在整个过程中，可以快速假设可能有购买意图，并且用户可以显示和选择支付数据和选项的交换。例如，下拉菜单项可能会显示“绿色棒球帽，11美元，“A”机器人工资，“V”isa或“B”itcoin””，并且用户可以继续输入“棒球帽GCV”，这将指示选择Visa作为支付方式。可以通过此过程动态呈现图片，包括单击图片并继续通过输入字段提供信息的机会，以便最终用户选择了商品、商品的颜色、尺寸等支付方式，并可以确认支付。在一个示例中，菜单项可能比当前菜单项更具动态性，以使用户单击该项内的不同对象以选择支付选项、大小、颜色、商家、交货地址等。随着用户缩小用户想要关注的下拉/上拉商品的范围，可以提供更多信息来完成购买，从而使处理变得非常快速和简单。菜单项一开始可能简短而简单，但是随着用户键入更多内容或与菜单项进行交互，可以显示新数据或对象，这些数据或对象可以通过与API交互以动态方式进行显示，从而可以快速完成该项的购买。例如，用户最初可能选择“来自Bob的音频视频中的iPhone8”，但随后商家可以传达其可以通过API处理Visa和Android Pay的信息。如果用户还具有这些可用的支付选项，则菜单项可以添加两个可选择的对象，用户可以单击它们或可替换地继续在输入字段(因为用户已经在键盘上打字了)中输入“v”或“a”以表示该选择。交互以确认商品、金额、送货地址、支付选项等之后的系统可以如在此在API的任一侧上公开地管理支付，并指示商家进行送货。
该过程通过浏览器API，可以交换支付数据、一键式参数或设置、任何其他数据，并以用户选择的方式处理支付。商家交付物品。本文公开的下拉菜单概念与浏览器支付请求API以不同的方式工作，但是为用户实现了更有效的购买过程的类似结果。本公开涵盖了浏览器方面的交互，既包括通过API与商家在整个过程中与商家进行交互的交互，也包括来自商家网站的处理，在商家网站中，他们管理商品数据库，并通过API与浏览器进行交互和交换信息、请求等。
以下讨论继续涉及使用API或其他协议从浏览器、网站、代理或其他存储位置向商家网站传达与支付有关的数据，以填充支付字段，以便用户简化购买过程。在一方面，本公开现在涉及使用API将用户从搜索引擎、社交媒体网站或任何网站转换到商家网站。在另一方面，商户网站可以(与用户导航到网站的方式无关)通过API与浏览器/代理/实体交互以获得用于自动填充支付信息以消除或减少用户填写数据字段的需求的支付数据，这在移动设备上特别麻烦。
在一个方面，公开了一种系统、方法和计算机可读存储设备，其基于由分类器确定的意图来预先填充在线销售商的网站中的购物车，该分类器处理提供给统一输入字段的输入。用户意图可以以任何方式分类或确定。可以使用浏览器(例如Chrome、Firefox、Internet Explorer、Samsung Internet、Microsoft Edge、Safari或Opera)注册和/或登录用户，以便将用户的购买信用卡/借记卡或其他帐户和收货地址和/或其他数据存储在用户个人资料中。然后，如果用户希望通过可能在其注册网站上找不到商品的目标网站进行购买，则浏览器(或网络中的系统处理)可以处理浏览器与网站之间的协商(通过API)，这样系统可以将未注册用户的基于购物车的模型网站转换为用户的“一键式”购买体验。例如，系统(通过Google电子钱包、Apple Pay、Android Pay或PayPal等服务)可以处理商品的支付并与商家网站进行通信以处理交货。当然，在这种情况下，该过程可以不从搜索引擎启动，而仅从商家网站中用户处于购买商品位置的状态启动。在该状态下，商家网站可以通过API与浏览器、代理或搜索实体进行通信，以获取用于填充必要支付字段的支付数据，并通过与用户的界面呈现简化的购买体验。通过API将支付数据(一个或多个帐户数据、投放数据、日期、投放选项、偏好设置等)传递到商家网站后，商家网站可以使用其正常的支付系统处理用户支付帐户中的支付。
假设适当的权限到位，例如在浏览器设置中，授权浏览器在网站的购买、注册或购物车过程中导航并提供输入以自动输入姓名、地址、信用卡信息等，则系统可以自动填充购物车，包括甚至代表用户在尚未注册的网站上注册。这可以作为基于一键式购买状态从社交网站到目标商家网站的转换的一部分而发生，该转换是基于浏览器中在转换中需要访问的设置的一键购买状态。用户在统一的输入字段中提供输入，例如“buy acmetoaster4.5”，系统和分类器将其归类为购买特定烤面包机模型的需求。该系统基于各种标准(例如定价、运输、国家/地区等)确定提供该烤面包机模型的商家网站。用户从未在提供烤面包机的商家网站上注册或购买过商品。因此，如果用户要从该商家网站购买烤面包机，则该用户必须将烤面包机放在虚拟购物车中，然后输入个人信息(例如地址、信用卡/借记卡信息、用户名、密码等)才能发货。
在一方面，该系统可以基于经由统一输入字段提供的输入来识别商家网站，或者可以独立于商家网站而直接发起该过程，而无需进行搜索以到达商家网站。然后，系统可以导航到商家网站中用户通常会单击以将商品放入购物车中的状态。但是，在这种情况下，系统将导航到可以将商品放置在购物车中的商家网站，并确定用户未在该商家网站中注册。然后，系统可以使用新的用户注册页面或API自动与商家网站进行通信，以使用系统和/或浏览器可用的用户数据代表用户创建新帐户。因此，该系统可以仅向用户呈现按钮中的确认以通过一键购买。该确认可以是创建新帐户的授权和使用新帐户下订单的授权的双重确认。用户可以自动授权新注册，并可以建立用于管理新配置文件注册的设置或首选项。然后，系统可以输入从浏览器或其他某个位置检索到的所有必要数据，以完成注册并无需进一步用户输入就可以购买和运输该物品。通过通过统一输入字段进行输入，该方法可以将非一键式购买网站转变为一键式购买网站。系统还可以使用注册的支付信息来处理支付，并与商家网站进行协调以填写订单。通过API获得用于自动提供支付和/或交付数据的支付数据的过程也可以简单地通过API在商家网站和浏览器之间发生。在用户可以进行购买的适当状态下，商家网站可以通过API提交对支付数据的请求，该请求可以由浏览器或代理存储，以简化购买过程。数据也可以通过令牌化过程从浏览器提供给商家网站，以保护支付帐户信息。用户查看的界面可以是商家信息(商品图片、评论、其他日期)的组合，也可以是通过API提供给图形界面的“立即购买”或“通过Google购买”或“Android Pay”类型的按钮。
一方面，系统在用户设备上存储使用支付请求API所需的任何信息。例如，当用户将借记卡或信用卡添加到支付机制时，帐户信息将被加密并发送到网络服务器。然后，服务器与用户银行链接以验证信息。银行可以创建一个加密的设备帐号，该帐号被传送回服务器并存储在用户设备中的安全元素上。可以将安全元件嵌入设备上的近场通信(NFC)芯片中。该号码对于用户设备以及与其关联的信用卡和借记卡(或加密货币或其他支付方式)是完全唯一的。
当用户通过浏览器API进行购买时，安全元件(它是安全芯片)会创建一个唯一的代码，并将其与设备帐号一起发送到支付终端，以代替卡号。一方面，卡信息未存储在用户设备或服务器中，并且可能不会备份至云提供商。唯一代码通过浏览器API传输到商家网站，以处理支付。因此，根据这个方面，存储在用户设备上的信息可以不特别是支付帐号，而是与用户的支付帐号相关联的特定帐号。最终结果与设备将帐号传输到商家网站进行支付的结果相同。在某些服务提供商中，设备帐号用于标识用于支付的信用卡或借记卡。
图17E示出与支付请求API一起使用的令牌化过程1740。当使用令牌化处理时，商家1744可能需要几条信息才能处理从浏览器API接收到的令牌。商家可能需要唯一的标识符，该标识符代表与支付方法关联的商家。商家可能需要用于安全传输支付数据的支付处理证书。网络服务器1750可以使用支付处理证书公钥来加密支付数据。在处理支付或令牌信息时，商家可以使用私钥来解密数据。商户身份证书或传输层安全证书可用于认证与网络服务器的商户会话。接下来将更详细地说明该过程。
如图17E所示，当用户浏览网站时，商家或应用程序1744将与用户或购物者1742进行交互1754。一旦用户决定进行购买，他们可以单击购买按钮并授权进行支付方法。这还可以包括诸如指纹之类的触摸ID以授权支付1756。可以在Xcode中启用这种功能。如上所述，在一方面，商家1744已经注册了商家ID并创建了支付处理证书，该支付处理证书是用于将支付数据安全地发送给商家服务器的加密密钥。单击购买按钮并提供指纹授权以处理支付可能涉及一个步骤，也可能涉及多个步骤。
为了发起支付，商家应用程序创建一个支付请求，以提交给商家1744与浏览器1746之间的支付请求API。此请求可以包括所购买的服务和商品的小计，以及任何税费、运费或折扣的额外费用。商家可以将此请求传递给支付授权视图控制器，该控制器将请求显示给用户并提示输入任何所需信息，例如送货地址或帐单地址。当用户与视图控制器1754交互时，可以调用委托来更新请求。这还可以包括对尺寸信息、颜色首选项、社交媒体数据(如生日信息)或任何其他与购买有关的信息的请求。
一旦用户授权了支付1756，就可以对支付信息进行加密以防止未经授权的第三方访问它。一方面，可以将支付请求发送到安全元件(例如，iPhone上使用的安全元件以使Apple Pay能够在商家网站进行近距离通信)，该安全元件是用户设备1746上的专用芯片。元素添加用于指定的卡和商家的支付数据，创建加密的支付令牌1758。然后，将该令牌传递1760到网络服务器1750，在网络服务器1750中，服务器使用商家支付处理证书1762对令牌进行重新加密。服务器1750将1762重新加密的令牌发送回用户设备1746。重新加密的令牌表示准备发送给商家网站1744的第二令牌。通过浏览器API，用户设备1746将加密的令牌和/或支付数据发送回商家网站1764以进行处理。所请求的其他数据也可以通过API传输回网站，例如鞋码、衬衫尺寸、裤子尺寸、颜色首选项、样式首选项等。可以在此过程中的不同阶段对API进行多次不同的调用。例如，在提出支付请求之前的几个步骤中，商家网站可能需要尺寸信息，以便用户不必单击“X”或“XL”或“M”即可获得衬衫尺寸。此外，正在为人体生成人体模型。用于用户的数据可以存储在浏览器中的身体形状模型中，或者可以被浏览器访问。如果用户正在网上寻找衣服，则可以通过浏览器API检索有关其身体模型的数据，并将其传输到可以为该人调整衣服外观的网站。它们还可以包括其他个人的数据，例如，当用户与该网站进行交互时，该网站可以说是为您或您的姐姐准备的，或者您的妻子可以传输他们的身体模型数据，这样衣服才能适合合适的人。然后可以针对该人体模型修改衣物的视图。
然后，作为支付方法的一部分，商家网站1744调用具有加密令牌和支付数据1766的REST服务(这是本领域技术人员已知的用于处理支付的信息)或其他类似服务，该REST数据或支付数据1766将该数据通信至商业服务器1748。服务器1748将购物车提交至订单1768，并将支付1770授权给支付网关1752。“确定”信号1772被发送回商业服务器1748，商业服务器1748将退还支付状态传达给商家网站1744。已经处理并确认的支付使商家网站1744撤消支付单1776，并向用户1778显示订单确认。
一方面，支付令牌从未被访问或存储在用于加密支付数据和令牌的网络服务器1750上。服务器仅使用商户证书重新加密令牌。此过程使商家可以安全地加密支付信息，而不必将支付处理证书作为商家应用程序的一部分进行分发。
在许多情况下，商家网站将加密的支付令牌传递给第三方支付解决方案提供商1748，以解密和处理支付。但是，在商家拥有现有支付基础结构的情况下，商家可以在自己的服务器上解密并处理支付。读取、验证和处理支付信息可能涉及一个或多个加密步骤，例如计算SHA-1哈希，读取和验证PKCS#7签名以及执行椭圆曲线Diffie-Hellman密钥交换。注意，以上方法表示与浏览器支付请求API一起使用的示例令牌化过程。支付令牌对象可以包括诸如交易ID，金额，关于商品的数据，关于支付网络的信息，诸如可以包括加密的支付数据的签名和标头之类的支付令牌数据，以及金额、持卡人姓名、CVV代码、到期日期、支付帐号、支付处理数据和地址、其他用户首选项、加密货币数据等。当然，也可以考虑用于令牌化的其他过程，这可以为该过程增加一层安全性。
在另一方面，浏览器可以在诸如膝上型计算机的第一用户设备上操作，并且支付数据可以被存储在诸如移动设备或移动电话的第二用户设备上。第一用户设备和第二用户设备可以通过诸如蓝牙协议的协议进行无线通信。在某些情况下，第一设备可能没有指纹识别选项，而第二设备却有。在这种情况下，当用户通过第一设备与配置为利用浏览器支付请求应用程序编程接口的浏览器进行交互时，作为支付方法的一部分，第一设备将与第二设备建立通信，以便用户可以通过触摸标识授权支付，其中第二设备可用于生成支付令牌并与网络服务器通信以接收第二支付令牌，该第二支付令牌从第二设备传递到第一设备，并通过浏览器支付请求应用程序编程接口传递到商家网站以用于支付方法。在其他情况下，第一设备包括指纹识别机制，因此仅需一个设备即可确认购买授权。浏览器可以是用于查看和导航网站或应用程序的任何用户界面。浏览器API还可以接收关于商品、商家的数据、用于加密通信的密钥或任何其他信息中的一个或多个，使得可以独立于通过API向商家传递支付数据来进行支付方法。例如，出于安全目的，可以将支付信息传送到可以处理支付的单独的支付处理器，从而不会将用户的支付数据提供给网站。但是，商家仍然必须交付商品，因此浏览器API可以让单独的支付处理器处理支付，但将用户名和地址交付信息传递给网站以交付商品。
在涉及从浏览器或应用程序的角度来看的处理的又一方面，一种示例方法包括在图形用户界面上呈现演示文稿，演示文稿是通过网络从网站接收的，通过用户界面并从用户接收与演示文稿的交互，通过浏览器和商家网站之间的浏览器应用程序编程接口，接收来自该网站的针对用户的支付帐户数据的请求，并经由应用程序编程接口向网站传输支付账户数据或其他数据，其中支付账户数据可用于填充支付字段以用于网站上的支付处理。数据可以是令牌，令牌可以一次用于支付，并且可以维护帐户信息的私密性。支付帐户数据可能仅由商家网站用于处理支付，并且可能没有按字面意义填充字段，否则这些字段将由用户输入手动填充。例如，如果以令牌化的安全方式接收到支付数据，则该数据可以仅用于处理支付，而不能用于字面意义上填写预设表单字段。该演示可以包括用于购买的商品和服务之一。该方法可以包括网站使用针对用户的支付账户数据来处理对物品或服务的支付。图形用户界面可以与浏览器或应用程序关联。在一方面，该API在网站(商户网站)和可以存储用户的支付账户数据的浏览器之间通信数据。从浏览器的角度来看，此方面涵盖了存储用户支付/交付数据并通过API将数据与商家网站进行通信的过程，用于填充必要字段(或同等类型的过程)以为商家网站上的用户创建一键式购买体验。
该API还可以用于为用户请求身体类型、尺寸或身体模型，以展示要购买的衣服。在另一方面，商家网站可以通过用于导航网站的浏览器来确定浏览器API是否可用。如果是这样，则浏览器API请求可以继续，如果没有，则该网站将继续使用用于支付和地址信息的标准输入字段方法。
该方法可以进一步包括更新表示以包括购买选项，该购买选项被配置为基于来自用户的确认，以使网站能够利用通过API接收到的支付帐户数据来处理商品或服务的购买，而无需用户填写网站上的支付字段。通过API进行通信的浏览器或其他代理也可以为“立即支付”类型的按钮提供图形，以与网站图形集成。支付账户数据可以进一步包括用户的地址数据、支付账户号、有效期、安全码、持卡人姓名和用户的运输指令中的一个或多个。
通过API进行的请求可以进一步包括以下一种或多种：网站支持的支付方式、购买的总金额、可以显示购买的商品、运送选项、支付修改项、对用户电子邮件地址的请求、对用户电话号码的请求以及对信息更新的请求。与浏览器相似或分离的用户代理可以在应用程序编程接口和网站之间传递支付帐户数据。
在另一方面，从网站的角度来看，该方法包括概念。在这种情况下，该方法包括：为了在图形用户界面上查看而发送演示文稿，该演示文稿从网站通过网络传输到具有图形用户界面的设备，经由网络并且从用户接收与呈现的交互，并将对用户的支付账户数据的请求传输到应用编程接口。该方法包括在现场并且经由应用程序编程接口接收支付账户数据和与支付方法相关联的填充支付数据字段，其中该支付数据与用于用户的支付账户数据一起产生填充的支付数据字段。支付数据也可以采用令牌化格式，以不泄露用户帐户信息的安全方式处理支付。可以发送部分帐户信息(例如，帐号的后4位)以在用户界面上显示，以确认要使用哪个帐户。该网站可以使用用户的支付帐户数据来处理商品或服务的支付。API可以在浏览器和网站之间协调数据，在该网站中浏览器存储用户的支付账户数据。在从用户接收到对与演示相关联的商品或服务的购买的确认之后，该方法可以包括使用填充的支付数据字段来处理商品的支付。
该方法可以进一步包括，在接收到支付账户数据时，更新演示以包括购买选项，该购买选项被配置为基于来自用户的确认，以使网站能够使用支付帐户数据来处理商品或服务的购买，而无需用户手动填写网站上的支付数据字段。支付账户数据可以进一步包括用户的地址数据、支付账户号、有效期、安全码、持卡人姓名和用户的运输指令中的一个或多个。该请求可以进一步包括以下一种或多种：网站支持的支付方式、购买的总金额、可以显示的购买商品、运输选项、支付修改、对用户电子邮件地址的请求、用户的电话号码，以及更新信息的请求。用户代理还可以在应用程序编程接口和网站之间传递支付帐户数据。在另一方面，一种方法包括在图形用户界面上呈现演示，该演示是通过网络从网站接收的，经由用户界面并从用户接收与演示文稿的交互，经由应用程序编程接口接收来自网站的针对用户的支付账户数据的请求，使用支付帐户数据自动填充与演示文稿关联的支付字段(或仅使用支付处理所需的数据)，并通过应用编程接口将支付账户数据传输到网站，其中网站可以基于用户的支付账户数据处理支付。该方法还可以包括在自动填写支付字段之后，从购买者接收确认。
系统可以在后台选项卡或浏览器的新窗口中静默处理新的注册页面，也可以与商家网站协商新的注册过程，而无需向用户展示注册页面。在用户请求购买后，系统可以在包含统一输入字段的同一页面上显示进度条，例如在通过统一输入字段提供输入后按Enter。进度条可以向用户指示创建新帐户，输入运输数据，将商品添加到商家网站的购物车以及下订单的进度。
用户可以为要用于新注册的个人信息建立默认首选项。用户可以在遇到商家网站之前，甚至在遇到统一输入字段之前建立这些默认首选项。可替代地，在需要注册的第一实例中，系统可以提示用户建立这样的设置和/或提供附加信息。
该系统可以优选商户网站，用户已经在该商户网站上注册了帐户或已经向其注册了用户。例如，如果商户X和商户Y都提供相同的待售商品，则系统可以选择使用用户已经拥有帐户的这两个商户之一。系统可以通过检查浏览器历史记录、浏览器可用的配置文件数据、浏览器类型或由浏览器或与用户关联的其他浏览器存储的cookie来确定这一点。该系统可以例如基于运送时间的差异或价格的差异来智能地确定何时使用未向其注册用户的商家。例如，如果未向其注册用户的商家以比向其注册用户至少低25％的价格提供所需商品，则系统可以创建一个新帐户。如果用户不希望系统代表他或她创建用户帐户，则用户可以指示系统在他或她已经拥有帐户的地方或允许访客帐户的商家网站上进行购买。
但是，系统可以使用分类器和用户配置文件数据来识别用户最有可能选择的商家，并将其呈现给用户以消除歧义。该系统可以向用户显示一个表格，例如通过JavaScript弹出窗口，以显示商家、运送时间以及包括运费和税金在内的总价。用户可以简单地从表中单击所需的商家，并且系统可以在需要时自动向该商家注册用户，并处理该商家的订单。用户只需单击一下即可识别商户，系统将处理其余的步骤，从而通过统一的输入字段将一键式界面提供给非一键式网站。
图17F示出使用浏览器API来传达支付数据的另一方面1782。在用户浏览网站并启动结帐过程1787之后，网页应创建支付请求，该请求通常在用户单击“购买”按钮时启动。支付请求可以包括方法数据、详细信息和选项。该方法数据可以包括所需的支付方法数据，该数据包括支付方法标识符、所需的交易信息以及可选信息，例如应当返回的运输或联系信息。在一方面，支付金额可以为负，并且支付请求API可以用于处理退货或折扣。当然，在这方面，资金将从商家网站通过浏览器API流入用户的数字钱包或支付帐户。同样在此方面，在用户将要从浏览器或网站发起支付请求的情况下，该过程实质上可以颠倒，并且此过程的任何方面都可以从本质上颠倒过来，其中可以利用运输信息、折扣和其他任何必要的数据来处理退款。可以在浏览器端或商户端使用和生成令牌，并使用帐户信息和数据来处理退货或点对点支付。退货信息、额外费用或使用户能够退货并获得退款所需的任何其他数据，可以通过浏览器API进行交换，方式与用户在商户网站进行购买时类似。
继续图17F，支付请求1788可以启动“显示”功能，该功能示出用作处理支付的界面的对话框1789。用户的钱包1786(例如Microsoft钱包、加密钱包、存储在浏览器或其他位置的支付信息等)可以被标记为商标或用作用户界面的一部分。在该示例中，用户通过界面选择送货地址1791。图17G示出界面1781，其具有诸如用户的姓名、送货地址、送货选项以及收据的电子邮件地址之类的信息。运输信息从钱包1786返回到浏览器1785，浏览器1785随后被传递到网页1784，使得网页可以从Web服务器1783请求运输成本1793，Web服务器1783将运输费用返回给商家1784，商家1784然后可以更新价格1794，该价格被传递到浏览器1785和钱包1786。生成针对浏览器1785的钱包的支付响应1795，浏览器1785将支付响应通过浏览器API传递给进行购买1796的商家1784。成功或失败信号1797被提供给商家，然后商家可以通过通知浏览器1785完成过程1798，此时购买完成1799。尽管图17F没有具体提到令牌化过程，但是各种加密技术也可以用于加密数据或令牌化数据，从而通过浏览器API传递的支付请求或支付响应可以是一次性使用令牌，该令牌可加密处理一项或多项支付、支付的传递以及用户信息更新等所需的各种信息。
图17H示出界面1771，该界面1771具有几个独特的特征。一个独特的特征是在触敏屏幕1779中没有购买按钮。提供具有指纹ID的安全购买体验的标准方法是需要多次交互来完成购买。第一种是单击用户界面1779上的购买按钮，然后单击通过指纹确认的用户ID。由于涉及两次单击，因此可以采用以下针对包含指纹ID的系统批准的机制。当用户在网站上导航以使他们接近可以进行购买的状态时，该网站可以通过浏览器支付请求界面提供与购买相关的初步信息的请求。初步信息可以包括买方的城镇或城市以及买方的名称。它可能包括支付帐户信息。某些信息可能被加密或部分传递以维护隐私。在一种情况下，传达了足够数量的信息以向用户提供足够的信息以确认正确的用户以及正确的城镇1773被识别。还可以显示一种运输类型1773。通过初步信息的通信，可以计算出要收取的总金额，并在用户单击任何购买按钮之前将其显示给用户。浏览器支付请求API是一个适当的通信通道，用于通过浏览器或用户界面接收到达用户界面状态所需的基本数据。浏览器何时向浏览器API提交支付请求调用以获取信息的触发器可能是网站上导航的状态。因此，与其基于用户点击购买按钮来触发支付请求，网站可以识别出用户已将商品放置在购物车中，并且当用户单击显示购物车的功能按钮时(该互动将在购买互动之前发生)，系统可以提交支付请求，从而无需在界面上按下购买按钮。可以在分析中包含以下一个或多个参数，以确定何时启动支付请求或调用浏览器API以获得与潜在购买相关的一条或多条信息：机器学习工具或有关用户习惯的信息、对用户以前的互动和用户的购买习惯的分析、网站的配置、一天中的时间、可能购买的商品类型、社交媒体信息、例如朋友和家人的生日、用户导航网站的位置、用户使用的设备的类型、例如台式机、笔记本电脑或移动电话等。可以分析这些数据中的任何一个或多个，以确定何时启动对浏览器API的调用，而无需用户单击购买按钮。如上所述，通过基于导航的状态而不是用户点击购买按钮来发起呼叫，可以去除交互以进行购买。用户无需同时点击购买按钮和按下指纹读取器。
界面1779中还示出用于用户改变所呈现的信息的选项。通常，用户会反复使用特定的模式，例如选择陆运。因此，在许多情况下，在用户界面中提供的指示用户现在可以使用指纹进行购买的信息1775使用户能够真正拥有单次触摸购买体验，其中单次触摸不仅可以指示购买意图，还可以提供指纹授权。当然，如果指纹授权如此配置，则也可以在触敏屏幕1779上提供指纹授权。由于指纹按钮1777的使用在浏览器外部，因此设备1771可以将触摸传达给网站，指示用户已经提供了购买意图以及指纹授权。此时，系统可以继续创建各种必要的令牌或加密数据，以将加密令牌和支付数据返回到网站以处理支付。
在系统可能希望包括诸如没有指纹传感器的笔记本电脑和具有指纹传感器的协作移动设备之类的设备的情况下，可以将该配置传达到网站，这样就可以从移动设备通过无线接口向笔记本电脑或其他设备提供适当的信息，然后再到该网站，以便图17H中提供和显示的初步信息可以使笔记本电脑上的浏览器在通知1775中指示用户进行购买，用户只需提供以下信息即可：移动设备上的指纹识别。在此方案中删除的步骤是用户要求在设备上的浏览器中单击“立即购买”按钮的要求。因此，界面1779可以是动态的，这取决于用户是需要单个设备进行指纹授权还是多个设备。可以基于检测到的浏览器类型或用户支付帐户类型来显示动态购买按钮。如果使用单个设备，则通知1775可以简单地指示用户在指纹传感器1777上提供他们的指纹以进行购买。如果使用多个设备，则通知1775可以指示用户在其第二个设备上简单地提供指纹认证。还可在第二设备上提供显示器以协调信息并确认通过触摸第二设备上的指纹识别按钮，用户正在购买第一设备上所示的礼帽。通过在商家网站、第一设备和第二设备之间提供这种协调，支付方法可以消除一个交互。此过程可以使购买成为真正的一键式购买体验。
以下示例说明了以上观点。假设用户一直在导航并选择几个要从网站购买的商品，并将这些商品放置在购物车中。假设已经在购物车中放置了三个商品，并且用户希望现在结帐。用户单击“查看购物车”按钮。该按钮可以导致系统启动对浏览器API的调用，该浏览器可以检索一条或多条信息，以便可以向用户显示购物车中的三个商品，诸如签证之类的支付帐户标识、送货地址和送货方式的标识以及为购买提供简单指纹授权的说明。在此阶段，确实不需要购买按钮。当然，可以提供选项供用户编辑信息或更改支付帐户等。可以利用机器学习或其他智能来确定用户可能使用哪个支付帐户的优先级。例如，可以基于一个或多个因素，例如用户进行购买的位置、购买的种类、一天中的时间等，来呈现商务信用卡。
机器学习算法也可以应用于其他类型的界面，例如口头对话界面。过去，通常在对话管理方面开发了与语音相关的模型。本文公开的附加概念是利用机器学习来动态地修改或呈现支付方法，作为任何类型的用户界面的一部分。支付方法可能是口头对话、图形、多模型、近场通信、基于移动设备、基于桌面等。例如，在包括文本组件和语音组件的Messenger应用程序中，可以通过机器学习模型选择或确定以文本或消息形式呈现的内容与以语音或视觉形式呈现的内容之间的平衡。语音对话可以根据哪种类型的交互不仅使用户更轻松，而且摩擦更少，从而选择说什么、怎么说、使用哪种声音(男性、女性、口音等)、是否从一种声音切换到另一种声音等等，还可以增加转化次数和完成支付方法。另外，语音可能与特定的支付服务相关，例如Apple或Google。对话框、音量、音调、口音、支付服务、显示的选项的选择可以基于历史数据、机器学习数据以及其他数据(例如购买历史、用户偏好等)。使用这种方法可以使支付方法因人而异，从而增强个人用户在购买过程中的体验。不再向所有人显示相同的输入字段集或相同的PayPal按钮。承诺进行购买和授权购买的重点可以针对个人。还可在不同平台和网站之间提供该个性化方法，以使用户拥有一致的体验。浏览器API可以将一些与用户历史上经历过结帐的方式相关联的数据传递给网站，或者可以传递用户参数，或者传递任何其他数据来指示网站改进流程。例如，在通常的图形用户界面体验中，如果在显示购买按钮时发出可听见的评论，例如“玛丽，谢谢您访问我们的网站”，则一位用户完成购买的可能性可能会增加30％。我们将为您使用Apple Pay”。可以在图形体验中添加一个对话框，以引导人们逐步完成该过程，并使他们更加舒适。教程、图形、视频、聊天机会等等都可以成为支付体验的一部分，并且可以以动态的方式呈现给每个用户。
多网站购物车
参考上面的购物车带来了本公开的另一方面，如图17I所示。系统1701和该图的配置表示用户导航到多个网站1703、1705、1707进行购物。我们首先要注意的是，如果用户正在单个网站(例如Amazon.com)上购物并将大量商品放入购物车中，则用户可以查看该购物车，并一键购买购物车中的多个商品。但是，即使使用浏览器API，如果用户导航到多个不同的网站进行购买，则用户也必须进行多次单击购买才能购买三个商品。例如，如果用户从网站1(1703)购买了第一件商品，并且从网站2(1705)购买了第二件商品，而从网站3(1707)购买了第三件商品，则由于这些网站的独立性质，用户必须点击3次才能进行购买。以下是一种在多个网站上进行购买时消除大量点击的方法。本公开的一方面是使用浏览器API来存储放置在购物车中的物品。另一个方面涉及通过搜索引擎或搜索实体在通用购物车中存储数据，以便对通过不同模式进行的购买进行一次结帐(例如，购物车中装有一个来自网络搜索的商品，而另一个商品是来自具有对话系统的口头对话中的商品，以向购物车中填充另一个商品)。搜索实体或管理从通用购物车中结账的实体可以向商家收取管理结账的费用。例如，在多个商家在通用购物车中具有商品的情况下，管理结帐的实体可以向每个商家收取用于管理支付方法的一部分费用。在搜索实体的情况下，搜索实体可以不向与商家的广告收取费用，而可以仅对通过通用购物车进行的购买收取费用。
例如，假设用户在网站1上，并将烤面包机放在虚拟购物车中。可以向用户呈现将烤面包机放置在浏览器购物车中的选项。这可以是一个单独的按钮，用于与保留在网站上的普通购物车与用户进行交互，也可以与用于将商品放入购物车的标准网站按钮集成在一起。如果是这种情况，则系统可以在用户从网站1过渡时通知用户将烤面包机放在浏览器购物车中。无论如何，浏览器1711将通过浏览器API 1709接收与烤面包机相关的所有必要信息。如果用户在购物前放弃购物车，则可以通过浏览器API传递信息，该过程可以通过用户设置进行修改。在这方面，浏览器购物车在导航到多个网站时变得持久。接下来，假设用户导航到网站2，并以类似的方式将食谱放入虚拟购物车中。该信息通过浏览器API 1709传达，并存储在网站2购物车中。假设用户尚未购买菜谱。接下来，假设用户在网站3上，并向其虚拟购物车中添加了一支铅笔。此时，假定用户单击“查看购物车”按钮。在这种情况下，该交互可以触发对浏览器API 1709的调用，该API可以检索网站1的购物车中的烤面包机和网站2的购物车中的食谱，并在用户位于网站3时使用铅笔将这些物品显示在购物车中。可以显示一个购买按钮，使用户可以一次购买所有三个商品。可以理解，该过程已经消除了在不同网站上购买多个商品的传统方式中至少两次点击。用户确认支付后，每个相应的网站都会获得全部支付的一部分。对于各个商品、运输成本、税金等，浏览器或其他实体可以处理例如105美金的支付，其中第一个网站的支付是30美金，第二个网站的支付是$50，而第三个网站的支付是分别为25美金。可以利用本文公开的用于管理购买的公开信息，例如，在界面上的通知，即指纹交互可以购买所有物品。可以为要运送到两个不同位置的不同物料提供选项，依此类推。机器学习、历史信息或其他分析和算法可用于预测地址、支付帐户、运输选项等，以减少交互次数或简化用户的过程。经由API或其他方式(例如搜索引擎、搜索实体或其他服务)的网络服务也可以提供用于多网站购物车体验的功能。例如，网络服务可以使用相似或不同的界面模式在购物车中存储来自第一设备访问的一个网站的商品和来自第二设备访问的第二网站的第二商品，然后立即处理购物车中所有物品的支付。网站可以向该服务注册，并且可以向该服务、浏览器、购物车模型和商家处理提出索赔。通过利用浏览器API来处理支付，系统可以减轻用户登录购物车扩展程序或将支付和地址信息提供给单独的购物车扩展程序的需求。本文公开的通用购物车可以利用浏览器API来消除用户将其支付信息和地址信息提供给另一个实体的需求。当诸如搜索实体之类的实体存储支付/地址数据时，它可以提供支付方法并将该支付应用于购物车中的物品。
注意，浏览器API以及与任何相应商家的通信将相对于用户利用的支付类型协调针对商家的有能力的支付方法。本公开认识到跨多个网站的持久购物车可能导致跨网站的相对于用户能力的不同支付能力。所有这些差异都可以在此过程中解决，无论是在浏览器上，还是与其他服务或实体进行协调。换句话说，网站1只能使用Visa，而网站2只能使用万事达卡。网站模式3可能需要Apple Pay。在这种情况下，假设用户拥有一个已存储的Visa卡，一个万事达卡以及一个Apple Pay帐户。组合的购物车可以向用户提供确认，确认实体已协调了所有用户可用的支付机制，并将其分配给相应的相应网站，从而使单击交互将导致向网站1支付签证费用，万事达卡支付要从网站2进行，而Apple Pay要支付到网站3。每个相应的过程可以利用浏览器API、搜索实体或其他基于网络的服务来完成相应的支付，必要时生成令牌等。服务也可以提供其他机制，只需支付少量服务费即可为Visa卡或用户提供的任何其他单一支付机制收费，并处理向其他各个商家的其他支付。一方面，可以将单个令牌化支付发送到支付处理器，以处理不同网站之间的所有相应支付。
图17I表示可以用于使用浏览器API在不同网站之间提供持久购物车的任何和所有类型的通信、请求、呼叫、响应等。在一些情况下，浏览器或运行浏览器的设备可以与服务器1713通信以存储信息、检索信息、分析数据、检索加密的支付数据或令牌化数据等等。作为该过程的一部分，服务器1713还可以直接与存储购物车商品的任何网站进行通信。支付数据、任何其他数据或通信可以在服务器1713与相应网站之间发生。可以对购物车数据进行加密或标记为一次性使用，或者以其他方式提供安全措施。本公开的该方面表示原始浏览器API的增强利用，其使得能够在导航用于购物的多个网站之间维护持久性购物车。
在另一方面，浏览器1711仅表示基于网络的服务，该服务利用API1709并且以相同的方式起作用。可以在过程的任何多个不同阶段中通过API调用传达放置在购物车中的商品数据。例如，商家网站可以设置何时通过API转移购物车信息的不同方案。一旦有人将商品放入购物车或他们单击“购买”按钮，就会传送信息。在某些情况下，不一定有“购物车”，而仅仅是在购买过程中与商品关联的数据。例如，在某人单击“Apple Pay”按钮的时间与他们提供指纹以确认购买的时间之间，可以将数据提供给API进行存储和以后访问。如果用户后来购买了该商品，因为该商品是在持久性购物车中生产的，则该服务可以向商家收取一定的费用，从而引起他们的注意。
当前，例如社交媒体上的许多广告涉及基于其他网站导航向用户的新闻源中呈现广告。用户可能会浏览烤面包机，但永远不会将其放入购物车或接近购买模式。该烤面包机的广告随后会在其新闻源上显示，这可能会导致转化。本公开的另一方面是将这样的物品添加到本文公开的购物车中。因此，如果用户搜索了一个烤面包机，但从未将其放置在购物车中，而不是随后在社交网络页面上对该烤面包机做广告，则一方面可以涉及将该烤面包机放置在他们的购物车中，这样以后他们在购物车中购买其他商品时，他们可以看到烤面包机并一键购买其他商品和烤面包机。可能还会有用户交互，以确认应该与其他物品一起购买烤面包机。可以显示选项，从购物车中删除烤面包机，或将其保存以备以后购买。因此，购物车成为一个更加动态的环境，在该环境中可以总计购买商品，从而简化了流程。在另一方面，当在烤面包机上的社交媒体网站上与之交互时，发布可以使用户不过渡到商家网站，而是过渡到他们的购物车，其中包含该商品以及来自多网站购物车的其他商品。换句话说，广告或发布上的可选对象可能导致过渡到多网站购物车，以包括广告商品以及用户放置在购物车中的其他商品。
另一个方面涉及汇总帐户。例如，有些夫妻共享amazon.com帐户，这样在购买历史中就可以看到任何一个人进行的购买。如果将物品存储在购物车中，则每个人都可以看到另一个人存储的物品。在当前情况下可以应用的另一个原理是基于任何数量的因素来组合购物车。例如，在进行本公开之前，如果丈夫在商家网站1上购物，将其放置在购物车中，而妻子在商家网站2上购物，并将第二个商品放置在购物车中，则没有将这两个商品组合成持久购物车的机制。因此，无论是通过链接到计算机或帐户，还是基于所使用的支付帐户，还是基于任何其他数量的因素(例如用户偏好)，个人都可以将其单独的购物车商品组合为一个汇总的购物车。因此，当链接的用户跨多个网站购物和放置商品时，他们都将能够查看汇总的购物车并可以购买这些商品。此外，用户可能具有不同的权限，例如孩子可以添加商品，但只有父母可以购买。
图17J示出图17I中公开的系统的方法方面。该方法包括：通过浏览器购物车API或第一设备从第一网站接收第一购物车信息包(1715)，通过浏览器API或第二设备从第二网站接收第二购物车信息包(1717)。该方法包括，在用户请求查看购物车时，通过浏览器API将第一购物车信息包和第二购物车信息包传递到网站(如果用户正在浏览网站)或浏览器界面(如果用户在其浏览器上请求购物车)(1719)，并接收购买购物车中的物品的愿望的指示(1721)。购物车信息包可以包括从相应网站识别购物车中的商品所必需的信息、网站的标识和/或用户选择的任何其他参数的标识，例如该商品的送货地址、与该物品关联的支付帐户、是否是礼物、是否应该包装礼物、运输说明等。可以通过API包含和传达的其他商品可以是视频、图像、评论、比较、评论和/或指向任何此类信息的链接。提供图像、视频或其他品牌资料的必要协议可以包含在修改后的浏览器API中，该API提供了持久的购物车。当用户在任何相应网站上导航时，用户可以做出这样的选择和决定，并且该信息是购物车信息包的一部分，可以通过浏览器API传达给浏览器以进行存储和以后的检索。也可以使用不同的设备通过不同的方式访问不同的网站，并且可以将来自每个网站的商品分别包含在购物车中，以便从一个或多个网站进行单个购买多个商品的过程。
该概念还涵盖确定用户是希望本地购物车视图还是多网站购物车视图。通过使用第一设备，用户可以在将多个物品放入本地网站购物车中的网站上。选项或对象可以作为查看本地购物车的一部分显示，以添加存储在浏览器API购物车中的其他商品。这些选项可以根据用户习惯、包含在本地购物车中的商品成本(与包含浏览器商品的总成本相比)、社交媒体数据等来动态变化。当用户继续查看购物车时，本地网站可以通过API发起调用(对浏览器或基于网络的实体)，以确定其他商品是否在等待或存储在浏览器购物车中。如果是这样，则网站可以向购物车呈现将“添加浏览器商品”之类的可选对象，以使用户能够一起购买所有商品。也可以提供有关商品的简要信息。例如，如果用户的浏览器购物车中有烤面包机和牙刷，则商家可以提供一个对象，要求用户“将您的烤面包机和牙刷添加到该购物车中”，或者可以修改“购买”按钮以指示在本地网站上购买商品也可以导致处理其他浏览器购物车商品的购买。在这种情况下，可以显示两个购买按钮，一个用于仅购买本地网站商品，另一个用于一键式购买本地网站以及浏览器存储的商品。可以通过API的支付请求类型进行购买，也可以使用与搜索实体或其他实体一起存储的与支付相关的信息通过搜索实体进行管理。
一方面，用户可以通过浏览器API或网络服务从浏览器检索购物车。由于用户将支付信息存储在浏览器中或可以通过浏览器访问，因此浏览器可以包括一个选项，可以通过交互按钮或下拉菜单查看其购物车。仅当购物车中有物品提醒用户他们已经存储了物品时，才可以显示动态对象。换句话说，在浏览器的顶部界面上，仅当购物车中有物品时，才可以显示“查看购物车”选项。当用户单击对象时，可以向购物车显示所有可用选项，用于选择送货地址、支付帐户等。图17K示出基于浏览器的持久性购物车界面1721。由于浏览器可以访问支付信息，因此用户可以从浏览器进行购买。还可以通过社交媒体发布或菜单或用户导航或花费时间的任何位置来提供对购物车的访问。例如，如果用户在购物车中有商品，则可以通过API将这些信息传递到社交媒体网络(例如Facebook)，并且可以在用户的新闻源上生成发布，该发布提供一个对象，用户可以与之交互以访问其购物车以进行最终购买。这样的对象可以呈现在任何社交媒体网站上，并可以根据用户与该网站的交互方式以及任何辅助服务(如Facebook Messenger、短信等)进行配置。可以将触发器合并到该过程中，以便在某些情况下提供此类发布或通知，例如商品相对于即将到来的生日已经在购物车中的时间长度，或可用于触发向用户发出此类通知的因素的任何其他组合。口语对话系统也可以使用。
从任何相应网站到浏览器的传输时间也可以是动态的。例如，如果网站1的用户将几个商品放在购物车中，然后简单地购买这些商品，则可能不需要通过浏览器API将信息包传达给这些商品的浏览器。但是，如果用户在购物车中放置了几件商品，但随后放弃了购物车或未完成购买，并且从网站过渡，则可以传达信息包，以便将这些商品保存在通用购物车中。可能会实施用户首选项，以防止这种情况自动发生或需要进行交互以确认数据包的传输。一方面，该方法即使在通过浏览器支付请求API即可使用的一两次点击购买选项的情况下，也可以在某种程度上解决废弃购物车的问题。这种方法增强了浏览器API或网络服务(例如搜索实体)的使用，以维持更持久的购物车体验，从而使废弃的购物车可能不会被完全废弃，但是用户可以稍后在具有简化购买过程的购物车中再次查看带有这些商品的购物车，这可以增加用户在第二次或第三次购物时购买商品的可能性。本公开还包括用于用户管理浏览器持久性购物车的任何其他对象或操纵机会。例如，用户可以与之交互的任何呈现对象可以从购物车中删除商品，将商品添加到购物车，在特定时间段内维护购物车的商品，在一段时间后放置购物车的商品时间，例如两个星期，依此类推。
图17K示出持久性购物车中的各种物品。来自site1.com的烤面包机显示为1723，带有来自site2.com1725的遥控车和来自site3.com1727的毛巾。这些网站也可以通过不同的设备访问。还显示了“继续购物”对象1729，它是立即支付按钮1731。同样，该方法的优点在于，通过立即支付进入操作1731，系统将执行(1)使用Visa卡向site1.com进行支付(例如，通过发送令牌或必要的支付信息，以及通过浏览器API向site1.com发送其他信息)，(2)使用Master Card向site2.com进行遥控车支付，以及(3)使用Apple的支付网站site3.com支付毛巾费用。当然，可以显示所有购买的总金额，以及用于删除购买、更改商品数量等的其他选项。在进行此类单独操作的地方，浏览器购物车API可以与相应网站进行通信，以便根据商品的数量或更改送货地址或送货说明来更新收取的总金额。因此，界面1721可以包括任何这样的对象，以使得用户能够对每个单独的订单进行适当的改变和调整，此时，当用户支付时，可以实现所有各种支付机制。通常，商家网站通过浏览器API发起对支付数据的调用。在通过购物车模型进行的以后购买中，浏览器可以发起对商家网站的呼叫，通知他们用户已经购买了他们的物品之一。该呼叫可以包括识别信息，以参考用户对该网站上的物品的较早搜索，并通过API发起必要的通信，以传输和处理支付数据。一方面，单独的本地或基于Internet的服务可以从用户处提供一个统一的支付，然后该服务可以基于有关每次购买的信息向每个单独的卖方或商家支付。
在另一方面，用户可以将第一烤面包机1723从网站1放置在永久性购物车1721中，然后找到与网站2不同的烤面包机。放置在购物车中的两个烤面包机都可以使系统识别出相似的物品已经被放置在购物车中，并且用户可能希望进行比较分析。在这方面，当用户用两个烤面包机取回持久性购物车时，购物车可能会在确切的两个商品之间显示一些可比较的信息。这是一个非常容易提供比较的位置，因为在与用户互动的这种状态下，用户可以简单地选择其中一项，然后从购物车中删除未选中的项，然后继续进行购买过程。此外，从持久性浏览器购物车中，可以为每个“网站”上的“继续购物”选项提供链接。此过程可以消除并简化跨多个网站的购物体验。
服务还可以提供对购物车中各种商品的分析，并相应地提供建议或升级。例如，如果用户从一个网站购买板块，从另一个网站购买眼镜，或者从一个网站购买西装，从另一个网站购买领带，则系统可以在此协调的购物车中分析商品，并为替代商品或可能更好地相互匹配、升级、替代颜色等的商品提供建议和广告。
浏览器还可以存储所购买商品的历史记录，以供以后检索和处理，例如选择退回商品或跟踪其运输进度。就这一点而言，在购买之后，该信息可以通过浏览器API进行通信并被存储以供以后从浏览器中检索，或者经由本文中公开的网站、社交媒体界面、应用程序等上的对象进行检索。
另一方面包括将购物车与除放置在购物车中的商品之外的其他商品搜索集成。例如，如果用户通过基于语音的设备导航到台式计算机或target.com上的Amazon.com并在烤面包机上查看或订购，但没有将烤面包机放在购物车中，而只是在一定程度上查看有关可以购买的烤面包机的数据(可能包括将其放入购物车中)，那么当前存在的一种流程是在带有该烤面包机的新闻源中展示亚马逊广告。广告使用户有另一个购买物品的机会。在当前场景中，对该概念进行了扩展，以使任何与商品的用户交互(无论是物理的、虚拟的在线的、在虚拟现实环境中的交互等等)都可以使系统生成该商品的购物车条目。服务可以检索有关用户购买或查看过哪些商品的信息，并生成用户想要购买的最有可能的商品。然后，当用户查看其多网站购物车时，可以列出该商品并轻松单击一下，轻松地单独购买或与其他商品一起购买。由于用户从未将此类物品放入购物车，因此可以显示其他交互，例如用户可以单击以将物品正式放置在购物车中进行购买的可选对象。在另一方面，可以以预先配置的状态将物品放置在购物车中，使得点击购物车内的购买按钮将导致对该物品以及购物车中的任何其他物品进行购买。可以为何时将此类物品放入购物车设置阈值。例如，可以利用机器学习来确定参数，例如用户搜索和研究商品的深度、用户在商品上花费的时间、用户阅读的评论数量、用户是否将商品与其他类似商品进行了比较等等。在这种情况下，一旦达到该阈值，系统就会为带有该商品的用户的购物车创建一个条目。在另一种情况下，如果搜索到两个相似的商品，则系统可以在购物车中向两个商品展示比较数据，从而使用户可以查看比较信息，单击所选商品，这样，下一次点击或下一次互动就可以从字面上看是所选商品与购物车中其他商品的购买。
本文公开的购物车可以集成在网站内，从而无需登录或点击扩展即可使用这些功能。购物车扩展内无需单独注册支付数据或地址。通用购物车可以在浏览器界面上没有可选对象的情况下运行，以激活购物车。网站可以向搜索引擎注册，以便能够协调通用购物车模型，从而可以跨不同设备以及跨不同商家和不同设备将商品放置在通用购物车中。购物可以从助理应用程序中的设备，通过基于语音的设备、通过浏览器、通过基于车辆的设备、手表等发生。通用购物车可以跨越与商家互动的各种方式，并且可以通过基于网络的系统进行协调。然后，搜索实体可以使用存储的支付数据为同一通用购物车中的一个或多个商家处理多个商品的支付。这可以通过本文公开的浏览器API或由搜索实体管理的API或其他技术来完成。可以通过第一设备上的网络搜索将商品放置在购物车中，然后通过第二设备通过语音对话框将另一商品放置在购物车中。用户可以通过使用浏览器API的统一购买过程或基于搜索实体的过程(其中将与搜索实体一起存储的数据应用于购买多个物品)来针对这两项进行一次结帐。可以给每个商家支付，然后运送相应的物品。搜索实体可以在购买时向商家收取使用通用购物车的费用。
与通用购物车有关的其他概念包括从购物车向网站提供数据(即购物车中的物品、人口统计数据)以改善网站搜索或展示效果，这可以修改用户的购物体验。例如，如果site2知道通用购物车中有来自site1的烤面包机，则可以修改site2处用户的导航结果或搜索结果或显示的商品，以改善用户体验。接下来，我们再次指出，API的使用可以双向使用。例如，用户购买购物车中的商品，一包信息通过API与对象、令牌、支付信息、地址信息、注册信息、登录信息、商品信息、大小数据等中的一个或多个一起传递到网站，以从浏览器API发起整个交易。如果您离开网站但将商品放入购物车，则会发生这种情况。
一种方法可以包括基于用户导航来识别可以从第一网站购买的第一物品，但是不购买第一物品。这可以在网站的常规标准导航内完成。该方法包括：接收与第一项相关联的数据的转变(可以通过API到达浏览器、扩展或网络服务)。例如，W3C浏览器API包含“DisplayItems”成员和/或“additionalDisplayItems”，它们是PaymentDetailsBase词典的一部分，PaymentDetailsBase词典是一种可选功能，用于提供商品明细或税金和运费明细。可以修改浏览器API，以便该网站可以在导航过程中随时将商品详细信息传递给购物车，以供以后检索。传送有关商品的数据的触发可以在初始搜索到完成购买之间的任何数量的导航状态或阶段。例如，如果用户显示了浏览器API接口，但是他们没有完成交易，则网站可以将商品数据传递给浏览器进行存储和以后的检索。然后，假设用户通过同一设备或完全独立的设备导航至第二网站，该设备也可以包括具有基于语音或其他类型用户界面的设备。该方法包括基于用户导航来识别可以从第二网站购买的第二物品，该第二物品被放置在购物车中，将关于第一物品的信息传输到购物车，通过用户与购买对象的购买对象的交互来接收确认，以购买第一物品和第二物品，将购买信息传达给第一网站以处理物品的购买，并将支付数据传达给第二网站以处理第二物品的购买。所述通信可以包括浏览器API与用于在第一商品的第一网站处发起购买的信息之间的通信。例如，浏览器API可以将数据传输到第一网站，以将第一网站置于一种状态，就好像用户已导航到购买第一件商品并单击“购买”按钮一样。通常，该交互将导致第一网站通过浏览器API向浏览器发起支付请求的支付请求。但是，在上述情况下，用户离开了第一网站，有关第一项的信息保留在购物车中。因此，为了便于购买第一件商品，该改进包括扩展浏览器API的使用，以通过将信息通过API发送到第一网站来启动商品的购买。在这方面，第一网站随后将向浏览器API发起支付请求，以检索支付数据、地址数据等，并以正常方式完成商品的购买和交付。为了实现此目的，可能需要交换其他通信。发送到第一个网站的信息包可能诱使用户认为用户已导航到第一个商品并单击“购买”按钮。该信息可以使商家网站向浏览器发起支付请求API请求，以请求支付信息来处理商品的支付。当用户打开购物车时，可以发送信息包。这样，从用户的角度来看，当用户单击“购买”按钮时，具有来自第一网站的第一项和来自第二网站的第二项，这两个网站基本上都处于一种状态，就像用户已经导航到使用购买按钮来处理相应商品的位置一样，用于处理购买。但是，购物车的“购买”按钮可以链接到这两个不同的状态，以便当用户确实按下“购买”按钮时，两个网站都通过浏览器API发送支付请求，以基于单击来处理支付。购物车的插件可以消除歧义或提供处理支付所需的任何其他交互信息。例如，如果一个网站要求使用Apple Pay，则购物车可以简单地询问用户的支付指纹，而不必识别它是针对某一特定商品的购买。
在另一方面，与购物车配合的浏览器可以发送数据包，该数据包包括用于用户的支付能力、支付令牌、支付数据、地址数据、商品数据、价格等，使得第一网站可以最终确定购买和交付商品。这种方法代表了浏览器API概念功能的扩展。在一个方面，基于用户在第一网站的初始导航，缺乏对第一网站的物品的购买，第一网站可以生成交易ID，该交易ID通过API传输到购物车管理系统(可以是浏览器或基于第三方网络的服务的插件或扩展)。以后可以将该交易ID与支付数据、地址数据和任何其他数据(例如一次性令牌)一起用于第一个网站，以便记住该物品并为用户处理该物品的购买。
其他方面包括跟踪商品的电话位置，例如坐在Staples的椅子上，一旦与表明有兴趣的商品进行阈值交互，就在持久购物车中提供有关商品的详细信息。当您上网时，一旦达到该阈值(例如阅读商品评论或在商品页面上花费一定的时间)，该信息就可以转发到包含商品ID、商家ID、时间、个人信息、成本、折扣等信息，即使用户位于其他网站，也可以将其放入购物车。
可以用于管理放置在通用购物车内的多个物品的本文公开的网络设备可以在用户使用的各种设备上协调通用购物车。例如，搜索实体可以从移动设备上的第一浏览器搜索中识别放入购物车中的第一商品，然后使用第二设备上的语音指令识别用户，以识别要放入购物车中的第二商品。然后，用户可以在任一设备上或任何时候购买两种商品。该系统可以通过语音识别或通过其他方式来识别用户，以将物品连接为同一用户购物车的一部分。基于语音的设备可以已经与特定的支付帐户相关联，或者可以基于语音标识调整为不同的支付帐户。例如，在家中的用户可以将第一款商品从台式计算机放到通用购物车中，然后去朋友家。通过社交网络数据或语音/语音识别，用户可以与朋友家中的基于语音的设备交谈，后者可以通过询问“这是玛丽·史密斯吗？”来确认自己的身份，此时用户可以通过语音命令将其他商品添加到购物车中，并购买所有商品。社交媒体数据或偏好设置可以使玛丽潜在地使用其朋友的基于语音的设备进行购买。在这些情况下，也可以提供单独的生物识别确认，以确认购买的是正确的人。在一个示例中，当玛丽去朋友家时，基于语音的设备或其他设备可以通过手机识别她。也可以根据玛丽的位置提供地理位置数据。根据此数据，可以将通过搜索实体的基于语音的设备配置为可能期望玛丽通过该基于语音的设备在朋友家中发出购物请求。语音识别模型、说话者识别模型或可能需要发生的任何其他与语音相关的预配置可以在网络上启动或转移到基于本地语音的设备，或两者都进行。因此，当玛丽对基于语音的设备说“请在我的购物车中添加纸巾”时，系统可以识别玛丽的语音，使用量身定制的语音识别模型解释语音，然后回答“好，玛丽，纸巾在您的购物车中，昨天添加了盐和胡椒罐，您要结帐吗？”。然后，她可以通过朋友基于语音的界面设备对购物车中的所有商品进行一次购买交易。为了确认购买，系统可能会要求Mary提供可以通过网络系统进行协调的指纹认证。它也可以类似于NFC支付体验。基于语音的设备可能具有NFC功能，并且要确认购买，Mary只需将手机移至基于语音的设备附近并提供指纹即可完成所有商品的购买。当使用Apple Pay或Google Pay时，提供给基于语音的设备的数据将类似于零售商在NFC设备上提供的数据。用户会将其设备移至基于语音的设备附近，然后会弹出支付界面，要求进行指纹识别或面部识别。通过这种方式，用户可以使用相同的简单界面，在朋友的家中或与家位置不同的设备上轻松完成购物或开始购物。在基于语音的设备和系统之间，可以进行往返于网络系统(例如管理支付方法的搜索实体)的必要通信，以使Mary能够订购商品，将其包含在购物车中并结账。
如果Mary没带手机，则启用语音的设备上可能也有指纹读取器，Mary可以用来在设备上“注册”。也可以使用面部识别或任何其他机制。一旦在设备上被识别，就可以成为通用购物车所使用的设备。可以出于类似目的将设备放置在餐馆、商店或任何位置。如果有多个人在朋友家中，则可以在该位置将多个配置文件添加到启用语音的设备中，以便该组中的任何人都可以与该设备交谈，并使其适应其配置文件、通用购物车等，即使人们不住在那个地方。基于该人在该位置的知识，该设备也可能没有任何预先配置的数据。当用户与基于语音的设备通话时，系统可能只是通过用户的语音来识别用户。
本文公开的概念也可以用于实体购物中心。人们可以做两件事。在一种情况下，用户只需购物，然后将商品放入他们的实体购物袋中即可。用户不会在各个商店结帐，而只是在商店之间结帐。所有商店的一次结帐可用于所有物品以及一次支付。结帐可以通过条形码阅读器或商品的其他标识符在出口处或在自己的电话上进行，这些标识符可以将它们组合在一起，从而使单击即可处理所有支付。
同样，用户可以去实体商店并仔细购买物品。他们可以在手机上安装一个读码器，并在查看自己喜欢的商品时扫描它们，或者可以通过近场通信或其他一些无线协议自动识别该代码。然后，用户可能不会真正随身携带物品。他们去了所有商店并查看了4家不同商店中的4种商品后，便可以将其购物车拉到移动设备上，并查看放置在购物车中的所有商品。然后，他们可以一键购买，并为各个商店处理所有支付。这些物品可以在他们离开商店时在某个出口处带给他们，这样，通知购物中心内每个商店的跑步者可以将购买的物品拿到购物中心东出口的约翰手中，也可以在家中将其运送给他们，以便用户可以离开。该系统还可以跟踪买家的移动设备的移动，并在商场中找到它们。跑步者可以使用代码来确认正确的用户正在接收购买的商品。购物车可以提供选项或代码或其他数据。可以向用户提供时间期望、他们需要等待多长时间。也许用户可以在他们开始走到汽车上并通过跟踪移动设备(可以提供有关他们进入哪个入口的地理围栏信息)后在手机上购买这些物品，这可以提供有关他们进入哪个入口的地理围栏信息，他们所购买的物品可以在他们到达那里时在出口处等待。跑步者可以根据手机的位置信息或出口处的位置，将物品交付给已识别的储物柜，以便用户将物品带回家。这样可以改善用户在购物中心走动时不必随身携带所购买的所有物品的体验。可以提供所有商品的预计交付时间。用户可以在他们的购物车上单击“购买”，系统可以预测所有商品将交付给用户的10分钟时间。这可能还会增加人们购买的商品数量。从单个购物车中，可以使用浏览器支付请求API，并且插件可以管理对不同商店的所有支付。用户还可以在每个商店使用Apple Pay或其他支付机制，系统可以简单地将购买的商品组合到“购物车”中，这样，当用户离开时，他们可以指示他们要离开并且需要送货。然后可以收集商品并将其交付给用户。一个或多个跑步者可以通过一个应用程序接收有关从哪些商店获得的商品的说明、购买者的身份证明，并且可以轻松地收集所有物品并将其带给购买者。
在另一方面，该系统可以存储已经在各种网站上浏览的各种商品。然后，当用户将商品输入购物车时，可以显示选项，该选项将用来自其他网站的一个或多个其他商品填充购物车。系统可以策略性地显示此选项。例如，如果用户在不同网站上仔细阅读了烤面包机中的牙刷，但现在在购物车中放入了不同的烤面包机，则系统可能只会询问他们是否希望看到另一个烤面包机并提供类似信息。如果用户最近浏览过一定数量的商品，则系统可能会询问他们是否要查看最近添加到购物车中的三个商品、还是他们花费最多时间进行检查或花费最多的商品、或价格昂贵的商品、或用户可能需要的其他任何特征。这种方法允许用户控制一键购买商品组中将哪些商品添加到其通用购物车中。还可以利用人工智能和/或机器学习方法来针对用户的购买习惯来表征用户的购物和导航历史，从而可以仅用具有用户实际购买的阈值概率的那些物品来填充购物车。如上所述，购物车还可以涉及多个用户。因此，可以协调按家庭、朋友、支付帐户、浏览器使用情况或任何其他分组进行的多个用户分组，例如，如果父母打开了购物车，则可以将孩子查看的商品添加到购物车中，以决定是否购买。这样的购物车也可以是在任何相应网站继续购物的起点。例如，如果购物车包括来自三个不同网站的三个商品，而来自第二网站的第二个商品是一个烤面包机，但不完全是正确的烤面包机，则可以显示一个可选对象以继续在该网站上购买类似商品。该对象可以配置为将用户转换为具有与购物车中的商品相关联的搜索结果的第二个网站中的深层链接，但该链接显示了可比较的商品，供您继续阅读。在这种情况下，可以维持持久状态，以便当用户过渡到第二个网站进行继续购物时，如果用户选择一个单独的烤面包机，则用户可以使用单独的烤面包机代替最初的烤面包机，再回到购物车，再次单击即可购买一组物品。
本文公开的方法的一个好处是，由于浏览器API用于支付信息，因此用户无需在购物车插件或服务中注册其支付信息或地址信息。但是，在用户使用购物车插件或扩展程序注册支付信息、地址信息或任何其他信息的地方，也可以应用某些其他功能。
另一个方面适用于利用API以不同的方式填充跨网站购物车。它涉及用户如何使商品信息通过API或其他机制从网站传输到浏览器或其他位置，以进行存储、汇总、演示和支付/交付处理。网站可以在网站上添加程序，以监视用户在网站上的搜索和导航，以确定要向API发送哪些商品。例如，如果用户花20秒钟查看烤面包机、阅读评论、查看图片等，则系统可以确定是否有足够的兴趣通过API发送商品数据，以将其存储在浏览器或其他地方。例如，API可以具有类似于“发送商品数据”(商品、UPC、大小、时间、颜色、大小、价格、税金、令牌、等级等)的语法。此数据和任何其他数据都可以通过API传输，并被存储以供以后购买时使用。用于发送数据的触发器可以是自动的或手动的(例如，用户单击对象以发送数据)。当用户导航到网站时，网站可以发送API请求，以确定该API是否可用于商品信息。如果是这样，则网站可以利用API发送用户搜索的商品的商品数据。如果用户以后在该网站上购买商品，则可以从浏览器商品存储中删除该商品。数据可以包括对用户期望以后购买商品的可能性的评估。所有这些信息都通过API传输到存储位置。
然后，用户也可以导航到其他网站并浏览商品。达到阈值后，可以将多个商品传输到浏览器进行存储。与商品相关的数据也可以发送，例如用户的购买可能性。随着用户上网，商品将被收集并通过API进行存储。用户可以在导致商品数据发送的情况下设置参数，例如查看时间超过60秒，或在家人生日前2周查看过的所有商品，或价格超过10美元的所有商品，或在导航的某个阶段，例如将商品放置在网站购物车中(并且还应将其传输到浏览器购物车中)。然后，当用户到达使用浏览器API界面进行购买的要点时(例如，在site3.com上)，用户可以浏览不同网站上的商品，系统将或可以在“购买”按钮界面中包含他们搜索的第一个网站和第二个网站中的商品。参见图17K。重要的一点是，这里的接口是浏览器支付请求API接口，而不是常规的支付接口(虽然可以)，但不是必需的。该界面还可以包括其他选项。例如，用户正在site3.com上从该网站购买商品，支付界面可以包括一个可选选项，以“添加浏览器购物车中的其他2个商品”或“添加今天搜索到的商品”或“添加本周搜索到的商品”。然后，用户可以将那些商品添加到购物车，一键即可管理每个商品的单独购买和交付。在搜索或支付方法的任何阶段都可以收集不同的收货地址、问候语或任何其他数据的歧义。可以包括下拉菜单，以便当用户处于购买模式时，可以将各种商品收集在一起以作为一个聚合组进行支付。购物车也可以在浏览器中直接查看，而与任何网站无关。可以在汇总的商品组中提供比较、折扣、激励购买的选项。浏览器或其他服务管理对单个网站的所有支付。可以调整支付请求API的语法以实现本文公开的功能。
好处是可以修改浏览器支付请求API界面，以便当用户在任何网站上进行购买并且访问浏览器支付请求API进行购买时(自动或手动)，购物车中的其他商品都可以添加到界面中，以便用户可以单击一次或一系列点击来购买多个商品，以完成支付方法。可以满足转移阈值。网站可以提供加号按钮，购买按钮或其他对象，当达到用户可以单击添加到浏览器购物车的阈值时，就会动态显示这些对象。然后，用户可以继续进行下一个商品。从网站的角度(监视导航，确定将商品数据传输到浏览器购物车API以及从另一个网站的浏览器支付请求API界面接收有关商品购买的数据)这一概念都适用。当然，即使用户从未在第一个网站上导航到该商品并在第一个网站上指示他或她想要在该网站上进行购买，也当然可以这样做。在支付界面上显示的一组商品的一部分中，浏览器可以管理返回到第一个网站的购买通知，并可以通过浏览器购物车API和/或有关商品、支付帐户、一次性使用令牌、地址传递信息、商品标识等的浏览器支付请求API数据。数据包可以与所有数据一起传输到第一网站，以使第一网站能够标识先前搜索并传达给浏览器的商品，支付令牌或其他支付数据，地址信息等，以便该网站可以处理支付并交付商品。该网站还可以根据商品浏览器API是否可用进行调整。例如，如果可用，则可以显示按钮以将正在查看的商品添加到购物车。该网站还可以包括Messenger应用程序、通信应用程序、视频应用程序等。因此，在展示商品的任何情况下，网站或应用程序都将能够将数据传输到商品API，以存储在用户的购物车中。
在另一方面，随着用户导航到网站，网站可以访问与浏览器或基于网络的服务相关联的用户信息API。浏览器或任何其他服务可以存储以下信息：用户帽子尺寸、衬衫尺寸、裤子尺寸、显示尺寸、颜色首选项、样式首选项、购买历史记录、社交媒体信息(例如朋友和家人信息)、尺寸、首选项等。当用户开始搜索时，网站可以通过API接收此类数据。基于此数据，网站可以调整其向导航对象和界面用户的显示方式。例如，如果API通知网站用户是中型，则可能不需要向用户显示在S、M或L衬衫之间进行选择的选项。可以在用户搜索网站时为他们量身定制颜色或样式首选项。一旦用户导航到相应的网站，该网站就可以调用浏览器以询问个性化参数，并且浏览器可以使用该用户和/或网站可以用来定制浏览体验的其他用户的个人数据进行响应。用户可以设置参数，例如网站上的按钮、菜单、商品的自动传输等。
确实，在用户冲浪时，可以显示一个界面来询问用户感兴趣的内容。自然语言或文本界面可以从用户那里接收数据，例如“我在为我妻子的生日购物”。在系统知道用户的社交媒体数据(包括家人/朋友的大小)后，用户可以更有效地购物，例如为妻子的生日买一件外套。与妻子相关的颜色和款式选择可以改善提出的选择。可以预先配置尺寸信息，以便用户无需选择尺寸。在用户导航时，任何参数、社交媒体数据、大小、首选项、样式、购买历史记录等都可以用于更改网站的导航功能。不再需要选择衬衫、裤子或鞋子等的尺寸。可以通过API将此类数据传输到网站，以便为该用户的导航重新配置网站。该网站可以接收有关用户的其他数据，这些数据可以帮助更有效地展示商品/服务。如果该网站知道用户正在为母亲购物，那肯定可以帮助商品更集中地展示。
此外，搜索到的商品可以自动或手动分类，例如生日、圣诞节或母亲节。可以根据社交媒体数据、商品特征或菜单选择在网站上显示分类选项。因此，用户可以浏览不同的网站，并将三类归为母亲的生日物品，并将两类归为自己的购买商品。当用户使用浏览器API界面购买商品时，可以选择添加母亲的生日礼物，添加个人商品或添加所有要购买的商品。这些商品可以分为玩具、厨房用品、浴室用品或办公材料。可以提供多种方法将一组分类商品添加到购物车中。购物车中的所有物品都可以基于手动或自动方式进行分组或组织。因此，您想要一起购买的物品可以更加简化。
在任何时候，消歧对话框都可以帮助集中来自用户的信息以改善导航。例如，当用户导航到某个网站时，系统可能会询问“您是在为您购物还是在为妻子的生日购物？”利用有关购物目的的一些数据，系统可以通过API将个性化信息、地址信息等发送到网站，以便网站可以为用户修改体验。例如，系统可以显示“玛丽”、“妈妈”、“南希”、“蒂姆”，而不是像“S”、“M”或“L”之类的尺寸按钮。您只需要选择兄弟Tim的尺寸即可。下拉菜单可以包括用户要购买的各种人，因此用户只需选择该人。可以将一个或多个人的所有名称、大小、首选项等发送到网站进行处理。如果系统知道蒂姆喜欢红色衬衫，则系统也可以建议买家蓝色衬衫可能不是最佳选择。
网站何时通过API传输商品数据的触发事件可以是花在商品上的时间、评论阅读、将商品放入购物车、评论商品、这些导航数据与传输到网站的数据(例如购物车中的其他商品)、有关用户的摘要信息、用户规模、颜色偏好等结合在一起。如果用户授权要发送的个性化数据，则可以向用户提供折扣。从网站的角度来看，网站接收用户导航、通过API接收用户的个性化数据、例如尺寸信息、样式首选项、购买历史记录、社交媒体数据、假日数据等，这样网站可以根据收到的数据显示界面和可选选项。这些首选项还可以驱动确定何时将商品数据传递到API以便放入其通用购物车的算法。可以根据传输到现场的数据来调整触发算法，例如，根据即将到来的生日，商品的30秒时间范围可以减少到20秒。
您也可以根据社交媒体数据传递社交网络中人员的尺寸信息。例如，如果您的朋友即将过生日，则可以传递您朋友的尺寸信息。该系统还可以标记该尺寸信息，以便您可以选择朋友的衣服尺寸，但是您不知道他们的尺寸是多少。您可以从浏览器存储中以令牌化或安全方式共享数据。
图17L示出示例方法实施方案。本公开的一个方面适用于多网站通用购物车，并且特别提出了一种解决方案，该解决方案可使用W3C实现的浏览器支付请求应用程序编程接口的修改版本。用户可以使用不同的方式和在不同的位置跨不同的设备访问多个网站。在一个方面，一种方法，系统或计算机可读存储设备从浏览器的角度进行操作。该方法包括通过与浏览器相关联的浏览器购物车应用程序编程接口接收与第一商品相关联的第一数据，该第一数据与用户使用该浏览器在第一网站上导航的用户所观看到，其中用户没有在第一网站上购买该商品(1733)。存储第一数据，使得浏览器或诸如搜索实体之类的网络服务可访问第一数据。该存储可以与浏览器一起，位于用户设备上，也可以位于由搜索实体或其他支付实体托管的网络设备上。该方法包括向用户呈现用于管理第二商品的购买的浏览器支付界面，该浏览器支付界面与浏览器支付请求应用程序编程界面相关联，其中用户的支付数据通过浏览器支付请求应用程序编程接口从浏览器传递到第二网站(1735)。作为支付请求API的一部分，向用户提供了一个界面，用户可以与之交互以实现支付。此界面增加了其他购物车商品，以使您可以通过“一键式”购买多个商品。(该界面通常需要点击几下，但比正常的支付方法要少得多，在正常的支付方法中，用户必须手动填写多个字段)。该方法进一步包括在浏览器支付界面上呈现关于第一商品的信息，并基于与浏览器支付界面的用户交互来处理第一商品和第二商品的支付(1737)。通过浏览器支付请求应用程序编程接口使用浏览器和第一网站之间的第一通信，以及通过浏览器支付请求应用程序编程接口使用浏览器和第二网站之间的第二通信，可以进行第一商品和第二商品的支付处理。不同之处在于，第二个网站已经在与浏览器通信以进行第二个商品的支付方法。但是，用户已经离开了第一网站，因此返回第一网站的通信必须识别商品，并向第一网站提供支付和/或交付数据，以“提醒”先前搜索的商品的第一网站。处理第一商品和第二商品两者的支付还可以包括通过浏览器应用程序编程接口传输数据包，该数据包使得第一网站能够处理第一商品的第一购买。数据包可以包括用于第一网站的支付数据以处理针对第一商品的支付以及与用户相关联的地址信息以用于第一网站以交付商品。该方法还可以包括：利用用于经由浏览器支付接口购买一个商品的同一组对象交互，从用户接收对第一商品和第二商品的购买的确认(1739)。换句话说，由于用户已经在浏览器界面中用于处理第二种商品的支付，因此该方法可以包括利用相同的“一键式”加上一个指纹识别或CVC代码输入，或者采用任何少量步骤购买第二个商品，也要处理第一个商品的支付。如上所述，通用购物车可以与浏览器API分开，也可以完全由网络实体或搜索实体进行管理。API和网络实体之间也可能存在协调，以管理购物车和购买。
处理第一商品和第二商品的支付可以包括通过浏览器支付请求应用程序编程接口将第一信息传达给第一网站，以完成从第一网站的第一商品的购买和交付；以及通过浏览器支付请求应用程序编程接口将第二信息传达给第二网站，以完成从第二网站购买和交付第二商品。接收与使用浏览器在第一网站上导航的用户所观看的与第一商品相关联的第一数据还可以包括：基于与第一商品相关联的阈值用户交互来接收第一数据。例如，用户可能需要将第一个商品放入购物车，或单击按钮，或查看商品一段时间，以表明可能有购买兴趣。在另一方面，搜索实体可以存储用于购买的支付凭证和地址和/或其他信息，并管理用于通用购物车的支付方法。
从第一网站的观点来看，该方法在图17M中示出，并且可以包括从第一个网站开始并通过与浏览器关联的浏览器购物车应用程序编程接口传输与使用浏览器在第一网站上导航的用户查看的第一商品相关的第一数据，其中用户未在第一网站上购买商品，其中，浏览器可以管理存储的第一数据，以便浏览器可以访问它(1741)，并且在用户从第一网站导航到第二网站之后，从浏览器支付请求应用程序编程接口接收数据包，以处理第一商品的支付，其中，数据包标识第一商品，并且可以包括与用户相关联的支付数据，用于处理第一商品的支付，其中，用户通过与浏览器支付界面的交互来确认对第一商品的支付，该交互是在使用浏览器应用程序编程界面管理第二网站上第二商品的购买时呈现的(1743)。
在第一网站处接收的数据包还可以包括用于用户的第一商品的交付的地址信息。该方法可以包括第一网站和第二网站之间需要进行的任何通信以标识支付方式、交流购物车和浏览器的支付功能、商品数据、与用户在第一个网站上的搜索相关的会话数据、用户数据、支付数据、交付数据、尺寸数据、或与处理第一商品的支付或将第一商品和第二商品聚合到与浏览器支付请求API关联的浏览器支付界面相关的任何其他数据，以便可以通过单个购物车购买来自不同网站的多个商品。取决于所覆盖的实施方案，从第一网站或第二网站的观点来看，本文引用的用于处理购物车的任何概念都可以适用。
在另一方面，用户可以在浏览器购物车中具有多个物品，并决定他们想要购买物品并使其交付。但是，用户可能不需要导航到网站上的商品并在网站上购买商品以启动浏览器API支付界面。在这种情况下，系统可以在浏览器上提供通知，或者可以呈现动态对象或可以呈现菜单项，这使得能够从浏览器向用户呈现具有购物车项的支付界面。可以向用户显示与他们的浏览器类型、支付请求API类型或用户帐户类型相关联的动态修改的购买按钮。然后，用户可以通过与所需对象的交互来购买这些物品。在这种情况下，由于用户不在任何网站上，因此，例如，如果购物车中有来自第一网站的第一项和来自第二网站的第二项，则浏览器API随后将商品ID、支付细节、地址详细信息等发送到各个网站以处理商品的支付和交付，即使这些网站未根据标准支付请求API发起支付请求。在使用诸如ApplePay之类的支付服务的情况下，可以对这些服务进行适当的处理，以便可以通过API接收各个网站处理购买(卡类型、收到的令牌、购买确认书等)所需的标准数据，并可以实现商品的交付。无论用户在哪里冲浪，购物车都将可用，例如在他们的社交媒体网站(Facebook可以有一个可选对象，指示购物车中有商品)、短信应用程序、电子邮件应用程序、日历应用程序等。
在另一个方面，当一个网站使用Apple Pay、另一个网站要求VISA、第三个网站使用Android Pay时，带有该网站中三个商品的用户购物车可能会利用一些不同的交互方式(例如指纹与CVC代码)来完成支付。在此类交互存在差异的情况下，该界面可以汇总需求，以便一键单击一个对象可以指示“使用Apple Pay和AndroidPay进行支付”或“使用ApplePay和VISA进行支付”。该接口然后可以请求指纹，然后请求CVC代码。各种交互的汇总和组织可以简化在具有不同支付机制的一个购物车中进行购买的过程。
另一个方面涉及如何在不同版本的API之间进行协调。例如，如果用户正在使用使用专有浏览器API的Apple Pay进行购物，则系统可以访问有关与行业标准W3C浏览器支付请求API关联存储的购物车商品的数据。无论使用通用协议还是使用不同API之间的某些参数转换，一种方法是显示一个购物车，其中包含一个购买按钮或一组交互，这些交互或聚合在一起，以便在购物车中购买多个商品，即使汇总的购物车跨越了两个不同版本的浏览器API或两个版本的浏览器购物车API或两个不同的购买接口。在一个示例中，假设用户在Apple Pay界面中，然后单击“购买”按钮并使用三个商品的指纹来确认购买，其中一个商品是Apple Pay商品，其中两个商品是在不同的上下文中合并的，但这将需要Android Pay支付一项商品，而VISA支付另一项商品，而每个商品均来自不同的网站。本地设备和/或服务器可以协调Apple Pay流程(在Safari中)和W3C浏览器API(例如，在Chrome或Mozilla或Microsoft Edge上)之间的信息通信，以便可以使用购买确认信息以正常方式处理ApplePay购买，但随后向W3CAPI提供指令以执行与各个网站进行通信的过程，从而实现通过Android Pay购买第二件商品并协调通过VISA购买第三件商品。因此，此方面涵盖了在两个不同的API(浏览器)之间交换的所有协调和信息，以使包含跨多个网站的多个商品的单个购物车和浏览器支付请求API的多个版本的单个购物车一起用于购买多个商品，可以在后台完成从多个网站的购买。此方面涵盖浏览器之间以及一个或多个浏览器、不同网站、服务和/或支付处理器之间的所有通信、响应、确认、与安全相关的通信、指令等，以作为浏览器API支付界面的一部分实现了购物车中物品的一键式购买，但其中购物车中包含的商品跨越了浏览器支付API的不同版本或不同的浏览器，因此可以基于多个商品的单一支付流程来进行不同网站的通知和支付处理。因此，Safari可以管理支付界面，但可以与Chrome进行通信以接收购物车中的物品，然后将购物车中相应的Chrome物品的购买通知Chrome。然后，Safari可以管理从网站购买商品的支付，而Chrome可以管理从网站购买商品的支付。此外，购物车可以与其他非浏览器API接口集成。例如，PayPal界面或Amazon Payments界面还可以通过API购物车访问与浏览器关联存储的商品，并将这些商品合并或汇总到一键式购买体验中，这些体验不仅跨越不同的浏览器API接口，而且跨越非浏览器API接口。
多个浏览器API版本
浏览器API有不同的风格。有Apple pay和标准化的W3C浏览器API，它们使用同一API的不同版本。也可能有其他人。用户还利用设备上的不同应用进行支付，例如PayPal应用。希望使用这些浏览器API之一提供结帐过程的任何特定网站都可能需要检测哪个浏览器API可用，并因此选择适当的购买按钮以呈现为与用户进行交互的对象。如果用户使用Microsoft edge作为浏览器，则商家网站不应显示Apple pay购买按钮。因此，本文公开的概念涉及确定哪个浏览器API可用的商家网站。确定在Safari、Mozilla、Microsoft Edge、Chrome、三星、Internet等之间使用哪个浏览器的商家网站。然后，商家网站可以呈现适合用于导航网站的相应浏览器的购买按钮。如果商家网站确定用户正在使用Apple Safari浏览器浏览网站，则用户可以与之交互以表示购买意图的呈现对象可以是Apple支付按钮。当然，这可能还涉及通过API进行调用，以确定用户是否在其设备上设置了Apple pay。
商家网站还可以提供一些品牌作为界面来管理支付方法。因此，如果用户拥有Microsoft钱包，并且他们正在使用Microsoft Edge，则界面可以包括Microsoft钱包的品牌。无论如何，在商家网站确定要显示哪个购买按钮之后，在用户单击对象或与对象进行交互之后，商家网站将通过相应的浏览器API进行通信，以请求支付信息并提供与购买相关的必要数据，以便商家网站可以通过浏览器API接收以下一项或多项：支付数据、名称、地址、安全性代码、指纹识别、音频信息、视觉或面部信息等，以完成购买和交付商品。本公开的该方面主要涉及由商家网站进行的关于使用哪个浏览器API以及如何呈现用户界面的确定评估，以确保通过使用浏览器API可以提供改进的结帐流程的一部分，从而不会向用户显示不正确或不可用的选项。
浏览器API之间的差异可能是：利用商户验证程序或启用来自另一用户设备的支付数据的通信，用户正通过该设备通过浏览器访问网站。例如，Apple pay具有一个具有不同协议的浏览器API，然后是W3C支付请求API。Apple pay需要商家验证程序，并且还使用户能够通过便携式计算机或台式计算机上的Safari浏览器访问商家网站，并且，当用户通过浏览器单击网站上的Apple pay购买按钮时，Safari浏览器可以在单独的移动设备(例如通过蓝牙与笔记本电脑或台式机进行通信的iPhone)上访问支付数据。因此，使用Apple pay时。以这种方式，用户在便携式计算机或台式计算机上单击Apple pay，然后在其iPhone上提供指纹验证，该iPhone通过蓝牙链接到便携式计算机或台式计算机。当然，在第一浏览器支付请求API和第二浏览器支付请求API之间可能存在其他变化。面部识别也可以用于验证身份。
在另一方面，用户可能在MacBook上使用Mozilla，而不是Safari。用户可能已经存储了Apple Pay的支付信息。系统可以检测到用户正在使用Mozilla浏览，但是通过用户设备上的Safari浏览器，用户可以实现Apple Pay。可以提供适当的数据通信，以使用户即使使用Mozilla进行浏览也可以使用Apple Pay。例如，这将需要验证用户是否正在使用AppleiOS设备并具有Apple Pay配置。商家网站将通过Mozilla浏览器收到有关Apple Pay可用的通知。可以传送数据以确认Mozilla可以启用从Mozilla浏览器到用户设备上的Safari浏览器的通信链接，以将信息通过隧道传送到商家网站。以这种方式，Mozilla可以使Safari实例在Apple设备的后台启动，以便Mozilla可以与Safari和商家网站进行通信，以便商家网站可以显示Apple Pay按钮并且可以通过Mozilla浏览器API进行用于支付Apple Pay的相同交互。
在另一方面，一种方法包括确定用户是否正在通过第一浏览器或第二浏览器访问网站，其中第一浏览器实现第一浏览器支付请求API，第二浏览器实现第二浏览器支付请求API以产生确定。当确定指示用户正在通过第一浏览器访问网站时，该方法包括在与购买相关联的网站上呈现第一购买按钮，并接收用户与第一购买按钮的交互。该方法包括：经由第一浏览器支付请求API发送支付请求以接收存储在用户设备上的支付数据；以及经由第一浏览器支付请求API接收支付数据。当确定指示用户正在通过第二浏览器访问网站时，该方法包括在与购买相关联的网站上呈现第二购买按钮，接收用户与第二购买按钮的交互，经由第二浏览器支付请求API发送支付请求以接收存储在用户设备上的支付数据，并且经由第二浏览器支付请求API接收支付数据。
第一浏览器支付请求API可以来自第二浏览器支付请求API。第一个浏览器支付请求API可以验证网站。第一浏览器支付请求API可以使多个用户设备进行通信，以便经由第一浏览器支付请求API向网站提供支付数据。用户可以通过用户客户端设备上的第一个浏览器访问该网站。第一浏览器可以使用户客户端设备无线地接收存储在用户设备上的支付数据，其中，用户设备是与用户客户端设备物理上分离的设备。用户设备可以通过蓝牙无线协议与用户客户端设备通信。
此外，可以为每个接口提供定制信息。例如，Apple pay有其自己的浏览器API，而其他浏览器(例如Mozilla、Microsoft Edge、Chrome和其他浏览器)则使用W3C浏览器API。每个浏览器都可以使用特定的钱包。例如，Microsoft edge利用Microsoft钱包通过浏览器API提供支付信息。用户可能希望查看正在使用哪个钱包进行支付。例如，用户可以将签证存储在Microsoft钱包中，将万事达卡存储在Google钱包中。因此，本公开的一个方面是结合浏览器API在与支付方法相关联的接口上提供通知，该通知标识正用于特定交易的钱包。确实，在一个方面中，用户可能在设备上具有多个浏览器，因此可能具有多个钱包，本公开的一方面是在浏览器API界面中向用户展示，并且可以从不同的钱包中进行选择的选项是支付数据的存储位置，这些数据将通过浏览器API进行通信。在这方面，一种方法可以包括呈现用户可选择的对象作为浏览器支付请求API接口的一部分。该对象可以与用于支付的默认钱包相关联。在另一方面，该界面可能仅呈现几个对象，用户只需单击即可选择合适的钱包。例如，该界面可以为Microsoft钱包提供一个对象，为Apple pay提供一个对象。这些可以是一键式操作，其中用户简单地指示他们希望进行支付并使用特定的钱包。在另一方面，可以呈现默认钱包，例如Apple pay，其具有指示其他备用钱包可能可用的对象。可以提供用户无法选择的按钮、下拉菜单或链接以从默认钱包中进行更改。在接收到与对象的用户交互后，将根据所选钱包继续通过浏览器API进行信息交换。
使用上述场景，实际方法的一个示例可能是用户通过Safari浏览网页并想要购买小部件。因为用户具有Apple pay帐户，并且Apple pay按钮作为支付方法的一部分出现，供用户选择。但是，如果用户在设备上还具有Mozilla浏览器，该浏览器在其自动填充数据库中包括支付信息(包括必要的支付帐号、用户地址等)，那么该界面可以通过Mozilla存储的数据向用户提供支付选项。在这方面，Safari浏览器可以与Mozilla浏览器进行通信，以接收通过Apple浏览器API传递给商家的支付数据。API可以用于这种浏览器到浏览器之间的数据通信。此外，假定用户还具有Microsoft Edge浏览器和Microsoft钱包。在这方面，可以向用户提供切换到Mozilla帐户或Microsoft钱包帐户进行支付的选项。在某些方面，如果选择了替代的支付机制，则系统可以启动关联的浏览器，该浏览器然后可以与商家进行通信，并且可以通过该浏览器API将支付信息传达给商家。换一种说法，如果用户开始使用Safari浏览商户网站，并在其中选择了Microsoft钱包进行支付，则该设备会导致Safari浏览器与Microsoft Edge浏览器之间进行必要的通信，这将启动Microsoft Edge浏览器，并提供到要购买小部件的会话的深层链接或通信，以便商家可以向Microsoft Edge浏览器发起支付请求API调用，或者简单地接收存储在Microsoft钱包中的支付数据以处理购买。这种方法可以使用户更好地控制用于特定购买的钱包。这种方法还使与用户的通信变得容易，通知用户所有可用于任何特定零件购买的可用钱包。当然，这种方法也可以扩展到包括可能在设备上可用以进行购买的比特币或其他加密货币。
银行或信用卡公司可以提供折扣或优惠券以进行这种选择。例如，在用户界面中，如果Apple pay是默认支付机制，则如果用户在Microsoft钱包中选择支付帐户，则商家、银行或任何其他实体可能会为小部件的价格提供折扣。这可能是因为Apple pay向商家收取费用，或者是因为特定的信用卡也收取了更高的购买费用。就这一点而言，本公开的一个方面包括对于特定的购买，评估与每个可能的支付账户相关联的各种费用，这些费用可以通过浏览器API从用户设备进行。如果确定一个特定的可用支付帐户具有较少的费用或提供特定的利益，则一种方法可以包括在用户支付界面中显示折扣或优惠券，该优惠券为用户提供了选择备用支付帐户的机会，从而在小部件上获得折扣价或其他一些好处。用户可以选择一种通过其设备上的每个浏览器访问其各种钱包的方法。此外，广告或通知也可以在浏览器API界面上显示，该界面可以基于社交媒体数据、先前的购买历史记录、可用于购买的钱包等。
一键式支付的整体架构
图18A示出用于预填充商家购物车以及用于使用浏览器API的示例架构1800。在该示例中，运行网络浏览器1806的计算设备1804的用户1802加载具有统一输入字段或任何其他网站(例如，社交网站)的网页。该网站通过API 1812与服务器1810通信。服务器1810可以代表任何网站或应用程序，甚至是支付服务应用程序。当用户1802在统一输入字段中输入数据，或基于其各自的功能以任何其他方式与网站进行交互时，浏览器1806通过API 1812将数据发送到服务器1810。服务器1810可以根据在统一输入字段中输入的数据，分析数据以识别用户1802打算进行购买。服务器1810可以识别出售期望物品的商家网站1816，并且如果可用，则经由其关联的浏览器支付请求API 1818与该商家网站1816通信。在这种情况下的一方面，存储的支付数据1814可以使网站1810能够处理支付，并且经由API与商家通信支付细节和信息给商家1816以交付商品。如果API不可用，则服务器1810可以通过HTTP与商家网站1816进行通信，并且可以以自动方式浏览网站，就像用户在商家网站1816上单击或输入数据一样。服务器1810可以使用基于网络的支付和交付数据或有关用户1802的其他个人数据的数据库1814来填充商家网站1816上的数据字段。
然而，如果基于网络的数据库1814不完整或不存在，则服务器1810可以经由API1812从浏览器1806或计算设备1804本地的支付和递送数据数据库1808中请求数据。支付数据1808可以是存储在本地设备(或基于网络的服务)上的任何支付数据，即使用于其他目的(例如YouTube帐户)，或与电子邮件帐户或iTunes帐户相关联。如果用户登录到其浏览器，他们的电子邮件帐户或任何其他类型的帐户，并且存储了支付数据，则系统可以利用或访问该支付数据来发起商业购买。当用户进行购买时，系统可以显示存储的各种支付帐户(例如Google电子钱包中的信用卡)以及Play商店帐户，并允许用户在可用的支付选项中进行选择。跨平台也可能发生这种情况，例如Chrome中存储的信息以及Amazon.com中存储的Amazon帐户。在这种情况下，Amazon.com数据可以由服务器1810和数据1814表示，并且可以通过API 1812或其他方式提供给浏览器1806。浏览器1806可以访问和利用任何存储的支付数据来简化支付方法。服务器1810可以通过以下方式连续接收用户在统一输入字段中输入的附加数据，以及更新或修改在商家网站1816输入的数据，在商家网站1816选择购买的商品，或者甚至完全切换到不同的商家网站。服务器1810可以经由API 1812向浏览器1806发送响应，因此浏览器1806可以基于在统一输入字段中输入的数据向用户1802呈现动作或目的地。然后，如果用户选择动作或目的地之一，则浏览器1806可以导航到该页面并直接与商家网站1816通信，或者在没有服务器1810的情况下与之通信，尽管服务器1810可以继续与浏览器1806通信以在商家网站1816上跟踪用户1802的行为。例如，服务器1810可以跟踪通过统一输入字段引用的最终购买细节。服务器1810可以基于从本地支付和交付数据1808处理的信息或者基于用户输入，不时更新基于网络的支付和交付数据1814。浏览器支付请求API 1818建立用于在商家网站1816和浏览器1806之间传递信息的基本协议，以简化支付方法。浏览器1806还可以代表任何设备，例如语音控制助手或设备。从浏览器1806通过API1818传送到商家网站1816的支付数据可以出于安全目的被标记化。然后，商家网站1816可以使用其支付处理器1820处理商品的支付。这种方法的好处是，商户可以使用相同的支付基础结构，并且只需要对网站进行较小的更改即可利用浏览器API 1818获得用于处理支付的必要数据。如图18A所示，在商户网站1816之间经由API 1818与浏览器1806之间的通信以获得任何种类的数据1808可以在两个方向上发生。因此，商家1816可以通过浏览器API发起对数据的请求，并出于任何目的接收该数据，例如支付数据，以避免用户需要手动填写支付帐户、地址信息以及任何其他数据，例如衬衫尺寸、裤子尺寸、鞋子尺寸、颜色偏好、一键式购买参数等。
例如，如果商家网站1816是amazon.com，并且该网站已经具有登陆amazon.com的用户的支付帐户和地址，一键购买授权或参数可能需要在浏览器1806上设置，以使目标状态成为“一键”购买状态。在从服务器1810到网站1816的过渡中，该过程可以包括访问或确认浏览器的一键购买状态为“开启”，以使用户能够登陆网站1816并进行下一次交互即可一键购买商品。
本文公开了实现支付请求API 1818的各种示例方面。注意，支付和/或交付数据以及可以用于处理购买的任何其他数据(例如用户个人资料数据、一键式购买数据、设置、参数等)可以被本地存储在用户设备1804上1808，或者可以从网络服务器或服务中获取，或者两者的结合。例如，当浏览器1806通过API 1818接收到支付请求时，它可以与与购买相关的网络服务器通信数据。网络服务器可以加密数据并创建令牌，该令牌被传输回用户设备，以传递给商家以处理支付。服务器1810还可以表示除了搜索网站之外的任何网站，例如社交媒体网站，并且与各个网站相关联的各个功能将适用于如何从与第一网站1810的交互过渡到目的地商家实体网站1816。换句话说，发起的过渡交互可能不是正在将数据输入到输入字段中，而可能是与相应网站相关联的任何交互，例如与广告交互或与游戏、地图应用程序、会议应用程序等相关的交互。
在一方面，如图18A所示，网站1816还可以经由API 1818请求来自服务器1810的支付数据，该服务器可以访问支付数据、用户数据和/或其他数据。因此，例如，当用户导航商品并决定进行购买时，网站可以显示购买按钮，并将其转变为一键式体验，该网站可以对服务器(例如，基于Google的服务器或基于Amazon的服务器)执行API调用，并检索可以通过Google或Amazon或任何其他实体存储的支付信息和/或其他数据，其可以通过API传递给商家网站，以处理支付并可能将商品交付给买方。因此，可以快速、轻松地访问和提供存储在说Google Play或电子邮件地址或YouTube或Amazon中的支付数据，从而使用户不必手动输入数据即可进行购买。服务器1810还可以访问与浏览器1806相关联存储的支付数据以进行支付。实际上，API 1818和/或API 1812可用于通过用户界面呈现许多不同的支付选项，例如存储在浏览器1808中的一个支付选项和存储在Google服务器1814或AndroidPay中的一个支付选项，例如，并使用户能够选择用于支付的支付帐户。关于所选择的支付帐户的信息可以通过API1818传递到网站1816以进行处理。
图18B示出与图18A所示的浏览器API有关的方法示例。该方法可以由浏览器执行，并且包括在用户客户端设备的非暂时性存储介质中存储用户的支付数据的步骤(1830)。一方面，支付数据可包括地址信息、支付账户信息、到期日期、CVC代码、令牌或可用于或加密以提供商户使用的支付令牌的代码、用户投放偏好、衣服的用户尺寸信息等中的任何一个或多个。与处理购买有关的任何数据都可以包含在支付数据中。支付数据通常不与任何特定网站相关联，但可以在多个网站之间使用。可以实施任何安全机制以确保将支付数据或修改的支付数据安全地传送到网站1816以处理购买。通过浏览器API进行通信时，用户大小信息也可以被标记。当通过社交网站和商家网站之间的应用程序编程接口进行购买时，社交网站可以通过应用程序编程接口传输支付数据，使得商家网站可以处理商品的购买。
该方法可以包括：经由诸如浏览器之类的用户界面，接收用户与与在浏览器内呈现的网站相关联的对象的点击交互(1832)，该点击交互指示用户意图进行购买，在浏览器上基于点击交互并通过浏览器支付请求应用程序编程接口接收，该接口定义了用于在网站和浏览器之间传递支付数据的协议，来自网站的与购买有关的支付数据请求(1834)，通过浏览器检索支付数据(或为安全起见经过加密或加密的支付数据版本)，以产生检索到的支付数据(1836)，并通过检索器支付请求应用程序编程接口向网站发送检索到的支付数据，其中检索到的支付数据可用于处理支付或交付与购买相关的商品(1838)。在一个方面，浏览器还可以与另一服务器1810交互，该服务器也可以处理支付数据1814，例如生成令牌，该令牌被传递回浏览器1806以与商户网站1816通信。图19，特征1908示出可以与之交互以发起商家网站1816与浏览器1806之间的交互的对象。在另一方面，可以将支付数据1808全部或部分与浏览器一起存储，并且可以经由网络服务器1814全部或部分地访问其他数据以生成支付数据或支付信息，该支付数据或支付信息被传达给商家1816以用于处理支付。在该示例中，可以将支付数据与用户大小信息、注册数据或通过浏览器API交换的任何其他数据进行交换。
图18C从商户网站的角度示出过程。在这种情况下，该方法可以包括用于经由诸如浏览器1806之类的用户界面来呈现用户可以与之交互的对象1908，其中该对象包括按钮、下拉屏幕或超链接之一(1840)，接收用户与网站相关联的对象的点击交互，该点击交互指示用户打算进行购买(1842)，基于点击交互并经由浏览器支付请求应用程序编程接口来发送该请求，该浏览器支付请求应用程序编程接口定义了用于在网站和浏览器之间传递支付数据的协议，来自网站的关于与购买有关的存储在用户设备1804上的支付数据的请求，支付数据可在多个网站上用于支付(1844)，并在网站上并通过浏览器接收支付请求应用程序编程接口1818，接收支付数据1808(或基于支付数据的安全数据，例如令牌)，其中该支付数据可用于处理商品支付或交付与购买相关的商品(1846)。商家1816可以将接收到的支付数据或信息提交给支付处理器以处理购买。
浏览器API具有许多特性，可以将其与网站和支付服务器(例如PayPal场景)之间的API以及常规的超文本标记语言(HTML)协议区分开。HTML是一种标记语言，Web浏览器用于将文本、图像和其他材料解释和组合为可视或可听网页。Web浏览器将从Web服务器或本地存储接收HTML文档，然后呈现这些网页。HTML通常以语义方式描述此类网页的结构，并使用其协议进行描述。浏览器中文档外观的说明。级联样式表和JavaScript也可以是HTML的一部分。浏览器中定义了HTML标记的每个商品的默认特征，这些特征可以通过网页设计者额外使用CSS来更改或增强。相反，应用程序编程接口代表一组子例程定义、工具和协议，这些子例程定义、工具和协议概述了一组清晰定义的结构，用于各个软件组件之间的通信。它是用于在网站(例如商家网站)和浏览器之间进行通信的已建立API。因此，浏览器必须使用例程、数据结构、对象类、变量和/或远程调用进行编程，以使希望利用API的各个网站能够进行支付请求调用并通过API接收适当的数据以处理支付。浏览器API不是HTML界面，也不是旨在用于网站之间以及直接与基于网络的支付服务器或支付服务进行通信的API。我们注意到，此处公开的过程是浏览器可以充当代理并通过浏览器与基于网络的支付服务之间的其他API进行管理的过程，支付或向商户网站提供支付数据(例如令牌化数据)的过程。但是，在那种情况下，网站不需要对基于网络的服务器进行单独的API调用，因为将浏览器建立为管理进程的代理，从而简化了网站的通信，从而仅需要通过浏览器API进行调用即可进行身份验证、授权、基于网络的过程。因此，该API(它可以是一组HTTP请求消息，以及对请求消息和响应消息的结构的定义，可以以XML或JavaScript对象表示法格式建立)内置在浏览器中，使浏览器可以充当代理，以提供授权的支付数据、密码数据、登录数据、令牌化的支付数据，或者作为代理管理基于网络的支付处理或登录处理，全部通过支付请求或网站通过浏览器API进行的其他调用来完成。浏览器API管理浏览器和网站之间的数据流，并使浏览器可以分别与身份验证、数据、令牌或其他基于网络的服务联系。该API在支付方式、系统、平台和商家之间提供一致的体验。典型的基于Web的API已在网站和Web服务之间定义了接口，并且本文中公开的新颖概念是定义了内置于浏览器中的体系结构和可编程接口、数据结构等的新API，这样浏览器就可以接收支付请求、检索授权的支付数据、对请求做出响应(无论该过程是支付方法还是登录过程)，从而可以简化和统一网站之间的支付或登录过程。
图19示出用于预先填充的商家购物车的示例用户界面。在第一用户界面1900中，用户已经在浏览器中的网页的统一输入字段1902中输入了文本“购买ACME烤面包机4.5”。按下Enter键或单击搜索按钮后，浏览器与已经导航到(或当前正在导航至)商家网站的服务器进行通信，以使用所需的烤面包机在商家网站中填充购物车。服务器可以将浏览会话移交给浏览器，以继续在结帐或购物车过程中的特定点，或者可以将URL返回到浏览器，该URL构成为可以直接转到基于统一输入字段中输入的文本填充的购物车。在这种情况下，在点击回车或单击搜索按钮之后，浏览器直接自动导航到商家网站1904，其中列出了已经放置在购物车中的商品、订单明细和一键式购买按钮1908。替代地，浏览器可以导航到已经下订单的阶段，诸如在用户点击购买按钮1908之后将加载的页面。值得注意的是，商家在屏幕1904上具有一些品牌。如通过这里的公开可以理解的，其中购买按钮1908用于使用在搜索引擎网站处存储的支付信息来处理支付，API的搜索引擎端的支付处理与API的商家端处理的交付之间的协调，使购买者的过程变得更加简单容易，从而增加了发生销售的机会。
屏幕1904还可以表示用户在商家网站上的简单导航，以使他们到达用户致力于进行购买的点1908。点击或与购买按钮交互作用1908可以通过浏览器API发起通信，以请求并最终接收用于处理支付的必要支付数据。
屏幕1904可以由搜索引擎/社交媒体网站和/或商家托管。系统也可以代表用户自动填充购物车的其他详细信息。如果用户在该商家处没有帐户，则该系统甚至可以代表该用户在该商家处创建一个新帐户。这样，该系统使用户能够通过统一的搜索字段访问网站，就好像它们是一键式购买商家网站一样，即使用户之前未在该商家处注册，或者商家未提供“亚马逊风格”一键式购买界面。例如，与提供通用输入字段相关联的第一网站实体可以基于商品存储的支付账户信息来处理商品的支付，并在完成商品的交付时与商家进行协调。
使用两个API来管理支付流程
本文公开的另一方面涉及第一API 1818和第二API 1812之间的协调，两者均以相关方式与浏览器1806对接以管理支付方法。当用户未注册并且在网站1816上没有帐户时，该方法使在网站1816上的购买更像是Amazon.com的“一键式”购买体验。在某些情况下，用户可以拥有Paypal帐户，但他们仍必须登录该帐户进行支付。API 1812、1818和充当网站1816与支付提供商1810之间的代理的浏览器1806的协调可以简化购买过程。在这方面的方法在图18D中示出，并且包括从用户接收指示希望从商家网站1816购买商品的输入(1850)。输入可以是单击，作为对话框一部分的语音输入、虚拟现实输入或任何类型的输入。该方法包括基于该输入，在浏览器1806处并经由第一应用程序编程接口1818接收该第一应用程序编程接口1818，该接口定义了浏览器1806与商家网站1816之间的第一协议，来自商家网站的支付请求，用于购买用户商品的用户支付数据(1852)。
响应于支付请求，该方法包括：从浏览器1806并经由第二应用程序编程接口1812进行通信，该第二应用程序编程接口1812定义了用于在浏览器1806和支付服务1810之间传递支付信息的第二协议，向支付服务1810进行支付请求事件，其中支付服务1810可基于支付请求事件处理商品的支付(1854)。该方法包括在浏览器1806处并且从支付服务1810并且经由第二应用程序编程接口1812接收对商品的支付的确认(1856)，并且从浏览器1806并经由第一应用程序编程接口1818向商家网站1816传达对商品支付的确认(1858)。支付服务1810可以是诸如Paypal、谷歌支付服务或任何其他支付服务或支付处理器之类的服务。该方法以新的方式利用浏览器1806和几个API 1812、1818启用商家1816和支付服务1810之间的公共接口，以简化签约用户使用该服务或利用诸如服务之类的用户的购买过程。
第一应用程序编程接口1818可以定义用于在浏览器1806和商家网站1816之间传递支付数据和地址数据中的至少一个的第一协议。第二应用程序编程接口1812可以包括第二协议，该第二协议用于在浏览器1806和支付服务1810之间传送与商品的支付相关联的数据。支付请求还可以包括对用户地址和/或与用户相关联或与购买相关联的其他数据的请求。因此，支付可以由支付服务提供商1810执行，并且地址可以由浏览器通过第一API 1818提供。
该方法可以进一步包括基于支付请求，从浏览器1806并且通过第一应用程序编程接口1818发送用户1808到商家网站1816的地址，以用于将商品交付给用户。第一应用程序编程接口1818可以包括浏览器支付请求应用程序编程接口，因为它涉及来自商家网站1816的对支付数据和/或与用户相关联的其他数据的请求。第二应用程序编程接口1812可以被称为支付处理程序应用程序编程接口，因为它更具体地涉及支付处理器1810进行的支付处理。从商家的角度以及从支付处理器的角度，本公开的这个方面也可以具有实施方案。
图18E从支付处理器1810的角度示出本公开的这一方面。一种方法包括：基于来自用户的指示希望从商家网站购买商品的输入来接收1816，并且基于浏览器1806在浏览器1806处并经由第一应用程序编程接口1818接收，该第一应用程序编程接口1818定义了浏览器1806与商家网站1816之间的第一协议，来自商家网站1816的用于购买商品的用户的支付数据1808的支付请求，支付服务1810处的支付请求事件，其中从浏览器1806并且经由第二应用程序编程接口1812接收到支付请求事件，该第二应用程序编程接口1812定义了用于在浏览器1806和支付服务1810之间传递支付信息的第二协议，在支付服务1810中，基于支付请求事件处理对商品的支付(1862)，并通过第二应用程序编程接口1812从支付服务1810向浏览器1806发送对商品支付的确认，其中浏览器1806经由第一应用程序编程接口1818与商家网站1816通信对商品支付的确认(1864)。在这种方法中，商户没有使用他们自己的支付处理器1820，如果商户1816正在接收支付账户数据或用于处理购买的令牌则将发生这种情况。由于购买是由支付服务1810执行的，因此商家1816需要确认购买已完成。支付服务可以利用存储的支付数据1814和/或用户账户。因此，诸如Stripe、Google.com、BrainTree、Amazon.com、Paypal等的支付服务可以由支付服务1810表示。因为用户可以登录到他们的浏览器或Google帐户(电子邮件，youtube等)，则无需用户手动输入其帐户数据即可利用用户的凭据登录用于支付的任何特定帐户。
从商家网站的角度执行的方法在图18F中示出。该方法包括从用户接收指示希望从商家网站购买商品的输入1816(1870)，并根据输入，并通过第一应用程序编程接口1818传输到浏览器1806，该接口定义浏览器1806和商家网站1816之间的第一协议，来自商家网站1816的用于购买商品的用户的支付数据的支付请求(1872)，其中(1)响应于该支付请求，浏览器1806从浏览器1806并经由第二应用程序编程接口1812进行通信，该第二应用程序编程接口1812定义了用于在浏览器1806和支付服务1810之间传递支付信息的第二协议，向支付服务1810的支付请求事件，(2)支付服务1810可基于支付请求事件处理商品的支付，并且(3)浏览器1806通过支付服务1810和第二应用程序编程接口1812接收对商品支付的确认。该方法包括：从浏览器1806在商家网站1816处并且经由第一应用编程接口1818接收对商品的支付的确认(1874)。
使用所公开的各种API的浏览器、支付服务和商家网站之间的任何通信可以是本公开的一部分，以实现用户在商家网站.1816处的一键式购买体验。
接下来讨论关于支付处理器处理到网站的支付的其他概念。在一个方面，一种方法包括：在浏览器处并且经由浏览器接收支付请求应用程序编程接口，该接口定义了用于在网站和浏览器之间传达关于购买的信息的第一协议，支付请求具有用于用户的与从网站购买商品相关的数据，并基于支付请求，从浏览器并通过浏览器支付处理程序应用程序编程接口传输请求，该请求定义了用于在浏览器和支付服务之间传递数据的第二协议，该请求用于处理向支付服务的商品支付。根据该方面的方法可以包括：在浏览器处并且经由浏览器支付处理程序应用程序编程接口从支付服务接收对支付服务已经处理了向网站的商品支付的确认。
该方法可以进一步包括从浏览器并且经由支付请求应用程序编程接口向网站发送从支付服务接收到的确认。该方法可以进一步包括：从浏览器并且经由支付请求应用程序编程接口将用户的地址信息传输到网站，以将商品交付给用户。
从支付处理器的角度来看，一种方法可以包括：基于在浏览器处接收到的支付请求，以及经由浏览器的支付请求应用程序编程接口，该接口定义用于在网站和浏览器之间传达关于购买的信息的第一协议，该支付请求具有与针对用户的从网站购买商品相关的数据，从浏览器在支付服务处并经由浏览器接收处理程序应用程序编程接口，该接口第二协议，用于在浏览器和支付服务之间传递数据，处理商品支付的请求并通过浏览器支付处理程序应用程序编程接口向浏览器传输来自支付服务的确认，该支付服务已处理了商品向网站的支付。
从网站上下文来看，示例方法可以包括：从网站向浏览器传输，并通过浏览器支付请求应用程序编程接口，该接口定义第一协议，该第一协议用于在网站和浏览器之间传达关于购买的信息，支付请求，该支付请求具有与从网站为用户购买商品相关的数据，并从支付服务接收对商品的支付，其中，基于浏览器接收到的支付，该浏览器基于支付请求从浏览器发送并经由浏览器支付处理程序应用程序编程接口，该接口定义了用于在浏览器和支付服务之间传递数据的第二协议，即处理向支付服务支付商品支付的请求。该方法还可以包括：从浏览器并且经由浏览器支付请求应用程序编程接口接收从支付服务发起的确认，该确认是支付服务已经处理了向网站的商品支付。该方法还可以包括：从浏览器并且经由支付请求应用程序编程接口接收网站处的用户的地址信息，以将商品交付给用户。
多种支付方式
图18G公开了与提供支付方法的选择有关的本公开的另一方面。在这个方面，该方法包括在浏览器处并且经由浏览器接收支付请求应用程序编程接口，该接口用于在网站和浏览器之间传达关于购买的信息的协议，支付请求具有与用于用户的从网站的商品购买相关的数据(1880)，通过浏览器或浏览器界面呈现用于购买商品的第一支付方式和第二支付方式之间的选择，其中第一支付方式和第二支付方式各自包括或要求存储在用户设备上的支付数据、存储在网络服务器上的支付数据以及支付服务(1882)中的一个，从第一支付方式和第二支付方式中的一个的用户接收对支付方式的选择以产生选择的支付方式(1884)，并且基于选择的支付方式，并且响应于支付请求，从浏览器并经由浏览器支付请求应用程序编程接口向网站发送与所选择的支付方法相关联的数据(1886)。
该方法可以包括：当选择的支付方法包括支付服务时，基于支付请求和选择的支付方法，从浏览器并通过浏览器支付处理程序应用程序编程接口传输的步骤，该浏览器定义用于在浏览器和支付服务之间传递数据的第二协议，用于处理向支付服务支付商品支付的请求，并在浏览器上并通过浏览器支付处理程序应用程序编程接口接收来自支付服务的确认，确认该支付服务已经处理了该商品的支付，使得该网站被支付。
该方法还可以包括从浏览器并且经由支付请求应用程序编程接口向网站发送从支付服务接收到的确认(或其他数据)。该方法还可以包括：当选择的支付方式包括存储在用户设备上的支付数据时，基于支付请求和选择的支付方式执行步骤，从浏览器并通过浏览器支付请求应用程序编程接口向网站发送响应数据，该响应数据基于存储在用户设备上的支付数据。
响应数据可以包括基于存储在用户设备上的支付数据而生成的令牌，该令牌可用于处理网站对商品的购买。该网站可以使用支付数据处理商品的支付。当所选择的支付方式包括存储在网络服务器上的支付数据时，该方法还可以包括：基于支付请求和选择的支付方法，从浏览器并通过浏览器支付请求应用程序编程接口将存储在网络服务器上的支付数据传输到网站。可以通过与浏览器关联的一个或多个API将支付数据传送到网站以进行处理。
该方法还可以包括：从浏览器并且经由支付请求应用程序编程接口将用于用户的地址信息(或任何其他信息)传输到网站，以将商品交付给用户。一方面，其他信息可以包括衣服尺寸、演出尺寸、衬衫尺寸、裤子尺寸等，使得用户可以简单地购买他们想要的鞋子并购买。甚至没有必要选择大小甚至自己的大小。通过API传递用户的尺寸，鞋子的尺寸才合适。
从网站的角度来看，多种支付选项的概念可以包括经由浏览器传输支付请求应用程序编程接口，该接口定义了用于在网站和浏览器之间传达有关购买信息的协议的支付请求，支付请求具有与用户从网站购买商品相关的数据，通过浏览器界面呈现用于购买商品的第一支付方式和第二支付方式之间的选择，其中第一支付方式和第二支付方式各自包括或要求存储在用户设备上的支付数据、存储在网络服务器上的支付数据以及一种支付服务中的一个(或多个)，从用户接收第一支付方式和第二支付方式中的一种的支付方式选择，以产生所选支付方式，并基于所选支付方法，并且响应于该支付请求，从浏览器并经由浏览器支付请求应用程序编程接口接收与所选支付方法相关联的数据到网站。
与所选择的支付方式相关联的数据可以包括用于网站以处理购买商品的支付的支付数据或者用于确认购买商品的支付是由支付服务执行的确认。
从支付处理器的角度来看，该方法可以包括以下概念。基于(1)，在浏览器处并通过浏览器支付请求应用程序编程接口接收到的支付请求，该接口用于在网站和浏览器之间传达关于购买的信息的第一协议，该支付请求具有与针对用户的从网站购买商品相关的数据，并基于(2)用户从经由用户设备呈现的多种支付方式中选择一种支付方式，该支付方式需要支付处理器来处理商品的购买，该方法可以包括：从浏览器在支付服务处并且经由浏览器支付处理程序应用程序编程接口接收请求，该第二协议定义了用于在浏览器和支付服务之间传递数据的第二协议，该请求用于处理商品的支付，通过支付服务处理商品的支付以产生支付确认，并从支付服务向浏览器并通过浏览器支付处理程序应用程序编程接口传输支付确认。
浏览器可以通过浏览器支付请求应用程序编程接口将支付确认(或相关数据)发送到网站。在该概念的另一种形式的浏览器视图中，该方法可以包括：结合商品购买，在浏览器上并通过浏览器支付请求应用程序编程接口接收支付请求，该接口定义了用于在商家网站和浏览器之间通信数据以管理支付的协议，经由用户界面呈现第一支付方法和第二支付方法，经由第一支付方式或第二支付方式的用户界面接收选择以产生选择的支付方式，并且响应于支付请求，从浏览器并且经由浏览器支付请求应用程序编程接口传输支付信息，支付信息与所选支付方式相关联。
支付信息可以包括支付数据，供商家网站用于处理购买。支付信息可以包括对支付已经被支付处理器处理的确认。
该方法还可以包括：从浏览器并且经由浏览器支付处理程序应用程序编程接口传送信息，该接口定义用于在浏览器和支付处理器之间传送数据的协议，将信息传送给支付处理器以处理支付。该方法还可以包括在浏览器处并且经由浏览器支付处理程序应用程序编程接口接收确认信息，该确认信息确认支付处理器已经成功地向商家网站支付了商品的支付。
凭证管理API
接下来公开了一个或多个示例应用程序编程接口，用于传达网站的登录凭证，例如名称和/或密码。图18H从浏览器1806的角度图示了该示例。一种方法包括：从网站1816在浏览器1806处并且经由浏览器凭证管理应用程序编程接口1818接收网站1816，该接口1818定义用于在网站1816和浏览器1806之间传递数据的协议，以使用户1802能够登录到网站1816，该请求与该网站所需的登录凭证相关联(1890)，基于该请求，检索用户数据1808/1814(1892)，并从浏览器1806经由浏览器证书管理应用程序编程接口1818向网站1816发送对请求的响应(1894)。示例性API在图18A中被公开为API 1818。检索用户数据可以包括浏览器1806，从本地存储器1808检索数据或使用浏览器1806和基于网络的服务器1810之间的API 1812检索用户数据1814。用户数据可以包括提供用户凭据的各种帐户或方法。例如，一种方法可以是使用与浏览器一起存储或可由浏览器1806访问的用户名和密码。另一种方法可以是可由浏览器1806或网站1816访问的凭证服务、单独的帐户或网络设备。可以向用户提供一个选项(视觉界面、口头界面或互动、文本、多模式界面等)，以选择用于登录的方法。通过选择的方法，API 1818可以用于根据选择的方法并且根据API 1818或任何标准化协议将证书数据从浏览器1806传递到网站1816，或者从网络设备1810传递到网站1816。这样的网站1810可以是将向用户授权并且网站可以信任正确的身份提供者。这样的提供者可以是例如Google、Facebook或任何其他实体。该界面还可以提供不同用户之间的选择。所传达的数据可以是用于安全性的一个或多个令牌或直接用于用户名和/或密码的令牌。
浏览器凭证管理API 1818的目的是使网站1816能够轻松检索登录凭证，例如用户名、密码、代码或任何其他数据中的一个或多个。用户的认证还可以结合诸如指纹之类的生物指标的接收来执行。网站1816通过API1818进行通信，以获取登录证书。经由API 1818传达请求和响应和/或其他数据的过程可以包括当API 1818与浏览器1806或网络服务器1810通信时，API 1818之间的任何组合或协调，以及经由API 1812在网络服务器1810与浏览器1806之间的任何通信。在实践中，这些API通常将涉及用于网站1816的协议，以请求数据、发送数据和以某些格式接收数据，最终用于接收用于用户登录网站1816的登录凭证。网站1816将使用其在登录流程中收到的凭据和/或令牌，使用户只需单击一下即可登录(如果是自动，则单击不登录)，因此，无需用户输入用户名、密码或任何其他凭据。网站1816例如可以在网站上或通过对另一服务器的呼叫来认证用户。与这样的协议相关联的所有这样的细节被认为在本公开的范围内。
该响应可以包括用户名和密码中的至少一个，或其他数据，例如虹膜扫描、指纹、代码或此类数据的任何组合。在一方面，用户名和密码或其他数据中的至少一个与浏览器一起存储。数据也可以存储在网络节点中。该响应可以指示基于网络的实体将提供用于登录到网站的凭据数据。就这一点而言，网站可以经由网站和基于网络的实体之间的第二应用程序编程接口访问用于用户登录到网站的证书数据。图18A中所示的API 1818可以表示网站之间的API。1816和存储用户数据1814的网络服务器1810。API 1812也可用于通过浏览器1806并从网络实体1810检索登录凭据。API1818、浏览器1806、API 1812和网络实体1810之间的数据和信息通信的任何组合或协调被预期在本公开的范围内。例如，网站十八十六可以经由浏览器1806通过API 1818请求登录证书。然而，用户可以具有存储登录证书1814的网络服务1810。因此，响应于该请求，网站1816可以通过API 1818定向到网络凭据提供程序1810，以检索用户数据1814。
在一方面，该方法包括经由浏览器证书管理应用程序编程接口接收用户证书中的改变。在这种情况下，用户可能试图登录到网站1816，并可能提供更改的密码或更新的凭据。API 1818可用于将更新的登录凭证传输到浏览器1806，以供存储和以后使用。API 1818和/或API 1812中的一个或多个也可以用于将更新的登录凭据传递给网络实体1810。
凭证管理API 1818也可以从网站1816上发生的处理中查看。在这个方面，一种方法包括从网站1816传输到浏览器1806，并通过浏览器凭证管理应用程序编程接口1818传输，该协议定义了用于在网站1816和浏览器1806之间传递数据的协议，以使用户能够登录到该网站，该请求与该网站所需的登录凭证相关联，并在网站1816处，从浏览器1806并经由浏览器证书管理应用程序编程接口1818接收对该请求的响应。
该响应可以指示基于网络的实体1810将提供用于登录到网站的证书数据。该方法可以进一步包括经由网站1816和基于网络的实体1810之间的第二应用程序编程接口1818请求用于用户登录到网站的证书数据。辅助API还可以包括API 1812，其在浏览器1806和网络实体1810之间进行操作和传达请求和响应或其他数据。该方法可以包括经由浏览器证书管理应用程序编程接口传输用户证书中的改变。
响应可以包括用户名、密码和/或其他凭据数据中的至少一个，网站1816可以使用该用户名、密码和/或其他凭据数据来应用于网站1816上的登录过程，以将用户1802登录到网站1816。
车辆/物联网应用
在另外方面，浏览器支付请求应用程序编程接口可以应用于车辆接口。车辆可以具有计算机组件和具有本文公开的浏览器或界面功能的图形界面(或语音界面)。例如，在餐馆中通过开车驶入的汽车中的用户可以利用汽车中内置的触摸屏来处理支付。通过近场通信协议、WiFi协议、蜂窝协议或任何其他无线协议，车辆可以与餐厅进行通信并交换有关支付、餐厅和/或车辆的支付能力、金额、订购的商品等等信息。该人可以点餐并说餐费是15美元。用户可以拿出内置在车辆中的触摸屏进行交互，以查看所订购的物品以及购买金额的摘要，并通过用户界面确认购买，而不是拿出钱包或拿出他们的移动设备。指纹读取器可以内置在用户界面中，也可以内置在方向盘或车辆内任何其他易于访问的设备(包括用户的移动设备)中，可以用来确认购买。一方面，可以将界面呈现给用户，以在界面上输入CVV代码以确保安全。可以包括基于位置的服务或功能，以使过程正常运行。一方面涉及以不需要用户拉出或使用他们的移动设备的方式提供整个购买过程。在另一方面，支付方法利用车辆的计算设备和用户的移动设备的组合。
该过程也可能仅通过用户的移动设备发生。在这方面，当用户输入餐馆或商店的Wi-Fi信号范围并启动通信界面时，交互式应用程序或网站可以跟随用户，从而使选择、购买和支付更加容易。例如，当一个家庭到达餐厅并处于Wi-Fi网络范围内时，可以在移动设备上显示界面，该设备欢迎您进入餐厅并询问他们的聚会人数。该家庭可以在用户界面中输入三个成年人和两个孩子，并给他们安排何时就座的时间。甚至可以为他们提供选择座位的机会，例如展位。关于家庭名称的信息和其他数据可以通过浏览器与餐厅或网站之间的API进行通信。家人可能会被告知那里的摊位将在十分钟内准备就绪。我可以在网站上提供针对该家庭的等待时间的媒体演示，或者当然，该家庭可以开车兜风并在十分钟内回来。可以通过应用程序提供展位可用性的通知。在此期间，还可以通过移动设备或用户界面或在可用性之前的预定时间提供菜单。机器学习和人工智能可用于计划和管理预测的可用性时间。当一家人在餐桌旁进入餐厅和系统时，基于位置的数据可能表明他们在展位，并且可以向用户界面提供菜单。一家人可以通过界面直接点菜，并且可以提供将食物运送到摊位的估计时间。在交付食物之后，可以向界面显示支付选项，并包括任何其他组件，例如甜点菜单、留下小费的选项等等。可以在餐厅网站和浏览器之间利用浏览器API来处理支付。可以使用基于位置的服务来指示订购餐的移动设备是否正在离开餐厅而无需付费。即使在以后的日期，用户也可以授权支付餐费。当识别出移动设备时，可以打给用户以提醒他们授权支付。在这种情况下，使用支付请求API，用户可以去餐馆、任何商店或任何场所，并能够通过与他们的移动设备进行交互来购买商品，服务或食物，而无需携带信用卡或现金进行购买。在以上情形中，本描述中包括的任何请求、药物、数据、视频、图像等都将在移动设备上的浏览器和与商家相关联的网站之间交换，以能够选择要购买的物品，检索这些物品并通过其移动设备支付。
在另一方面，如上所述，内置在车辆中的计算设备可以与用户的移动设备进行通信。例如，移动设备通过诸如蓝牙的无线接口，可以将浏览器信息和API与加载在车辆的计算设备上的浏览器或接口进行协调，这样，用户可以使用支付数据、登录数据、用户数据或移动设备上的任何其他数据与车辆的计算设备进行交互。因此，在诸如饭店、收费站或停车场的实体，或需要从车辆支付的任何实体之间，信息、授权、支付数据或支付确认的通信和交换可以在实体与车辆之间以与本文所公开的相同方式在商家网站和具有浏览器的用户设备之间发生。还可以传送其他数据，例如在用户要去鞋店、服装店或任何其他类型的商店的情况下，还可以传送数据，例如衣服尺寸、鞋子尺寸、帽子尺寸、服装或人体模型或任何其他可以通过API进行通信的数据，以帮助简化实体提供的服务。
在车辆应用的一种情况下，假设一家人要去餐厅吃饭。他们想在餐厅用餐。使用浏览器API可以使他们进行订购和购买的方法如下。家庭或车辆进入WiFi范围之内，例如Panera Bread，或者基于位置的地理围栏或其他应用程序使Panera系统知道他们在停车场，正在接近餐厅，或在某种意义上被“打开”。这个想法是在不使用移动设备或与移动设备连接的情况下实现订购和购买。汽车中的系统(计算设备)(也可以仅使用移动设备完成此操作)将建立连接，该连接将提供信息交换。例如，识别信息，例如家庭成员的照片、车辆描述、支付数据(Panera接受的支付方式和用户可用的支付方式)、语音识别语法或其他启用语音的数据，等等。在某种意义上，假设当家人开车进入停车场时，在交换必要的信息之前或之后，并且可能基于信息的正确交换，在车辆中提供了烙印的声音。声音可以是PaneraBread的声音，也可以是普通声音，也可以在显示器上显示图像。在另一方面，不提供任何通知。然后，车上的人会说“Panera，我们想点餐。”用户可以进行对话(口语或书面、涂鸦或任何组合)来点餐。
车辆中的屏幕可以显示选项、显示对话交换的文本、显示可以购买的食物的图像等等。车辆具有安装在其计算设备上的“浏览器”或接口，该“浏览器”或接口用作本文公开的浏览器。数据的订购和交换完成后，实体(Panera面包)可以询问用户是否准备支付。用户可以说“是”，并使用Panera Bread和浏览器之间的浏览器API，并利用此处公开的任何支付机制(包括浏览器和支付服务之间的辅助API)来处理支付。用户的系统可以包含家庭的图像，或者车辆可以包含用于为车内所有人拍照的摄像头(例如，后视镜摄像头)。系统可能会询问详细信息，例如聚会中有多少人，您是否需要婴儿座椅。可以提供社交媒体数据，例如生日信息。支付处理将如本文所公开的那样发生。然后，该家庭可以坐下来，并可以向该餐馆提供该家庭的图像、姓名、描述、人数等。餐馆的工人然后可以利用图像找到有食物的家庭。餐馆甚至可能会说“您的订单已经支付，请在进入时进入左侧的23号展位。”该系统可以将家庭放置在特定的位置，以带来食物并协调他们的坐姿。任何特殊的需求也需要传达，例如用户的喜好和愿望。当服务员把食物带到家人的摊位时，他可以说“欢迎琼斯一家，祝詹妮生日快乐！这是你的晚餐。”食物已经付费，并且在一方面，用户甚至不需要使用他们的移动设备。在另一方面，所有这些处理可以在移动设备上完成。该系统还可以处理积压的订单，以便用户可以订购、支付并被告知他们应该在25分钟内回来，因为他们将准备好食物并准备好餐桌。
如果一个封闭区域中有众多餐馆，则WiFi服务或其他服务可使家庭从一个停车场提供服务的不同餐馆中进行选择。可以基于选择哪个餐馆来提供和实现不同的语音语法。该系统可以为家庭提供订单号或密码，也可以用来识别他们。也许与他们的移动设备协调，可以显示一个数字，这样他们只需要将其移动设备放在桌子上就可以看到服务员ID。
类似的方法也可以通过这种方式进行驱动，以便将汽车识别信息提供给餐厅，以便工人可以看到汽车，知道订单是什么，并在他们开车到窗户时简单地将其交给用户。用户将不需要在窗口上或与工人一起使用移动设备来移交信用卡或支付现金。如上所述，可以在汽车内的任何位置提供供任何驾驶员或乘客使用的指纹读取器，以用于安全购买。
通过电子方式，汽车还可以知道来自另一个家庭的移动设备也在汽车中。如果两对夫妇外出吃饭，并且他们希望各自为各自的饭菜付费，或者任何物品要由一群人支付，则系统可以处理让两个人支付的选择，并且可能会发生歧义对话，在移动设备和车辆系统之间进行任何形式的协调，从而使适当的当事方为他们的部分付费，并且所有用户都在进餐或消费。
该方法可适用于用户可能开车去该公司的任何公司，并参与对话以订购和支付。然后可以向工人通知购买情况，然后用户可以去沃尔玛，让工人将物品带到汽车上(基于位置的数据可能会有所帮助)或在特定的取货地点。或者，用户可以去查找物品，并让工作人员能够在移动设备上扫描条形码或具有图像识别功能，以便用户可以随身携带物品走出大门。
可以理解，浏览器API可以应用于任何设备和任何物联网场景。例如，冰箱可以配备浏览器或界面，该界面可以与商家进行通信以通过单击来订购和支付食品杂货，并利用浏览器API或API的组合。可以配备包含库存物品和闹钟的架子，用于电力、水或天然气的公用程序接口或任何其他类型的设备，以实现此处公开的功能，以便无需向用户注册即可向实体提供支付，而向该实体提供其支付信息。例如，任何对象，诸如诸如路由器、交换机、服务器、存储设备之类的IT设备，都可以应用如本文所公开的支付方法。其他示例包括环境监视器、公共安全车辆、销售点终端机、自动售货机、标牌、灯、飞机、收费站、泵、阀门、输送机、管道、电机、驱动器、组装和包装设备、容器、手术设备、泵、远程医疗设备、植入物、数码相机、电源系统、阅读器、洗衣机和烘干机、各种仪表、电视、MP3设备、游戏机、涡轮机、风车、电池、发电机、燃料电池、电钻、HVAC系统等。如本文所公开的，任何一个或多个这样的设备可以利用浏览器支付请求API及其相关技术来处理购买信息。
通过浏览器API接口提供的其他功能
就在Internet上的通用接口中处理支付而言，使用浏览器API接口(即W3C.org支付请求API，以引用方式并入本文)非常有用且高效。这是革命性的。在其他领域，购买按钮现在在社交媒体、Facebook等中非常普遍，因为这些按钮在人们所在的地方和花费时间的地方都可以看到。现在，使用浏览器API，问题不再是在人们所在的地方带来购买按钮，而是与浏览器API接口有关的操作，这简化了支付方法。现在，整个网络上的人们都将使用一个通用的界面来购买商品和服务。W3C标准支付请求API由Microsoft、Google、Mozilla、Samsung、Safari(专有版本)等实现。本公开内容涵盖使访问其他服务更有效的其他功能。
例如，支付界面可以补充有诸如按钮、下拉菜单或超链接之类的可交互对象，当与之交互时，可以向用户呈现他们所进行的购买的清单以及每个商品的相应处理。这类似于在Amazon.com中向用户提供的帐户信息，该信息列出了他们通过Amazon.com进行的所有购买的状态。在这种情况下，可以将购买报告给中央代理，以便在不同网站(不仅仅是亚马逊)上进行购买。它也可以包括amazon.com。因此，在浏览器API界面内，用户可以看到“管理购买”对象等。用户可以在其浏览器的选择字段中选择一个代理。例如，不同的代理可以提供可以集成到浏览器API中的服务，从而可以提供标准化的调用和响应。或者，用户可以超链接以从帐户/购买管理代理接收信息，该信息将与支付界面集成，并使用户能够以有效的方式访问其商品购买历史和状态。
因此，可以呈现一个用户界面，该用户界面可能看起来像在标准商家网站上，但在浏览器API内，该API提供了对用户帐户购买历史和信息的访问。这使跨多个网站的采购汇总变得更加容易管理。“帐户”可以涵盖该用户或家庭中的一组链接用户或其他链接在Internet上的所有购买。用户将要求轻松访问所有购买的商品，因为他们逐渐习惯于使用常见的购买技术，例如我们的浏览器API可以使用我们的商品。因此，由于用户将要求访问权限来控制、审查和进一步管理其购买，因此他们将期望并要求这种便捷的可访问性。
商户网站可以根据需要提供对浏览器API的调用以启用此类功能。例如，可以设置一个参数，当用户进行购买过程时，商家可以打开或关闭难处理对象的浏览器API界面中的显示，该显示使得可以访问用户帐户。因此，商家可以通过不提供这种访问来简化他们的购买过程。商家当然还可以包括浏览器API的授权，以便能够将与购买相关的基本数据传达给服务，该服务可以存储购买的商品2并将购买历史添加到可以通过这种难处理的对象访问的购买历史。因此，浏览器API不仅可以成为将支付方法与用户和商家联系起来的代理，而且还可以成为将购买数据传达给将接收所有此类购买并将它们组合在一起的完整服务历史的服务或系统的代理，该历史记录可以由用户在许多不同平台上访问。在一个示例中，可以在移动设备上提供单独的“应用程序”，其可以简单地接入并访问这种服务器并提供用户管理其所有购买的能力。例如，此类“应用程序”或服务可以吸引所有Amazon.com购买以及报告给该服务的互联网上的购买，并提供目前仅在Amazon.com或单个商家网站上可用的所有功能和控件。
另外，从与浏览器API界面进行交互的状态，系统可以知道用户是谁，他或她的支付信息以及有关所购买商品的信息。因此，从该界面以及过程中的任何状态、系统可以做广告、加售、建议替代商品、提供折扣、提供附加服务、提供保修等。此外，从该界面可以提供社交网络机会。因此，可以向用户提供指向其与该商品相关的Facebook页面或Pinterest发布的链接。可以通过从浏览器中检索到的数据来建立和启用处于特定相关状态的“深层链接”到社交网站。例如，如果买家的朋友在一周前购买了相同的商品并发布了有关商品的信息，则系统可以识别该信息，并在用户完成支付界面上的购买后出示商品，这会将用户转换为以该好友的发帖位置定位的社交网络供稿。例如，有时候，Facebook feed可能有10或100个帖子，而很难找到朋友的特定帖子。可以从浏览器API支付界面过渡到与刚购买的商品有关的特定社交网络发布。系统可以在购买前、购买中或购买后在界面上显示一个按钮，该按钮显示“tweet this Purchase”或“在Facebook上发布此购买”。这可以在任何社交网站或甚至在其他任何网站例如商家网站中发生。任何其他网站的特定功能都并入本文，并假定为本公开的一部分，例如Twitter、Facebook、Facebook Messenger、短信、电子邮件、Pinterest、Instagram等的工作方式。换句话说，系统可以分析购买、用户信息、支付历史记录、购买者和朋友/家人周围的社交媒体数据等中的一个或多个，以获取与购买相关的数据，并在支付方法的任何阶段展示社交媒体对象(或任何其他过渡对象，例如商品购买的帐户对象)(在支付之前，因为用户启动了导致通过浏览器API进行交互的过程，在支付之后，等等)。例如，系统可以呈现一个对象，该对象被配置为以某种状态将用户转换为FacebookMessenger，就像用户选择了上周购买商品的朋友发送消息一样。该对象可能表明，通过按此按钮，用户将和John一起转换到Facebook Messenger，后者将收到一条消息，并且可供您键入。
此外，所呈现的对象可以被配置为在社交网站上的发布。例如，拥有Facebook帐户的用户可以在支付界面上授权一个对象，该对象可以利用有关购买的信息(商品、大小、编号、描述等)，并可以在其Facebook时间线上准备有关购买的发布。因此，通过与对象交互，系统可以配置和准备针对Facebook的发布，该Facebook预先配置了商品的图片、描述、甚至是购买按钮，供发布者供用户的追随者购买。这是一种新型的广告，用户可以通过购买商品来发布广告。用户甚至可以插入他或她自己的评论。因此，通过单击对象，可以向用户显示显示商品详细信息的帖子，并有机会输入有关购买的文本“我刚刚获得了GoPro版本10–非常激动”，并让系统将发布信息发送给其关注者，包括购买选项。这将是不同的，因为它是来自用户的私人帖子，不一定来自商家。然而，像Shopify或Bigcommerce这样的公司也可以提供后端处理服务来启用该过程。过帐人员甚至可以通过过帐购买商品获得折扣。折扣通知可以在购买过程的任何阶段进行。例如，进行购买时，如果用户单击社交媒体按钮并导致通过他们的社交网络从他们那里发送可购买的帖子，则商家可以给予5％的折扣。库存跟踪可以确保仅在库存中有其他商品时(用户刚刚购买了商品)才显示购买选项或购买过程机会。如果没有更多物品，则过帐可以显示有关何时补货的信息。
该过程本质上是在社交网站上的非商家发布，但是具有商家组件。它之所以强大，是因为人们会看到它是个人发布而不是商家发布，但仍将其配置为可购买的交互。注意，这种发布或导致这种发布的对象也可以发生在支付请求API接口之外，但可以在任何网站(例如amazon.com或使用任何支付机制的任何商家网站)上运行。在某个时候，用户登录并且系统具有足够的信息，能够转换到社交网站以进行配置的发布。可以在社交媒体网站上的商家和私人张贴者之间建立关系，以便在后端流程中将私人帖子与现在许多商家使用的可购买期权处理联系起来。
在这方面，从个人用户的发布可以在某种意义上在用户和商家之间“联合品牌化”。演示文稿可以包含可能将用户的个人资料图片和商家徽标结合在一起的图形。该过程可以在以下情况下工作：如果用户要亲自发布可购买的发布，则系统可以动态地或预先生成与发布相关的联合品牌形象，以便发帖的收件人不仅可以识别出该商品是佳能相机还是梅西百货的商品，而且还可以由其朋友亲自发帖，而不是企业发帖。这种方法可以增强收件人对基于该过帐进行购买的信任。
购买界面还可以包含一个过渡到Facebook Messenger之类的选项。用户可能正在进行购买并且有疑问，使者可以启用与商家有关商品的交互。用户可能要确认其具有2年保修或4轮驱动器或任何问题。系统可以将最终购买转换为在Messenger应用程序中完成，或者转换回API接口以确认购买。API可以包括适当的调用和功能，以实现往返于接口的此类转换。当然，此过程可以包含任何与商家进行交互的应用程序，而不仅仅是FacebookMessenger应用程序。
其他选项可用于使人们能够通过社交网络私下发布商品，并获得交易、折扣、积分、积分、免费商品等。例如，社交网络用户可能会看到amazon.com或canon.com发布的商品广告，例如cannon 7D相机。当前，有“立即购买”或“立即购买”按钮或与操作关联的其他按钮。建议是添加另一个按钮，用户可以在其中使用相同的结构自行发布该商品。在这种情况下，发布变得个性化，用户可以添加评论或自己的照片(可能与他们购买的商品或视频一起使用)并发布。所发生的变化是，发布是通过他们自己的社交网络进行的，但可以保留“立即购买”选项，以便可以转换用户购买该商品。这是一个比较个人化的帖子，因为它来自朋友而不是公司。用户也可以在购买商品后得到这样的信息。因此，假设用户购买了佳能7D相机。他们可能会看到佳能7D相机发布，并可以选择重新发布，以便下次购买时可以减价10美元。可以在他们的新闻源中将发布配置为正在准备并配置为重新发布。例如，它可能不会说“买这台相机”，而是会说“朋友，我刚买了这台相机并喜欢它-亚马逊正在以折扣价出售给您”。因此，当用户重新发布发布时，它是从他们发布到其关注者的，并且已经有些个性化了。这将使用户可以轻松共享商品并配置发布以便于购买。可以由社交网站、单独的支付处理器，商户网站通过Apple Pay或Androidpay或浏览器支付请求API或Amazon.com或传统的支付方式来处理购买。在这种情况下，购买者还可以获得结构性折扣，例如，如果从朋友发布的商品中购买商品，则可以享受一种折扣，或者如果自己在自己的社交网络上购买商品并将其发布，则可以获得额外的折扣。如果他们在购买后在社交网络上发布，则额外的折扣可以记入他们的支付帐户。还可以包括“重新定向”方法，其中买方可能在购买时可能不会在其社交网络上重新发布购买或商品，但是可以对系统进行编程，使其在一天、一周或某个智能时间之后为该用户发布机会，如果他们张贴他们上周购买了该商品并喜欢的话，则给予他们5美元退款或优惠券、折扣、里程或其他优惠的机会。
此示例的好处是，一旦用户购买了商品，用户就会在一段时间内对购买的商品进行测试或试验。然后，用户可以在社交网络上发布他们对商品的感觉，例如他们对相机的热爱或吸尘，并建议朋友购买。系统可以获取有关商品使用情况的基于网络的某种反馈，这可能会触发重新发布。例如，用户可以购买iphone 7，并且系统可以确定在用户拍摄50张照片后，他们应该选择几张进行个性化发布。除商品和用户的图片外，发布内容还可以包含购买选项和个人评论。
上述概念的另一方面是如何处理深层链接转换。例如，如果John在amazon.com上发布了某商品的信息，则他可以立即单击商店或立即购买(或类似标签)以浏览和/或购物。在某些情况下，由于John知道发布信息，因此如果他单击某个对象，系统可以将其转换为amazon.com中的深层链接，在该链接中他将自动登录，他的支付和交货信息已经存储，并且他可以在过渡后立即点击购买，或者只需点击几下即可进行购买。amazon.com的“状态”是与用户和商品相关联的深层链接，以便于购买。可以利用从浏览器访问数据以启用深度链接一键购买状态，例如访问一键购买参数。
回到个人商品发布中，由于John可能会重新发布商品发布，因此他的100个关注者可以看到该发布并且也可以进行购买，因此可能需要进行其他信息的转移或共享。系统将跟踪每个收件人，以便所有单击立即购买的收件人也将转换为amazon.com中的深层链接，并且处于登录状态并且可以一键或单击几下进行购买，而无需手动输入支付信息或交付信息。可以在社交网站、商家网站、浏览器、支付处理器和/或任何其他实体之间建立API，以处理过渡和后端处理以实现上述结果和过程。
一方面，机会和概念包括社交网络结构之间的过渡。例如，用户可能会在其新闻提要中获得Facebook广告，并希望将其重新发布到其Pinterest帐户中作为可购买的图钉。该系统还可以将过帐从一种格式转换为另一种格式，同时保留可购买的配置。如果需要从一种支付结构过渡到另一种支付结构，则也可能发生这种过渡。例如，当用户在Facebook、Pinterest、Instagram、Twitter上以自己的身份将商家发布重新发布到amazon.com时，发布可能会从深度链接处理过渡到浏览器API支付或Android支付方式，或者它们是否从一种社交网络过渡到另一种。用户首选项也可能会更改，并驱动发生哪种类型的转换。如果amazon.com已经存储了用户支付和地址信息，则转换可能仍需要在浏览器中访问数据，例如一键购买参数集。
从浏览器API支付界面的另一个示例过渡可能是“继续购物”按钮或对象，该按钮或对象可能使用户回到网站中的购物状态。可以将用户带到一个新的搜索字段，就像没有进行任何搜索一样，或者用户可以过渡到部分搜索，而该部分搜索将一直到他们购买的商品的最终状态。
还可以增强浏览器API的功能，以提供其他功能，例如选择购买2个或更多商品，并自动调整价格、更改参数(颜色或大小、数量等)。
附加功能也可以独立于开发浏览器API的基本购买过程。商家网站和/或浏览器、用户或其他实体可以通过调用API来启动此附加功能。例如，如果将浏览器API修改为包括将用户与他们的支付历史记录和管理机制联系在一起的附加功能，并且商家网站希望在浏览器API界面上提供该功能，则可以设置参数，或者可以与与浏览器的其他通信相关联的调用来打开购买历史管理组件。如果启用了该功能，则浏览器可以通过另一个API或其他机制与一项服务交互，该服务在网络上存储该用户的支付历史记录并以信息和管理功能进行响应。浏览器API可以帮助格式化该信息并显示在浏览器API界面上，以及棘手的按钮、超链接或下拉菜单，当用户与之交互时，它们将显示购买历史，以供用户查看和/或采取行动。如果选择了该功能，系统还可以过渡到用户，再过渡到用于管理购买的单独网站。这种方法的好处是，它将在界面上为用户提供其他功能，该界面将在购买互联网时标准化。它通过以较少用户点击或较少交互的方式提供对服务的访问来减少“业务价值链”，因为可以通过浏览器API正确启动对各个服务的访问，该接口是一个接口很多人会用。
一方面，商家可以提供其提供的服务种类的报告。从某种意义上说，这可能与提供授权的支付机制列表的商家类似，例如Visa、Discover和MasterCard。有权访问用户支付机制的浏览器API会以匹配项进行响应，以便可以继续支付。在此附加上下文中，商家可以提供可通过浏览器API接口执行的替代服务列表。例如，商家可以提供购买历史管理访问、Facebook发布访问、Pinterest访问和FaceTime访问，其中用户的个人朋友已经进行了类似的购买。在用户个人资料中，用户还可以选择他们希望或可能想要访问浏览器API界面的替代服务类型。因此，如果用户希望通过其API访问他们的购买历史并且是Facebook的成员，则确定浏览器API接口应该为Facebook提供一个对象，为购买历史提供另一个对象。
然后，如果用户与Facebook对象进行交互，则系统可以执行许多不同的功能。该系统可以简单地将用户转移到Facebook及其常规新闻源。系统可以在用户的时间轴上生成发布的预览，该预览连接到特定购买并针对特定购买进行配置。还可以呈现选项，例如，确认这种发布，如果可以用购物按钮或可购买的按钮呈现发布，则接受5％的折扣，等等。这些参数可以通过API与其他数据一起分发，也可以根据需要连接到备用服务。
例如，可以在界面中显示一个对象，该对象指示用户的最好的朋友买了同一顶帽子，并且他们想谈一谈。该按钮可以发起呼叫、FaceTime、Skype交互以及电子邮件、文本等。可以基于双方的能力、过去的历史等等来发起任何类型的通信。因此，一方面，浏览器API的扩展超出了仅仅为了使支付方法更简单和统一的目的而提供浏览器和商家之间的通信。可以将浏览器API扩展为任何其他类型的服务或信息的代理。在支付方法中，某些信息是已知的，例如成本、商品、用户、地址、电子邮件地址等。可以利用该数据的任何其他服务或功能都可以通过浏览器API加以利用，以在用户所在的位置或位置添加该其他功能。因此，通过添加该新功能，该新功能可能与或可能不与购买直接相关，用户转换或访问这些附加服务的能力，无需离开商家网站并转到其他网站或单独网站即可提供Facebook发布，用户只需最少的交互即可访问并实现此附加功能。
可以通过浏览器API界面显示的选项类型也可能会根据交互状态而有所不同。换句话说，尽管过程很简短，但整个过程存在不同的状态。有一个状态会在最终确认之前显示支付和购买摘要。最终确认后会有状态，依此类推。可以根据交互状态提供不同的服务。如果状态是在最终确认购买之前，则可以显示一个对象，该对象提供可从第三方服务网站获得的评论或评级摘要或有关商品的信息。这可以为用户提供可能仅通过商家网站无法获得的有关商品的其他信息。购买之后，实体可能会提供与商家可能有关联或无关的担保人、服务计划、其他购买选项等。商家可以通过API接口协调和授权此类其他活动。例如，商家可以设置或发送参数，该参数指示可以允许授权的保修提供公司通过浏览器API接口提供保修机会。以这种方式，商家可以通过界面控制这种附加功能的级别。
在某些情况下，浏览器API界面甚至可能根据正在执行的功能添加其他页面或交互。因此，除了仅添加取决于功能的可选对象之外，浏览器API还可以呈现附加接口或更多接口，该附加接口或多个接口使用户能够进行附加选择并实现或执行所提供的功能。可以将其作为界面的一部分来呈现，就像将其作为商家网站的一部分一样呈现，也可以清楚地启动从商家网站到另一个环境的过渡，例如社交网络页面、网站、应用程序等。在这些情况下，重要的是用户要与他们进行交互的用户感到舒适。因此，浏览器API在商家网站上作为支付方法的一部分呈现。此附加功能也可以在网站上显示，也可以单独显示。
此外，浏览器API接口可以扩展为包括其他功能。用户可以将扩展安装到界面，就像他们将扩展安装到浏览器一样。可以安装将在界面中显示的AmazonAssistant。可以使用通过接口从购买获得的数据进行预处理。例如，用户购买一条裤子。系统知道用户的腰围和裤子的样式。亚马逊助理可以在预填充的输入字段中显示“皮带”或“腰部棕色皮带34”一词，以便可以轻松地在Amazon.com上购买配件。可以设置其他参数，这些参数将使搜索结果适合您的需求并与刚购买的商品相匹配。一方面，可以通过浏览器API接口访问添加到浏览器的扩展。换句话说，可以从API接口而不是仅从主浏览器接口访问安装在浏览器上的Amazon助手。
可以在API接口上显示一个对象，该对象可以进行进一步的搜索，例如Google搜索或eBay搜索。还可以设置参数，以根据通过API进行的购买来缩小或过滤搜索活动。例如，如果用户刚刚购买了商品，则可以显示一个Pinterest搜索字段，该字段预先填充或未填充有一个术语，该术语使用户能够从API界面过渡到Pinterest以搜索和查看配件或类似物品。
虚拟现实
浏览器API也可以在其他上下文中使用，例如虚拟现实。例如，如果用户有机会使用虚拟现实的护目镜或头戴式耳机来购买诸如衣服之类的物品，则可以应用浏览器API。可以对浏览器API协议进行修改，以专门提供该上下文。例如，上面已经讨论了出于安全目的提供适当的用户标识。使用指纹授权或安全码来确认它是正确的购买者。虚拟现实的护目镜可以放在用户的脸上。可以将元素内置到护目镜中以提供不同类型的用户标识。例如，护目镜可能已经内置了用于扫描用户的虹膜的机构，而不是要求用户提供指纹授权。虹膜扫描可以匹配用户的身份，是授权购买的机制。特定的用户手势或动作可以指示购买确认。此外，一些虚拟现实的护目镜将在其屏幕上接收移动设备。他们提供了一种配置，使用户可以连接他们的移动设备，然后将其布置为虚拟现实体验的护目镜。移动设备可以在其背面配置有指纹扫描组件，以便用户在观看虚拟现实体验的同时，只需举起手并触摸指纹扫描器即可确认购买。通常，指纹扫描仪位于移动设备的正面，以方便用户访问。然而，当移动设备以护目镜配置安装时，指纹扫描仪将很可能位于护目镜内部，并且用户不容易访问。在另外方面，可以将指纹扫描仪放在护目镜上，以便通过蓝牙、近场通信、有线连接或任何其他机制，可以将护目镜上指纹扫描的数据传送到移动设备，以进行进一步处理以授权购买。在这方面，移动设备可以具有两台指纹扫描仪-一台用于正常使用，而一台位于背面，用于在虚拟现实耳机中进行购买。
其他方面还可以包括护目镜配置，该护目镜配置能够识别前额形状、鼻子形状、用户的DNA数据、温度数据、运动模式、语音、面部识别等，从而出于购买或其他原因出于安全目的识别个人。例如，可以建立特定的闪烁模式以确认用户的身份。这些各种方法可以使用浏览器API确认或替换指纹或安全码以确认购买。在虚拟现实环境中使用这些方法可以减少用户在虚拟现实环境中完成购买所需的点击或互动次数。因此，本公开的一方面可以包括在护目镜和配置有护目镜的移动设备之间的电子协调，以向用户呈现虚拟现实体验，其中，移动设备利用浏览器API来完成如本文所公开的简化的购买过程。当然，任何用于虚拟现实的耳机都可以包括一个浏览器组件，无论它是可分离的移动设备的一部分还是内置屏幕，它都可以包含浏览器API。在一个示例中，使用像HTCVibe这样的VR耳机可以使用户在虚拟现实世界中进行交互，就像他们在商店里进行购买一样。虚拟环境中的交互可以包括试穿衣服或玩玩具。用户可以在虚拟环境中进行购买，VR耳机和/或协同计算设备可以通过浏览器API处理从虚拟世界中进行的支付。VR头戴式耳机内的传感器能够感应到头部的动作或手势，可以将该动作转换为购买互动，从而促成购买。此外，VR头戴式耳机与其他设备(例如计算机或游戏设备)之间的任何协调都可以用于使用浏览器API完成购买。因此，可以将任何步骤或任何过程划分为VR头戴式耳机和任何其他设备，以完成一种改进的购买方式。
问题是如何将浏览器API整合到虚拟现实环境中。使用Apple Pay，您必须使用指纹来确认购买。其他方法可能需要CVC代码或语音身份验证等等。对于Apple Pay等指纹环境，解决方案是在用户开始虚拟现实会话时接收指纹。当用户将移动设备安装到头戴式耳机或带有完整的头戴式耳机而没有可分离的移动设备时，头戴式耳机可以包括指纹读取器。通过预先接收指纹，用户可以在虚拟环境中进行购买的同时利用存储的认证。用户甚至可以使用手势或在虚拟指纹读取器上提供指纹来购物并进行虚拟购买。当在虚拟环境中提供购买指示时，耳机或移动设备可以访问会话开始时提供的指纹授权，并应用该身份验证完成购买。虚拟环境中的用户甚至不需要使用指纹来授权购买，甚至可以真正使用一键式购买进行支付。不管用户在虚拟现实环境中如何表示希望支付，所记录的较早的指纹授权都可以用于任何虚拟支付。例如，环境可以模拟用户向某人提供现金并购买商品，但是在后台，系统可以处理Apple Pay、Google Wallet或Android支付。在虚拟环境中，可以虚拟地或在VR会话之前提供任何必需的身份验证(例如CVC代码或语音、手势或任何其他确认数据)以用于购买。例如，用户可以在开始会话之前提供CVC代码，或者可以提供支付信息、地址信息等，以使虚拟现实环境能够利用浏览器API来请求和接收用于处理支付的支付数据。
在一个示例中，Apple pay通过关联两个设备来利用浏览器API。用户在购买不具有指纹授权机制的便携式计算机时，该便携式计算机与iPhone通信，该iPhone包括一个安全元素，该安全元素存储与该用户关联的支付信息，并且具有指纹授权对象。当用户购买膝上型计算机时，用户通过单独移动设备上的指纹授权来确认购买。在虚拟现实场景中，用户佩戴的虚拟现实耳机，通过该虚拟现实耳机，用户将获得虚拟现实体验，该虚拟现实耳机可以包括配置为传达请求和响应的浏览器(或类似的代理软件)，或通过浏览器API在商家与浏览器之间进行的任何其他通信。当要在虚拟环境中进行购买时，耳机可以与具有指纹授权机制的移动设备进行无线通信。在这种情况下，当需要指纹授权时，还可以配置虚拟现实耳机，以口头、视觉或任何其他方式提供指令，将用户定向到用户需要触摸以提供指纹授权的物理移动设备。可以包括该方面以向虚拟现实环境提供物理组件，以使用户能够安全地进行购买。
同样，在虚拟现实购买环境中使用浏览器API时，使用的头戴式耳机或其他设备可以充当代理或浏览器。如果将移动设备用作头戴式耳机的一部分以创建VR环境，则该移动设备可以按此处公开的方式运行，以提供用于支付和用户数据的存储设施，并且浏览器(Mozilla、Chrome、Safari、Opera等)可以配置为接收商家的支付请求并按照协议进行响应。如果头戴式耳机不使用可移动设备，而是一个独立的系统，则可以将其装入浏览器或类似的软件，该软件也配置了浏览器API，并且还可以类似的方式存储支付和用户数据(以及此处引用的任何其他数据)。可以在自带耳机中提供功能，包括用于用户识别的指纹读取器或其他生物特征读取器。然后，当用户参与虚拟现实环境时，如果他们去商店或以虚拟方式购买商品，则系统可以将该购买视为对待在用户单击购买按钮的商家网站上的购买。用户可以虚拟地提供信用卡，或虚拟地使用Apple Pay，或在虚拟商店中的销售点虚拟地提供现金。用户实际上可以在计算机上进行在线购买。进行购买的任何虚拟情况都可以适用于耳机中提供的浏览器API。在虚拟互动的某个时刻，将进行兑换或确认支付的确认，这时，代表商家或卖方的网站或实体可以向与头戴式耳机关联的浏览器API发起支付请求，并根据协议为该实体提供可用的支付机制，并通过浏览器API接收支付数据、地址数据，用于处理支付的一次性使用令牌等，用于处理购买。例如，在这种情况下，用户可以走过虚拟购物中心并试穿衣服、看玩具或书籍并进行购买，然后可以购买在虚拟世界中购买的实物并运送到用户家中。
与浏览器API关联的协议可能会针对虚拟环境进行修改。例如，可以在通过浏览器API从商家到浏览器的通信中设置一个参数，该参数指示该商家是虚拟商家，并且不会单击任何购买按钮，但是许多其他类型的触发器会触发该过程。可以设置参数，该参数指示由于用户处于虚拟环境中，因此当用户开始使用虚拟环境时将接收并存储指纹授权，如果用户在虚拟体验期间进行了购买，将可以访问该指纹授权，以减轻对实时指纹授权的需求(通常会发生这种情况)，例如Apple Pay，但在虚拟环境中将不方便也不可能。因此，作为浏览器API协议一部分的来自头戴式耳机的响应可能表明指纹授权已存储，并且当前可用以进行购买。可以通过针对虚拟现实上下文的浏览器API的修改版本来传达在虚拟现实环境中有效使用浏览器API所必需或有帮助的任何参数或信息。
该方法也可以用于进一步简化普通移动设备的过程。例如，系统可能要求用户在启动设备时以及在一段时间内可以为Apple Pay或类似商品访问指纹时使用指纹。通常，用户必须单击“Apple Pay”按钮，然后提供指纹授权。但是，如果先前已获得授权，则可以与单击Apple Pay按钮相关联地应用该授权，并在单击Apple Pay完成购买后无需使用指纹。如果在指纹授权下将使用时间设置为例如30分钟，则系统可能会发出一条通知，告知需要重新授权，并且用户有5分钟的时间在没有指纹授权的情况下进行购买。
虚拟现实环境中的浏览器还可以包括或可以访问其他数据，例如衣服大小、鞋子大小等，尤其是如果用户在虚拟现实环境中购物时。该数据可以帮助驱动呈现给用户的内容，使其适合用户的大小或其他偏好。
下载浏览器
本公开的另一方面包括一种服务器，该服务器存储必要的数据以通过网络向客户端设备发送或下载浏览器更新或完整的浏览器。该过程包括：接收或识别提供浏览器或更新的浏览器的请求；以及将浏览器或浏览器更新下载或传输到客户端设备以安装在客户端设备上。下载的浏览器包括必要的功能，以通过支付请求API接收和处理支付请求。因此，该过程包括下载包含或配置有支付请求API功能的浏览器或浏览器更新。安装后，网站可以启动对浏览器的支付请求调用，浏览器将执行通过支付请求API传达支付信息的过程，使网站无需用户输入支付帐户信息，交付信息即可处理购买交易等等。
一种方法包括将数据或代码从服务器下载到客户端，以使数据在安装在客户端上时安装或更新浏览器。浏览器被配置为在被激活时执行包括本申请中公开的任何功能的操作。这些功能包括操作浏览器支付请求API，或使用下拉菜单提供浏览器和第二网站之间的通信，以转换到第二网站，该下拉菜单在接收到用户输入后显示，并且当选择一个对象时，会将用户从一般输入字段转换为在已转换为第二网站的状态下进行预处理的第二网站，在该状态下，用户将以基于处理用户输入的方式呈现的搜索结果转换为第二网站，就好像用户输入已经输入到第二网站的第二输入字段一样。
从第一网站过渡到第二网站
图20A示出用于从一个网站过渡到另一网站的方法示例。方法示例中的步骤可以以任何顺序执行，可以以包括附加步骤或排除所描述步骤中的某些步骤的全部或一部分的其他组合或排列来执行。该系统可以在第一用户界面中呈现与经由浏览器处理的第一网站相关联的第一输入字段(2002)，并且分析来自用户到第一输入字段中的输入，以确定用户是否希望执行搜索或进行购买以做出确定(2004年)。如果确定指示用户希望进行购买，并且除了输入之外没有其他用户输入，则系统可以将用户从第一网站转换到可以通过购物车模型处理商品购买的第二网站(2006)。系统可以使用输入来预填充与第二网站相关联的第二输入字段(2008)。
系统可以使用第二输入字段中的输入对第二网站进行预处理，以使用户处于自动转换后的状态，在该状态下，可以通过用户的一键式操作来处理与输入关联的商品以进行购买和交付(2010)。预处理第二网站可以包括将用户数据从第一网站和浏览器中的一个传输到第二网站，或者自动浏览第二网站的购物车模型以产生一种状态，可以通过单击操作来处理要购买和交付的商品。该系统可以使用第三输入字段中的输入进一步预处理第三网站，使得用户处于自动转换之后的状态，在该状态下，可以通过用户的一键式操作处理与输入关联的商品以进行购买和交付，并第三个网站，供用户在浏览器中选择。
预处理可以根据具有各种偏好的用户简档来进行。例如，在与第一个网站或浏览器关联的用户配置文件中。用户配置文件可以利用信息，例如支付帐户数据、交付数据、首选项(例如不要单击以接收任何电子邮件通知)以及在处理购物车模型时可以做出的任何其他可能的选择。然后，应用程序、浏览器或网站可以通过API在后台进行通信，并执行所有必要的导航和输入，这样就可以在用户准备好“单击”并进行最终购买和交付的状态下，自动向用户显示第二个网站的程度来处理此类输入。该API可以包含第二个网站所需的所有必填信息，并填写所有必要数据以完成购买。例如，第一个网站可以处理支付，第二个网站可以通过填写订单和处理交货来确定订单。第一个网站或浏览器或应用程序可以保存各种购物车模型可以并且在处理购买过程中要求的所有可能的信息。作为选择、特定的第二网站是用户可能从其购买商品的网站。第一网站或浏览器通过API建立到第二网站的连接，并具有预处理输入所需的各种信息。如果第一网站是支付服务，则第一网站还可以通过浏览器API通信以从商家网站接收指令以处理支付。诸如用户输入之类的数据标识了他们想要购买的商品，以及任何其他生成的数据，这些数据都有助于通过一键式输入来缩小和区分要展示的商品。例如，用户可以输入“iPhone 5S 32GB”，但不能输入颜色。该系统可以选择一种最流行的颜色，并将该数据提供给第二个网站，以缩小显示哪种模型的范围。该系统还可以显示次要选项，以便在主要选择颜色错误或不是想要购买的商品时，可以通过第二个网站轻松访问其他选择，以进行潜在选择。
接下来还描述了进一步的增强。以下涉及从一个网站(社交媒体网站、浏览器搜索字段、搜索引擎或任何网站或州)过渡到另一个网站或在网站上进行支付处理的概念。一方面，系统在目的地网站处使用深链接，该深链接被配置为用户已搜索商品，登录和/或输入支付信息的状态，从而用户无需输入支付信息或登录即可完成购买过程。如果目标网站已经存储了用户的支付和地址数据，则转换可以包括从浏览器检索其他数据，例如一键购买参数或其他数据，以用于过渡到一键购买状态。
一个方面还涵盖了从目标网站开始的步骤，例如Facebook上的amazon.com广告。当类似amazon.com的网站向社交网站上的收件人提交帖子时，它会包含有关收件人身份的信息。如果该收件人已在amazon.com上注册，并将其支付信息提供给amazon.com，然后，当收件人在Facebook(任何社交网站)上的帖子中作为广告或新闻源单击“立即购买”对象或表示希望进行购买的对象时，收件人可以使用“深层链接”从与商品关联的社交网站发布过渡到带有“深层链接”的发布网站(例如amazon.com)，在该深层链接中，用户会转换为该网站，处于一种状态，就好像用户已经搜索过该商品，并且该网站处于用户可以“一键式”购买该商品的状态。这是可能的，因为从社交网络发布到网站的过渡包括使用户能够登录到网站并为用户提供一个界面，使他们可以用最少的点击就可以购买商品。浏览器存储的信息可用于实现深度链接目标降落。
在另一方面，第一网站可以是社交网站，并且目的地网站可以是商家网站。一键式方法以深度链接状态登陆到目标网站，以便用户可以进行一键式交互(或两次点击或其他次要确认互动，但无需手动输入支付，地址等)以实现购买，可以通过浏览器支付，一旦用户登陆到目标网站，就需要调用应用程序编程界面。在这方面的方法可以包括通过社交网站接收商品的发布，其中，社交网站接收发布的商品并将其从发布实体发送到接收实体，以及在商品数据库中该发布与要购买的商品不相关时，该方法可以包括通过社交网站传输帖子，而无需选择购买。这只是新闻订阅源上的正常发帖。当发布在商品数据库中引用商品时并由此指示与销售相关的意图时，该方法可以包括当用户与之交互时，由社交网站将支付方法发起对象插入该发布中以产生商品发布，该支付方法发起对象，指示用户打算在商品发布中发起购买商品的过程，并通过社交网站发送商品发布以及与该商品相关联的支付方法发起对象，其中支付方法发起对象可以包括按钮、下拉菜单或超链接之一，并接收与支付方法发起对象相关的交互。一方面，当发布发生时，发布实体可以包括购买选项对象。可以将购买选项对象配置为引起从社交网站到发布实体网站的深层链接转换。
基于交互，该方法可以包括将用户从社交网站转变为与商品发布相关联的商家网站。基于用户与商家网站上的支付对象的购买交互，该方法可以包括：经由浏览器应用程序编程接口从商家网站接收支付请求，该浏览器应用程序编程接口向向用户呈现商家网站的浏览器与商家网站之间。响应于支付请求，该方法可以包括通过浏览器应用程序编程接口将针对用户的支付数据传达给商家网站，以使商家网站能够使用支付数据来完成商品的购买。可以理解的是，一方面，社交网站上关于呈现购买选项或购物按钮的功能可以改变，只要一个通常过渡到目的地网站，以便目标网站可以调用浏览器API来完成支付方法。
一旦用户登陆到目标网站或导航到目标网站进行购买，系统便可以使用商家网站和浏览器之间的第一浏览器API以及浏览器和支付服务之间的第二API提供支付服务以处理支付。可以根据相应API的协议进行各种通信，以完成支付服务的支付，并通知商家网站，以便商家网站可以接收支付并将商品交付给用户。
图20B示出过渡的另一个方面，即从一个网站过渡到另一个网站。表示为图18A的特征1810的服务器可以代表该网站的各个功能中的任何网站，并且可以应用于本公开。将通过示例的方式讨论社交媒体网站，但是任何网站的任何功能都包括在本公开中。
假设服务器1810代表诸如Facebook、Instagram，Pinterest等的社交媒体网站。该网站当然可以是任何网站，并且与该网站上的对象的交互可以取决于该网站的功能。每个网站的相应功能都包括在本公开中，并且与网站的任何交互都可以触发向根据本公开的辅助网站的转换。举例来说，假定该网站是社交媒体网站，并且该社交媒体网站接收与要购买的商品相关联的发布或广告。对于其他网站，数据可以是游戏交互或视频电话会议界面或任何其他网站功能。广告可以在新闻源内或通常在网站上。问题是如何从第一网站1810过渡到商家网站1816，这样一来，用户无需输入支付信息、登录信息、地址信息和/或密码等，即可一键购买该对象。该方法包括经由社交网站(2020)从用户接收商品的对象(可以在此示例中与广告或在任何其他上下文中用于其他网站功能的任何其他对象相关联)的交互并在浏览器1806中呈现。例如，在社交媒体网站上用于烤面包机的广告可以具有“立即购买”按钮。当用户单击“立即购买”按钮或以其他方式与来自商家实体的广告进行交互时，会启动一系列事件，以将用户过渡到处于特定状态的与商家实体相关联的网站。该系列事件包括作为从社交网站(或任何第一网站)的过渡的一部分，从浏览器1806中获取点击购买数据(2022)。该方法使用来自浏览器的数据使用户能够在深度链接状态下从第一网站过渡到目标商家网站。来自浏览器的数据不仅仅是在具有超链接的网站上找到的超链接数据。在一方面，该数据优选地是存储在浏览器内的数据，例如用户简档或存储的用户参数、一键购买参数、支付数据等。深度链接状态使用户可以通过与购买对象的单次交互来购买商品(要么在过渡后，没有任何其他交互作用，要么在继续购物以选择其他商品之后)，而无需手动输入支付帐户数据或用户地址数据。一键购买数据表示使用户能够以一键购买状态登陆到目的地商家实体网站的任何数据。一键购买数据可以包括支付数据、交付数据、名称、地址、浏览器设置、一键购买设置、用户配置文件选项、首选项、一键购买参数、注册信息、电子邮件地址等等。过渡过程包括从浏览器1806检索一键购买数据。这可以通过API1818或通过检索数据的某种其他机制来完成。在后台检索数据，这样就不需要其他用户交互来检索日期或与“立即购买”对象或其他表示购买意图的对象进行交互。
接下来，系统利用一键购买数据并基于一键购买数据将用户从社交媒体网站转换为处于深度链接状态的商家实体网站，其中用户可以通过与商家实体网站上显示的一键式购买对象的单次交互来购买商品(2024)。深度链接状态具有某些特定特征。可以应用的一个或多个示例特性包括一种状态，在该状态下，与社交媒体网站上的通知或广告关联的商品或商品在商家实体界面中显示。商家实体界面位于商家网站上，并且包括一键购买对象。支付信息、地址递送信息、运送方法等对于商家实体网站已经可用。从浏览器检索并提供给商家实体网站的一键购买数据使用户能够到达目标商家网站。在这样的状态下，在社交媒体网站上第一次单击“购买”按钮之后的下一次交互可以是商家网站上的“一键购买”交互。商家网站利用来自浏览器的一键购买数据来启用此深层链接状态。在另一方面，用户可以登陆目的地商家实体网站并且能够继续购物或改变商品的参数，并且因此在商家实体网站具有其他交互，并且当用户到达他们想要购买的商品时，用户可以通过一键购买，就像购买者amazon.com一样。以这种方式，从第一网站到商家网站的过渡减少了为了达成购买所需的点击或交互的次数。
从商家实体网站的角度来看的过程在图20C中示出。从商家实体网站的角度来看，商家实体将通知或广告发送到第一网站以进行呈现(2030)。这可以是通常在网站上的广告，也可以是链接到广告资源的广告，以便在新闻源或其他社交网络上发布。基于用户与与第一网站上的广告相关联的对象的对象的交互，该方法包括从浏览器检索一次点击购买数据(2032)，并基于单次点击购买数据以深度链接状态从第一网站到商家实体网站的过渡，其中用户可以通过与商家和网站上的一键式购买对象的单次交互来购买商品(2034)。在此阶段，用户位于商家网站处，并继续与商家实体网站进行正常交互，例如继续购买其他商品，依此类推。
图20D从商户网站的角度示出另一方面。该方法包括从商家向第一网站发送广告以在浏览器中的第一网站上呈现(2040)，并在与商家相关联的目的地商家网站处，并基于用户与广告中对象之间的交互，在深度链接状态下接收用户从第一网站到目的地商家网站的过渡(2042)。过渡可以利用几个步骤，包括：从浏览器检索数据(2044)，并使用来自浏览器的数据使用户能够在深度链接状态下从第一网站过渡到目的地商家网站，其中，目标商家网站的深层链接状态可以包括商家网站对象(2046)。商家网站对象可以实现商品的进一步导航和浏览，或者可以是单击对象，用于购买广告中标识的商品。该方法还包括在目的地商家网站处接收与商家网站对象的交互(2048)，并且基于与商家网站对象的交互来处理商品的购买，而不需要用户手动输入支付账户数据或用户地址数据(2050)。
确定用户输入是广义的非购买查询还是有购买意向的查询
公开了一种系统、方法和计算机可读存储设备，其使得网站或某些其他基于计算机的用户界面中的任何输入字段能够充当统一的输入字段。统一的输入字段允许用户提供输入，这些输入不仅可以导致搜索结果列表，但可能导致代表用户执行许多其他操作中的任何一个，例如直接导航到预先填充了所需商品的商家购物车，甚至自动执行购买并为所需商品下订单。使用这样的统一输入字段可以为用户节省大量时间，精力和点击次数。但是，可能不会在用户希望的每个网站或其他用户界面中实现这种统一的输入字段。用户在处理统一输入字段时可能习惯了特定的工作流程或功能集，并且在使用传统的受限输入字段时可能会感到受限或受限。
在一个示例中，如果将用户从启用了输入字段的统一输入网站(例如one-search.com)定向到Apple.com，则可以修改该用户与Apple.com的交互，这样Apple.com(或任何网站，例如Google.com或Amazon.com)的搜索字段就变成了one-search.com统一输入字段。例如，JavaScript脚本或浏览器插件可以拦截在启用了非统一输入字段的网站或非统一输入字段上输入到文本字段中的文本，并将该输入重定向到one-search.com以实现这些功能并显示自动完成选项，以及一键式购买选项。换句话说，可以使在特定网站之外执行任何数量的不同处理选项的选项对用户可用。以这种方式，任何搜索字段、文本字段或输入字段都可以适于作为本文公开的统一输入字段。当然，本文公开的所有功能可以内置到任何网站，应用程序或用户界面上的任何搜索或输入字段中。
浏览器的功能可以直接修改，也可以通过插件、脚本或扩展名进行修改，以实现统一的输入字段来代替现有的输入字段。用户可以激活输入字段增强器，例如通过选中菜单中的复选框、单击按钮、使用用户名和密码登录或提供其他一些用户标识凭据来激活输入字段增强器。然后，输入字段增强器可以标识用户，并检索有关用户的个人数据，例如存储在浏览器缓存中的配置文件或存储在服务器上的配置文件。系统可以从简档数据中识别用户偏好，这可以提供关于何时以及如何将某些输入字段修改为统一输入字段的规则或偏好。例如，用户个人资料可能指示不要修改craigslist.org上的输入字段，而要修改其他地方的输入字段。另一个用户配置文件可能指示修改位于网站前10％内的所有文本输入字段。另一个用户配置文件可能指示不修改智能手机和平板电脑等移动设备上的文本输入字段，而是修改台式机或便携式计算机上的文本输入字段。用户可以登录到存储在服务器上的用户配置文件，以便用户的首选项和其他个人数据不限于一台本地计算机，而是可以从任何启用此功能的计算机上访问。因此，用户可以登录到工作计算机上的浏览器以启用统一的输入字段，并且可以在家用计算机上执行相同的操作，同时使用相同的个人资料、偏好和历史记录。当基于相对短的输入字符串确定意图时，此个人信息对于分类者可能很重要，并且当统一的输入字段在多个设备上的行为相似时，可以为用户提供一致的感觉。
当在浏览器中加载新页面时，或者在刷新或更新页面时(例如通过动态加载或修改页面元素的Ajax调用)，可以触发增强器。增强器可以与渲染引擎或Web浏览器引擎一起操作，以在渲染页面时识别输入字段。在该变体中，增强器可以在页面被解析和/或呈现时修改页面的代码。增强器可以用作后加载操作，该操作可以返回并修改已经加载并呈现的页面。无论哪种方式，增强器都会修改已标识输入字段的功能，以捕获输入并将其重定向到本地或远程服务器，以提供与统一输入字段相似或相同的功能。然后，服务器可以与浏览器进行通信，以实现统一输入字段的各种好处和功能，例如将一键购买行为的预览呈现为网页上的眼泪，新标签页或窗口，通过“搜索”按钮或其他一些按钮来显示此类一键购买行为，等等。
该系统可以标记输入字段或呈现某种视觉或听觉的指示，表明该输入字段已被修改或启用为统一输入字段。例如，当系统检测到标准文本输入字段(例如ebay.com顶部的搜索字段)时，系统可以确定该标准文本输入字段是否适合用作统一的输入字段。如果系统做出肯定的决定，则系统可以修改标准文本输入字段的功能及其外观。例如，系统可以在文本字段周围呈现不同的颜色边框，或者当焦点移到文本输入字段上或文本输入字段中或鼠标或文本光标进入文本字段时会发出噪音。该系统可以应用大小、字体、外观的更改，甚至可以引入突出显示修改后的文本字段的动画。用户首选项还可以指示系统如何突出显示修改后的文本字段。
然后，当用户在修改后的文本字段中输入文本时，系统可以通过分类器处理输入以确定意图，并根据意图生成一个或多个动作。在某些情况下，如果分类器无法确定高于确定性阈值的意图，则系统可能不会基于输入呈现任何动作，并且可能选择等待可能会改变意图和/或确定性阈值的其他输入。系统如何基于确定的意图确定呈现一键式操作的方式可能会因浏览器显示页面或托管修改后的文本字段的页面布局而异。例如，如果文本字段具有足够的相邻空白，则系统可以在文本字段附近渲染一键式按钮，以执行各种操作。系统可以在浏览器的一部分(包含修改后的文本字段)的呈现的网页外部，通过单击功能将下拉菜单显示为浏览器的一部分。系统可以使用JavaScript来修改或重新排列某些页面元素，以临时或永久地(在生命中呈现的页面)容纳用于一键式操作的用户界面元素。系统可以使用JavaScript在呈现的页面顶部覆盖新的用户界面元素，以提供对一键式操作的访问。在一个示例中，系统显示用户界面元素，这些元素看起来像“眼泪”，窥视渲染的页面以显示页面的一部分，该部分似乎位于渲染的页面下方。
但是，即使修改了文本字段，系统仍可以保留输入字段的原始功能，同时将输入字段扩展为也可以用作统一的输入字段。例如，用户可以通过在输入字段的开始处按shift键来在修改的功能和原始功能之间切换。系统还可以切换修改后的输入字段的外观，以指示用户将输入定向到修改后的输入字段的哪个功能。
系统可以识别要修改的候选文本字段，但可以使其保持不变，直到接收到某些用户命令或要求统一输入字段功能的输入。例如，在用户通过按下键或组合键或双击输入字段来激活或请求功能时，系统可以提供对统一输入字段功能的访问。用户可以通过这种方式在输入字段的不同功能之间切换。这对于避免破坏某些依赖于输入字段特定功能的网站可能是有益的。但是，系统可以将统一的输入功能覆盖在输入字段的现有原始功能上，而不会妨碍其操作。例如，系统可以在用户界面的不同区域中实现统一的输入字段一键式操作，同时允许原始功能保持不变。或者，系统可以将原始功能合并为通过统一输入功能显示的一键式操作之一。例如，如果用户在eBay.com上的修改后的输入字段中输入了文本“iPhone5C 32GB黄色”，则系统可以通过JavaScript生成一组覆盖在页面顶部的按钮：第一个单击操作按钮用于通过Amazon.com购买指示的iPhone 5C，第二个单击操作按钮用于通过Apple.com购买指示的iPhone 5C，第三个单击操作按钮用于通过Amazon购买指示的iPhone5C attwireless.com，以及第四个单击操作按钮，用于实现在eBay.com上执行拍卖搜索的原始输入字段功能。
该系统还可以基于检测到的浏览器类型或界面上的可用空间来调整统一输入字段的功能。例如，系统可以呈现与托管修改后的输入字段的页面的外观一致的用户界面。如果托管修改后的输入字段的页面上有广告，则系统可以以避免混淆那些广告的方式放置一键式操作按钮或其他用户界面元素。此设置可以由托管修改后的输入字段的页面中的代码或设置(例如旨在指导修改后的输入字段的行为的令牌或指令)决定。
在一个示例中，网站可以通过使其统一输入字段感知来预修改输入字段。在网站检测到用户未参与或使用统一输入字段的情况下，该输入字段可以保留其原始功能。但是，当网站检测到用户确实参与或使用统一输入字段时，例如通过检测用户浏览器中的cookie，网站可以抢先修改或激活统一输入字段，以为该用户提供更熟悉的界面。该网站可以通过建立的应用程序编程接口(API)与服务器进行交互，以管理此类统一的输入字段请求。
图21示出方法示例。方法示例中的步骤可以以任何顺序执行，可以以包括附加步骤或排除所描述步骤中的某些步骤的全部或一部分的其他组合或排列来执行。该系统可以在第一用户界面中呈现与经由浏览器处理的第一网站相关联的第一输入字段，该第一网站是购买网站，用户在该购买网站中搜索要购买的商品(2102)。该系统可以分析来自用户的输入到第一输入字段中，以确定用户是否希望执行广义搜索或想要进行购买以产生确定(2104)。广义搜索的一个示例是人们可能在Google.com上进行的搜索。例如，用户可能使用术语“北达科他州”进行搜索。在这种情况下，他们正在寻找有关该州的信息。但是，如果用户使用Amazon.com的URL，则输入“北达科他州”并不一定意味着他们希望购买整个州的房地产。与在Amazon.com上搜索要购买的商品相比，该用户输入强烈表明他们不想购买，而是要进行广义搜索。如果确定指示用户希望执行搜索，并且除了输入之外没有其他用户输入，则系统可以至少部分地将用户从第一网站转换到可以处理搜索的第二网站(2106)。将用户从第一网站转变为第二网站可以包括经由第一用户界面中的泪水来呈现第二网站，从而露出第二网站的至少一部分。然后，用户可以通过泪水提供用户期望导航到第二网站的指示，并且基于该指示，系统可以将用户导航到第二网站。该系统可以基于对第一网站的结构的分析来选择在第一网站中的眼泪的位置。系统可以使用输入预先填充与第二网站相关联的第二输入字段(2108)，并且可以使用第二输入字段中的输入对第二网站进行预处理，以使用户处于转换后查看可选搜索结果的状态(2110)。
图22示出该示例的一些基本组件2200。诸如浏览器2202或智能手机应用之类的应用可以具有增强器2204，该增强器是可以与用户偏好数据库2212进行通信的模块或组件，以帮助改善经由任何输入字段的输入处理。浏览器2202可以经由网络2206与服务于诸如amazon.com之类的网站或应用的web服务器2208通信。浏览器和/或增强器2204还可以经由网络2206与统一输入域服务器2210通信。该统一输入域服务器2210还可以按照浏览器2202的指示与用户偏好数据库2212通信，相应地调整用户输入的处理。使用这种方法，系统可以通过将处理连接到统一输入字段服务器2210，来处理从任何Web服务器2208提供的任何输入字段并将其转换为统一输入字段。以这种方式，尽管用户可能在诸如Amazon.com的网站上，该网站具有通常期望购买商品的输入字段，但是该输入字段可以变成更统一的输入字段，以跳转到其他地方并执行其他功能。因此，利用到统一输入字段服务器2210的连接，amazon.com输入字段可以成为通用搜索、电话呼叫、Skype型呼叫、视频会议或通过本文公开的更灵活和开放的输入字段处理方法可以实现的任何其他目的。
通过网站搜索基于应用程序的门户网站
图23示出方法示例。此示例更多地侧重于应用程序与其他人而不是网站之间的通信。但是，基本概念相似。例如，具有平板电脑或智能手机的用户可以具有用于执行搜索的应用程序。这与设备上的浏览器不同，浏览器使用户能够导航到搜索引擎URL。该应用程序又可以是任何内容，例如搜索应用程序、Skype或FaceTime应用程序、银行应用程序等。任何第一类应用程序都可以具有输入字段。这里的重点是将传统上与应用程序的特定用途相关联的输入字段转换为可以处理输入并确定用户是否应自动过渡到另一个应用程序的更通用的输入字段。也可以在浏览器和应用程序之间切换。例如，用户可以使用浏览器应用程序在智能手机上，其URL位于www.google.com上。但是，用户可以在搜索字段中输入商品。该系统(本地，在服务器上，或者通过使用两者的组合进行的处理)确定用户希望根据输入进行购买。系统可以自动启动Amazon.com应用程序(而不是通过浏览器过渡到amazon.com)，进行预先协商，这样，使用输入来定位amazon.com应用程序的输入和“状态”，以呈现搜索结果，就像用户已经启动了该应用程序并进行搜索一样，或者可以将应用程序置于“一键式”状态，用户只需进行购买即可。
一种方法，包括经由与第一类型的第一应用程序相关联的统一输入字段从用户接收输入(2302)，并分析输入以确定要对输入执行的处理是否应该由第二类型的第二应用处理以产生确定，其中第一类型和第二类型是不同的类型(2304)。如果确定指示要根据输入执行用户的意图，则第二应用应处理该输入，然后系统与包括输入的第二应用信息进行通信，其中使用输入启动和预处理第二应用程序，以产生处于处理状态的第二应用程序(2306)。最后，系统将第二应用程序以已处理状态呈现给用户(2308)。
进行演示时，无需用户提供任何其他输入即可导航到第二个应用程序。与第二应用程序通信可以进一步包括将以下至少一项与第二应用程序通信：用户标识信息、支付账户信息、交付地址信息和用户偏好。如上所述，该过程可能涉及在特定网站的浏览器之间切换到智能手机或平板电脑或其他设备上的应用程序。在这种情况下的应用是众所周知的。它是一种免费购买或下载的软件商品，通常执行一项通用任务，例如通过亚马逊启用购买功能，或处理像Skype这样的视频和音频呼叫。这样的应用程序当然不同于可以与同一公司关联的URL，但是提供了访问该公司服务的不同机制。
第一应用程序和第二应用程序是智能手机应用程序和平板电脑应用程序之一。再次，在另一方面，本公开提供了在URL(网站)和应用之间切换的描述。系统可以自动关闭第一个应用程序，并在用户界面上以已处理状态启动和显示第二个应用程序。这使用户可以避免关闭一个应用程序并手动启动所需应用程序的过程。在一个示例中，第一类型是搜索类型，第二类型是商品购买类型。第一类型可以例如是不与购买商品相关联的类型，而第二类型可以与购买商品相关联。这提供了在上下文，类型，应用程序目的等之间进行切换的示例，但是使用的是单个输入字段。这种方法减少了用户获得执行功能(搜索、购买、交付、致电等)所需的交互，因为它无需导航到执行所需功能的单独的URL或单独的应用程序。在一个示例中，第一应用程序可以处理商品的支付，并与第二应用程序协调以将商品交付给购买者。
在搜索界面之间选择过渡类型
图24示出方法示例。此示例着重于选择从一个界面过渡到另一个界面的模式。一种方法包括经由第一应用上的统一输入字段从用户接收输入，该第一应用启用多种不同的处理类型(2402)并分析该输入以确定用户的意图(2404)。基于用户个人资料，该方法包括确定将用户从第一应用程序转换为第二应用程序以产生所选模式的模式(2406)，从一组模式中选择模式，并基于所选择的模式，将用户从第一应用转换为第二应用(2408)。
第一应用程序可以是第一网站和第一智能手机/平板电脑应用程序之一，第二应用程序是第二网站和第二智能手机/平板电脑应用程序之一。模式组可以包括：撕裂、自动更改、搜索按钮变形、下拉菜单、下拉菜单、处理指示器变形和多个缩小尺寸的一键启用窗口。“撕裂”表示第一界面中的开口，使得第一界面似乎被撕开以露出其下方的另一个界面。因此，如果第一个应用程序是google.com，并且用户输入的搜索字词被确定为表明用户希望进行购买，可能会出现google.com页面空白处的开口或撕裂，并且通过该开口会出现amazon.com网页的一部分，并使用搜索词进行了预处理，因此用户可以点击该空白处并轻松地从google.com转换到amazon.com，同时输入字段数据也将转换。这种方法减少了必要的点击次数。自动更改功能无需用户输入即可自动将网址从google.com替换为amazon.com(或两个不同的网站)，这样当系统确定需要切换时，它会自动进行切换，并可能需要进一步处理，以根据用户输入将目标网站置于一键购买状态。搜索按钮(指示用户单击“输入”时将执行什么过程的按钮)可以根据用户输入来改变其功能。要处理的功能的通知也可以变形。还可以提供下拉菜单、下拉菜单、扩展菜单，这些菜单不仅可以自动完成，还可以提供一键购买选项、通话选项、视频会议选项等。这些各种模式提供了自动转换到新网页的替代机制、应用程序或功能。但是，由于存在进行这种过渡的不同方法，因此用户可以呈现并存储如何进行过渡的首选项。或者，可以呈现各种选项，并且可以使用用户历史记录，先前的搜索以及互联网或应用程序使用情况，或者可以使用用户配置文件之外或与之相关的其他因素来决定所选择的模式。
打开另一页的“泪水”可以包含一键式选项，用户可以单击该选项进行一键式购买。系统可以在执行其他搜索，浏览其他搜索结果或浏览到其他网站时，在搜索界面上保持另一页面的撕裂视图。例如，用户可以将泪水“固定”在适当的位置，以便在用户执行其他浏览活动时，泪水仍然可用。因此，用户可以在浏览、研究、在Web上搜索时握住一键购买的泪水，并且用户以后仍然可以使用泪水进行购买。
转换用户可以包括转换用户而无需用户手动导航到第二应用程序。可以通过用户执行一次单击操作来启动和完成转换来实现转换用户。将用户从第一应用程序转换到第二应用程序还可以包括使用输入、用户标识、用户帐户信息、用户传递信息和用户首选项中的至少一个预处理第二应用程序，以一键购买状态产生第二个应用程序。例如，第一应用程序可以处理支付并将必要的数据协调到第二应用程序以进行交付。确定模式可以进一步基于运行第一应用程序的设备的屏幕配置。模式也可能从一种类型的应用程序(例如通过浏览器访问的网站)更改为另一种类型的应用程序(例如智能手机/平板电脑应用程序)。所有预处理等等都可以在任何过渡中发生，从而使用户处于目标内部的状态中，使他们能够浏览搜索结果(例如在Amazon上，其中google.com提供的输入用于显示搜索结果)，或者处于一键式状态，用户可以单击以购买商品。
广告
图25示出方法示例。该示例涉及如何结合本文公开的统一输入字段来呈现各种广告。一种方法包括经由第一网站中的统一输入字段从用户接收输入，该输入可以以多种不同方式处理输入(2502)。第一网站也可以是第一应用程序或第一用户界面。该方法包括：识别与第二网站或应用程序相关联的广告(2504)，并以与从一个网站(应用程序)过渡到另一网站(应用程序)的模式相关联的方式呈现广告。有多种平滑过渡的方式，可以根据过渡模式定制广告。例如，可以通过以下方式之一显示广告，或将其与以下转换之一相关联：第一网站内的一滴泪，揭示了第二个网站的至少一部分；以与识别第二个网站并可供用户选择的扩展菜单相关的方式；以与变形搜索按钮相关联的方式，该搜索按钮根据从输入中识别出的意图来改变其功能；以与从第一网站到第二网站的自动过渡相关联的方式，而无需用户直接导航；并且以与第二网站的协商版本相关联的方式将第二网站置于一键购买状态以供用户选择(2506)。
从第一输入字段上下文或环境过渡到另一输入上下文或环境有多种不同的方式，而无需用户主动导航到目标环境。在该示例中，由于系统基于对用户的输入数据的分析来了解用户的意图，因此系统可以使用该意图和目的地网站的知识来在过渡期间的某个时刻呈现广告。
例如，如果用户在google.com上并输入“iPhone 5s 64GB银色”，则系统可能会确定要购买商品。可能会在网页的空白区域中出现撕裂声，从而显示amazon.com页面处于购买状态的一部分，在该状态下，用户可以“单击”并购买iPhone，然后将其交付。但是，在空白区域的其他地方，系统可以显示三星设备广告，该广告也可以定位为一键式状态，以诱使用户购买其他商品或浏览其他商品。呈现广告可以基于为广告支付的价格。第二网站的扩展菜单内的位置或广告的应用也可以基于协商的价格。在这种情况下，当显示扩展菜单时，收入最高的广告主可能会被定位为最靠近输入字段。可以基于协商的价格来选择以所标识的方式之一显示广告。该方法可以包括基于从输入中识别出的意图将用户从第一网站(或应用程序)转换到第二网站(或应用程序)，而无需手动用户导航。
在通用搜索界面中预览目标网站的预览
图26示出方法示例。本示例着重于呈现一个或多个目标网站的微型版本或其他网站的修改版本，作为处理统一输入字段输入的结果。例如，展示一个小版本的amazon.com，其中包含与输入相关联并经过预处理的商品，以便用户可以触摸“一键式”按钮进行购买。方法示例包括：经由与第一类型的第一网站相关联的统一输入字段从用户接收输入(2602)；以及分析输入以确定将在输入上执行的处理是否应该由第二类型的第二网站处理以产生确定，其中第一类型和第二类型是不同类型(2604)。如果确定指示根据输入执行用户的意图，则第二网站应处理输入，则该方法使处理器执行向第二网站传达包括输入的信息的操作，其中使用输入启动和预处理第二网站，以产生处于处理状态的第二网站(2606)。处理状态可以是搜索结果状态，相当于用户导航到另一个网站并输入输入内容并搜索商品。基于用户的输入和其他因素，与一键式购买该商品有关，处理后的状态可能是用户希望购买的最好和最有可能得到的商品。当与用户互动时，购买选项可以导致系统通过与第一应用程序一起存储的支付数据处理支付，并通过第二应用程序协调商品的交付。该方法包括在用户界面上的区域中在统一输入字段周围的位置中以已处理的状态向用户呈现第二网站(2608)。
可以在没有来自用户的任何附加输入来导航到第二网站的情况下进行呈现。换句话说，用户只需在输入字段中输入输入，即可自动执行其他网站的预处理，并以多种可能的预处理状态之一自动呈现这些网站，而无需用户进行任何导航输入。还可以根据所需的消歧信息的数量来处理状态下显示的备用网站的数量。如果用户仅输入“iPhone 5s”，则可以显示许多备用的经过预处理的网站，供您进行32GB一键式购买、金色64GB一键式购买等。用户只需输入诸如“32”和“silver”之类的歧义数据就可以看到这些各种商品并消除歧义。然后，另一个网站的演示文稿可以自动变形，从而将商品范围缩小到Amazon的一键式和Apple的一键式。图27示出具有搜索字段2702、搜索按钮2704和各种替代目的地网站的界面2700，例如来自亚马逊2706的一个一键购买，以及苹果网站2708的一键购买。在这种情况下，Apple当然可以代表通过API与搜索引擎/社交媒体/非商家网站进行通信的任何商家。一键或购买选项按钮2714可以指示广告2708被配置为启用改进的支付处理，其中可以使用网站或通过类似Apple Pay的服务器存储的支付信息来处理支付，并由商家管理和完成交货。因此，用户可以点击广告2708或按钮2714，并被要求根据该改进的步骤集合来完成购买过程，这减少了完全转移到商家网站以再次输入支付信息的痛苦。因此，从这个意义上讲，“单击”按钮2714可以是字面上的单击或用户希望使用此处公开的这种新的支付处理/交付方式进行购买的指示。
带有一键购买或一键竞标按钮的eBay网站2710，以及Amazon搜索结果提供2712，其中，如果用户单击该按钮，则URL切换到amazon.com并经过预处理，就好像用户输入了“iPhone 5S 32GB”并直接在Amazon.com上点击“搜索”一样。可以理解，以这种方式预处理输入减少了用户从搜索网站(如Google.com)导航到商品购买网站(如Amazon.com)并提供输入以进行搜索和购买所需的交互次数。在另一方面，向第二个网站(如Amazon.com)的过渡可以利用存储在浏览器中的数据(例如一键式设置)，以便用户以深层链接状态登陆目标网站，从而可以一键式购买商品。
处理状态可以包括以下状态之一：用户可以单击一次，从而导致与该输入相关联的商品的购买和交付，或者用户可以单击一次，并在第二个网站上查看搜索结果，就像用户已经导航到第二个网站并在输入中进行搜索一样。该方法可以包括：识别可以处理输入的第三网站，以及在围绕统一输入字段的第二位置的用户界面上的区域中呈现第三网站。图27示出该方法。第二网站和第三网站可以处于不同的状态。此外，第二网站和第三网站相对于统一输入字段的位置可以取决于第二网站和第三网站中的哪个基于输入具有最可能的意图。在一个目标网站中单击“单击”或“搜索”按钮不仅会导致购买和交付，还会导致从第一个网站URL(例如www.google.com)自动转换为所选网站URL(例如www.amazon.com)。换句话说，单击“一键式”按钮(或其他功能按钮，例如“搜索结果”)不仅可以处理购买和交付，还可以转换到另一个网站。如果用户最初导航到www.amazon.com并进行搜索，直到他们单击了“一键购买”按钮，那么他们将在www.amazon.com上看到“感谢您一键购买，正在处理中”的通知。在那个阶段，用户可以去他们的帐户并更改或取消订单，跟踪订单等。这里的要点是，通过单击显示在URLwww.google.com上的图27的功能2706中显示的一键式按钮，系统会自动在处理状态下将URL更改为www.amazon.com，以显示以下消息：“谢谢您的一键式购买，正在处理中”。在那个阶段，从初始导航到www.amazon.com到从www.google.com的自动转换之间在本质上没有区别。当然，导航可以从任何网站或应用程序导航到任何其他网站或应用程序。过渡还可以包括将支付处理和交付管理分开。例如，google.com可以处理商品支付，但可以与www.merchant.com协调以交付订单。
图28A示出与本文公开的处理有关的另一示例。系统可以在用户界面上呈现输入字段，其中该输入字段与通用互联网搜索引擎相关联，该通用互联网搜索引擎基于对来自至少25,000个单独域的网页进行爬网和索引来提供搜索结果(2800)。当然，这个数字可以更改，但是它旨在区分通过Google或Yahoo进行的Internet搜索与在单个网站上进行的搜索(例如搜索www.newyorktimes.com)之间的区别。该方法包括在输入字段中从用户接收用户输入(2802)并且在用户界面上呈现用户可选选项，该用户可选选项与处理与该用户输入相关联的物品的购买相关联，其中通过流程购买引擎(可以由输入字段实体操作)来处理和完成购买，并且基于用户和用户可选选项之间的单个交互，该单个交互是在接收到用户输入之后的第一次交互(2804)。可以通过与输入字段实体不同的商家来完成商品的交付。
例如，用户在搜索字段中输入iPhone 6，因此“用户输入”为“iPhone 6”。用户键入文本，然后单击“输入”或“搜索”。该系统为用户输入并构建使用户启用的交互，而无需在点击“输入”后执行任何进一步的交互(即，无需导航到另一个网站或跳转到另一个应用程序)，这样，下一次互动就可以(不必一定是结构化的，而是可以这样构造)与用户可选的购买(购买和/或交付)iPhone 6的用户互动。因此，该方法包括从用户接收具有用户可选选项的单一交互(2806)，并基于该单一交互来处理与用户输入相关联的物品的购买(2808)。当然，处理可以包括购买和交付。用户可以使用的其他选项当然可以包括调整购买过程，以交付给亲戚或朋友(购买者以外的其他人)，或以可在用户个人资料上设置的其他方式支付。与在诸如Amazon.com之类的网点的购买过程和功能非常相似，本公开内容在此阶段也涵盖了所有此类功能。例如，与购买选项的交互可以导致与统一输入字段相关联的第一实体处理商品的支付，并与单独的商家协调以通过将商品交付给买方来填写或确定订单。然后，第一实体将处理向商家支付。
图28B示出另一个示例，其不需要用户实际进行购买。一种方法，包括在通用搜索实体的用户界面上呈现输入字段，其中该通用搜索实体使用通用搜索引擎处理数据，该通用搜索引擎索引并搜索商家网站和非商家网站(2820)，在输入字段中接收查询(例如，基于文本的查询，尽管可以考虑其他输入模式)(2822)，并将基于文本的查询与商家出售的商品的商品数据库相关联以产生相关性(2824)。关联可以简单地表示访问商品数据库以确定商品是否在库存中，可以将其作为带有购买选项的搜索结果的一部分来显示。
该方法包括至少部分地基于相关性来确定该查询与搜索意图和购买意图之一相关联以产生确定(2826)。当确定指示搜索意图时，该方法包括呈现包括非商家网站的搜索结果(2828)，接收与非商家网站相关联的搜索互动(2830)，并根据搜索互动过渡到非商家网站(2832)。当确定指示购买意图时，该方法包括呈现与购买相关的搜索结果，该搜索相关搜索结果包括与查询相关联的购买选项(2834)。可以配置与购买相关的搜索结果，以使得当用户与与购买相关的搜索结果进行交互并通过与购买选项进行交互来确认购买时，广义搜索实体(或独立于商家的单独支付服务)启动对物品的购买的处理。该方法可以包括可选地从用户接收与购买相关的搜索结果相关联的交互(2836)。具有购买选项的搜索结果的结构是此方面的一部分。与搜索结果进行交互和/或完成购买交易的用户是可选功能。
该方法可以包括：从用户接收与购买选项的交互；以及基于存储在广义搜索实体，浏览器或另一支付服务处的支付信息来管理物品的购买，其中商品的交付是通过与广义搜索实体不同的商家网站进行的。用户可以具有一个预先存在的帐户，该帐户存储用于控制如何呈现搜索结果，与购买相关的搜索结果和购买选项之一的首选项。与购买有关的搜索结果可以包括用户可选择的选项以接收进一步的搜索结果。一方面，用户界面可以在移动设备上。在另一方面，可以进一步配置与购买有关的搜索结果，以使得当用户与表示希望过渡到商家网站的与购买相关的搜索结果交互时，该方法还包括转换到与购买相关搜索结果关联的商家网站。在这种情况下，通常商家将继续处理支付。换句话说，搜索结果可以包括购买选项，但是也可以包括转换到商家网站以继续搜索和/或进行购买的选项。通用搜索实体和商家网站可以通过应用程序编程接口进行通信，以管理商品的购买和交付。
在另一方面，这些步骤可以由商家执行。在这种情况下，商家从商家网站经由通信接口在商家网站与广义搜索实体之间建立通信。通用搜索实体以上述方式处理查询。商家提供对商品库存的访问，并且通过API将提供商品供应并从广义搜索实体或其他支付服务接收支付以及有关购买的数据，以便商家可以处理和管理交货。
社交媒体
现在，本公开返回到社交媒体或搜索网站功能。图29示出可以在诸如www.google.com的搜索网站与社交网络网站之间的不同网站上应用的方法的一般示例。概念是改变这些网站中任何一个的常规处理，以通过使用非常规步骤从技术上确定用户是否已将具有购买/销售意图的网站的输入(文字、图片、视频、推文等)包括在内。第一步是接收用户对该网站的输入(2902)。系统针对指向商品数据库的数据评估用户输入(2904)。系统可以确定不存在任何意图，或者可能无法标识到商品数据库的链接或对可能与商品数据库中列出的商品匹配的商品的任何引用。当没有对商品数据库的引用时，系统以常规方式针对各个网站(Google、Twitter、Facebook、Instagram、Pinterest)处理用户输入(2906)。当用户输入中存在链接到商品数据库的某种数据时，系统更改为非常规处理，以提供与用户输入的进一步处理的接收者相关联的购买选项(2908)。推文、Facebook帖子、Instagram图片、Google搜索结果等的收件人将看到购买选项，并可以通过Apple Pay之类的服务或通过存储和处理用户支付数据的网站在网站内购买商品。当用户与购买选项交互时，将进行新的处理以处理商品的支付和/或交付。例如，可以发生从网站到发布用户输入的商家或卖方网站的深链接的平滑过渡，使得用户可以容易地从商家网站购买商品(2910)。可替代地，网站可以存储支付信息，或者可以使用单独的支付服务来通常在网站而不是由商家直接或通过商家网站来处理支付。
图30示出与社交媒体特别是与Facebook有关的示例。一种示例方法包括：通过社交网站接收文本、图像或视频中的至少一个的发布，其中，社交网站从发布实体接收发布的商品并将其发送到接收实体(3000)，并标识与发布相关联的数据(3002)，确定数据是否标识来自发布实体的待售商品数据库中的商品以产生确定(3004)。当确定指示在商品数据库中没有对商品的引用时，该方法包括通过社交网站传输发布而没有购买选项(3006)。当确定指示过帐发布引用商品数据库中的商品，从而指示与销售相关的意图时，该方法包括通过社交网站发送具有与商品相关联的购买选项的发布，以及从与购买选项相关联的购买者接收购买交互(3008)。这可以简单地包括用户或收件人查看或单击发布以引起进一步处理。可选地，该方法包括基于购买交互来处理商品的购买，使得处理购买发生在社交网站或网站的webview呈现版本中。可以通过存储在社交媒体网站上的支付信息或通过其他支付服务(如
或
)来完成在社交网站中处理购买交易的过程。浏览器API也可以用于通过用户界面处理支付。这些服务与网站集成在一起，因此用户与“购买”按钮的交互会触发来自其中一项服务的支付，该服务已集成到社交媒体网站和商家之间的流程中。
确定发布是否与来自发布实体的商品数据库中的商品相关联可以进一步包括经由应用程序编程接口在社交网站和商品数据库之间进行通信。处理商品的交付的步骤可以包括通过应用程序编程接口通知销售实体的商品的发布实体来运送商品。用户可以具有一个预先存在的帐户，该帐户存储用于控制如何显示和处理图像或视频以及购买选项的首选项。
在另一方面，除了如上所述在网站处处理支付之外，该方法可以包括将购买者从社交网站转移到由发布实体运营的网站中的深层链接。以这种方式，商家可以在商家网站内的预先配置的位置和状态处接收用户，以直接通过商家网站查看和购买商品。
在另一方面，从商家的角度实践该方法。商家通过社交网站提交文本，图像或视频中的至少一个作为发布实体，以产生发布。然后，该网站按上述概述处理过帐。如果用户单击发布，或启动针对购买发布中商品的处理，则该处理可以包括由发布实体基于购买交互来处理商品的交付。发布实体还可以接收从社交媒体网站到其自己网站的深层链接转换，以继续购物、处理商品的支付和交付等等。上面概述的过程为通过Facebook等社交媒体网站管理购买按钮提供了各个方面。
图31示出另一示例性社交媒体方面，其可以适用于诸如Pinterest、Instagram、Youtube等的媒体。社交网站可以是视频或图像共享网站或插板网站之一。该方法包括从发布实体接收通过社交网站发布的图像或视频的发布，其中，社交网站从发布实体接收发布的商品并将其发送到接收实体(3100)，并通过处理器分析图像或视频的发布以获取相关的基于文本的数据(3102)，并确定相关联的基于文本的数据是否标识了商品数据库中的要从发布实体出售的商品以产生确定(3104)。当确定指示在商品数据库中没有对该商品的引用时，该方法包括通过社交网站发送图像或视频的发布而无需立即购买按钮(3106)。当确定指示图像或视频的发布参考商品数据库中的商品，从而指示与销售有关的意图时，该方法包括通过社交网站传输图像或视频的发布，并带有与图像或视频的发布相关的购买选项，其中购买选项可以包括按钮、下拉菜单或超链接(3108)之一，并接收与购买选项相关的购买交互(3110)。可选地，该方法可以包括基于购买交互来处理对物品的购买。当收件人实际单击发布并完成购买时，就会发生这种情况。值得注意的是，这里的概念通常涉及发布的新颖结构，而不必涉及用户进行购买时的支付处理。具有购买按钮的发布也可以简单地由发布实体以具有购买按钮的广告类型发布作为发布的一部分来发起。
确定图像或视频的发布是否与来自发布实体的商品数据库中的商品相关联可以包括经由应用程序编程接口在社交网站和商品数据库之间进行通信。处理物品的交付可以包括通过与社交网站相关联的支付帐户(即存储在该网站上或与单独的支付服务集成)来管理商品的支付，其中支付帐户未与过帐实体存储在一起，并通过应用程序编程接口通知过帐实体通过销售该商品来销售该商品。用户可以具有一个预先存在的帐户，该帐户存储用于控制如何呈现图像或视频的发布以及购买选项的首选项。
与上面的Facebook示例一样，可以从商家的角度实践该方法的另一方面。商家通过社交网站提交文本、图像或视频中的至少一个作为发布实体，以产生发布。然后，该网站按上述概述处理过帐。如果用户单击发布，或启动针对购买发布中商品的处理，则该处理可以包括由发布实体基于购买交互来处理商品的交付。发布实体还可以接收从社交媒体网站到其自己网站的深层链接转换，以继续购物、处理商品的支付和交付等等。上面概述的过程提供了通过社交媒体网站(如Pinterest、Instagram、Twitter、YouTube等)管理购买按钮的各个方面。
商品管理引擎
现在，本公开转向商品管理引擎、购买管理器或跨多个平台管理商品购买的引擎。
图32示出本公开解决的一般环境3200。特征3202示出用于进行购买的各种系统。例如，Amazon.com可以使用所示的支付方式通过互联网3204从商家3206提供购买。类似地，如上所述，诸如搜索引擎或社交媒体应用之类的其他实体可以提供购买按钮，在其中可以处理支付3202，并且经由因特网3204与商家3202的通信可以使得能够交付这种购买的商品。类似地，诸如Facebook之类的社交媒体网站也可以提供购买按钮，在其中处理支付3202并通过Internet 3204与商家3206进行通信。但是，如图2所示，在这些各种类型的方法中，用户可以通过Internet进行购买之间没有协调。由于可以在Internet和移动应用程序上跨多个平台购买商品的能力各不相同，因此人们可以轻松地忘记购买的商品以及从何处购买商品。例如，某人可能在一周前从一键式购买中购买了一把雨伞，可能还没有到货，他们可能不记得自己是从Twitter、Google.com还是Facebook上购买的。使用Amazon.com这样的系统，可以轻松转到用户帐户并管理购买历史记录。使用新的购买按钮环境，访问购买历史记录变得更加困难。因此，本公开解决了这个问题，并试图通过商品购买管理系统或引擎来提供增强的用户帐户。
图33示出该方法。整个生态系统3300涉及购买管理系统3302或商品购买历史管理引擎。提供了API 3304，其允许来自多个不同实体的通信，其目的是协调和接收各种购买数据，关联该数据和协调该数据，以及呈现统一的购买历史和管理用户帐户，这样可以通过许多不同的购买平台进行访问。
例如，API 3304可以与诸如诸如Amazon.com之类的商户聚集者网站3308进行信息通信。因此，考虑到可以通过API 3304传达在用户帐户和购买历史中找到的所有信息。亚马逊为商家3310出售商品。此类商家以与Amazon.com3308交流购买、定价商品等类似的方式，也可以通过API3304与购买管理系统3302交流。
以类似的方式，随着购买按钮的出现和各种不同的环境，当通过搜索引擎3302进行购买时，搜索引擎可以经由API 3304与购买管理系统3302进行通信。类似地，出售商品的商家3314商品通过搜索引擎3312可以通过API传达信息。以类似的方式，通过社交媒体3316通过它们各自的商家3318进行的购买也可以经由因特网3306和API 3304与购买管理系统3302进行通信。递送服务3320还与各种商家3310、3314、3318集成在一起，并且还可以通过API 3304与购买管理系统3302通信。此外，广告商3322可以通过API 3304或通过其他方式与购买管理系统3302进行通信，以接收有价值的购买行为信息，该信息可以使得能够改进通过任何一个网点或针对任何商家来提供广告。因此，商家3310、3314、3318中的任何一个不仅可以通过图33所示的各种方式来访问其商品的销售，而且还可以具有他们自己的独立网站，并且可以利用商业智能数据3322并将其提供给这些途径中的任何一种，以进行购买和为用户改善广告。可以对API进行结构化，以便可以使用标准化的调用和通信协议在引擎或其他处理聚合和管理的代理与商家或用户之间识别和交换，以执行此过程所需的各种数据。这可以包括诸如购买的商品、交货地址、商品是否为礼物、与交货相关联的消息、交货计划时间、当前交货状态、预定交货时间、保修信息、支付状态、缺货状态、退货状态和/或信息等等的数据。可以在API与通过API进行通信的任何组件之间请求、传输、接收或以其他方式传达这些以及对管理购买有用的其他数据。
该API还可以包括诸如何时以及如何显示用于访问引擎的交互式按钮或图形的功能。例如，此管理引擎的使用是在用户跨不同的应用程序或网站进行一次单击或其他购买的情况下。这里还公开了支付请求API。例如，商家在向支付请求API或其他API提交呼叫或通过其自身的处理时可以请求在交互中还显示商品购买管理访问按钮。通过这种方式，可以在用户所在的位置(在社交媒体网站上，可以在任何位置进行购买等)显示访问用户帐户的功能。要求访问按钮的调用可能包括针对用户帐户的分析请求或分析结果，这可能表明用户可能希望进行某种更改或检查其帐户。例如，商家可能要求如果用户具有常规的帐户访问权限和/或更改，并且时间安排使得用户可能很快会再次访问其帐户，则在他们购买按钮时或之后要显示帐户访问按钮。然后，用户可以在购买“处于区域内”时查看当前购买并查看其他购买。该分析可以确定用户在其帐户中拥有与他们将要购买或刚刚购买的商品类似的商品，并且他们可能希望查看其总体帐户以确保他们不会重复购买。因此，系统可以提供关于是否包括用于用户购买的购买历史和管理引擎的访问按钮的智能考虑。该访问按钮可以通过商家的请求、用户个人资料考虑因素或通过单独的实体来提供。例如，用户可能会在他们的个人资料指示器中放置他们不想每次都看到访问按钮，除非他们将与之发生冲突的购买或与先前的购买重复。用户可能希望在每次购买后都看到购买历史记录，或者希望用户可以选择访问他们的帐户历史记录。可以在视觉上和/或在听觉上配置(即更亮、闪烁、发出某种声音)访问按钮，以便在购买历史记录中可能存在异常时(刚发生过两次购买，或预期某件商品延迟交货)发出通知，并且用户应检查。在这种情况下，给定有限的显示空间(例如在移动购物中)，系统可以更智能地确定何时向用户显示访问按钮(或其他访问机制，例如声音)，以便其显示与用户查看或更改购买历史记录的可能需求有关。
机器学习引擎还可以应用于用户的实际使用和访问其帐户。因此，系统可以通过每次或每隔一次或在某种其他策略下提供按钮来开始，并了解用户访问帐户的方式和时间。例如，系统可以得知用户仅通过Amazon.com访问其帐户，因此系统停止在社交媒体或搜索引擎网站上显示访问按钮。或者系统可能会得知，通常在购买任何商品后的两周内，用户就会访问其帐户以查看状态。因此，机器学习算法会学习并应用新规则，在购买后两周内(三天之内)显示访问按钮，如果用户未访问其帐户，则访问按钮会消失。当然，访问总是可以通过总是可用的选项卡或帐户按钮来实现，但是可以如本文所公开的那样管理对其购买历史和管理系统的“一键式”访问。可替代地，也可以通过其他方式来提供对购买历史管理系统的访问，诸如通过文本或电子邮件中的链接，或语音激活系统等。用户配置文件、机器学习算法或通过其他触发事件可能导致，例如，系统通知用户他们应访问其帐户以检查某事。例如，如果计划第二天交付的包裹将要迟到，则系统可以通过电子邮件、短信、社交媒体消息或发布之类的任何渠道提供通知，或在用户进行Google.com搜索或在Facebook上时向用户“所在”的位置提供通知。
此外，图33示出API 3304与各个购买途径之间的双向通信。因此，一个例子将说明这一点。假设某个用户拥有一个Amazon帐户，并通过Amazon.com3308从不同的商家处进行了三笔购买。该用户可以进入其帐户并处理与他们的购买相关的各种事务，例如跟踪、交付、取消购买等。但是，该帐户仅限于在亚马逊上进行的购买。使用此处公开的原理，如果用户要通过搜索引擎3312从商家3314购买小部件，则该信息将通过API3304提供给购买管理系统3302，然后结合Amazon.com用户帐户上的现有购买。在该帐户中，用户可以进入其在Amazon.com3308上的用户帐户，并且还可以通过搜索引擎3312查看小部件购买并管理该购买。另外，该相关数据也可以被呈现给所有商店3312和3316。因此，通过搜索引擎或社交媒体网站或某些甚至不销售商品的其他网站，可以访问相关用户帐户，其中可以完全或几乎完全查看和管理三个亚马逊购买和一个搜索引擎购买，从而简化了最终用户的总体流程。
图34A示出界面3400，其包括商品3406(帽子)的呈现以及“立即购买”按钮3402和“管理购买”按钮3404。该界面3400可以代表用于购买商品的任何方法上的任何界面。因此，界面3400可以表示立即购买广告，作为Google.com上搜索结果的一部分，或者表示使用户能够购买当前商品的Pinterest帖子。在这些出口中的任何一个中，用户可以与管理购买按钮3404交互以访问他们的用户帐户。
图34B示出示例性用户账户3410。这里，以简化的方式示出谷歌购买3412、Facebook购买3414和亚马逊购买3416的图示。给用户以各种方式列出这些购买3418的选项。用户可以例如借助媒体、成本、时间、交货日期、退货、折扣等来组织这些购买。
图35示出更详细的用户帐户3500。这里，呈现了各种选项卡3502，以使用户能够查看订单、未结订单、数字订单或取消订单。各种选项3504使用户能够按媒体、按成本、按商家、按交货日期等来管理最近六个月(或任何时间段)下的订单。信息3506可以包括诸如Google进行的购买并且商家是Joe's Sporting Goods的信息。用户具有再次购买商品的选项3510或包括其他选项3508，例如跟踪包装、退回或更换商品、留下包装反馈、撰写商品评论、归档订单等等。可以理解，从其他传统非商家网站的购买细节的添加提供了对用户帐户的先前操作和管理的改进，以使用户能够更轻松地管理他们的购买。如图17I所示，用于订单清单的数据也可以存储在浏览器或本地用户设备上，并通过浏览器界面或API来接收和/或发送。换句话说，图17I的浏览器API不仅可以被实现为跨多个网站存储物品的购物车，而且还可以维持所购买的商品的持久列表，以供以后检索和处理或跟踪进度。如果所有购买历史数据都存储在浏览器中，那么也可以仅从浏览器对象中进行这种检索。
图36示出商品管理引擎的方法方面。该方法包括从服务器或其他位置接收来自第一网站的第一转换数据，该第一网站包括广义搜索引擎、商家网站和社交媒体网站中的一个，其中，第一转化数据可以包括基于与呈现给第一网站的用户的第一购买选项的交互而与第一商品的第一购买相关联的第一数据(3602)，在服务器处从第二网站接收第二转换数据，该第二网站包括广义搜索引擎、商家网站和社交媒体网站之一，其中第二转换数据可以包括基于与呈现给第二网站的用户的第二购买选项的交互而与第二商品的第二购买相关联的第二数据，其中第一网站不同于第二网站(3604)。该方法包括将第一数据和第二数据相关以产生相关数据(3606)，并从用户接收对相关数据的请求，其中从第一网站和第二网站之一接收该请求以产生请求网站(3608)。该方法可以包括将相关数据发送到请求网站(3610)。可以理解，这种方法使“微时刻”不仅可以涵盖购买决策，还可以包含购买历史管理决策。无论是在Facebook、Instagram、Pinterest、Twitter等上，本公开内容都使用户可以触及广泛的用户购买帐户，无论他们身在何处。用户帐户数据的传输并不仅要传输到购买网站，还可以传输到任何位置、任何应用程序。因此，即使Outlook没有可用的“立即购买”按钮或选项，用户也可能会使用Outlook的电子邮件来查看，并且可以选择通过API访问其购买帐户，并且可以通过Outlook应用程序选择该选项。即使像Twitter这样的商店都放弃了“购买”按钮功能，用户仍然会在此类社交网站上花费时间，并且可以在那里访问购买历史管理引擎。
社交媒体网站可以包括用于交换图像的网站、用于张贴图像和评论的网站、用于交换短文本消息的网站以及用于张贴视频的网站之一。上述第一网站可以包括通用搜索引擎，该通用搜索引擎通过将文本用户输入分析为购买意图和搜索意图之一来确定用户的意图。当用户的意图是购买意图时，通用搜索引擎可以用包括与第一商品相关联的购买选项的响应来响应文本用户输入。将相关数据传输到请求网站还可以进一步包括将接口传输到请求网站，该接口使用户能够执行以下一项或多项操作：(1)取消第一次购买第一件商品或第二次购买第二件商品；(2)替换第一次购买的第一件商品或第二次购买的第二件商品；(3)跟踪第一商品或第二商品的运输；(4)阅读第一个商品或第二个商品的评论；(5)购买更多的第一商品或第二商品；(6)修改用于购买第一商品或第二商品的购买帐户；(7)修改第一个商品或第二个商品将交付到的地址；(8)修改将第一种商品或第二种商品交付到收件人地址的日期；(9)为第一个商品或第二个商品撰写商品评论；(10)组织第一商品和第二商品的相应展示，并通过以下其中的一个：(1)哪个网站用于购买第一商品和第二商品；(2)第一商品和第二商品各自的成本；(3)分别销售或交付第一商品和第二商品的商家；(4)第一商品和第二商品分别的购买日期；(5)与第一商品和第二商品相关的各自的交货数据；(六)第一商品和第二商品的折现率或折现率；(七)取消订单；(8)数字订单；(9)未结订单；(10)用户可定制的类别。用户还可以为第一商品和第二商品之一购买保修。
可以通过接收来自用户的交互来使相关数据可用于第一网站和第二网站，该交互具有访问选项，该选项可以访问维护相关数据并管理包括至少第一网站和第二网站在内的多种不同类型网站的购买的用户帐户。访问用户帐户的选项可以包括在第一网站和第二网站上显示的按钮或下拉菜单。服务器可以通过应用程序编程接口与第一网站和第二网站进行通信。一方面，用户帐户可以与具有管理从商家聚集网站的购买的商家聚集网站用户帐户的商家聚集网站相关。
该方法还可以包括在服务器处从商家网站接收第三转换数据，其中，相关数据还包括第三转换数据。商家网站可以不是商家聚合网站，而可以是单个商家网站。换句话说，Amazon.com聚集了许多商家来管理商品的销售，但是个别商家也可以从商品管理引擎提供和接收数据。
加密货币
注意，本文公开的任何API或金融交易都可以通过区块链技术来实现。因此，买卖双方或商品之间的任何通信都可以通过区块链上的合同来实现，并且可以根据区块链技术通过用户地址提交支付。例如，在区块链上编程和实施的智能合约可以接收和实施交易中的商品。
本公开的另一方面是如何在搜索引擎结果上实现“一键式”或购买按钮购买机会，到可以进行购买的商家网站的界面，或在社交网络上发布购买按钮的方法。该概念还可以在可以购买商品或服务的任何应用程序或网站中简单地工作。在这些情况下，为了使购买过程更有效，将支付/交付信息存储在搜索实体、社交网络实体、单独的代理、浏览器或任何其他位置，这样，数据就可以以无需用户手动填写字段(例如地址、信用卡号等)即可完成购买的方式应用于购买交易。填写这些字段会阻止更多的购买转化。可以通过API或其他协议来完成本文公开的方法，以请求数据、检索数据并填写支付表格，并为用户提供更多“一键式”体验。例如，这是通过W3C支付请求API或Android PayAPI实现的，其详细信息在本应用程序的优先级应用程序中进行了描述。浏览器或支付API也可以与用户设备上的支付应用程序进行通信，以根据支付应用程序的功能来处理支付方法。
但是，使用用于山寨币支付的区块链方法，没有像信用卡那样“持有”支付账户的实体。区块链包含三个要素，并使用加密货币进行购买。有一个地址、一个私钥和钱包软件。该地址是其他人可以向个人或实体发送硬币的地方。私钥是一个密码秘密，人们可以通过该秘密秘密将比特币(或任何山寨币)发送给他人。每当引用诸如“Bitcoin”之类的特定山寨币时，它就可以应用于任何类型的加密货币。钱包还可以存储您在区块链分类账上控制的替代币数量的记录。
钱包软件是一个人在自己的计算机上运行以管理其比特币的软件。钱包商品由ChromaWallet，CoinSpark和CounterWallet等公司提供。其他公司包括Coinprism，Melotic和OneWallet。通常，要向某人或实体发送山寨币，发送者将扫描钱包地址QR码，或者通过电子邮件或其他方式获取接收者的地址字符。发件人使用钱包应用程序输入有关交易的其他信息，例如金额、费用、交付成本等。当发送者使用他们的私钥确认交易时，将从发送地址的所有者向网络广播一条消息，该消息表明该地址中的x个硬币现在属于新地址。它由发送者的私钥授权。几分钟后，每个区块链矿工将在区块链中记录该交易，并可以发送确认通知。用户设置钱包时，会自动生成一个altcoin地址以及一个公共和私有密钥。altcoin地址通常是一个以1或3开头的26-34个字母数字字符的标识符，表示altcoin支付的可能目的地。有时，该地址表示为QR码。它可以像电子邮件地址一样操作。拥有用户公钥钱包地址的人可以向该人发送山寨币。
本公开结合了该功能并且在通过网络或移动应用进行购买的情况下简化了该功能。在一个示例中，使用比特币、莱特币(或任何加密货币)时将发生的事情是一种新的API，该API通过存储在他们设备上的个人钱包和购买界面来协调山寨币支付(即购买按钮搜索结果、商家网站上的购买选项或社交媒体网站上发布的立即购买商品)。可以使用令牌和必要信息的适当通信协议来管理诸如存储、消息传递、钱包交互、移动支付、身份确认、安全性和信誉之类的组件，以将山寨币支付集成到广泛采用的支付请求API中。
假设在这种情况下，商家将接受加密货币。因此，当本文所公开的情况适用并且向用户呈现购买按钮时，将使用户能够使用其私钥来访问其山寨币以及商家的地址来进行购买，以及能够接收山寨币支付的商家地址。钱包软件可以保留区块链的副本(以特定货币进行的所有交易的记录)，作为验证硬币交易的分散计划的一部分。钱包可以是基于浏览器的、基于应用程序的，也可以是来自Blockchain.info、Mycelium、Coinbased、Electrum或其他提供商的单独的应用程序或智能手机钱包。换句话说，本公开的一个方面是将钱包合并到浏览器中，以便存储用户的贷方/借方/其他支付帐户，其地址以及他们的山寨币钱包。或者，协议可以在浏览器(在浏览器和商家之间使用API)和山寨币钱包之间传递数据。例如，钱包可以共享地址和私钥以执行支付，但是随后接收详细信息以将支付添加到区块链。
如上所述，对于要向用户发送山寨币以购买商品的用户而言，用户需要商家的地址和买方钱包的私钥部分，软件将在该部分检查其对要支付给商家的山寨币的控制权。在某些情况下，人们会扫描QR码查找钱包地址。通常，发件人(买方)扫描收件人地址的QR码，然后使用钱包应用程序输入有关交易的其他信息，例如金额、交易费用(确认由钱包软件预先指定的金额)或任何其他参数。当发送方提交交易时，将从发送地址的所有者向网络广播一条消息，该消息表明该地址中的x个硬币现在属于新地址。操作由发件人的私钥授权。发件人可以输入其私钥，也可以使用密码或指纹、声纹或其他授权来检索发件人的私钥。交易几乎立即在接收者的钱包应用程序中接收，状态为“未确认”，大约10分钟后，交易已确认，并且可以在每个区块链矿工的区块链中记录。
将基本的altcoin操作应用于当前方案，必须实现一些修改和新颖的功能。目标是使用户能够以简单易用的方式选择altcoin支付，就像通过支付请求API管理的是Visa支付或万事达卡支付一样，尽管altcoin是以完全独立的方式处理的。目前，例如，在用户的Amazon.com帐户中，可以列出几张信用卡，并且可以选择一张信用卡进行支付。这种方法也将使购买的山寨币也成为可能。
启用简单的“一键式”功能来选择山寨币支付流程，然后处理支付存在一些问题。如果用户在移动设备上并想要购物，则他们将无法扫描商家地址的QR码。另外，并非所有买家都拥有比特币型钱包。因此，通过API，商家广告或发布用户最终可以与之交互以进行购买的界面的商家可以接收到以下数据：查看该广告或界面的人已设置了网络货币钱包，并且具有表明他们可能通过比特币或其他货币进行购买的配置文件。API可以交换必要的要求和数据，以便在广告或其他界面(用户处于指示或可能发生购买意图的状态)中，可以将购买者的山寨币钱包所使用的相同类型的身份验证集成到界面中，以便用户只需要执行相同类型的功能即可访问其私钥。这可能是通过生物识别、密码等进行的。集成可以包括通过应用程序检索金额、交货地址、日期、商家以及所有此类数据、以及检索或接收买方的私钥以及使用他们的加密货币钱包，以便可以使用加密货币进行支付，但是商家通常以正常方式处理交货、商品购买和交付生命周期的管理以及潜在的回报等。
就这一点而言，假设数据指示存在钱包或用户偏好通知商家山寨币将/将被用于购买商品，则广告或图形表示将包含替代币可寻址到的商家地址作为其数据的一部分。在一种情况下，“购买按钮”可以包括使用存储的信用卡/借记卡或任何其他传统支付帐户的选项，或者用户可以选择一种加密货币帐户。如果选择了传统支付帐户，则此处公开的过程将利用存储在搜索实体、社交媒体网站、浏览器、其他支付代理或其他位置的支付帐户来处理购买或通过API将支付数据传输到商家网站，以提供必要的数据供商家处理支付(即，用户不必填写表格)。通过API交换的各种请求和响应使支付信息/交付信息和/或其他信息可以传达到商家网站，从而使购买过程简单且不需要用户填写支付表格中的字段。
本文公开的过程增加了加密货币支付机会。如果选择了替代币支付，则该界面将通过API或其他协议与用户的钱包进行交互，以检索用户的私钥或使用户能够输入私钥，从而可以进行加密货币交易并向商家支付。例如，可以生成一次性使用令牌，该一次性使用令牌向商户网站提供地址和/或私钥，使得其可以执行支付功能。或者，API可以从商家网站接收金额，商家地址，任何其他数据(例如税金，费用等)，并且API可以接收该数据并与电子钱包或浏览器进行通信，以处理来自用户的山寨币钱包的支付。可以将山寨币钱包集成到浏览器中，以便由Chrome、Mozilla、InternetExplorer等执行处理。如果API位于商家和浏览器之间，则单独的API或协议可以在浏览器和浏览器之间传递数据用户在其设备上的山寨币钱包。同样，山寨币向商家的实际转移可以发生在任何可行的组件中。可能是通过用户的altcoin钱包，合并到浏览器中的altcoin钱包的实例，也可能是通过进行转移的商家进行的。
通常，必须计算山寨币的购买金额，因为它最初可能会以美元设置，但需要转换为购买者将使用的相应加密货币的相应价值。在这方面的过程可能包括访问数据提要，该数据提要提供以美元(或商家使用的任何其他货币)为单位的加密货币的当前值。该访问可以实时或接近实时地进行，使得当买方进行购买时，将加密货币的适当价值应用于购买。该价值和数据馈送可以在购买时呈现给用户，并且可以是购买界面的一部分。
购买过程中的购买按钮和后续屏幕可能包括界面与购买者对货币钱包的访问权的混合。因此，该界面可以包括与传统支付帐户连接或触发支付的一部分，以及与买方的用于加密货币的钱包相关联的另一部分。可以向用户提供购买选项，以使用Visa、Mastercard或Bitcoin进行支付。如果用户选择了加密货币，则系统将启用与钱包的交互，以便通过自动或手动访问来提供或访问用户的私钥。密码、指纹授权或手动输入私钥都可以通过商品的购买界面进行，无论它是商家网站、广告、Google购物图形、Google上的购买界面(或任何搜索实体界面)、任何浏览器图像或应用程序界面、或使用W3C.org开发的PaymentRequestAPI的一部分。商家可以提供他们的地址，并且一旦买方提供了他们的私钥，就可以将加密货币从买方传输到卖方，以获取商品的适当金额。然后，商品的所有过程都可以照常进行，例如跟踪、商品交付、交付信息的传达、取消、修改等。
在一个示例中，为了将用户的私钥保存在其钱包中的设备上，该过程可能包括接收到确认用户想要通过比特币进行支付的确认。通过API，商家应用程序可以提供成本信息、交易ID、商家ID、商家地址、送货费用、税金和/或折扣数据等。API可以直接或通过浏览器或两者结合将数据传递到用户的钱包。钱包可以确认并填充其交易所需的字段，例如商户地址、金额、票据等。可以修改典型的钱包以包括交易ID、商户ID、用户偏好(2天发货)等。但是，许多信息也可以通过API从代理、浏览器、搜索引擎等提供。一旦用户的钱包中填充了用于执行交易的数据，然后，与用户进行交互的商家网站或应用程序上的界面可以请求密码或生物特征确认以完成交易。或者，尽管安全性较差，但当用户单击“支付”或样式相似的按钮时，用户可能只选择自动处理。通过与API的购买接口交互，确认命令会指示钱包进行交易并将山寨币转移给商家或接收者。
当前，设置了用于信用卡、借记卡等的支付处理系统以供商家使用。因此，在通过API的标准支付方式中，支付账户信息通过API从浏览器或其他代理传递到商家网站以进行支付处理。支付帐户数据可以一种安全的一次性使用方式传输给商家，并进行配置，以便可以处理支付，但商家无法存储用户的支付帐户数据。但是，如果用户选择山寨币支付方式，则他们不太可能希望将其私钥发送给商家。处理山寨币支付与标准的Visa/Mastercard交易类型不同。因此，一方面，API将从商户接收他们的地址，金额和/或完成山寨币支付所需的任何其他数据。然后，API可以将该数据提供给用户的替代币钱包，无论该钱包与浏览器或其他代理是分开的，还是集成到浏览器或其他代理中的。然后，山寨币钱包可以向商户地址支付山寨币的金额以支付商品/服务。交易ID可以与购买的商品相关联。然后可以继续通过API将通知传达回商家。可以通过界面向用户通知进度以及后端发生的情况(“亚马逊正在将数据发送到您的比特币钱包以处理支付”…“电视已确认1.2比特币的支付”)。如果用户有多个不同的山寨币钱包，则可以以类似的方式并行处理它们。即，用户可以选择使用比特币还是莱特币(或他们拥有的任何其他山寨币)支付。根据选择哪个，执行访问相应山寨币钱包的特定处理以进行支付。
通过上述方法，即使使用完全独立的基于区块链的支付流程，也可以将加密货币的使用与其他标准形式的支付和通过API(如Payment RequestAPI)进行支付处理的集成集成在一起，该API通过消除用户填写姓名、地址、支付帐户数据等的支付表单字段的方式，简化了购买过程。
该方法的示例方法可以包括：接收购买者具有山寨币账户的指示；呈现使用山寨币账户进行支付的选项；以及接收使用山寨币的确认。该方法包括从商家网站通过API与浏览器或代理进行通信，以提供有关物品购买的信息。山寨币钱包可以配置为单独的应用程序，也可以集成到浏览器或其他代理进程或组件中。山寨币钱包接收有关购买的数据并处理向商家的支付。钱包可以使用通过API从商家接收的信息来填充其数据字段。山寨币钱包可以包括通过协议将支付细节传达给浏览器或通过API传达给商家的能力。商家网站界面可以将使用他们的山寨币帐户进行购买成功/失败的更新告知购买者。可以访问数据供稿以提供当前的美元价格。如果要购买的商品是20美元，那么在购买时，用户可以看到购买该商品的成本为.02比特币，而他们目前有5比特币。实施方案可以包括从山寨币钱包、浏览器、代理、智能合约、一个或多个API的任一侧和/或商家网站的角度所公开的处理。因此，可以在此过程中以任何配置将权利要求指向任何组件(即，将altcoin钱包分开或集成到浏览器中，等等)。最终目标是使通过altcoin进行的支付像“一键式”购买一样简单，即可进行Visa类型的支付。
此类支付的处理也可以通过使用智能合约来实现。智能合约是可以在区块链上实现的程序，它以不信任的方式执行某些操作。换句话说，它使用区块链技术的分布式方法以已知且透明的方式执行其操作。智能合约是自主的、自给自足的和分散的。它们自动运行并执行编程功能。无需“信任”人员来履行合同的一部分。在一个示例中，智能合约可以用于本文公开的全部或部分处理。例如，假设商家网站的用户界面为用户提供了使用其山寨币购买商品的选项。用户通过“支付”按钮确认购买。说的数量是1比特币。购买者对承诺的指示或确认可以与1比特币一起传输到基于区块链技术的智能合约。物品的卖家也许可以确认他们拥有商品并且可以明天发货。智能合约可以将1比特币转移给商家，并向买方发送通知，告知该物品正在运送中。或者，可以对智能合约进行编程，以在发生交付确认时将1比特币交付给商家。在某个阶段，数据包的通信和跟踪可以过渡到正常的跟踪和通知过程，例如由Amazon.com操作以管理所进行的购买、退货政策等。如果要退货，则商家可以将1Bitcoin转移到智能合约，然后可以根据其协议向购买者支付。因此，就此而言，本公开涵盖了在商家网站之间通过API与浏览器、山寨币钱包、智能合约和/或其他代理进行通信的所有通信、请求、响应和数据，以实现使用山寨币以相同方式进行支付的一键式购买选项作为常规支付帐户。由于山寨币的使用方式不同，因此必须修改当前的API(例如支付请求API)，以适应山寨币的替代支付结构。通过扩展API并包括山寨币钱包和/或智能合约的组件以在该过程中执行功能，可以实现购买方式的改进，以增加通过山寨币进行支付的能力。
这种方法的另一个方面可能是向用户的山寨币钱包支付。例如，有了可以包含买方地址和商家地址的altcoins结构，altcoins支付可以双向流动。因此，少量的激励可以流向用户。当前，如果点击广告作为搜索引擎结果的一部分，则搜索引擎将获得支付。将用户的钱包整合到流程中，广告商可以向点击其广告的买方支付一些山寨币的费用。例如，图形可以显示用户通过点击广告并浏览商家网站上的内容来生成多少山寨币。当用户到达导航中进行购买的状态时，用户可以将通过浏览生成的山寨币应用于购买或保留它们。购买结束时的所有余额和调整都可以任何方式实施，包括通过提交智能合约。可以通过积分向用户的altcoins钱包提供特惠价、折扣、激励措施等，这些积分在销售结束时已完成或最终确定。这种信用也可以在整个过程中自动进行。因此，当用户点击广告时，山寨币可以通过将其地址与浏览器/代理集成而自动转移到他们的山寨币钱包中，或者可以存在或提出一定数量的山寨币转让承诺，从而如果用户点击并在网站上购买了商品，则最终的实际转移会发生。如果用户不是使用山寨币而是使用美元或其他某种货币进行购买，则甚至可能发生转移。这方面涵盖了所有有关商户在与买家交互或通过其他方式(例如，通过短信，电子邮件、社交媒体互动等)与买家交互时如何向他们提供山寨币的变化。如果用户喜欢某个商家或非商家网站，则该网站可以将山寨币发送到用户的钱包。这将增强用户的体验，并鼓励他们与商家或其他网站进行更多互动。
另一个方面可能是使用区块链来存储和维护有关浏览器API交易的知识。区块链是一个分布式数据库，维护着不断增长的有序记录列表(称为块)。每个块都包含一个时间戳和一个到前一个块的链接。通过设计，区块链具有固有的抵制数据修改的能力-一旦记录下来，块中的数据就无法追溯更改。通过使用对等网络和分布式时间戳服务器，可以自主管理区块链数据库。区块链是“一个开放的、分布式的分类帐，它可以有效地、可验证的、永久的方式记录双方之间的交易。分类帐本身也可以被编程为自动触发交易。”
区块链通过设计和具有高拜占庭式容错能力的分布式计算系统的示例是安全的。因此可以通过区块链实现去中心化共识。这使得区块链适合于记录事件，例如此处披露的购买交易。
Satoshi Nakamoto在2008年将第一个区块链概念化，并于次年将其作为数字货币比特币的核心组成部分，在其中充当所有交易的公共分类账。比特币区块链的发明使其成为解决双重支出问题的第一种数字货币，而无需使用受信任的授权机构或中央服务器。比特币设计一直是其他应用程序的灵感来源。
例如，可以为特定用户开发通过特定浏览器进行的所有购买的区块链记录。还可以将区块链的范围缩小到使用可通过浏览器API获得的一个支付帐户来跟踪交易。因此，如果用户拥有可用的VISA帐户和Apple Pay，则使用签证帐户进行的所有支付都可以保留在区块链上。或者可能是通过存储的API进行的购买。在这方面，可以修改API，以便与交易关联的数据可以使用与交易关联的一个或多个信息(名称、地址、支付帐户、商品、价格、提供的折扣、订购时间、交货时间、已付税金等、是否为礼物、退回的物品、购买历史、购买环境，例如在Facebook上投放广告，或从Google广告交易，等等)。其他服务可以访问这种区块链的结构。利用有关购买信息的管理系统，以帮助用户可以为该交易或该浏览器利用区块链中的信息。其他交易(例如Amazon.com购买)也可以输入该用户或该账户的区块链。
该权利要求可能涵盖接收有关通过互联网进行的购买的信息，并利用该信息创建区块链记录。以后使用该帐户进行购买时，可以将API、浏览器、PWA、App、person等添加到该区块链，以记录和提供信息。
要解决的问题是，当您使用浏览器API在网络上购买商品时，人们如何才能轻松地管理这些购买、跟踪购买、取消购买、更改参数(运输模型)等等。没有一种机制可以使一个人去一个可以看到所有各种购买商品的地方。如果将用户的每次购买添加到私有或公共的区块链中，并且有API或机制可将互联网上的购买报告给基于每次购买而持续构建的区块链，那么本公开还提供了随后访问个人数据的能力。可以授予该人访问区块链的权限，作为购买授权的一部分(Apple Pay的指纹或VISA购买的CVC代码)，协议中可以包括当用户授权支付时，其中包括添加或访问其购买区块链的授权。
如果用户基本上是在访问其购买历史以进行更改或跟踪购买，则该用户可以通过用户界面授权对其数据的访问，并且当该访问被授予时，可以将区块链上的信息转换成类似于在Amazon.com上购买但跨商家和/或应用程序的商品清单的用户界面。同样，一方面，用户可以出售对其区块链的访问权限。用户可以通过向人们提供访问其区块链的方式来赚钱。在这种情况下，可以解剖一些信息，例如其名称和地址。可以以匿名方式提供数据，以便为商品、时间、上下文和邮政编码提供数据，但不提供名称、地址、帐号等信息。
一方面，商家网站将通过API接收支付信息，作为令牌化支付或作为支付帐号、名称、到期日期等。区块链的过程可以以任何形式使用该信息，以识别要访问的区块链以追加当前交易的数据。也可以通过其他某种机制来访问它，例如用户名或与浏览器关联的另一个ID号。
此外，可以通过用户身份来识别区块链，因此多个帐户可以与用户相关联并存储在同一区块链上。其他数据(例如存储其衬衫、裤子、鞋子的尺码的用户的身体模型以及其他与身体相关的数据)也可以存储在区块链中。
区块链可以通过浏览器API购买或任何其他购买(包括实体购买)来构建。用户可以注册一项服务，该服务将使用他们使用的各种账户向每次购买交易报告给区块链服务，从而使用户可以从单个用户界面访问所有这些购买交易，类似于用户如何访问和管理购买历史。可以使用API来建立区块链服务，无论用户是在线、在Amazon.com还是通过浏览器API等进行购买，公司都可以与之交互。可以设置与支付账户或用户账户相关联的参数，使得与购买相关联的特定细节集合被传达给区块链服务API。因此，如果某人使用其存储的VISA帐户在Amazon.com上购买了一本书，则可以通过API将购买的详细信息传达给为该购买创建一个区块的区块链服务提供商。接下来，此人使用VISA卡在HomeDepot购买锤子。由于已设置参数，因此可以通过API将购买的详细信息(包括锤子的购买、时间、位置等)传递给服务，并且可以将该购买添加到区块链中。接下来，问题是用户如何获得所有这些购买数据的访问权？用户可能想返回并返回书。人们在不同的商家之间进行购买并采用不同的支付方式时(一些商家将使用购物车，另一些商家将使用浏览器API，Amazon.com，亲自使用等)，用户会希望将所有购买的商品都放在一个位置进行管理。区块链服务可以提供一个管理用户界面，向用户呈现购买历史和状态。区块链服务还可以通过API接收来自分销实体(FedEX、UPS等)的跟踪信息，该API可以将跟踪状态与特定商品相关联，并包括区块链上的更新数据。因此，就此而言，区块链可以不断更新。区块链服务可以通过用户界面显示信息。可以通过网站、应用程序、浏览器API界面、通过社交媒体、数字钱包界面、Apple Pay界面或Androidpay界面等中的可选对象或可选菜单访问用户界面。换句话说，在用户“所在”的任何虚拟位置，都可以显示一个可选择的对象，该对象使用户能够访问购买管理界面。可选对象还可以显示在用户可用的多个位置，包括浏览器中的选项。例如，在AmazonAssistant或浏览器的另一个插件中，该服务可以提供以前购买及其状态的更新列表。此状态更新的基础数据可以基于区块链。
此外，可以在浏览器中存储的信息(例如支付帐户、地址等)可以存储在区块链上，并可以从浏览器访问。还可以调用服务的单独API，该服务将该信息存储在区块链上并返回支付帐户数据、令牌、地址信息、名称等。因此，区块链可以保存信息，而不是浏览器，并且一旦浏览器接收到针对支付信息和/或与购买相关的其他信息的API请求，浏览器便可以从区块链访问必要的信息。这也可以分几个步骤进行。此外，商家网站还可以通过API直接从区块链访问信息，而不是通过浏览器功能来访问区块链。
使用这种方法，个人可以将他们的支付信息、地址等存储在一个区块链中，任何需要该支付信息的网站都可以通过适当的API安全地访问它。设备上的数字钱包可能是使用信息访问区块链的机制。浏览器(使用“浏览器”的任何时候，它也可以覆盖用户界面或商家的代理)，一旦接收到API请求，就可以识别将使用区块链数字钱包(或访问代理)来获取信息，而不是在浏览器中存储签证帐户。浏览器与访问代理进行通信，以从区块链中检索信息并将其返回给浏览器。浏览器通过浏览器API将信息传达到商家网站以进行支付处理。
与本文公开的API有关的加密货币或分类帐技术可以包括一种经由浏览器授权支付数据的方法。权利要求可以针对浏览器操作、系统设备/客户端设备和操作、商家网站操作、从数字钱包或提供加密货币支付的支付服务的角度来看的操作等。
一种示例方法包括从网站在浏览器处并通过浏览器支付请求应用程序编程接口接收与潜在购买相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求包括网站接受的加密货币支付方法的标识，从所述浏览器并通过所述浏览器支付请求应用程序编程接口向所述网站传输数据，该数据表明浏览器用户能够通过由所述网站接受的加密货币支付方法为潜在购买支付，并通过所述浏览器支付请求应用程序编程接口接收授权的支付数据，以使用所述加密货币支付方法进行购买支付.该方法还可包括使用授权的支付数据填充加密货币钱包，以使所述加密货币钱包能够进行支付，并通过所述浏览器支付请求应用程序编程接口启动所述加密货币钱包。
授权的支付数据可以通过加密货币支付信息来进行，该信息包括用于接收支付的网站地址、用户的私钥、接收者的公钥、电子邮件地址、接收者标识信息、支付金额和用户评论中的至少一个。加密货币钱包可以包括在运行所述浏览器的设备上本地存储的钱包和基于Web的钱包中的至少一种。
当加密货币钱包是基于Web的钱包，该方法还可包括通过应用程序编程接口将所述授权的支付数据传输到所述基于Web的钱包以处理所述支付。除了加密货币支付方式之外，该请求还可以标识网站使用的受支持的支付方式。授权的支付数据可以包括私钥，该私钥用于签署与加密货币钱包的交易。该方法还可包括通过所述浏览器支付请求应用程序编程接口传输数据到所述网站，以通过网站加密货币钱包用于接收支付。授权的支付数据可以存储在浏览器中，由浏览器从单独的实体访问，可以通过浏览器支付请求应用程序编程接口从网站接收，可以从第三方接收，按照浏览器的指示从第三方传递到网站。
其中当用户选择所述加密货币支付方法用于购买时，该方法还可包括通过所述浏览器支付请求应用程序编程接口生成混合用户界面，该界面混合支付交互界面和加密货币钱包界面，以供用户用来确认支付.
在另一个示例中，一种方法可以包括从网站到浏览器并通过浏览器支付请求应用程序编程接口传输与购买支付相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求包括网站接受的加密货币支付方法的标识，在所述网站处从所述浏览器并通过所述浏览器支付请求应用程序编程接口接收数据，该数据表明浏览器用户能够通过由所述网站接受的加密货币支付方法为购买支付来支付，并基于来自所述用户确认通过所述浏览器支付请求应用程序编程接口使用所述加密货币支付方法来处理所述购买支付，接收使用所述加密货币支付方法来支付。
该方法还可包括在网站加密货币钱包处从加密货币钱包接收所述支付，其中授权的支付数据用于填充所述加密货币钱包以启动所述支付。授权支付数据可以包括识别网站加密货币钱包和金额的数据中的至少一个。
加密货币钱包可以存储在操作浏览器的设备和与该设备分离的基于Web的设备之一上。
系统示例包括处理器和存储指令的计算机可读存储介质，该指令在由处理器执行时使处理器执行操作，包括从网站在浏览器处以及通过浏览器支付请求应用程序编程接口接收信息，该接口定义用于在网站和浏览器之间传递数据的协议，与潜在购买相关的请求，其中该请求包括网站接受的加密货币支付方法的标识；从所述浏览器并通过所述浏览器支付请求应用程序编程接口向所述网站传输数据，该数据表明浏览器用户能够通过由所述网站接受的加密货币支付方法为潜在购买支付并经由浏览器支付请求应用程序编程接口接收用于潜在购买的授权支付数据。
授权的支付数据可以包括用于接收支付的网站地址、用户的私钥、收件人的公钥、电子邮件地址、接收者标识信息、支付金额、用户评论中的至少一个。与授权的支付数据相关的加密货币钱包可以包括在运行所述浏览器的设备上本地存储的钱包和基于Web的钱包中的至少一种。
其中当用户选择所述加密货币支付方法用于购买时，计算机可读存储介质可以存储其他指令，这些指令在由处理器执行时，使处理器执行进一步包括通过所述浏览器支付请求应用程序编程接口生成混合用户界面的操作，该界面混合支付交互界面和加密货币钱包界面，以供用户用来确认支付。该计算机可读存储介质可以存储附加指令，这些附加指令在由处理器执行时使处理器执行进一步的操作，包括经由应用程序编程接口将授权的支付数据传输至加密货币钱包以处理支付，或通过所述浏览器支付请求应用程序编程接口传输数据到所述网站，以通过网站加密货币钱包用于接收支付。
在处理支付的另一示例方法中，该方法可以包括在加密货币钱包处接收与购买相关的授权的支付信息，其中从网站在浏览器处并通过浏览器支付请求应用程序编程接口接收与潜在购买相关的请求，基于浏览器生成所述授权的支付信息，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求包括网站接受的加密货币支付方法的标识，使用来自所述加密货币钱包的加密货币并基于所述授权的支付信息来处理所述支付，并向所述浏览器传输与使用所述加密货币的支付处理相关的确认数据。
用于处理支付的示例系统包括处理器和存储指令的计算机可读存储介质，该指令在由处理器执行时使处理器执行包括以下的操作：在加密货币钱包处接收与购买相关的授权的支付信息，其中从网站在浏览器处并通过浏览器支付请求应用程序编程接口接收与潜在购买相关的请求，基于浏览器生成所述授权的支付信息，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求包括网站接受的加密货币支付方法的标识，使用来自所述加密货币钱包的加密货币并基于所述授权的支付信息来处理所述支付，并使用加密货币向浏览器传输与购买处理相关的确认数据。
另一示例方法包括接收支付的方法，该方法包括从网站到浏览器并通过浏览器支付请求应用程序编程接口传输与购买支付相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求可以包括网站接受的支付方式的标识，其中所述支付方法使用加密货币，并在所述网站处根据所述支付方法接收支付，其中所述支付方法根据通过所述浏览器支付请求应用程序编程接口传输的请求启动的加密货币支付方法来使用所述加密货币。加密货币支付方法还可以包括将第一货币转换为第二货币。
加密货币支付方法可以使购买者能够使用第一货币从卖方购买商品，并以第二货币向卖方支付，其中，加密货币用于桥接所述第一货币和所述第二货币之间的转换。
另一个系统示例包括用于处理支付的系统。该系统可以包括处理器和存储指令的计算机可读存储介质，该指令在由处理器执行时使处理器执行以下操作，包括：从网站到浏览器并通过浏览器支付请求应用程序编程接口传输与购买支付相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中所述请求包括由所述网站接受的支付方法的标识，其中所述支付方法使用加密货币，并在所述网站处根据所述支付方法接收支付，其中所述支付方法根据通过所述浏览器支付请求应用程序编程接口传输的请求启动的加密货币支付方法来使用所述加密货币.
加密货币支付方法使购买者能够使用第一货币从卖方购买商品并且以第二货币向卖方支付，其中加密货币用于桥接所述第一货币和所述第二货币之间的转换。
一种操作支付服务的方法还可以包括在所述支付服务处接收与购买相关的授权的支付信息，其中从网站并通过浏览器支付请求应用程序编程接口接收与购买支付相关的请求，在浏览器上生成授权的支付信息，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求可以包括至少部分使用加密货币的支付方法的标识，使用所述加密货币并基于所述授权的支付信息来处理支付，并向所述浏览器传输与使用所述加密货币的支付处理相关的确认数据。
示例性支付服务包括处理器和存储指令的计算机可读存储介质，该指令在由处理器执行时使处理器执行以下操作，包括：接收与购买相关的授权支付信息，其中从网站在浏览器处并通过浏览器支付请求应用程序编程接口接收与潜在购买相关的请求，基于浏览器生成所述授权的支付信息，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中请求可以包括至少部分使用加密货币的支付方法的标识，使用所述加密货币并基于所述授权的支付信息来处理支付，并向所述浏览器传输与使用所述加密货币的支付处理相关的确认数据。
进一步处理支付可以包括将第一货币转换成加密货币。处理支付还可以包括将从购买者接收到的第一货币转换成加密货币，以及将加密货币转换成用于支付卖方的第二货币。
另一示例方法包括基于来自用户的表明购买意愿的输入，从网站在浏览器处通过第一应用程序编程接口接收与所述购买相关的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议，从所述用户并通过所述第一应用程序编程接口接收由所述网站支持的支付方法的选择，其中所述支付方法至少部分使用加密货币，并且其中支付交易至少部分由支付服务管理，并且响应于所述支付请求和所述支付方法的选择，从所述浏览器并通过第二应用程序编程接口将支付请求事件通信到所述支付服务，该接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议，支付请求事件包括由所述支付服务使用以至少部分地使用所述加密货币来处理支付的数据。
支付请求可以包括有关购买的信息以及由所述网站支持的一系列支付方法的选择。由支付服务管理的支付流程可以使用加密货币进行支付。
由支付服务管理的支付方法还可以通过执行以下至少一项来进行支付：(1)从第一货币转换为加密货币，以及(2)从加密货币转换为第二货币。
支付服务管理的支付方法可以通过将购买者提供的第一货币转换为加密货币，再将加密货币转换为卖方接受的第二货币进行支付。第一货币可以包括第一法定货币和第一加密货币中的一个，并且其中第二货币可以包括第二法定货币和第二加密货币中的一个。
示例系统包括处理器和存储指令的计算机可读存储介质，所述指令在由处理器执行时使处理器执行以下操作，包括：基于来自用户的表明购买意愿的输入，从网站在浏览器处通过第一应用程序编程接口接收与所述购买相关的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议,从所述用户并通过所述第一应用程序编程接口接收由所述网站支持的支付方法的选择，其中所述支付方法至少部分使用加密货币，并且其中支付交易至少部分由支付服务管理，并且响应于所述支付请求和所述支付方法的选择，从所述浏览器并通过第二应用程序编程接口将支付请求事件通信到所述支付服务，该接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议，支付请求事件包括由所述支付服务使用以至少部分地使用所述加密货币来处理支付的数据。
支付请求可以包括有关购买的信息以及由所述网站支持的一系列支付方法的选择。由支付服务管理的支付交易可以用加密货币进行支付。支付服务管理的支付交易可以通过执行以下至少一项来进行支付：(1)从第一货币转换为加密货币，以及(2)从加密货币转换为第二货币。支付服务管理的支付方法可以通过将购买者提供的第一货币转换为加密货币，再将加密货币转换为卖方接受的第二货币进行支付。第一货币可以包括第一法定货币和第一加密货币中的一个，并且其中第二货币可以包括第二法定货币和第二加密货币中的一个。
另一个方法示例包括在支付服务处接收支付请求事件，其中在支付服务处接收支付请求事件基于下列：通过第一应用程序编程接口浏览器接收来自网站的用于与商品购买相关的支付数据的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议，其中支付请求是基于来自用户的表明购买商品意愿的输入并可以包含有关购买的信息以及从所述用户并通过所述第一应用程序编程接口接收所述支付服务的选择，其中所述支付请求事件从所述浏览器并通过第二应用程序编程接口接收，所述第二应用程序编程接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议。该方法包括在所述支付服务处处理所述支付请求事件以启动包括至少部分使用加密货币的支付方法。
该方法还可包括向所述浏览器从所述支付服务并通过所述第二应用程序编程接口传输授权的支付信息，其中所述浏览器通过所述第一应用程序编程接口向所述网站通信所述授权的支付信息。支付请求可以包含有关购买的信息，以及由所述网站支持的一系列支付方法的选择。由支付服务管理的支付方法可以用加密货币进行支付。支付服务管理的支付方法可以通过执行以下至少一项来进行支付：(1)从第一货币转换为加密货币，以及(2)从加密货币转换为第二货币。支付服务管理的支付方法可以通过将购买者提供的第一货币转换为加密货币，以及将加密货币转换为卖方接受的第二货币进行支付。第一货币可以包括第一法定货币和第一加密货币中的一个，并且其中第二货币可以包括第二法定货币和第二加密货币中的一个。
另一个示例系统涵盖支付服务。就这一点而言，支付服务包括处理器和存储指令的计算机可读存储介质，所述指令在由处理器执行时使处理器执行以下操作，包括：接收支付请求事件，其中，接收支付请求事件基于：通过第一应用程序编程接口浏览器接收来自网站的用于与商品购买相关的支付数据的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议，其中支付请求是基于来自用户的表明购买商品意愿的输入并可以包含有关购买的信息以及从所述用户并通过所述第一应用程序编程接口接收所述支付服务的选择，其中所述支付请求事件从所述浏览器并通过第二应用程序编程接口接收，所述第二应用程序编程接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议。该方法包括在所述支付服务处处理所述支付请求事件以启动包括至少部分使用加密货币的支付方法.
支付请求包括有关购买的信息以及网站支持的一组支付方式选择。支付服务使用的支付方法可以用加密货币进行支付。支付服务使用的支付方法可以通过执行以下至少一项来进行支付：(1)从第一货币转换为加密货币，以及(2)从加密货币转换为第二货币。
支付服务使用的支付方法可以通过将购买者提供的第一货币转换为加密货币，以及将加密货币转换为卖方接受的第二货币来进行支付。第一货币可以包括第一法定货币和第一加密货币中的一个，并且其中第二货币可以包括第二法定货币和第二加密货币中的一个。
另一个方法示例包括基于来自用户的表明购买意愿的输入，从网站在浏览器处并通过第一应用程序编程接口传输与购买相关的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议,通过所述第一应用程序编程接口传输由所述网站支持的支付方法的选择，其中所述支付方法至少部分使用加密货币，并且其中支付交易至少部分由支付服务管理，其中，响应于所述支付请求和所述支付方法的选择，第二应用程序编程接口将支付请求事件通信到所述支付服务，所述第二应用程序编程接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议，所述支付请求事件包括由所述支付服务使用以通过至少部分地使用所述加密货币的支付方法来处理支付的数据，并通过所述支付方法接收所述支付。
另一示例系统可以包括处理器和存储指令的计算机可读存储介质，所述指令在由处理器执行时使处理器执行操作，包括：基于用户指示要购买的输入，从网站向浏览器并通过第一应用程序编程接口传输，该接口定义用于在浏览器和网站之间传递数据的第一协议，与购买相关的支付请求，通过所述第一应用程序编程接口传输由所述网站支持的支付方法的选择，其中所述支付方法至少部分使用加密货币，并且其中支付交易至少部分由支付服务管理,其中,响应于所述支付请求和所述支付方法的选择，第二应用程序编程接口将支付请求事件通信到所述支付服务，所述第二应用程序编程接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议，支付请求事件包括用于由支付服务用于根据至少部分地利用加密货币的支付方法来处理支付并且经由至少部分地利用加密货币的支付方法来接收支付的数据。
与上述任何示例系统或方法相关联的任何特征都可以应用于任何其他示例系统或方法。
动态购买按钮
上面讨论了上面的动态对象或动态按钮的概念。可以提供动态按钮或双重用途按钮的概念。此概念解决了以下情况：具有第一帐户的用户可以与第一浏览器类型相关联，该用户可以导航到商家网站以购买商品。可以对商家网站进行编程，以检测该用户的浏览器类型、浏览器特性、支付请求API类型和/或帐户类型中的一种或多种，并显示相应的动态购买按钮。因此，呈现给用户的购买按钮可以适合这些因素中的一个或多个。如果第二个用户使用第二个浏览器类型或第二个帐户类型，或基于某些其他因素导航到相同的商家网站，则商家网站可以动态地调整提供给该用户的对象，这样就可以根据自己的特点量身定制购买按钮。这种方法的好处是，每个用户都可以拥有一个可识别的、个性化的、动态修改的或动态呈现的购买按钮，这些按钮对于品牌或整个网站的一致体验是他们熟悉并信任的。以下讨论涉及与在使用支付请求API和提供动态购买按钮的情况下减少点击次数相关的几个概念。
本文公开的概念涉及如何在浏览器支付请求API的上下文中减少点击。当前过程是用户位于商家网站(任何网站或应用程序)上，并单击“购买”按钮，添加到购物车按钮或提供其他输入(如语音)以发起购买。merchant.com网站将与浏览器进行通信，通过浏览器浏览该网站，以协调该网站接受的支付方式和用户可用的支付方式。假设用户和商家均可使用比特币和Visa。一旦确定了支付方式的重叠，浏览器API将提供一个界面(或语音或其他方式)，用户可以从中选择比特币或Visa。关键是在此阶段，用户只需要单击一下或一次命令即可选择支付方式并启动支付方法。有几种方法可以做到这一点。一个可以是与用户要使用的支付类型相协调的动态按钮，也可以是两用按钮。
可以对浏览器API进行编程，以显示一个两用按钮，用户可以在其中选择并启动支付方法。该按钮也可以是动态的，并可以根据用户使用的支付类型或浏览器类型进行调整。对于比特币或任何加密货币支付方法，用户可以在API界面中单击比特币对象，该对象将接受对方法的选择并启动支付方法，而无需再次单击“支付”按钮。该API将基于“选择并支付”按钮的单击，启动商家网站与浏览器和买方钱包之间的数据通信。例如，在API界面中点击比特币后，API可以从商家网站请求公共密钥或数据以识别商家钱包。这可以是一组数据，包括公钥、交易ID、网站上的用户搜索历史记录、社交媒体数据、动态公钥数据或任何其他数据。但是，数据中应包含merchant.com钱包的标识。可以将该数据与加密货币中的购买金额以及任何其他数据通信到购买钱包。加密货币钱包经过编程以从浏览器API接收数据和功能指令，从而在后台自动执行打开钱包，填充数据，启动交易等过程，并根据用户从浏览器API界面中选择的加密货币自动生成。
在浏览器API界面中启用选择和启动按钮的一种方法是使用户界面(而不仅仅是界面外部的按钮)能够读取指纹。如果整个界面或界面的选定部分都能够读取指纹以确认购买，则“选择比特币和支付”按钮可以接收选择比特币的手指按下操作，而用户界面则读取该手指按下的指纹确认用户的身份并通过相同的交互方式启动支付方法。指纹读取器以及用户界面外部也可以具有图形组件，用户可以在其中看到“比特币”或“Apple Pay”，从而用户只需单击带有指纹的按钮即可选择支付方式和以安全级别确认买方。指纹感测组件的位置可以基于用户要选择的对象的位置而在触摸屏上的位置变化。
面部识别也可以与支付方式的选择结合使用。用户可以选择或说出比特币，然后简单地查看用于面部识别步骤的界面，然后该面部识别步骤将确认并执行此处公开的功能。
一方面，仅图形显示器的区域可以包括指纹读取器。在这种情况下，可以将图形界面的显示与指纹读取器进行协调，以便可以在指纹读取器区域上显示“选择并支付”的对象。图形显示可以包括多个区域，这样，如果用户可以选择在图形界面上选择比特币或Apple Pay，则用手指触摸选择的任何一个也将导致读取指纹并确认用户身份以进行支付处理。基于购买按钮的位置，该区域可以改变或移动到触敏屏幕上的不同位置。
在另一方面，一个公司可能想要以另一方不使用的货币或加密货币支付。在某些情况下，可接受的支付方式之间不会重叠。可以提供一项服务，如果双方都注册了该服务，则尽管它们使用不同的货币，但他们可以通过API协调支付。例如，买方可能想用美元支付，但卖方可能不想用美元支付，或者可能只有一个加密货币钱包。可以提供一种服务作为支付请求API交易的支付方式选项，这样支付人可以通过API接受VISA，但支付将转到服务提供商，后者会将支付从VISA转换为比特币，然后以比特币向卖方或商家支付。在一种情况下，无需为此方法签约双方，但也许只需要一个参与方。在这种情况下，如果商家仅接受比特币，并且已向服务注册，则可以对商家网站进行编程以提供以下功能。
假设商家接受比特币，并且买家可以用Visa、Mastercard或PayPal支付。假设该服务设置为可以接收Visa和Mastercard支付方式。可以对商家网站进行编程，使其通过支付请求API提示他们可以接收Visa或Mastercard(或比特币)。这就像通过API的代理通知一样。然后，该方法使API能够协调适用于买卖双方的支付方式。由于商家网站将显示Visa和Mastercard，因此买家可以选择Visa进行支付并确认支付。按钮可以根据这些帐户类型动态更改。可以向网站或服务提供商支付，然后由服务提供商将支付转换为比特币，然后将比特币转移到商家钱包。买家可能不知道最终支付是用比特币支付的，但只要支付方法本质上是“一键式”，就不必理会。
例如，网站可以通过API接收令牌以及交易的支付数据。该网站不接受VISA或信用卡支付，因此可以将令牌转发给处理支付的服务提供商，并向该网站返回与原始货币不同的币种。因此，可以处理签证支付并退还比特币。该处理可以全部或部分在商家网站或由单独的服务提供商完成。在上述情况下，如果商家接受比特币，而买方可以用比特币支付，则无需代理演示或服务提供商即可将美元转换为比特币。交易可以以标准方式发生。但是，如果各方之间没有货币匹配，则可以使用代理方法，在这种情况下，可以通过API通过代理表示为一方或双方进行货币转换，从而可以使用一种适用于买方的支付方式进行支付，以便可以接收支付，转换为卖方可以接受的新货币，然后传输或提供给卖方。该过程可能包括通过API发出的指令，即买方的支付应传输到URL标识的位置或基于网络的支付处理器，而不是通过令牌中的API。任何导轨都可以用于传输数据、令牌、公钥/私钥等。
图37示出关于动态修改购买按钮的该方法的一方面。一种方法包括在网站上确定通过浏览器访问网站的用户(1)是使用第一浏览器还是第二浏览器，或者(2)可以使用第一帐户或第二帐户进行购买以产生确定(3702)。当确定指示用户正在使用第一浏览器或可以使用第一帐户进行购买时，该方法包括，呈现与第一帐户相关联的动态修改的第一购买按钮(3704)，通过第一浏览器应用程序编程接口向第一浏览器发送，该接口定义用于在网站和第一浏览器之间传达关于购买的信息的协议，第一支付请求具有用于用户的与从网站的购买相关联的第一信息(3706)，并从第一浏览器并经由第一浏览器应用程序编程接口接收与第一账户相关联的第一数据，该第一数据与处理购买相关联(3708)。数据可以是支付服务已处理该数据的确认，也可以是网站处理购买或将数据提交给支付处理器的令牌或帐户数据。数据也可以是非货币数据，但有一定价值。
当确定指示用户正在使用第二浏览器或者可以使用第二帐户进行购买时，该方法包括呈现与第二帐户相关联的动态修改的第二购买按钮(3710)，经由第二浏览器应用程序编程接口向第二浏览器传输，该第二浏览器应用程序编程接口定义了用于在网站和第二浏览器之间传达有关购买信息的协议的第二支付请求，该第二支付请求具有与用户从网站购买相关的第二信息(3712)，并从第二浏览器并经由第二浏览器应用程序编程接口接收与第二帐户相关联的第二数据，该第二数据与处理购买相关联(3714)。
第一浏览器和第二浏览器可以是不同的浏览器类型，并且第一浏览器可以在第一设备上运行，第二浏览器可以在第二设备上运行。第一浏览器应用程序编程接口和第二浏览器应用程序编程接口可以分别与第一浏览器和第二浏览器的操作相关联。与第二帐户相关联的第二数据可以包括支付数据，该支付数据确认由支付服务执行了购买商品的支付。与第一帐户相关联的第一数据可以包括支付数据，该支付数据确认由支付服务执行了购买商品的支付。
该方法可以进一步包括：从第一浏览器接收通信，并且基于经由浏览器支付处理程序应用程序编程接口通信的数据，该接口定义用于在第一浏览器和支付服务之间传递数据的协议，该信息确认支付服务已处理了支付。
图38可以示出本公开的另一个方法方面。一种方法可以包括确定经由浏览器与网站接口的用户是否可以经由第一浏览器应用程序编程接口或第二浏览器支付请求应用程序编程接口进行支付以产生选定的浏览器和选定的浏览器应用程序编程接口，其中选定的浏览器应用程序编程接口定义了用于在网站和选定的浏览器之间通信数据以管理支付的协议(3802)，呈现与所选浏览器或通过所选浏览器启用的用户支付帐户相关联的动态修改的购买按钮(3804)，结合与动态修改的购买按钮的交互，向所选择的浏览器并经由所选择的浏览器应用程序编程接口发送支付请求(3806)，以及响应于所述支付请求，从所选择的浏览器并经由所选择的浏览器应用程序编程接口接收网站处的支付信息(3808)。
动态修改的购买按钮可以与用户支付帐户关联。可以将网站编程配置为接受例如不同的支付机制，并且API仅从浏览器中识别用户可用的支付机制。支付信息可以包括对支付已经由设备上的支付服务或支付应用程序进行处理的确认。该方法还可以包括从所选择的浏览器并经由所选择的浏览器应用程序编程接口接收确认信息。确认可以确认支付服务已成功向网站支付。优惠券、折扣、积分等也可以通过这些API合并到支付中。
这些实施方案可以按照方法、系统和计算机可读介质来描述，并且可以从商家网站、浏览器、浏览器制造商以及服务提供商的角度发生。
其他API也可以为网站提供有关正在浏览进行购买的特定用户的数据。例如，可以向网站提供位置、年龄、收入水平、购买习惯、社交媒体数据、浏览历史记录、用户使用的帐户类型、一个或多个用户帐户中有多少钱或有关该用户的其他信息，这样就可以将数据合并到有关如何显示支付按钮或如何为该用户修改支付流程的决策过程中。机器学习、人工智能、基于规则的逻辑或任何其他此类方法可以利用关于用户如何对支付流程做出反应的培训数据，以针对特定用户动态呈现特定流程，从而使他们的体验在各个支付平台上保持一致。这可以包括NFCPOS购买、在线购买、应用内购买和移动购买。实施方案可以包括从如上所述的商家网站发送和接收数据的角度出发的权利要求，从服务器或基于云的服务的角度来看的权利要求，该服务器或基于云的服务接收请求并提供响应以帮助网站为用户配置其基于浏览器的支付接口要求对其中的API进行更新，以接收请求并从充当代理的浏览器提供响应，以向网站提供参数或数据，以改善界面，从而在购买过程中减少摩擦。浏览器还可以使用另一个API，该API与基于网络的应用程序进行通信，以将数据发送回浏览器，然后浏览器可以将数据发送回网站以动态呈现接口。
在本公开的范围内的示例还可以包括有形和/或非暂时性的计算机可读存储设备，用于携带或具有存储在其上的计算机可执行指令或数据结构。这样的有形计算机可读存储设备可以是可由通用或专用计算机访问的任何可用设备，包括如上所述的任何专用处理器的功能设计。作为示例而非限制，这样的有形计算机可读设备可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储设备、磁盘存储设备或其他磁性存储设备、或任何其他可用于以计算机可执行指令、数据结构或处理器芯片设计的形式携带或存储所需程序代码的设备。当通过网络或其他通信连接(有线、无线或以上两种方式的组合)向计算机提供信息或指令时，计算机会将连接正确地视为计算机可读介质。因此，任何这样的连接被适当地称为计算机可读介质。上述的组合也应包括在计算机可读存储设备的范围内。
计算机可执行指令包括例如使通用计算机、专用计算机或专用处理设备执行某些功能或一组功能的指令和数据。计算机可执行指令还包括由计算机在独立或网络环境中执行的程序模块。通常，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构、对象以及专用处理器等设计中固有的功能。计算机可执行指令、相关联的数据结构和程序模块代表用于执行本文公开的方法的步骤的程序代码装置的示例。这样的可执行指令或相关联的数据结构的特定序列表示用于实现在这些步骤中描述的功能的相应动作的示例。
可以在具有许多类型的计算机系统配置的网络计算环境中实践本公开的其他示例，包括个人计算机、手持式设备、多处理器系统、基于微处理器的或可编程的消费电子商品、网络PC、小型计算机、大型计算机等等。还可以在分布式计算环境中实践示例，在分布式计算环境中，任务由通过通信网络链接(通过硬线链接、无线链接或两者结合)的本地和远程处理设备执行。在分布式计算环境中，程序模块可以位于本地和远程存储设备中。
上面描述的各种示例仅以说明的方式提供，并且不应被解释为限制本公开的范围。可以在不遵循本文示出和描述的示例示例和应用的情况下，并且在不脱离本公开的精神和范围的情况下，对本文描述的原理进行各种修改和改变。引用一组中的“至少一个”的声明语言表示该组中的一个成员或该组中的多个成员满足声明。值得注意的是，在任何示例或实施方案中描述的任何特征可以与实施方案的任何示例的任何其他特征结合。例如，关于搜索引擎示例所讨论的任何特征可以适用于社交媒体示例或商品购买管理引擎示例，并且可以与之互换。
Claims (35)
1.一种通过浏览器授权支付数据的方法，该方法包括：
从网站在浏览器处并通过浏览器支付请求应用程序编程接口接收与潜在购买相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中所述请求包括由所述网站接受的加密货币支付方法的标识；
从所述浏览器并通过所述浏览器支付请求应用程序编程接口向所述网站传输数据，该数据表明浏览器用户能够通过由所述网站接受的加密货币支付方法为潜在购买支付；和
通过所述浏览器支付请求应用程序编程接口接收授权的支付数据，以使用所述加密货币支付方法进行购买支付。
2.根据权利要求1所述的通过浏览器授权支付数据的方法，还包括：
使用授权的支付数据填充加密货币钱包，以使所述加密货币钱包能够进行支付；和
通过所述浏览器支付请求应用程序编程接口启动所述加密货币钱包。
3.根据权利要求2所述的通过浏览器授权支付数据的方法，其中所述授权的支付数据是加密货币支付信息，包括以下至少一种：用于接收所述支付的网站地址、用户的私钥、接收者的公钥、电子邮件地址、接收者标识信息、支付金额以及用户评论。
4.根据权利要求2所述的通过浏览器授权支付数据的方法，其中所述加密货币钱包包括在运行所述浏览器的设备上本地存储的钱包和基于Web的钱包中的至少一种。
5.根据权利要求4所述的通过浏览器授权支付数据的方法，其中当所述加密货币钱包为基于Web的钱包时，所述方法还包括：
通过应用程序编程接口将所述授权的支付数据传输到所述基于Web的钱包以处理所述支付。
6.根据权利要求1所述的通过浏览器授权支付数据的方法，其中除了所述加密货币支付方法，所述请求还标识由所述网站使用的支持的支付方法。
7.根据权利要求2所述的通过浏览器授权支付数据的方法，其中所述授权的支付数据包括用于与所述加密货币钱包进行交易签名的私钥。
8.根据权利要求1所述的通过浏览器授权支付数据的方法，还包括：
通过所述浏览器支付请求应用程序编程接口传输数据到所述网站，以通过网站加密货币钱包用于接收支付。
9.根据权利要求1所述的通过浏览器授权支付数据的方法，其中所述授权的支付数据存储在所述浏览器中，由所述浏览器从单独实体访问，通过所述浏览器支付请求应用程序编程接口从所述网站接收，从第三方接收，或根据所述浏览器的指示从所述第三方递送到所述网站。
10.根据权利要求1所述的通过浏览器授权支付数据的方法，其中当用户选择所述加密货币支付方法用于购买时，该方法还包括：
通过所述浏览器支付请求应用程序编程接口生成混合用户界面，该界面混合支付交互界面和加密货币钱包界面，以供用户用来确认支付。
11.方法，包括：
从网站到浏览器并通过浏览器支付请求应用程序编程接口传输与购买支付相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中所述请求包括由所述网站接受的加密货币支付方法的标识；
在所述网站处从所述浏览器并通过所述浏览器支付请求应用程序编程接口接收数据，该数据表明浏览器用户能够通过由所述网站接受的加密货币支付方法为购买支付来支付；和
基于来自所述用户确认通过所述浏览器支付请求应用程序编程接口使用所述加密货币支付方法来处理所述购买支付，接收使用所述加密货币支付方法来支付。
12.根据权利要求11所述的方法，还包括：
在网站加密货币钱包处从加密货币钱包接收所述支付，其中授权的支付数据用于填充所述加密货币钱包以启动所述支付。
13.根据权利要求12所述的方法，其中所述授权的支付数据包括识别所述网站加密货币钱包和金额的数据中的至少一种。
14.根据权利要求13所述的方法，其中所述加密货币钱包存储在操作浏览器的设备和与该设备分离的基于Web的设备之一上。
15.一种处理支付的方法，该方法包括：
在加密货币钱包处接收与购买相关的授权的支付信息，其中
从网站在浏览器处并通过浏览器支付请求应用程序编程接口接收与潜在购买相关的请求，基于浏览器生成所述授权的支付信息，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中所述请求包括由所述网站接受的加密货币支付方法的标识；
使用来自所述加密货币钱包的加密货币并基于所述授权的支付信息来处理所述支付；和
向所述浏览器传输与使用所述加密货币的支付处理相关的确认数据。
16.一种接收支付的方法，该方法包括：
从网站到浏览器并通过浏览器支付请求应用程序编程接口传输与购买支付相关的请求，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中所述请求包括由所述网站接受的支付方法的标识，其中所述支付方法使用加密货币；和
在所述网站处根据所述支付方法接收支付，其中所述支付方法根据通过所述浏览器支付请求应用程序编程接口传输的请求启动的加密货币支付方法来使用所述加密货币。
17.根据权利要求15所述的方法，其中所述加密货币支付方法包括将第一货币转换为第二货币。
18.根据权利要求15所述的方法，其中所述加密货币支付方法使买方能够使用第一货币从卖方购买商品，并以第二货币向所述卖方支付，并且其中加密货币用于桥接所述第一货币和所述第二货币之间的转换。
19.一种操作支付服务的方法，该方法包括：
在所述支付服务处接收与购买相关的授权的支付信息，其中从网站并通过浏览器支付请求应用程序编程接口接收与购买支付相关的请求，在浏览器上生成授权的支付信息，该接口定义用于在所述网站和所述浏览器之间通信数据的协议，其中所述请求包括至少部分使用加密货币的支付方法的标识；
使用所述加密货币并基于所述授权的支付信息来处理支付；和
向所述浏览器传输与使用所述加密货币的支付处理相关的确认数据。
20.根据权利要求18所述的方法，其中处理支付还包括将从买方接收的第一货币转换为所述加密货币。
21.根据权利要求19所述的方法，其中处理支付还包括将从买方接收的第一货币转换为所述加密货币，并将所述加密货币转换为第二货币以支付卖方。
22.方法，包括：
基于来自用户的表明购买意愿的输入，从网站在浏览器处通过第一应用程序编程接口接收与所述购买相关的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议；
从所述用户并通过所述第一应用程序编程接口接收由所述网站支持的支付方法的选择，其中所述支付方法至少部分使用加密货币，并且其中支付交易至少部分由支付服务管理；和
响应于所述支付请求和所述支付方法的选择，从所述浏览器并通过第二应用程序编程接口将支付请求事件通信到所述支付服务，该接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议，所述支付请求事件包括由所述支付服务使用以至少部分地使用所述加密货币来处理支付的数据。
23.根据权利要求21所述的方法，其中所述支付请求包括有关所述购买的信息以及由所述网站支持的一系列支付方法的选择。
24.根据权利要求21所述的方法，其中由所述支付服务管理的支付方法以所述加密货币进行所述支付。
25.根据权利要求21所述的方法，其中由所述支付服务管理的支付方法通过执行以下至少一项来进行支付：(1)从第一货币转换为所述加密货币；以及(2)从所述加密货币转换为第二货币。
26.根据权利要求21所述的方法，其中由所述支付服务管理的支付方法通过下列方式来进行支付：将由买方提供的第一货币转换为所述加密货币，并从所述加密货币转换为由卖方接受的第二货币。
27.根据权利要求25所述的方法，其中所述第一货币包括第一法定货币和第一加密货币中的一种，并且其中所述第二货币包括第二法定货币和第二加密货币中的一种。
28.方法，包括：
在支付服务处接收支付请求事件，其中在支付服务处接收支付请求事件基于下列：
通过第一应用程序编程接口浏览器接收来自网站的用于与商品购买相关的支付数据的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议，其中所述支付请求基于来自用户的表明购买商品意愿的输入，并且包括有关所述购买的信息；和
从所述用户并通过所述第一应用程序编程接口接收所述支付服务的选择，其中所述支付请求事件从所述浏览器并通过第二应用程序编程接口接收，所述第二应用程序编程接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议；和
在所述支付服务处处理所述支付请求事件以启动包括至少部分使用加密货币的支付方法。
29.根据权利要求27所述的方法，还包括：
向所述浏览器从所述支付服务并通过所述第二应用程序编程接口传输授权的支付信息，其中所述浏览器通过所述第一应用程序编程接口向所述网站通信所述授权的支付信息。
30.根据权利要求27所述的方法，其中所述支付请求包括有关所述购买的信息以及由所述网站支持的一系列支付方法的选择。
31.根据权利要求27所述的方法，其中由所述支付服务管理的支付方法以所述加密货币进行所述支付。
32.根据权利要求27所述的方法，其中由所述支付服务管理的支付方法通过执行以下至少一项来进行支付：(1)从第一货币转换为所述加密货币；以及(2)从所述加密货币转换为第二货币。
33.根据权利要求27所述的方法，其中由所述支付服务管理的支付方法通过下列方式来进行支付：将由买方提供的第一货币转换为所述加密货币，并从所述加密货币转换为由卖方接受的第二货币。
34.根据权利要求32所述的方法，其中所述第一货币包括第一法定货币和第一加密货币中的一种，并且其中所述第二货币包括第二法定货币和第二加密货币中的一种。
35.方法，包括：
基于来自用户的表明购买意愿的输入，从网站在浏览器处并通过第一应用程序编程接口传输与购买相关的支付请求，该接口定义用于在所述浏览器和所述网站之间通信数据的第一协议；
通过所述第一应用程序编程接口传输由所述网站支持的支付方法的选择，其中所述支付方法至少部分使用加密货币，并且其中支付交易至少部分由支付服务管理，其中响应于所述支付请求和所述支付方法的选择，第二应用程序编程接口将支付请求事件通信到所述支付服务，所述第二应用程序编程接口定义用于在所述浏览器和所述支付服务之间通信数据的第二协议，所述支付请求事件包括由所述支付服务使用以通过至少部分地使用所述加密货币的支付方法来处理支付的数据；和
通过所述支付方法接收所述支付。
Applications Claiming Priority (21)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/586,999 | 2017-05-04 | ||
| US15/586,999 US10121186B2 (en) | 2014-03-31 | 2017-05-04 | System and method of using a browser application programming interface for making payments |
| US15/600,388 | 2017-05-19 | ||
| US15/600,599 | 2017-05-19 | ||
| US15/600,599 US9922380B2 (en) | 2014-03-31 | 2017-05-19 | System and method for providing messenger application for product purchases |
| US15/600,388 US10504193B2 (en) | 2014-03-31 | 2017-05-19 | System and method for providing a universal shopping cart |
| US15/602,868 | 2017-05-23 | ||
| US15/602,868 US9922381B2 (en) | 2014-03-31 | 2017-05-23 | System and method for providing a payment handler API and a browser payment request API for processing a payment |
| US15/678,664 US20180019984A1 (en) | 2014-03-31 | 2017-08-16 | System and method for providing a credential management api |
| US15/678,664 | 2017-08-16 | ||
| US15/678,378 US10621653B2 (en) | 2014-03-31 | 2017-08-16 | System and method for providing payments for users in connection with a device software module having a payment application programming interface |
| US15/678,378 | 2017-08-16 | ||
| US201762560261P | 2017-09-19 | 2017-09-19 | |
| US62/560,261 | 2017-09-19 | ||
| US15/720,878 US10497037B2 (en) | 2014-03-31 | 2017-09-29 | System and method for managing cryptocurrency payments via the payment request API |
| US15/720,878 | 2017-09-29 | ||
| US201762569841P | 2017-10-09 | 2017-10-09 | |
| US62/569,841 | 2017-10-09 | ||
| US15/947,395 US10152756B2 (en) | 2014-03-31 | 2018-04-06 | System and method for providing multiple payment method options to browser |
| US15/947,395 | 2018-04-06 | ||
| PCT/US2018/031148 WO2018204822A1 (en) | 2017-05-04 | 2018-05-04 | Providing cryptocurrency payments through a browser application programming interface |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111279336A true CN111279336A (zh) | 2020-06-12 |
Family
ID=64016755
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201880044997.7A Pending CN111279336A (zh) | 2017-05-04 | 2018-05-04 | 通过浏览器应用程序编程接口提供加密货币支付 |
Country Status (9)
| Country | Link |
|---|---|
| EP (1) | EP3619627A4 (zh) |
| JP (2) | JP2020523716A (zh) |
| KR (1) | KR20200015517A (zh) |
| CN (1) | CN111279336A (zh) |
| AU (1) | AU2018261800A1 (zh) |
| BR (1) | BR112019023080A2 (zh) |
| CA (1) | CA3056933A1 (zh) |
| SG (1) | SG11201908661UA (zh) |
| WO (1) | WO2018204822A1 (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111857458A (zh) * | 2020-06-23 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 货运订单的生成方法、装置、电子设备及存储介质 |
| CN112131504A (zh) * | 2020-08-28 | 2020-12-25 | 长沙市到家悠享网络科技有限公司 | 一种网页编辑、展示方法、装置、设备以及存储介质 |
| CN113065134A (zh) * | 2020-12-28 | 2021-07-02 | 上海能链众合科技有限公司 | 一种区块链代码和数据安全计算方法 |
| CN113239300A (zh) * | 2021-04-21 | 2021-08-10 | 北京字跳网络技术有限公司 | 数据处理方法、装置和电子设备 |
| US20220272408A1 (en) * | 2020-08-14 | 2022-08-25 | Global Sports & Entertainment Marketing, LLC | Interactive video overlay with persistent cart |
| US20230230067A1 (en) * | 2022-01-20 | 2023-07-20 | VocaLink Limited | Tokenized control of personal data |
| US12034999B2 (en) | 2022-11-04 | 2024-07-09 | Global Sports & Entertainment Marketing, LLC | Interactive video overlay |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10419225B2 (en) | 2017-01-30 | 2019-09-17 | Factom, Inc. | Validating documents via blockchain |
| US10817873B2 (en) | 2017-03-22 | 2020-10-27 | Factom, Inc. | Auditing of electronic documents |
| US11170366B2 (en) | 2018-05-18 | 2021-11-09 | Inveniam Capital Partners, Inc. | Private blockchain services |
| US10783164B2 (en) | 2018-05-18 | 2020-09-22 | Factom, Inc. | Import and export in blockchain environments |
| US11134120B2 (en) | 2018-05-18 | 2021-09-28 | Inveniam Capital Partners, Inc. | Load balancing in blockchain environments |
| US11295296B2 (en) * | 2018-08-06 | 2022-04-05 | Inveniam Capital Partners, Inc. | Digital contracts in blockchain environments |
| US11989208B2 (en) | 2018-08-06 | 2024-05-21 | Inveniam Capital Partners, Inc. | Transactional sharding of blockchain transactions |
| JP6773756B2 (ja) * | 2018-12-17 | 2020-10-21 | 株式会社ランドスケイプ | 顧客情報入力支援装置、方法、およびコンピュータプログラム |
| CN109976515B (zh) * | 2019-03-11 | 2023-07-07 | 阿波罗智联(北京)科技有限公司 | 一种信息处理方法、装置、车辆及计算机可读存储介质 |
| WO2020183409A1 (en) * | 2019-03-12 | 2020-09-17 | Innoviti Payment Solutions Private Limited | A method and payment terminal for improving data communication reliability during transaction processing |
| JP6647674B1 (ja) | 2019-03-30 | 2020-02-14 | 株式会社オーガスタス | マルチ電子決済システム |
| CN110378691A (zh) * | 2019-06-18 | 2019-10-25 | 重庆金融资产交易所有限责任公司 | 基于部署中心的区块链部署方法、装置和计算机设备 |
| US11238444B2 (en) * | 2019-11-26 | 2022-02-01 | Flexa Network Inc. | Secure and trusted cryptocurrency acceptance system |
| US11444749B2 (en) | 2020-01-17 | 2022-09-13 | Inveniam Capital Partners, Inc. | Separating hashing from proof-of-work in blockchain environments |
| US11847624B2 (en) | 2020-05-11 | 2023-12-19 | Capital One Services, Llc | User registration based on unsupervised learning classification |
| US20210398211A1 (en) * | 2020-06-17 | 2021-12-23 | Coinbase, Inc. | Systems and methods for converting cryptocurrency |
| US11074142B1 (en) * | 2021-01-15 | 2021-07-27 | Coupang Corp. | Systems and methods for automatically resolving system failure through force supplying cached API data |
| US12008526B2 (en) | 2021-03-26 | 2024-06-11 | Inveniam Capital Partners, Inc. | Computer system and method for programmatic collateralization services |
| KR102382316B1 (ko) * | 2021-04-14 | 2022-04-04 | 주식회사 브링코 | 쇼핑몰에서 api에 의하여 구현된 제휴서비스카트를 이용하여 전자상거래서비스를 제공하는 방법 및 시스템 |
| US12007972B2 (en) | 2021-06-19 | 2024-06-11 | Inveniam Capital Partners, Inc. | Systems and methods for processing blockchain transactions |
| US20230162187A1 (en) * | 2021-11-19 | 2023-05-25 | Capital One Services, Llc | Autofilling data based on account authentication using a contactless card |
| CN114650436B (zh) * | 2022-03-15 | 2023-11-28 | 平安国际智慧城市科技股份有限公司 | 基于后台服务的遥控方法、装置、设备及介质 |
| CN117640109B (zh) * | 2024-01-26 | 2024-04-26 | 远江盛邦（北京）网络安全科技股份有限公司 | Api接口安全访问方法、装置、电子设备及存储介质 |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002312615A (ja) * | 2001-04-18 | 2002-10-25 | Toshiba Tec Corp | バーチャルモール装置 |
| US8244592B2 (en) * | 2008-03-27 | 2012-08-14 | Amazon Technologies, Inc. | System and method for message-based purchasing |
| US9317704B2 (en) * | 2013-06-12 | 2016-04-19 | Sequent Software, Inc. | System and method for initially establishing and periodically confirming trust in a software application |
| US10002396B2 (en) * | 2014-03-31 | 2018-06-19 | Monticello Enterprises LLC | System and method for transitioning from a first site to a second site |
| US10497037B2 (en) * | 2014-03-31 | 2019-12-03 | Monticello Enterprises LLC | System and method for managing cryptocurrency payments via the payment request API |
| US20180019984A1 (en) * | 2014-03-31 | 2018-01-18 | Monticello Enterprises LLC | System and method for providing a credential management api |
| US10496964B2 (en) * | 2014-04-02 | 2019-12-03 | Facebook, Inc. | Routing payments to payment aggregators |
| US9386078B2 (en) * | 2014-05-30 | 2016-07-05 | Ca, Inc. | Controlling application programming interface transactions based on content of earlier transactions |
| US20160071096A1 (en) * | 2014-09-08 | 2016-03-10 | Andrew Rosca | Method and System for Securing Cryptocurrency Wallet |
| CA3217643A1 (en) * | 2014-12-24 | 2016-06-30 | 10353744 Canada Ltd. | Settlement system and settlement method |
| US11301841B2 (en) * | 2015-05-13 | 2022-04-12 | Sony Corporation | Method and system for authenticating a virtual currency instrument |
| US9735958B2 (en) * | 2015-05-19 | 2017-08-15 | Coinbase, Inc. | Key ceremony of a security system forming part of a host computer for cryptographic transactions |
| WO2017070469A1 (en) * | 2015-10-22 | 2017-04-27 | Align Commerce Corporation | System and method for payment processing using crypto currencies |
-
2018
- 2018-05-04 SG SG11201908661U patent/SG11201908661UA/en unknown
- 2018-05-04 CN CN201880044997.7A patent/CN111279336A/zh active Pending
- 2018-05-04 WO PCT/US2018/031148 patent/WO2018204822A1/en unknown
- 2018-05-04 AU AU2018261800A patent/AU2018261800A1/en not_active Abandoned
- 2018-05-04 CA CA3056933A patent/CA3056933A1/en not_active Abandoned
- 2018-05-04 KR KR1020197035661A patent/KR20200015517A/ko not_active Application Discontinuation
- 2018-05-04 EP EP18794949.0A patent/EP3619627A4/en not_active Withdrawn
- 2018-05-04 BR BR112019023080A patent/BR112019023080A2/pt not_active Application Discontinuation
- 2018-05-04 JP JP2019572838A patent/JP2020523716A/ja active Pending
-
2021
- 2021-06-10 JP JP2021097185A patent/JP2021152931A/ja active Pending
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111857458A (zh) * | 2020-06-23 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 货运订单的生成方法、装置、电子设备及存储介质 |
| CN111857458B (zh) * | 2020-06-23 | 2023-03-31 | 北京芙睿特无限科技发展有限公司 | 货运订单的生成方法、装置、电子设备及存储介质 |
| US20220272408A1 (en) * | 2020-08-14 | 2022-08-25 | Global Sports & Entertainment Marketing, LLC | Interactive video overlay with persistent cart |
| US11496792B2 (en) * | 2020-08-14 | 2022-11-08 | Global Sports & Entertainment Marketing, LLC | Interactive video overlay with persistent cart |
| CN112131504A (zh) * | 2020-08-28 | 2020-12-25 | 长沙市到家悠享网络科技有限公司 | 一种网页编辑、展示方法、装置、设备以及存储介质 |
| CN112131504B (zh) * | 2020-08-28 | 2024-03-26 | 长沙市到家悠享网络科技有限公司 | 一种网页编辑、展示方法、装置、设备以及存储介质 |
| CN113065134A (zh) * | 2020-12-28 | 2021-07-02 | 上海能链众合科技有限公司 | 一种区块链代码和数据安全计算方法 |
| CN113065134B (zh) * | 2020-12-28 | 2024-03-12 | 上海零数众合信息科技有限公司 | 一种区块链代码和数据安全计算方法 |
| CN113239300A (zh) * | 2021-04-21 | 2021-08-10 | 北京字跳网络技术有限公司 | 数据处理方法、装置和电子设备 |
| US20230230067A1 (en) * | 2022-01-20 | 2023-07-20 | VocaLink Limited | Tokenized control of personal data |
| US12034999B2 (en) | 2022-11-04 | 2024-07-09 | Global Sports & Entertainment Marketing, LLC | Interactive video overlay |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3619627A4 (en) | 2020-08-26 |
| JP2020523716A (ja) | 2020-08-06 |
| BR112019023080A2 (pt) | 2020-06-09 |
| CA3056933A1 (en) | 2018-11-08 |
| EP3619627A1 (en) | 2020-03-11 |
| WO2018204822A1 (en) | 2018-11-08 |
| AU2018261800A1 (en) | 2019-12-05 |
| JP2021152931A (ja) | 2021-09-30 |
| KR20200015517A (ko) | 2020-02-12 |
| SG11201908661UA (en) | 2019-10-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11836784B2 (en) | System and method for providing a search entity-based payment process | |
| US11074640B2 (en) | System and method for providing a universal shopping cart across multiple search platforms | |
| US10152756B2 (en) | System and method for providing multiple payment method options to browser | |
| US10643266B2 (en) | System and method for in-app payments | |
| US10832310B2 (en) | System and method for providing a search entity-based payment process | |
| US10621653B2 (en) | System and method for providing payments for users in connection with a device software module having a payment application programming interface | |
| US10504193B2 (en) | System and method for providing a universal shopping cart | |
| US10121186B2 (en) | System and method of using a browser application programming interface for making payments | |
| CN111279336A (zh) | 通过浏览器应用程序编程接口提供加密货币支付 | |
| US9767520B2 (en) | System and method for managing a purchasing process associated with a social media site | |
| US11915303B2 (en) | System and method for providing a social media shopping experience | |
| US12008629B2 (en) | System and method for providing a social media shopping experience | |
| US20210174428A1 (en) | System and method for providing multple application programming interfaces for a browser to manage payments from a payment service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20200612 |
|
| WD01 | Invention patent application deemed withdrawn after publication |