 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is generally related to systems of performing
commercial activities over a general access computer network and, in
particular, to a system and method of conveniently and efficiently
performing advertising responsive secure commercial purchase transactions
over the Internet utilizing the World Wide Web.
2. Description of the Related Art
During the past few years, there has been a substantial growth in the
quantity and diversity of information and services available over the
Internet. The number of users of the Internet has similarly grown quite
rapidly. Perhaps one if not the predominant area of growth on the Internet
has been in the use of the World Wide Web, often referred to as WWW, W3,
or simply "the Web." The hyper-text transfer protocol (HTTP) that serves
as the foundation protocol for the Web has been widely adopted and
multiply implemented in Web browsers and Web servers. Web browsers provide
a convenient user application for receiving generally high quality text
and graphical based information in a scrollable display page format. Such
Web pages are related by embedded hyper-text links that reference other
Web pages. Selection of a hyper-text link, either by direct reference or
implied reference through an image map, causes a hyper-text jump to the
selection referenced Web page. Selection is generally through a simple,
single mouse click on a displayed portion of the text or graphics. This
system of simply selecting relations makes browsing successive Web pages
served from potentially quite diverse and distant Web servers convenient
and intuitive, and accounts in large part to the rapid and wide acceptance
of the Web as an information resource.
One of the anticipated uses of the Web has been to provide a venue for
commercial transactions in products and services. However, commercial use
of the Web has distinctly not met the anticipated potential for a number
of reasons. These reasons include security, convenience of use, and
efficiency. Regarding security, current conventional Web browsers
generally provide for the use of a reasonably secure encryption protocol
overlaid on the HTTP protocol. The encryption protocol, typically
involving a key-exchange based encryption algorithm, permits individual
transactions over the Internet to be secure. Consequently, sensitive
information, such as credit card numbers and the like, can be reasonably
transferred over the Internet with little risk that the information can be
misappropriated and misused.
An exemplary security system utilized by conventional HTTP browsers and
servers is known as the secure sockets layer (SSL). The secure sockets
layer defines and implements a protocol for providing data security
layered under various application protocols, such as HTTP in particular,
and over a conventional TCP/IP communications stack. The secure sockets
layer protocol discretely provides the potential for data encryption,
server authentication, message integrity, and client authentication for
supported protocol connections over a TCP/IP connection. In use, the
secure sockets layer is implemented at both the client browser and server
ends of a network connection. A conventional uniform resource locator
(URL), utilizing "https" as the secure HTTP protocol identifier, is issued
by the client browser to specifically request a secure client/server
session. A series of handshake transactions are provided to negotiate the
establishment of the secure session including performing an encryption key
exchange that is used in an encryption algorithm implemented by both the
client-side and server-side secure sockets layers.
As part of this handshaking, the client browser may also retrieve the
authentication certificate of the server for validation against a known
certificate authority to ensure that the server is not an imposter. The
secure HTTP protocol permits the server to also request and validate the
authentication certificate, if any, held by the client. However, in
general, client browsers and, more specifically, their client host
computer systems are rarely registered with a publicly accessible
authentication certificate authority. Thus, general use of client
certificate authentication is not a viable means for identifying specific
client users or client computer systems.
As a consequence, commercial use of the Web to sell products and services
practically requires the establishment of a forms based user
identification scheme, typically based on user name and password, by the
server system to securely identify and re-identify a specific client user.
Providing the user name and password to initiate each purchase session
with a particular server is the minimum required to authenticate the
client user. The underlying secure HTTP protocol session ensures that the
user name and password are securely transmitted in an encrypted form over
the Internet to the correct server. By the fundamental nature of the key
exchange encryption algorithm used, only the server can decrypt to clear
text the user name and password provided from the client browser.
A secure HTTP session may span a number of individual HTTP transactions
between a client browser and server. With each of these individual
transactions, the exchange keys are in effect permuted synchronously by
both the browser and server to vary the encryption coding used for each
transaction. However, each established secure HTTP session requires
definite closure to prevent a security breach commonly known as a "third
party assumption of identity attack." That is, a third party may be able
to continue the secure session started by another client browser relative
to the server. Since client user authentication only occurs at the
initiation of the secure session, the third party fully assumes the
authorization of the session initiating client browser.
Consequently, commercial transactions over the Internet conventionally
requires three distinct phases in order to securely perform a purchase
transaction. The first phase, conducted once a secure HTTP session is
established, is a logon transaction where the client user provides a user
name and password for authentication by the server. Once authenticated, a
second or selection phase allows the client user to select products and
services for purchase. The server system must in some way continually
track and manage the selections made by the client. The server may record
or log each selection against the client account as the selections are
made. This second phase is therefore an extended transaction that is made
up of many discrete HTTP transactions. Such an extended selection
transaction is subject to failure for a variety of conventional reasons,
including simply an extended delay in the selection process, resulting in
an incomplete or incorrect record of partial purchase selections being
kept by the server system. Without authoritative closure of the purchase
transaction, the server system typically aborts the purchase and discards
the record of selected items.
A facility known as persistent client-side cookies has been introduced to
provide a way for server systems to store selected information on client
systems. Cookies are created at the discretion of the server system in
response to specific client URL requests. Part of the server response is a
cookie consisting of a particularly formatted string of text including a
cookie identifier, a cookie path, a server domain name and, optionally, an
expiration date, and a secure marker. The cookie is automatically
discarded by the client system based on the expiration date. If the secure
marker is present, then the cookie is only returned to a server system
during a secure transaction. Where a URL client request made by the
client, the cookie paths and domain names of cookies stored by the client
are compared with those of the URL request. Cookies with matching paths
and domain names are passed with the client URL request to the server
system. Any text associated with the identifier is also passed back to the
server system. In Internet purchasing applications, the identifiers and
associated text can be used to store information about the current
purchase selections.
Finally, the third phase requires some action on part of the client user to
initiate closure of the purchase transactions and secure session.
Typically, the third phase is entered when the client user indicates that
all product and service selections are complete. A summary order
confirmation form is then presented by the server. The purchase
transaction and the secure session are closed on acceptance or
cancellation of the order as presented.
The convenience of conventional purchase transactions via the Internet,
however, leaves much to be desired. Because of the security concerns, a
secure purchase session is limited to encompassing a single vendor at a
time due to the required three phase login, select, commit purchase
protocol required to ensure the integrity of a secure purchase session.
Not only is the three phase purchase transaction itself self-evidently
cumbersome and thereby a limiting barrier to convenient use by client
users, but many purchase may involve only a single purchasable item or
some number of items that are available only from distinctly different
vendors. Where the purchase transaction is only for a single item, the
necessity of executing a complete three phase purchase protocol distinctly
reduces the likelihood that a client user will actually bother to make the
purchase. A greater barrier exists where the purchase transaction, from
the client user's perspective, is of multiple items from multiple vendors.
The necessity of completing independent three phase purchase transactions
with each of the vendors, particularly where the purchased items are not
entirely planned for or subject to comparative inter-dependant selection,
presents a significant barrier to the client user conveniently and
expediently making the purchase of products and services. The three phase
purchase transaction is simply cumbersome and limiting and will become
more so as products and services are more widely available from different
vendors over the Web.
Another aspect of convenience relates to the speed at which purchase
transactions can be performed and the efficiency of the vendors in
fulfilling the order for products and services. The implicit requirement
for a three phase purchase transaction is fundamentally slow due to the
requirement of client user planning of the purchase transactions where
products or services are to be procured from independent vendors and
alternately by requiring a decision to purchase to be made prior to
determining or selecting precisely what will be purchased.
In addition, the conventional three phase purchase transaction greatly
limits the flexibility of different types of vendors from being able to
deliver ordered products and services in their chosen most efficient
manner. All products selected during a secure purchase session are, in
effect, ordered from the single vendor regardless of whether another
vendor might actually be the source of a product or service sold. The
server vendor receives the entire order and must independently place
orders with supporting vendors by conventional means. As an implicit
result electronic catalog vendors, agent vendors, and order-clearinghouse
type vendors are constrained to separately processing each and every
ordered product or service to lower-tier vendors. Although an electronic
catalog vendor, for example, might wish to have each lower-tier vendor
directly fulfill their part of an order, the server vendor must itself
discriminate which products are to be sourced by which lower-tier vendor
and provide shipping and indirect billing information. In general, direct
order fulfillment from multiple vendors, though the purchase transaction
appears to be simply with the electronic catalogue vendor, would be
significantly more efficient for both the end user and the involved
vendors. Products and services would be shipped or provided sooner and
with less opportunity for error, while ordered products and services are
automatically processed through to the correct vendor with the correct
billing and shipping information.
Consequently, there is a clear need for the ability to perform purchase
transactions over the Internet that are secure, convenient and efficient
both for a client user and the many different vendors of products and
services available over the Internet.
SUMMARY OF THE INVENTION
Thus, a general purpose of the present invention is to provide a method of
efficiently performing secure purchase transactions over the Internet.
This is achieved in the present invention by providing for a purchase
transaction that appears to the client user as a singular selection of a
purchasable product or service and a singular confirmation of the
purchase. A persistent predetermined coded identifier is established on
the client browser corresponding to an account record stored by the
merchant server. A predetermined URL referencing a purchasable product or
service is served to the client browser. The predetermined URL includes an
implicit reference to the persistent predetermined coded identifier. The
predetermined URL is received by the merchant server, including the
predetermined coded identifier, in connection with a client browser
selection. The merchant server validates the predetermined coded
identifier against the server stored account record and records an
identifier of the purchasable product or service as derived from the
predetermined URL by the merchant server.
An advantage of the present invention is that essentially no redundant user
input is required to stage and maintain a secure purchase transaction over
the Internet.
Another advantage of the present invention is that a purchase selection URL
may be embedded in widely distributed hyper-text documents served by
merchant vendors, vendor agents, distributors, electronic catalogers and
the like while maintaining both transaction identity and transaction
security and affording substantial transaction efficiencies.
A further advantage of the present invention is that secure purchase
transactions can be implemented for unsecure servers of sponsored products
and services.
Yet another advantage of the present invention is that server side
automation can provides for automatic simultaneous purchase transaction
handling for both secure and unsecure client browsers.
Still another advantage of the present invention is that Internet purchases
can be performed as essentially atomic purchase transactions over the
Internet while maintaining security over the transaction without requiring
a user authentication manually entered by a client user in circumstances
where the client user has a pre-established credit relationship with a
particular merchant vendor.
A still further advantage of the present invention is that additional
levels of authentication and security, including usage of an optional
personal identification number (PIN), restrictions on shipping
destination, and e-mail confirmation of orders, can be readily and
optionally added in a convenient manner determined on a per server basis.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other advantages and features of the present invention will
become better understood upon consideration of the following detailed
description of the invention when considered in connection of the
accompanying drawings, in which like reference numerals designate like
parts throughout the figures thereof, and wherein:
FIG. 1 illustrates a client/server system architecture providing for a
hyper-text transfer protocol connection between client and server computer
systems;
FIG. 2 illustrates a variety of purchase transaction scenarios based on a
selection of goods or services to be purchased from an electronic catalog
Web page;
FIG. 3 is a flow diagram of the process of performing a client purchase in
accordance with the present invention; and
FIG. 4 is a flow diagram of the process of confirming a client purchase
subject to optional authentication and security provisions.
DETAILED DESCRIPTION OF THE INVENTION
An Internet computer system 10 is generally illustrated in FIG. 1. A
conventional client computer system 12, executing a client browser
application that supports the HTTP protocol, is connected typically
through an Internet Service Provider (ISP) to the Internet 14. A server
computer system 16 is also coupled typically through an Internet Service
Provider to the Internet 14. The server computer system 16, controlled by
a local console 18, executes a Web server application conventionally known
as a HTTPd server. In addition, the server computer system 16 preferably
provides local storage for at least one, though typically many Web pages.
The client computer system requests a Web page by issuing a URL request
through the Internet 14 to the server system 16. A URL consistent with the
present invention may be a simple URL of the form:
<protocol.sub.-- identifier>://<server.sub.-- path >/<web.sub.--
page.sub.-- path>
A "protocol.sub.-- identifier" of "http" specifies the conventional
hyper-text transfer protocol. A URL request for a secure Internet
transaction typically utilizes the secure protocol identifier "https,"
assuming that the client browser and Web server are presumed to support
and implement the secure sockets layer. The "server.sub.-- path" is
typically of the form "prefix.domain," where the prefix is typically "www"
to designate a Web server and the "domain" is the standard Internet
sub-domain.top-level-domain of the server system 16. The optional
"web.sub.-- page.sub.-- path" is provided to specifically identify a
particular hyper-text page maintained by the Web server.
In response to a received URL identifying an existing Web page, the server
system 16 returns the Web page, subject to the HTTP protocol, to the
client computer system 12. This Web page typically incorporates both
textural and graphical information including embedded hyper-text links
that permit the client user to readily select a next URL for issuance to
the Internet 14.
The URL issued from the client system 12 may also be of a complex form that
identifies a common gateway interface (CGI) program on a server system 16.
Such a HTML hyperlink reference is typically of the form:
<form action="http://www.vendor.com/cgi-bin/logon .cgi" method=post>
A hyper-text link of this form directs the execution of the logon.cgi
program on an HTTP server in response to a client side selection of an
hyperlink. A logon form supported by a logon CGI program is typically used
to obtain a client user login name and password to initiate an
authenticated session between the client browser and Web server for
purposes of supporting, for example, a purchase transaction.
In accordance with the present invention, a more complex hyperlink URL
providing for the autonomous redirection of a URL request to another
server can also be used. The form of the redirection URL and the method
use are disclosed in "Method and Apparatus for Redirection of Server
External Hyperlink References," invented by Steven T. Kirsch (application
Ser. No. 08/604,468) which is incorporated herein in its entirety by
reference. In brief, the redirection URL is embedded in a Web page
presented to the client system 12. On selection of a hyperlink coded with
the redirection URL, the URL is transmitted via the Internet 14 to the
server system 16. In a preferred embodiment, the embedded redirection URL
is of the form:
http://<direct.sub.-- server>/redirect?<data>?http://<redirect.sub.--
server>
The "direct.sub.-- server" portion of the redirection URL specifies the
HTTP server target of a transaction that is to be initially established by
the client system 12. The remaining information is provided to the
targeted direct server. While the direct server may be any HTTP server
accessible by the client system 12 that has been designated to service
redirection requests, the direct server is preferably the server system 16
that initially served the Web page with the embedded redirection URL to
the client system 12. The term "redirect" in the embedded redirection URL
is a key word that is detected by the server system 16 to specify that the
URL issued to the server 16 corresponds to a redirection request.
The "data" term of the redirection URL provides data to the HTTPd server
executed by the server system 16 to identify the source instance of the
selected hyperlink and potentially to further validate the redirection URL
as presented to the HTTPd server on the server system 16.
The final portion of the redirection URL is a second URL. This second URL
identifies directly the target server system for the redirection.
Preferably, any path portion provided as part of the direct server
specification with a redirection URL is repeated as a path component of
the redirect server portion of the redirection URL. However, path portion
identity is not required. In general, all that is required is a one-to-one
correspondence between the Web pages referenced by the direct server and
redirect server terms of the redirection URL.
On recognition of the redirect key word, the second URL in the redirection
URL is returned to the browser executing on the client system 12 as part
of a redirection message that directs the browser to issue a new URL
request consisting essentially of the second URL. As a result, the "data"
portion of the direct URL is effectively delivered to the direct server
for purposes of accounting and potentially also validation, while the
second URL is issued to the redirect server essentially transparently to
the client user.
Referring now to FIG. 2 a number of different scenarios are presented where
the present invention is utilized in simple to complex purchase
transactions that, at least from a client user's perspective, are all
equally secure and convenient. Each, from the merchant vendor's
perspective, is also quite efficient. In a first scenario, a Server-1 22
serves a Web page 24 to a client browser in response to a URL request/Web
page service transaction T1. The Web page 24 may embed any number of
hyperlinks including for example hyperlinks 26, 28, 30, 32. The hyperlink
26 may represent a direct reference to an embedded URL or an active image
map that can be utilized to ultimately resolve a client user selection on
a discrete portion of a displayed graphic to a specific URL. The image map
representation can thus be utilized to provide multiple selectable choices
regarding one or more products or services graphically depicted by the
hyperlink 26. These different but related URLS preferably allow the client
user to separately request further information about the indicated product
or service, information regarding other related products and services,
information regarding the availability, method of shipment and terms of
purchase for the indicated product or service, and to directly issue a
request to purchase the product or service.
Where the selection reflects a request for further information, an image
map selection identifier is passed as part of a transaction T2 to a vendor
Server-2 34. The Server-2 34 can be the same logical or physical server as
Server-1 22 or a completely independent server. The requested information
is returned to the client browser as part of the transaction T2 preferably
in the form of a Web page. Where the image map selection is resolved to a
request to purchase URL, the present invention preferably provides for the
purchase URL to specify use of a secure HTTP session with the Server-2 34.
In accordance with the secure protocol, such as implemented by the secure
sockets layer, the Server-2 34 negotiates and establishes a secure session
T2 with the client browser. Once the secure session is established, the
purchase request URL is, at least in effect, issued to vendor Server-2 34.
Any client-side stored cookie data that properly corresponds to the
request URL is also passed to the Server-2 34. In the preferred instance
where an authenticated credit relationship has been pre-established
between the client user and the Server-2 34, the client-side cookie
encodes information sufficient to re-authenticate the client user to the
Server-2 34. Where a client/vendor credit relationship has not been
pre-established, a corresponding cookie will not exist on the client
system 12. In this case, the Server-2 34 may initiate a conventional
process of establishing and validating a credit relationship with the
client user. Preferably, the Server-2 provides a registration form to the
client browser for display and completion by the client user as part of
the secure transaction T2. The registration form typically provides for
the entry of a name, a password, a credit card number, billing and
shipping addresses for the client user and possibly other relevant
information. The resulting information is used by the Server-2 34, in
accordance with the present invention, to create and store a client-side
cookie on the client system 12 for use in connection with a subsequent URL
purchase request. A database record is also preferably created in the
database 36.
Cookie data, when received by the Server-2 34 in connection with a purchase
request URL, is then used to lookup a client database record in the
database 36. The cookie data may be decoded and compared with the record
contents to validate the cookie. Assuming that the comparison is correct,
the identified record is then used as the source of billing related
information, needed by the Server-2 34 to fulfill the client user's
purchase request.
When the decoded cookie information becomes available to the Server-2 34,
directly as part of the secure transaction T2 or indirectly from form
entered data, the Server-2 34 may then perform an automated credit
extension authorization check to ensure that sufficient credit exists and
may be extended to cover the present purchase transaction. Again assuming
sufficient credit is available, the purchase of the product or service
identified by the selected URL 26 can be presented to the client user for
approval using a purchase confirmation form identifying the selected
product or service, the billing and shipping related information, and
provide active confirm and cancel buttons.
In an alternate embodiment, each purchasable item listed on the
confirmation form is also presented with individual confirm, cancel and
defer buttons. Deferred purchasable products and services are accumulated
by the Server-2 34 and presented with subsequent confirmation forms
generally until the product or service purchase is approved, cancelled or
expired. Additional authentication and security options may be added
through the operation of the confirmation form. These further options are
discussed below in relation to FIG. 4.
The data provided by the client user in response to the confirmation form
is preferably returned to the Server-2 34 and may terminate the secure
session portion of the HTTP transaction T2. The purchase of the product or
service, if accepted by the client user, is then a sales order that can
then be processed by the Server-2 34 or passed on to an automated order
processing system for order fulfillment consistent with conventional order
processing practices to provide for the delivery of the product or service
purchased to the client user.
Thereafter, should the client user again select the purchase portion of the
hyperlink image map 26, or any other purchase selection hyperlink that
corresponds to the same vendor operating from the Server-2 34, a new
secure session T2 is established, the client-side cookie is provided to
the Server-2 34, and a confirmation form is presented to the client user.
The client-side cookie provided during the secure session T2 specifically
encodes sufficient information to authenticate the client user to the
Server-2 34, thereby obviating the need for the client user to
re-authenticate manually.
As should now be appreciated, once a purchase relationship has been
established between a client user and vendor server, subsequent purchase
transactions in accordance with the present invention consist simply of a
product or service selection phase followed by a confirmation phase where
each phase requires nothing more than a single mouse click to complete.
Selection of, for example, a direct hyperlink URL 28 on the Web page 24
results in the issuance of a URL request initiating a transaction T3 with
a Server-3 38. Although, in this scenario, Server-3 38 is the direct
sponsor of the URL 28 on the Web page 24 served by the Server-1 22, the
Server-3 38 may not wish to or be able to participate in a secure purchase
transaction. However, as the sponsor of the URL 28, Server-3 38 may
require preemptive notification of the selection of the URL 28.
Accordingly, the URL 28 may be provided on the Web page 24 as a
redirection URL that identifies a Server-4 40 as the second URL within the
redirection URL 28. Where the Server-3 38 implements the secure sockets
layer, the initial URL reference to the Server-3 38 may provide for a
secure session within the transaction T3. Consequently, any and all data
provided as part of the redirection URL for accounting purposes to the
Server-3 38 is encrypted by operation of the secure transaction T3.
However, Server-3 38 need not and often will not be a secure server. The
accounting data provided with the redirection URL will typically not be of
a sensitive nature. Generally, the accounting data will provide an
identification of the particular instance of the URL 28 that was selected
by a client user. Furthermore, any client-side cookie corresponding to the
initial URL or the redirection URL will also not contain any sensitive
account or billing information relevant to the actual product or service
identified by the URL 28. Rather, the cookie containing the sensitive
information will be transferred only to the Server-4 40 within a secure
session transaction T4.
The Server-3 38 returns a redirection message and the second URL to the
client browser. As in the case of the purchase URL provided to the
Server-2 34, the second URL of the redirection URL preferably specifies a
secure protocol, such as "https," a specific Web server, such as Server-4
40, and includes a Web page path that can be used to identify a particular
product or service. Thus, in response to the redirection message from
Server-3 38, the client browser preferably autonomously operates to
establish a secure session transaction T4 with the Server-4 40. The
sensitive data provided by the client-side cookie that is selected
specifically by the second URL of the redirection URL is therefore passed
to the Server-4 40 within the secure session transaction T4. The secure
purchase transaction T4 then completes in the same manner as described
above with regard to transaction T2.
Consequently, by the ability to use a redirection URL as the URL 28 the
present invention readily supports the qualified use of unsecure Web
servers and provides a basic flexibility useful for Web servers that
choose to act only as URL sponsors, or product agents. That is, the
present invention directly supports merchant vendors who wish to, at least
in effect, contract out the actual server side execution of an Internet
purchase transaction. Utilization of the redirection URL permits the
purchase transaction T3 to be directed to a specific purchase transaction
processing Server-4 40 while ensuring that notice is provided to the
Server-3 38 with each selection of the redirection URL 28.
The use of the redirection URL allows any number of URL sponsoring Web
servers to utilize the services of the Server-4 40. The support of
redirected purchase transactions by Server-4 40, however, does not
preclude the Server-4 40 from directly supporting purchase transactions,
such as within a secure session transaction T5 initiated in response to
the selection of a directly hyperlinked URL 30. Thus, the present
invention provides substantial flexibility in the use of primary purchase
transaction Web servers such as Server-4 40.
Another form of indirection consistent with the present invention is
demonstrated by a Server-5 44 in connection with the sponsorship of a
hyperlink 32. Again, as implemented on the Web page 20, the hyperlink 32
may represent multiple URLs separately selectable through an image map.
The hyperlink 32 may also represent one or more separately selectable
direct URLs. In both instances, at least one selectable URL represents a
request to purchase a product. Other URLs may represent requests for
various types of product related information.
Selection of a URL 32 preferably results in the establishment of a
transaction T6 with the Server-5 44. Although the Server-5 44 may be a
secure server and preferably maintains a database 45 of client user
account records and Web pages detailing certain products and services
available for apparently direct purchase, the Server-5 44 may itself
maintain pre-established credit relationships with any number of other
servers, such as Server-4 40. In response to a URL request for product
information or to purchase a selected product, the Server-5 44 may
establish a transaction T7 with the Server-4 40. This transaction T7 may
be an HTTP or possibly a non-HTTP transaction, such as a network
filesystem read (NFS) or custom remote procedure call (RPC), that serves
to retrieve responsive information from the Server-4 40, preferably as or
suitable for incorporation in a Web page that is responsively served to
the client user.
The transaction T7 may also represent a secure purchase transaction in
accordance with the present invention. In this instance, the Server-5 44
acts as a product purchaser relative to the Server-4 40 and purchases
based on a credit relationship pre-established between the Server-5 44 and
the Server-4 40. The referenced account record held in the database 42 by
Server-4 may be used to specifically identify the Server-5 44 as a
possibly re-branding reseller of products purchased from Server-4 40.
Accordingly, after so identifying Server-5 44, the Server-4 40 may issue
an HTTP request to Server-5 44 to obtain the drop ship address of the
ultimately purchasing client user and, potentially, the brand
identification to be applied to the product upon shipping. Alternately,
though perhaps less efficient, the purchased product can be shipped to
Server-5 44 for reshipment to the client user.
< | | |
