Source: http://patents.com/us-9864990.html
Timestamp: 2019-10-14 08:26:40
Document Index: 327351567

Matched Legal Cases: ['Application No. 2001', 'Application No. 2001', 'Application No. 2001', 'Application No. 2001', 'Application No. 2', 'Application No. 60']

US Patent # 9,864,990. Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account - Patents.com
United States Patent 9,864,990
Hutchison , et al. January 9, 2018
A virtual payment system for paying for goods, services and content ordered over an internetwork is disclosed. The virtual payment system includes a commerce gateway. Buyers and sellers becomes registered participants by applying for virtual payment buyer and seller accounts. Once an account is established with the commerce gateway, a digital certificate is stored on the registered participant's computer. A buyer can then order a product, i.e., goods, services or content from a seller and charge it to the virtual payment account. When the product is shipped, the seller notifies the commerce gateway, which applies the charges to the buyer's virtual payment account. The buyer can settle the charges using a prepaid account, a credit account, or by using reward points earned through use of the virtual payment account. A buyer may create sub-accounts.
Hutchison; Robin B. (Vancouver, CA), Llewellyn; Robert J. (Poulsbo, WA), Viljoen; Andre F. (North Vancouver, CA), Griffiths; David (Ware, GB), Birch; David (Woking, GB), Begg; Iain M. (Vancouver, CA)
Hutchison; Robin B.
Llewellyn; Robert J.
Viljoen; Andre F.
Griffiths; David
Birch; David
Begg; Iain M.
CRIA INC. (Wilmington, DE)
Family ID: 1000003051982
13/028,024
US 20110137801 A1 Jun 9, 2011
11183127 Jul 14, 2005 7908226
10663443 Jul 24, 2007 7249097
10338133 Jan 6, 2003
09578395 May 25, 2000
09370949 Aug 9, 1999
60140039 Jun 18, 1999
Current CPC Class: G06Q 20/385 (20130101); G06Q 40/025 (20130101); G06Q 20/027 (20130101); G06Q 20/085 (20130101); G06Q 20/10 (20130101); G06Q 20/102 (20130101); G06Q 20/12 (20130101); G06Q 20/24 (20130101); G06Q 20/367 (20130101); G06Q 20/3674 (20130101); G06Q 20/3676 (20130101); G06Q 20/382 (20130101); G06Q 20/3821 (20130101); G06Q 20/3829 (20130101); G06Q 20/40 (20130101); G06Q 20/403 (20130101); G06Q 30/00 (20130101); G06Q 30/04 (20130101); G06Q 30/06 (20130101); G06Q 30/0601 (20130101); G06Q 30/0603 (20130101); G06Q 30/0613 (20130101); G06Q 30/0617 (20130101); G06Q 20/02 (20130101)
Current International Class: G06Q 20/38 (20120101); G06Q 20/10 (20120101); G06Q 20/12 (20120101); G06Q 20/24 (20120101); G06Q 20/36 (20120101); G06Q 20/40 (20120101); G06Q 30/00 (20120101); G06Q 30/04 (20120101); G06Q 20/08 (20120101); G06Q 20/02 (20120101); G06Q 30/06 (20120101); G06Q 40/02 (20120101)
Field of Search: ;705/78,79
5475819 December 1995 Miller
5610980 March 1997 Johnson
5715314 February 1998 Payne
5732400 March 1998 Mandler
5737414 April 1998 Walker
5790677 August 1998 Fox
5797127 August 1998 Walker
5798508 August 1998 Walker
5818933 October 1998 Kambe
5822737 October 1998 Ogram
5855008 December 1998 Goldhaber
5870473 February 1999 Boesch
5878403 March 1999 DeFrancesco
5883955 March 1999 Ronning
5899980 May 1999 Wilf
5903882 May 1999 Asay
5905736 May 1999 Ronen
5909492 June 1999 Payne
5930776 July 1999 Dykstra
5933625 August 1999 Sugiyama
5963625 October 1999 Kawecki
5996076 November 1999 Rowney
6003765 December 1999 Okamoto
6058250 May 2000 Harwood
6076078 June 2000 Camp
6088686 July 2000 Walker
6092147 July 2000 Levy
6119105 September 2000 Williams
6138107 October 2000 Elgamal
6158657 December 2000 Hall, III
6209091 March 2001 Sudia
6263447 July 2001 French
6282658 August 2001 French
6321339 November 2001 French
6341349 January 2002 Takaragi
6466917 October 2002 Goyal
6484182 November 2002 Dunphy
6629150 September 2003 Huded
6959382 October 2005 Kinnis
6961858 November 2005 Fransdonk
7020635 March 2006 Hamilton
7080049 July 2006 Truitt
7090128 August 2006 Farley
7150045 December 2006 Koelle
7356503 April 2008 Johnson
7587502 September 2009 Crawford
7606760 October 2009 Hutchison
7711586 May 2010 Aggarwal
7765151 July 2010 Williams
7908226 March 2011 Hutchison
8001039 August 2011 Crosthwaite
8078527 December 2011 Cerise
8127345 February 2012 Gregg
9690968 June 2017 Wadley
2001/0001877 May 2001 French
2001/0007098 July 2001 Hinrichs
2001/0018739 August 2001 Anderson
2001/0037310 November 2001 Saeki
2001/0039535 November 2001 Tsiounis
2002/0007343 January 2002 Oyama
2002/0023051 February 2002 Kunzle
2002/0035533 March 2002 Mache
2002/0046188 April 2002 Burges
2002/0059430 May 2002 Orbke
2002/0078344 June 2002 Sandhu
2002/0111919 August 2002 Weller
2002/0116341 August 2002 Hogan
2002/0144120 October 2002 Ramanathan
2002/0161719 October 2002 Manning
2003/0033259 February 2003 Walker
2003/0046223 March 2003 Crawford
2003/0171992 September 2003 Blagg
2004/0078394 April 2004 Powell
2004/0083184 April 2004 Tsuei
2004/0192306 September 2004 Elkarat
2004/0199456 October 2004 Flint
2005/0177518 August 2005 Brown
2006/0168663 July 2006 Viljoen
2006/0237528 October 2006 Bishop
2007/0052517 March 2007 Bishop
2007/0299684 December 2007 Goodwin
2009/0132819 May 2009 Lu
2010/0042542 February 2010 Rose
2010/0223186 September 2010 Hogan
2010/0228668 September 2010 Hogan
2011/0087526 April 2011 Morgenstern
2014/0258109 September 2014 Jiang
2015/0006392 January 2015 Brand
2015/0242825 August 2015 Mills
2016/0267477 September 2016 McDonald
2017/0103459 April 2017 Kim
2017/0132630 May 2017 Castinado
2167543 Jul 1997 CA
2217825 Apr 1998 CA
0765068 Mar 1997 EP
0 779 587 Jun 1997 EP
0818907 Jan 1998 EP
0883076 Dec 1998 EP
0902381 Mar 1999 EP
0 921 487 Jun 1999 EP
9-218903 Sep 1997 JP
9-297789 Nov 1997 JP
9-326002 Dec 1997 JP
10-509543 Sep 1998 JP
10-327145 Dec 1998 JP
11-3387 Jan 1999 JP
11-53444 Feb 1999 JP
11-503541 Mar 1999 JP
11-239128 Aug 1999 JP
11-353280 Dec 1999 JP
1020000012391 Mar 2000 KR
95/16971 Jun 1995 WO
96/21192 Jul 1996 WO
96/31965 Oct 1996 WO
96/37848 Nov 1996 WO
97/01920 Jan 1997 WO
97/22074 Jun 1997 WO
97/29584 Aug 1997 WO
97/49054 Dec 1997 WO
98/09260 Mar 1998 WO
98/40809 Sep 1998 WO
98/57460 Dec 1998 WO
99/21321 Apr 1999 WO
99/57835 Nov 1999 WO
Notification of Reason(s) for Rejection dated Apr. 19, 2011, in corresponding Japanese Application No. 2001-587188, filed May 25, 2001, and English Translation by Japanese foreign associate, 6 pages. cited by applicant .
http://www.echarge.att.com/how.sub.--wk..html, "AT&T eCharge: How Does It Work?" available at least as early as Oct. 29, 1997. cited by applicant .
http://www.echarge.att.com/cgi-bin/Register.cgi, "AT&T eCharge: Apply for an Account," available at least as early at Oct. 29, 1997. cited by applicant .
http://www.echarge.att.com/cgi-bin/Activate.cgi, "AT&T eCharge: Activate Your Account," available at least as early at Oct. 29, 1997. cited by applicant .
http://www.echarge.att.com/cgi-bin/Transactions.cgi, "AT&T eCharge: Account Activity," available at least as early as Oct. 29, 1997. cited by applicant .
http://www.echarge.att.com/indesx.html, "AT&T eCharge: Welcome to AT&T eCharge," available at least as early as Oct. 29, 1997. cited by applicant .
http://www.echarge.att.com/faq.html, "AT&T eCharge: Frequently Asked Questions/Customer Support," available at least as early as Oct. 29, 1997. cited by applicant .
http://www.echarge.att.com/, "AT&T eCharge: Simple," available at least as early as Oct. 29, 1997. cited by applicant .
http://www.echarge.att.com/terms.sub.--conditions.html, "AT&T eCharge: Frequently Asked Questions/Customer Support," available at least as early as Oct. 29, 1997. cited by applicant .
"Briefly Noted," Internet Business News, .COPYRGT. 1994-8 M2 Communications Ltd., Coventry, United Kingdom, Jan. 1, 1998, p. 1. cited by applicant .
Information Intelligence, Inc., "User Authentication and Authorization Challenges in a Networked Library Environment," Online Libraries & Microcomputers 15(10), Oct. 1, 1997. cited by applicant .
Lang, P., "Product Review: eCharge Billing System" .COPYRGT. 1997-2009 Optimum Interactive LLC, Apr. 1998, <http://sellitontheweb.com/ezine/echarge.shtml> [retrieved Dec. 10, 2008], 3 pages. cited by applicant .
Lau, H., "Open House: E-business and you: Buying on the Net . . . Safely," Businessworld (Philippines), Nov. 3, 1998. cited by applicant .
Marion, L., "Who's Guarding the Till at the Cybermall?" Datamation 41(3):38-39, Feb. 15, 1995. cited by applicant .
Notification of Reason(s) for Refusal dated Dec. 8, 2009, in related Japanese Application No. 2001-504945, filed Jun. 16, 2000. cited by applicant .
PR Newsire Association, Inc., "Verisign Offers Unique Seal to Show Internet Users `Proof of Authentication`," PR Newswire, Dec. 10, 1996. cited by applicant .
Summons to Attend Oral Proceedings mailed Aug. 19, 2009, in related Application No. EP 00942881.4, filed Jun. 16, 2000. cited by applicant .
"Victims Seeking Cheap Online Erotica Aroused by Not-So-Cheap Phone Bills," San Jose Mercury News, Feb. 20, 1997, p. 1C. cited by applicant .
Yamasaki, S., and K. Araki, "A Certificate Infrastructure Model for Integrated Cross-Authentification With Warranty and Use Policy Control," Trans. Information Processing Society of Japan 40(1):296-309, Jan. 1999 (English. Abstract). cited by applicant .
Decision of Rejection dated Dec. 6, 2011, issued in Japanese Patent Application No. 2001-587188, filed May 25, 2001, 8 pages. cited by applicant .
Ajluni, C., "Security Techniques Ensure Privacy," Electronic Design, Apr. 1995, pp. 83-84 (abstract). cited by applicant .
"Encryption Devices," Government Executive, Jul. 1996, p. 2A. cited by applicant .
European Examination Report dated Nov. 28, 2008, issued in related Application No. EP 01944177.3, filed May 25, 2001. cited by applicant .
"Internet 900 Billing Fills Void," Audiotex News, Dec. 1997, p. 5 (abstract). cited by applicant .
"Internet Service Considers 900," Audiotex News, Jan. 1997, p. 8 (abstract). cited by applicant .
Minkoff, J., "Ensuring Online Security," Discount Merchandiser, Jan. 1996, p. 49. cited by applicant .
Notification of Reason(s) for Refusal dated Apr. 11, 2011, in corresponding Japanese Application No. 2001-504945, filed Jun. 16, 2000, and English Translation by Japanese foreign associate, 5 pages. cited by applicant .
Pappalardo, D., "Tools Lets ISPs Charge for Fax, Voice," Network World, Apr. 1997, p. 116. cited by applicant .
Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C," 2nd Edition, John Wiley & Sons, Inc., New York, 1996 (rather than sending the entire text, applicants refer Examiner to the remarks regarding this reference that are contained in the European Examination Report identified in No. 3 above). cited by applicant .
Sirbu, M.A., "Creating an Open Market for Information," Journal of Academic Librarianship, Nov. 1995, p. 467 (abstract). cited by applicant .
Itoh, M., et al., "Outline of SET Protocol," NEC Journal 51(9):90-99, 1998 (with partial English translation provided by foreign associate). cited by applicant .
English translation provided by foreign associate of excerpts of Examiner's Opinion mailed Jun. 5, 2012, issued in Brazilian Patent Application No. PI 0011768-4, filed Jun. 16, 2000, 3 pages. cited by applicant .
Office Action (CA) dated Jan. 13, 2014, issued in related Canadian Application No. 2,377,706, filed Jun. 16, 2000, 5 pages. cited by applicant.
Primary Examiner: Obeid; Mamon
This application is a division of U.S. patent application Ser. No. 11/183,127, filed Jul. 14, 2005, which is a division of U.S. patent application Ser. No. 10/663,443, filed Sep. 16, 2003 (now U.S. Pat. No. 7,249,097), which is a continuation of U.S. patent application Ser. No. 10/338,133, filed Jan. 6, 2003, which is a continuation of U.S. patent application Ser. No. 09/578,395, filed May 25, 2000, which is a continuation-in-part of U.S. patent application Ser. No. 09/370,949, filed Aug. 9, 1999, priority from the filing date of which is hereby claimed under 35 U.S.C. .sctn.120. U.S. patent application Ser. No. 09/370,949 also claims the benefit of provisional U.S. Patent Application No. 60/140,039, filed Jun. 18, 1999, the benefit of which is hereby claimed under 35 U.S.C. .sctn.119. All of said applications are expressly incorporated herein by reference.
1. In a system for purchasing products, the system including at least one buyer computing device for ordering products from seller computers using a virtual payment account and at least one seller computer for selling products to buyers in response to the receipt of orders from buyer computing devices to purchase products that identify a virtual payment account as the payment source for ordered products, the improvement comprising: a commerce gateway, the commerce gateway: (i) maintaining virtual payment accounts; (ii) interfacing with credit processing servers; and (iii) authorizing and settling product purchases using said virtual payment accounts maintained by the commerce gateway, the virtual payment accounts including a virtual payment account associated with the at least one buyer computing device, the commerce gateway operative to: in response to receiving an account request from the at least one buyer computing device that includes an identification of a digital certificate installed on the at least one buyer computing device, wherein the digital certificate is generated by an authenticator component downloaded to the at least one buyer computing device upon approval of the virtual payment account and comprises a public key encryption pair, determine whether a virtual payment account maintained by said commerce gateway is associated with said digital certificate installed on the at least one buyer computing device; in response to determining that the digital certificate installed on the at least one buyer computing device is associated with a virtual payment account maintained by said commerce gateway, transmit a response to said at least one buyer computing device that identifies said virtual payment account; in response to receiving an authorization request from the at least one seller computer requesting verification that a purchase confirmation received by the at least one seller computer from the at least one buyer computing device is valid, determine whether the virtual payment account maintained by said commerce gateway can be used to pay for a product identified in the purchase confirmation; in response to determining that the virtual payment account may be used to pay for the product identified in the purchase confirmation, transmit a transaction authorization to the at least one seller computer; and charge the virtual payment account maintained by the commerce gateway for a cost associated with the purchase of the at least one product identified in the purchase confirmation.
2. The improvement claimed in claim 1 wherein the commerce gateway also determines if the virtual payment account associated with the digital certificate installed on the buyer computing device is valid.
3. The improvement claimed in claim 1 wherein the commerce gateway only transmits the response to the at least one buyer computing device if the commerce gateway determines that the digital certificate installed on, the buyer computing device is both associated with the virtual payment account maintained by the commerce gateway and the virtual payment account is valid.
4. The improvement claimed in claim 1 wherein: (i) the account request identifies more than one digital certificate installed on the at least one buyer computing device (ii) the commerce gateway determines whether virtual payment accounts maintained by said commerce gateway are associated with each of said more than one certificate included in said account request, and (iii) the response includes a list of virtual payment accounts maintained by the commerce gateway and associated with said more than one certificate included in said request.
5. The improvement claimed in claim 4 wherein the commerce gateway also determines if the virtual payment accounts included in the list of virtual payment accounts are valid.
6. The improvement claimed in claim 4 wherein the commerce gateway only transmits the response to the at least one buyer computing device if the commerce gateway determines that the digital certificates installed on the buyer computing device are both associated with virtual payment accounts maintained by the commerce gateway and the virtual payment accounts are valid.
7. The improvement claimed in claim 1 wherein, in response to the receipt of a settlement transaction request from the at least one seller computer, the commerce gateway transmits a settlement transaction to the at least one seller computer.
8. The improvement claimed in claim 7 wherein the commerce gateway also determines if the virtual payment account associated with the digital certificate installed on the buyer computing device is valid.
9. The improvement claimed in claim 7 wherein the commerce gateway only transmits the response to the at least one buyer computing device if the commerce gateway determines that the digital certificate installed on, the buyer computing device is both associated with the virtual payment account maintained by the commerce gateway and the virtual payment account is valid.
10. The improvement claimed in claim 7 wherein, prior to the commerce gateway transmitting a settlement transaction to the at least one seller computer, after receiving a settlement transaction request from the at least one seller computer, the commerce gateway determines if the transaction is permissible.
11. The improvement claimed in claim 10 wherein the commerce gateway also determines if the virtual payment account associated with the digital certificate installed on the buyer computing device is valid.
12. The improvement claimed in claim 10 wherein the commerce gateway only transmits the response to the at least one buyer computing device if the commerce gateway determines that the digital certificate installed on, the buyer computing device is both associated with the virtual payment account maintained by the commerce gateway and the virtual payment account is valid.
13. The improvement claimed in claim 10 wherein the system also includes a credit processing server and wherein: (i) If the transaction is permissible, prior to the commerce gateway transmitting a settlement transaction to the at least one seller computer, the commerce gateway sends a transaction request to the credit processing server; and (ii) the commerce gateway only sends the settlement transaction to the at last one seller computer if the commerce gateway receives an authorization from the credit processing server in response to the transaction request sent by the commerce gateway to the credit processing server.
14. The improvement claimed in claim 13 wherein the commerce gateway also determines if the virtual payment account associated with the digital certificate installed on the buyer computing device is valid.
15. The improvement claimed in claim 13 wherein the commerce gateway only transmits the response to the at least one buyer computing device if the commerce gateway determines that the digital certificate installed on the buyer computing device is both associated with the virtual payment account maintained by the commerce gateway and the virtual payment account is valid.
16. The improvement claimed in claim 7 wherein the system also includes a credit processing server, and wherein: (i) prior to the commerce gateway transmitting a settlement transaction to the at least one seller computer, the commerce gateway sends a transaction request to the credit processing server; and (ii) the commerce gateway only sends the settlement transaction to the at least one seller computer if the commerce gateway receives an authorization from the credit processing server in response to the transaction request sent by the commerce gateway to the credit processing server.
17. The improvement claimed in claim 16 wherein the commerce gateway also determines if the virtual payment account associated with the digital certificate installed on the buyer computing devices is valid.
18. The improvement claimed in claim 16 wherein the commerce gateway only transmits the response to the at least one buyer computing device if the commerce gateway determines that the digital certificate installed on, the buyer computing device is both associated with the virtual payment account maintained by the commerce gateway and the virtual payment account is valid.
Communication networks are well known in the computer communications field. By definition, a network is a group of computers and associated devices that are connected by communications facilities or links. Network communications can be of a permanent nature, such as via cables, or can be of a temporary nature, such as connections made through telephone or radio links. Networks may vary in size, from a local area network (LAN) consisting of a few computers or workstations and related devices; to a wide area network (WAN), which interconnects computers and LANs that are geographically dispersed; to a remote access service (RAS), which interconnects remote computers via temporary communication links. An internetwork, in turn, is the joining of multiple computer networks, both similar and dissimilar, by means of gateways or routers that facilitate data transfer and conversion from various networks. A well-known abbreviation for the term internetwork is "Internet." As currently understood, the capitalized term "Internet" refers to the collection of networks and routers that use the Transmission Control Protocol/Internet Protocol (TCP/IP) to communicate with one another.
The Internet has recently seen explosive growth by virtue of its ability to link computers located throughout the world. As the Internet has grown, so has the World Wide Web (WWW). The WWW is a vast collection of interconnected or "hypertext" documents (also known as "Web pages") written in HyperText Markup Language (HTML) that are electronically stored at "Web sites" throughout the Internet. A Web site is a server connected to the Internet that has mass storage facilities for storing hypertext documents and that runs administrative software for handling requests for those stored hypertext documents. A hypertext document normally includes a number of hyperlinks, i.e., highlighted portions of text that link the document to another hypertext document possibly stored at a Web site elsewhere on the Internet. Each hyperlink is associated with a Uniform Resource Locator (URL) that provides the exact location of the linked document on a server connected to the Internet. Thus, whenever a hypertext document is retrieved from any Web server, the document is considered to be retrieved from the WWW.
A user is allowed to retrieve hypertext documents from the WWW, i.e., a user is allowed to "surf the Web," via a Web browser. A Web browser, such as NETSCAPE NAVIGATOR.RTM. or MICROSOFT.RTM. Internet Explorer, is a software program implemented by a Web client, i.e., a user's computer, to provide a graphical user interface to the WWW. Upon request from the user via the Web browser, the Web client accesses and retrieves the desired hypertext document or Web page from the appropriate Web server using the URL for the document and a protocol known as HyperText Transfer Protocol (HTTP). HTTP is a higher-level protocol than TCP/IP and is designed specifically for the requirements of the WWW. It is used on top of TCP/IP to transfer hypertext documents between servers and clients.
At the advent of the WWW, the information stored on the Internet was freely transferred back and forth between those parties interested in the information. However, the WWW is quickly becoming a channel of commercial activity, whereby a vast number of companies have developed their own Web sites for advertising and selling their goods and services. Commercial activity that takes place by means of connected computers is known as electronic commerce, or e-commerce, and can occur between a buyer and a seller through an on-line information service, the Internet, a bulletin board system (BBS), or between buyer and seller computers through electronic data interchange (EDI). A buyer (also referred to as a user, consumer or purchaser in the context of e-commerce) may "visit the Web site" of a company or seller, i.e., retrieve the hypertext documents located on the Web server of a particular seller, and order any good or service that the seller has to offer. If that good or service is in the form of electronically stored information, such as a book, a video, a computer game, etc., the buyer may simply download the good or service from the company's Web site to his or her computer for immediate consumption and use. If the good or service is of a more tangible nature, such as an appliance or article of clothing ordered from an on-line catalog, a more conventional method of delivery, e.g., the postal service or a common carrier, is used.
FIGS. 21 and 22 are flow diagrams illustrating the logic used by various sub-systems of the credit processing server shown in FIG. 6 to provide for payment of goods, services and/or content ordered over the Internet using a virtual payment account;
As previously described and shown in FIG. 1, the Internet 40 is a collection of local area networks (LANs) 44, wide area networks (WANs) 46, remote computers 48 and routers 42 that use the Transmission Control Protocol/Internet Protocol (TCP/IP) to communicate with each other. The World Wide Web (WWW), on the other hand, is a vast collection of interconnected, electronically stored information located on servers connected throughout the Internet 40. Many companies are now selling goods, services and access to their premium content over the Internet using the WWW. In accordance with the present invention, a buyer orders goods, services and/or content (referred to interchangeably herein as "products") over the Internet 40 via a Web browser and is automatically billed for the purchase using his or her virtual payment account without transferring sensitive account information, such as account number and expiration date, over the Internet 40. The virtual payment account allows a buyer to settle transactions of the virtual payment account using a prepaid or credit account. In one actual embodiment of the present invention, the virtual payment account uses bank electronic funds transfers, for example, using the Automated Clearing House (ACH) standard, which is maintained by the National Automated Clearing House Association (NACHA)--the standards group promoting electronic commerce standards. In another embodiment, the virtual payment account can be funded using a traditional paper check, with the buyer mailing a check, e.g., via the postal service, to the providers of the virtual payment account system. Alternatively, funds transfer services and electronic bill payment services, such as CHECKFREE.RTM., may be used. Reward points earned through use of the virtual payment account can also be applied to the buyer's virtual payment account to pay for products.
More specifically, as shown in FIG. 2, the buyer purchases goods, services, and/or premium content from a seller server 51, i.e., a computer owned by the seller that sponsors or sells the product, by placing an order with the seller server from a computer 50 connected to the Internet 40. The order is processed and confirmed by a commerce gateway 52 connected to a LAN 44 located elsewhere in the Internet 40. The commerce gateway 52 is also connected to a credit processing server 53 via the LAN 44. The credit processing server 53 communicates with one or more identity bureaus 56 to verify the identity of the buyer. After verifying the identity of the buyer the credit processing server 53 communicates with one or more credit bureaus 58 in order to determine the credit worthiness of a buyer.
Finally, those of ordinary skill in the art will recognize that while only one buyer computer 50, and one seller server 51 are depicted in FIG. 2, numerous buyer computers and seller servers equipped with the hardware and software components described below may be connected to the Internet 40. It will also be appreciated that the term "buyer" used herein can be applied to any purchaser of goods and/or services and can be applied equally to an individual, non-commercial purchaser, a business or a commercial purchaser. In other words, the term "buyer" can apply to any purchaser and the term "seller" can apply to any vendor or merchant, be they on individual, non-commercial seller, a business or a commercial seller.
The buyer's computer 50 also includes a processing unit 61, a display 62 and a memory 63. The memory 63 generally comprises a random access memory (RAM), a read-only memory (ROM) and a permanent mass storage device, such as a disk drive. The memory 63 stores the program code and data necessary for ordering and paying for a product over the Internet 40 in accordance with the present invention. More specifically, the memory 63 stores a Web browser component 64, such as NETSCAPE NAVIGATOR.RTM. or MICROSOFT.RTM. Internet Explorer, and a buyer authenticator component 65 formed in accordance with the present invention for authenticating a buyer as a registered participant of the virtual payment system prior to performing any virtual payment account transactions. It will be appreciated that these components may be stored on a computer-readable medium and loaded into memory 63 of the buyer computer 50 using a drive mechanism associated with the computer-readable medium, such as a floppy or DVD/CD-ROM drive.
The memory 73 also contains a commerce engine component 75 for purchasing a product from a seller Web site. The commerce engine component 75 may be an existing commerce engine, such as MICROSOFT.RTM. Site Server, which allows for the payment of products ordered over the Internet using a major credit card, e.g., VISA.RTM. or MASTERCARD.RTM.. A commerce gateway adapter component 76 is also provided to allow the commerce engine component 75 to interface with the commerce gateway 52. The commerce gateway adapter component uses and provides application programming interface (API) calls to interface with the commerce engine 75. Also included in memory is a seller authenticator component 77 for verifying that the seller is an authorized or registered seller of the virtual payment system of the present invention. It will be appreciated that the product database 74, the commerce engine component 75, the commerce gateway adapter component 76 and the seller authenticator component 77 may be stored on a computer-readable medium and loaded into memory 73 of the seller server 51 using a drive mechanism associated with the computer-readable medium, such as a floppy or CD-ROM drive. Finally, memory 73 stores a Web server component 78 for handling requests for stored information received via the Internet and the WWW.
FIGS. 8A-8G are exemplary Web pages provided to the buyer by the Web browser 64 of the buyer computer 50 in connection with applying for a virtual payment account as described above. Using the Web page 600 shown in FIG. 8A, the buyer selects the type of virtual payment account they desire to apply for, e.g., credit or prepaid, and submits the information by clicking "continue." Next, the Web pages 605, 610 and 615 shown in FIGS. 8B-8D for the application form are displayed to the buyer via the Web browser 64. In one actual embodiment of the present invention, the buyer fills out the application form with the appropriate application data on-line. Alternatively, the buyer can request the application on a printed form and submit the printed form via facsimile or regular mail, in which case a customer service representative will enter the information into the account database 97 of the credit processing server 53 via the administrative user computer 54. The application data includes information such as social security number and income that will be used to determine a credit limit for the buyer. Information entered by the buyer in the application form is also used for demographic purposes. For example, banner advertisements can be displayed via the Web browser 64 on the buyer computer 50 and can be targeted to the buyer based on demographic information, such as the buyer's age and geographic location.
It will be appreciated, as described earlier, that a seller can apply for a "buyer" account. In other words, a seller can purchase products as the owner of a virtual payment account.
It will be appreciated that several levels of security can be imposed on on-line transactions. Moving from the lowest level to the highest level, there can be: (1) no security restrictions imposed; (2) minimal security, such as account name and password verification; (3) intermediate security, such as a digital certificate or secret key; (4) high security, such as a transaction signed with a digital signature using the buyer's secret key; or (5) maximum security, such as a digital signature and additional access controls, such as an account number, a last purchase verification, smart cards, secure tokens or some combination thereof. As will be described later, in the actual embodiment of the virtual payment system described herein, the term "digital certificate" is used to describe the authorization used; however, it will be appreciated that a higher level of security such as a digital signature, or a digital signature with additional access controls may be desired in order to ensure the highest level of security for all parties involved (i.e., the buyer, the seller, the commerce gateway, and the credit processing server) in virtual payment account transactions.
Once a buyer has created and customized his or her virtual payment account, he or she can immediately order products via the Internet if he or she was granted credit during the account application process. If, however, the buyer's virtual payment account is only a prepaid account, prepayment must be made before the buyer can order products. In an alternate embodiment, the buyer with only a prepaid account can order products, however, shipment of the product will be held until the prepaid account is sufficiently funded to cover the purchase. More specifically, this would allow any registered buyer to have a form of "digital layaway" and by ordering products directly from the Web site of any registered seller. It will be appreciated that in yet another embodiment, buyer and seller will use the same type of virtual payment accounts and that any buyer can therefore act as a seller and vice versa. Additionally, it will be appreciated that a seller can be an auction Web site, in which a buyer uses his or her virtual payment account to pay for the goods, services and/or content purchased from the auction Web site.
In one actual embodiment of the present invention depicted in FIGS. 11A-11C, the buyer may "surf the Web" and visit a registered seller's Web site, such as "Virtual Store," 1100 using the Web browser 64. Once the buyer visits a registered seller's Web site, the buyer may order and pay for products offered from that Web site using his or her virtual payment account. More specifically, a buyer using buyer computer 50 and Web browser 64 may retrieve the Web page 1100 shown in FIG. 11A from the seller Web site fictitiously known as "Virtual Store." The buyer makes a selection of a particular product 1105 by manipulating a graphics cursor with a pointing device, such as a mouse above the selection 1110 and "single-clicking." It will be appreciated that other pages, for example, a query page in which the buyer requests products by a keyword, may be displayed. It will also be appreciated that the Web page 1100 shown in FIG. 11A is a simplified example. It is common for a seller site to allow a buyer to select multiple products and place them in a "shopping cart." The buyer can then view the items in the cart and, if desired, remove items from the cart. Once the buyer has selected the desired items for purchase, the buyer indicates a desire to purchase the selected items, for example, by clicking an "OK" or a "Buy" button. In the simplified example shown in FIG. 11A, the buyer selects an item, such as the Virtual Store Personal Computer 1105 and presses the "Order" button 1110 to initiate the purchase transaction.
After initiating the purchase transaction, the seller server 51 provides the Web browser 64 of the buyer's computer 50 with the Web page 1150 shown in FIG. 11B, which requests shipping information 1160, such as a street address, from the buyer. Additionally the Web Page 1150 includes various payment options, i.e., major credit cards, such as VISA.RTM. or MASTERCARD.RTM., with electronic transmission of credit information. In accordance with the present invention, a virtual payment account option is also displayed as a payment option for registered sellers. After entering the shipping and payment information 1160 and selecting the virtual payment option 1155, the buyer can continue by clicking on the "Purchase" option 1165. In an actual embodiment of the present invention the buyer authenticator 65 displays a window 1170 requesting the buyer to select their choice of accounts 1172, along with an authenticating pass phrase 1175. After selecting an account and entering the correct pass phrase, the buyer clicks "Continue" 1177 to proceed with the purchase. In response, the seller server 51 calculates the total cost of the order, including tax and shipping and handling, and the buyer is presented with a confirmation screen 1180 as shown in FIG. 11C. After authorizing the purchase, the buyer may be presented with a payment confirmation screen 1185 as shown in FIG. 11D. Additionally, the buyer may be presented with an order confirmation screen 1190 as shown in FIG. 11E.
FIG. 12 illustrates the logic implemented by the Web browser 64 installed on the buyer computer 50 when the virtual payment account option 1155 is selected. The logic begins in a block 220 and proceeds to a block 222 where a secure connection between the buyer computer 50 and commerce gateway 52 is established. In an actual embodiment of the present invention, the Secure Socket Layer (SSL) protocol is used for establishing a secure connection. SSL uses public key encryption incorporated into a Web browser, such as NETSCAPE NAVIGATOR.RTM. Web browser and Netscape's commerce servers, to secure the information being transferred over the Internet. The logic then proceeds to a block 224 where a buyer authenticator component 65 on the buyer computer 50 is executed. It will be appreciated that the buyer authenticator component 65 can also be included, in part or in whole, in the Web browser 64. The buyer authenticator component 65 is shown in more detail in FIG. 13 and described next.
The buyer authenticator 65 determines whether a buyer is a registered holder of a virtual payment account or, put another way, a registered participant in the closed virtual payment system of the present invention. The logic of FIG. 13 begins in a block 243 and proceeds to a block 244 where an authentication request and container are received from the Web browser 64. The container includes: transaction information, such as purchase detail; identification of the parties, such as a buyer identification that identifies the buyer, e.g., the digital certificate previously issued to the buyer when he or she created the virtual payment account as described above; and a seller identification, e.g., the digital certificate issued to the seller upon creation of a seller account; and context, such as transaction date and time. It will be appreciated that the container is initially empty, and data is then added to the container by various components. As stated earlier, embodiments of the invention implement the buyer authenticator 65 in the Web browser 64. In one actual embodiment, the buyer authenticator 65 is an applet operating from within the Web browser 64.
If, however, in decision block 246 it is determined that a digital certificate is not installed on the buyer computer 50, the logic proceeds to a decision block 252 where a test is made to determine if "certificate not present" processing should be performed. Certificate not present processing allows a buyer to manually enter identification information when a digital certificate is not present. The identification information can include information such as an e-mail address, a password and personal information, for example, a mortgage payment amount. If the result of decision block 252 is positive, the logic proceeds to an alternate authentication in block 254. The alternate authentication is shown in more detail in FIG. 14 and described next.
Returning to FIG. 13 the logic then moves to a block 256 where the information from the alternate authentication process is passed back through the buyer authenticator 65 and the logic ends at block 262. If there is no digital certificate installed ("No" in decision block 246) and certificate not present processing is not going to be performed, for example by a user selecting "cancel" 3010 in the certificate not present authorization Web page 3000 shown in FIG. 30 (or "No" in decision block 252), the buyer likely does not have a virtual payment account. Accordingly, the logic of FIG. 13 proceeds to a decision block 258 where a test is made to determine if the buyer wishes to apply for a virtual payment account. If the buyer wishes to apply for a virtual payment account, the logic proceeds to a block 260, in which the buyer is allowed to apply for a virtual payment account as shown in FIG. 15 and described next. Otherwise, the buyer authenticator 65 returns an unsuccessful authorization message to the Web browser 64 in a block 261 and the logic ends in block 262.
In FIG. 15, once a response is received from the enrollment server 89 a block 265 examines whether an account was created. If it was, then a request is sent to the buyer computer 50 to generate a public key encryption pair in block 267 and to submit the public key to the enrollment server 89 on the commerce gateway 52. The enrollment server then signs the public key to create a digital certificate and returns a successful enrollment Web page 620, as shown in FIG. 8E, which is received in a block 276 along with the digital certificate in a block 278. If at block 265 it was determined that an account was not created then an unsuccessful application Web page is displayed (not shown) at a block 266. In the case of applying for a virtual payment account, the result page 620 provides details of the new account for the buyer, or contains a message informing the buyer that there was an error creating the account. The logic of FIG. 15 of applying for a virtual payment account then ends in a block 279 and processing returns to FIG. 13.
While the logic of authenticating a buyer as shown in FIG. 13 and described herein uses a digital certificate as the primary means for authenticating a buyer, it will be appreciated that other methods are possible. For example, a lesser level of security could be employed, whereby a user could be required to enter identifying information, such as the information entered in alternate authentication shown in FIG. 14. Alternatively, a greater degree of security could be employed whereby a digital certificate is required, and "certificate not present" processing is not allowed. Or, an even greater level of security could be used requiring a digital signature and other verifying information from the buyer.
However, if the buyer was successfully authenticated, the logic proceeds to a block 228 where a virtual payment account selection Web page 1170 as shown in FIG. 11B is displayed. Included in the requested information of the virtual payment account selection Web page 1170 is an identification of the applicable account or sub-account to which the purchase should be applied. Next, in a block 230, sub-account and password information (used to unlock the buyer's digital certificate) are obtained from the buyer from the information entered in the virtual payment account selection Web page 1170 of FIG. 11B when the buyer indicates that the information has been entered by selecting "Continue" 1177. The logic of FIG. 12 then proceeds to a block 232 where the sub-account, and an authentication container are sent to the commerce gateway 52 and processed by the account identification container generator 88 shown in FIG. 17 and described next.
However if at decision block 304, it is determined that the purchase request should not be forwarded to the commerce gateway 52; the logic proceeds to a block 316 where standard commerce engine processing is performed. More specifically, in block 316 traditional credit or debit card authorization is performed such as approval or denial for the use of a credit card, e.g., VISA.RTM. or MASTERCARD.RTM., for the specified purchase amount. Next, the authorized goods are shipped in a block 318. The logic then proceeds to a block 320 where a settlement request is sent to the traditional credit provider, e.g., VISA.RTM. or MASTERCARD.RTM.. A response confirming fulfillment of the order is then sent to the Web browser 64 of the buyer computer 50 in a block 322. The logic of FIG. 18 then ends in block 324 and processing returns to FIG. 12.
FIG. 23 is a diagram illustrating the actions taken by the buyer's computer 50, the seller server 51 and the commerce gateway 52 for ordering products using a virtual payment account system. This diagram presents a high-level view of the detailed processing shown in the flow charts described above. In response to an inquiry into purchasing a product 2305, a seller returns a purchase offer 2310 to the buyer's computer 50. At this point, the buyer has the option of beginning the purchasing process as shown in FIG. 12. To continue the buyer authenticator 65 checks to see which credentials, e.g. certificates, are available to the buyer and selects all available credentials to be used by the commerce gateway 2315 to authenticate the buyer. The buyer computer 50 then requests a list of all accounts or sub-accounts 2320 for these credentials from the commerce gateway 52. The commerce gateway 52 returns only those accounts that are usable by the buyer 2325 using the selected credentials. The buyer computer 50 then generates a purchase confirmation 2330 using one of the accounts on the list returned from the commerce gateway 52. Buyer computer 50 then sends the purchase confirmation 2335 to the seller server 51. The seller server 51 requests authorization 2340 from the commerce gateway to verify that the purchase confirmation is valid. The commerce gateway then returns an authorization 2350 that the purchase confirmation is valid. The seller server 51 may then notify 2355 the buyer computer 50 that the purchase confirmation was authorized. The seller server then prepares the purchase for delivery 2360. At this point, the seller may request a settlement transaction 2365 from the commerce gateway 52, which would then provide a settlement transaction 2370 back to the seller server 51. The seller server 51 may then notify 2375 the buyer computer 50 of delivery details. Finally, the good(s) or service(s) that the buyer purchased are delivered 2380.
If the seller is an auction Web site, the authorization 2340 sent by the commerce gateway 52 to the seller server 51 includes information such as a buyer account identification, a seller identification, a seller sale offering, a buyer authentication, a seller authentication, and a master identification, i.e., identification of the commerce gateway 52 provider. Particular to this type of response is an expiration date/time that is used to signal the shorter of the maximum times that the buyer and the seller are willing to "reserve" funds associated with this transaction. If the transaction, i.e., settlement request 2365, is not received by the commerce gateway 52 before the expiration date/time of the transaction, the products and/or funds will be released back to their owners. At a later time, once the buyer has committed to the purchase, the buyer releases an authorization to the provider of the commerce gateway 52 knowing that the seller has proven ability to ship the products on demand without delay. This initiates the actual settlement of funds and triggers payment to the seller in the next settlement batch, without any further interaction with the seller. This payment method supports buyer-initiated, pre-approved purchases with expiration date/time, such as auction and gift-certificate purchases.
FIG. 26 illustrates the logic implemented by the present invention when a refund transaction is initiated, for example, when a buyer disputes a charge on his or her virtual payment account. As with any payment dispute, it must be determined whether the buyer will receive all or a portion of the disputed amount. This process is external to the virtual payment system of the present invention. The determination of whether the dispute has merit is determined by the seller. If the seller determines that the dispute has merit, the seller notifies a customer service representative and a refund transaction is initiated. In the embodiment shown in FIG. 26 and described herein, if it is determined that an amount disputed by a buyer is subject to a refund, a customer service representative initiates the refund, or chargeback transaction via the administrative computer 54 shown in FIG. 2. In one actual embodiment, the administrative computer is a "dumb terminal" by which the customer service representative enters information directly into the transaction server 84 on the commerce gateway 52. In another embodiment, the administrative computer may have a Web browser that allows the administrator to enter the information using Web pages available only on the LAN 44 behind the firewall 55, i.e., the buyer and seller do not have access to these administrative Web pages.
In one actual embodiment of the present invention, the commerce gateway 52 requests report information from the credit processing server 53, in particular from the financial database 98 stored on the credit processing server. It will be appreciated by those of ordinary skill in the art, that a financial database may be used to store information for report generation, yet may also store information relevant for other purposes.
FIGS. 31, 33, 35, 37, and 39 illustrate exemplary Web pages 3100, 3300, 3500, 3700, and 3900 illustrating exemplary reports available to a seller. FIG. 31 shows an exemplary Web page 3100 with a graph charting the number of sales occurring each month during a year-long period. FIG. 33 shows an exemplary Web page 3300 with a table indicating the status and information on particular orders received. FIG. 35 shows an exemplary Web page 3500 with a table listing transactions that have already been processed for each order, and the result of that processing. FIG. 37 shows an exemplary Web page 3700 with a table listing item sales and along with relevant statistics such as number of units sold, what percentage of units have been sold and what percent of overall sales does that item account for. FIG. 39 shows an exemplary Web page 3900 with a table listing transactions that have yet to be processed and are still wait for the next batch of transaction to be run.
FIGS. 32, 34, 36, 38, and 40 illustrate exemplary Web page forms 3200, 3400, 3600, 3800 and 4000 for customizing seller reports.
Previous Patent US 9,864,989 | Next Patent US 9,864,991