CA2328807C - Method and system for secure data transmission - Google Patents

Abstract

A method and system for providing eCommerce services that are both secure and more easy to implement for merchants, eCommerce service providers and financial institutions. An internal state of a software object is transmitted across an unsecured network between a merchant and an eCommerce service provider, wherein both the party sending the software object and the party receiving the software object are identified prior to the information contained in the object being processed by the receiving party. The exemplary embodiment of the invention, hereafter referred to as "ECML"
language, operates to format, digitally sign and encrypt the information transmitted to an ECML, enabled eCommerce service provider.

Description

METHOD AND SYSTEM FOR SECURE DATA TRANSMISSION
BACKGROUND OF THE INVENTION
1. Field of Invention The present invention is directed to a method and system for secure transmission of data across an unsecured network. More particularly, transmission is performed with the ability to identify both the party sending a software object and the party receiving the software object prior to processing the data in the software object.

2. Description of Related Art Conventional eCommerce systems enable a computer operated under the control of a merchant to obtain information offered by a customer and transmitted by a computer operating under the control of the customer over a publicly accessible packet-switched network, e.g., the Internet, to the computer operating under the control of the merchant, without risking exposure of the information to interception by third parties that have access to the network and to assure that the information is from an authentic source.
Conventional eCommerce systems also enable merchants to transmit information, including a subset of information provided by the customer, over a network to a payment gateway computer system, such as a dedicated financial server, that is designated by a bank or other financial institution. Such information is transmitted so that the financial institution can provide payment on behalf of the customer without the risk of exposing that information to interception by third parties. Such institutions include, for example, financial institutions offering credit or debit card services.
Conventional eCommerce systems have provided secure transmission channels using secure payment technology such as Secure Electronic Transaction (hereinafter "SET"), jointly developed by the Visa and MasterCard card associations, and described in Visa and MasterCard's Secure Electronic Transaction(SET) Specification, Feb.
23, 1996.
Other such secure payment technologies include Secure Transaction Technology ("STT"), Secure Electronic Payments Protocol ("SEPP"), and Internet Keyed Payments ("IKP).
However, such secure payment technologies require the customer to operate software that is compliant with the secure payment technology, interacting with financial institutions, thereby requiring the customer to interact with a third party who subsequently provides encoded information to the merchant.
In other words, a customer communicates directly with both a merchant and a server of a financial payment certification authority, e.g., a credit card company.
Subsequently, based on the information provided by the customer to the financial payment certification authority, the authority communicates with the merchant to provide some certification of payment authorization. Therefore, to date, such schemes have not been readily adopted because they are inconsistent with a real-world transaction model in which a customer purchases a product using credit only after a merchant has taken steps to ensure that the customer's credit is sufficient for the purchase.
Alternatively, another attempt to provide secure transmission channels for eCommerce transactions is a general purpose communication protocol such as Secure Sockets Layer (hereinafter "SSL"), which was first introduced into the market by Netscape, Inc., as described in Freier, Karlton & Kocher (hereinafter "Freier"), The SSL
Protocol Version 3.0, March, 1996. SSL provides means for secure transmission between two computers. SSL has the advantage that it does not require special-purpose software to be installed on the customer's computer because it is already incorporated into widely available software that many people utilize as their standard Internet access medium and does not require that the customer interact with any financial payment certification authority.
SSL is designed to only validate one of the two parties participating in the online transmission. Thus, it does not require, nor facilitate, the validation of the sender; it only provides validation of the server. Server-to-server eCommerce systems require the validation of both parties which participate in the transaction. Other examples of general-purpose secure communication protocols include Private Communications Technology ("PCT") from Microsoft, Inc., Secure Hyper-Text Transport protocol ("SHTTP") and Pretty Good Privacy ("PGP") which meets the IPSEC criteria.

Financial institutions desire an Internet payment processing scheme that emulates existing Point of Sale (POS) applications that are currently installed on their servers, and that requires minimal changes to their network systems. The minimization of network system changes is a critical requirement since any downtime for a financial institution's server system represents an enormous expense. However, Internet-based payment processing applications require additional security measures that are not found in conventional POS terminals. This additional requirement is necessitated because Internet communication is performed over publicly accessible, unsecured communications lines in stark contrast to the private, secure, dedicated phone or leased line service utilized between a traditional merchant and a financial institution. Thus, it is critical that any payment processing scheme utilizing the Internet for a communication backbone employ some form of cryptography or some type of digital signature to further ensure security.
Open Market International offers SecureLink Commerce Architecture that connects transaction participants using secure, standards-based commerce objects; that is, Digital Offers, Digital Receipts, Digital Tickets, Digital Coupons and Digital Queries which require no custom coding, are secure and can be embedded in a HyperText Markup Language (HTML) or HyperText Transfer Protocol (HTTP) capable medium. The SecureLink Commerce Architecture provides online customer authentication and authorization, online order and payment processing, automated tax and shipping calculations, online order tracking and status and online customer service.
Open Market International provides increased security using digitally signed Universal Resource Locators (URLs). Such a scheme uses a symmetric key generated by a payment gateway, i.e., the eCommerce service provider server. This key is used during transactions to digitally sign data communicated to and from the eCommerce service provider server and the merchant server.
However, the symmetric key is generated at the eCommerce service provider server and needs to be transmitted to participating merchants. The symmetric key must be regenerated on a periodic schedule. As a result, computer architecture located at the eCommerce service provider server must perform the extensive task of maintaining and updating all the symmetric keys to ensure security. Also, conventional digitally signed URL technology is client-based, which requires that a consumer's browser re-direct to an eCommerce service provider server to interact with the eCommerce service provider.
Additionally, use of digitally signed URL technology is limited by the size of the Query String parameter, utilized in an HTTP GET operation. The Query String is required as part of an HTTP GET, in order to send options to a server. The Query String has a size limit, which is approximately 2K. Further, there are practical limits to the ability to provide highly structured data streams, because of both the size limitation and the potential for proxy servers to mangle the data.
Alternatively, Cybercash~ provides payment authentication services and software and provides access by merchants to their service via the Internet.
The Cybercash~ eCommerce transaction scheme requires that a merchant download software from the Internet without charge. The merchant can actually develop their entire catalog and buyer-flow application, utilizing this software. Cybercash~ allows merchants to access the service in "test mode", without paying any fees. However, when the merchant decides to collect real payments then Cybercash~ starts collecting a fee. Many Internet Service Providers support Cybercash~ because it does not cost them any up-front fee.
Thus, Web site developers are supportive of Cybercash~ technology. However, merchants are less satisfied with the service because fees are quite high and back-office tools, e.g., tax and shipping calculation tools, can be difficult to integrate within existing business processes.
SUMMARY OF THE INVENTION
The present invention is directed to a method and system for providing eCommerce services that is both secure and supports a highly structured data interface, utilizing an XML framework. According to the exemplary embodiment of the invention, an internal state of a software object is transmitted across an unsecured network between a merchant and an eCommerce service provider, wherein both the party sending the software object and the party receiving the software object are identified prior to the information contained in the object being processed by the receiving party.
An exemplary embodiment of the invention, hereafter referred to as "ECML"
(Electronic Commerce Markup Language) language, operates to format, digitally sign and encrypt the information transmitted to an ECML-enabled eCommerce service provider.
(ECML is not to be confused with the Electronic Commerce Modeling Language, which is a completely different standard, designed primarily to support e-wallet development.) In accordance with one aspect of the present invention there is provided a method for providing eCommerce services, the method comprising: generating a software object;
formatting the software object; digitally signing using a digest of clear text of data within the software object; encrypting at least one field within the software object using public key cryptography; passing the software object across an unsecured network between a merchant server and an eCommerce service provider server; and processing the software object by the eCommerce service provider server; wherein both the merchant server and the eCommerce service provider server are identified prior to the step of processing the software object by the eCommerce service provider server.
In accordance with another aspect of the present invention there is provided a system for providing eCommerce services, the system comprising: an eCommerce service provider server including a first software component and a first XML
processor; a first link coupled between the eCommerce service provider server and a publicly accessible packet-switched network; a second link between the eCommerce service provider server and a private network; wherein the eCommerce service provider server receives software objects, generated by a second software component by request of a second XML processor at a merchant server, from the merchant server via the first link and the publicly accessible packet-switched network and wherein the first software component generates a modified software object at the request of the first XML
processor and the eCommerce service provider server transmits the modified software object to the merchant server via the first link and the publicly accessible packet-switched network.

Sa The present invention provides an opportunity to perform secure eCommerce transactions between two server machines without using a private, secured network for transmission of transaction data between a merchant server and an eCommerce service provider server.
BRIEF DESCRIPTION OF THE DRAWINGS
The exemplary embodiment of this invention will be described in detail, with reference to the following figures, wherein:
Fig. 1 illustrates a system for secure data transmission according to the exemplary embodiment of the invention;
Fig. 2 illustrates the physical structure of an XML document;
Fig. 3 illustrates the logical structure of an XML document illustrated in Fig. 2;
and Fig. 4 illustrates a method of provisioning and performing an eCommerce service in accordance with the exemplary embodiment.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
Design of ECML allows it to be dynamically extensible. Therefore, in accordance with the exemplary embodiment of the invention, an eCommerce service provider has the ability to distribute a software object, e.g., including a service software improvement, to a retailer without having to ship, i.e., hand deliver, a new software object every time an eCommerce feature is added. By utilizing the invention, an eCommerce service provider can add features and functionality without requiring an entire overhaul of the merchant's ECML client software. Such additions are possible because ECML provides a format for transmission of information by establishing a definition for structuring data rather than a definition for all data elements. Thus, support for new data elements can be added by the eCommerce service provider, without requiring completely new software on the client server.
Figure 1 illustrates a system for secure data transmission according to the exemplary embodiment of the invention. In accordance with the exemplary embodiment of the invention, when prompted, a merchant server 110 uses ECML-based client software components 112 to generate an ECML-based software object 111 that is transmitted to the eCommerce service provider server 120 using a publicly accessible packet-switched network 130.
As shown in Fig. 1, the system architecture 100 includes at least one merchant server 110 coupled to an eCommerce service provider server 120 via a public network 130, e.g., the Internet. It should be appreciated that the public network is an unsecured network, as that term is commonly understood in the art. Therefore, data transmitted between the merchant server 110 and the eCommerce service provider server 120 is protected using methods in accordance with the exemplary embodiment of the invention.
The eCommerce service provider server 120 is also coupled to a firewall 150 through a communication link 140. The firewall 150 is also coupled to any number of financial institution servers 170 via communication links 160. It should be appreciated that communication links 140 and 160 can be any known or later developed device or system for connection, including a direct cable connection, a connection over a wide area network or a local area network, a connection over an intranet, a connection over the Internet, or a connection over any other distributed network or system.
Further, it should be appreciated that the communication links 160 and 140 can each be a wired or a wireless communication link to a network. It is preferred that communication links 140 and 160 are communication links forming part of secure networks.
Both the merchant server 110 and the eCommerce service provider server 120 include software modules called Extensible Markup Language (XML) processors 113 and 123, respectively, that read XML documents and provide access to their content and structure. XML processors 113 and 123 work on behalf of other modules, called applications 114 and 124, also incorporated on the servers 110 and 120, respectively.
ECML delivers powerful eCommerce components to merchants selling goods and services on the Internet. These components connect online merchants to fast, scalable and reliable Internet eCommerce services, e.g., AT&T's SecureBuy. ECML is a specification used by a combination of software components, application programming interfaces (APIs) and service platforms to connect a merchant store, i.e., merchant server 110, to various payment systems, i.e., financial institution servers 170.
The eCommerce service provider server 120 validates the software object 11 l and instantiates a local software object 125 on the eCommerce service provider server 120 with the internal state of the transmitted software object 111. The eCommerce service provider then processes the data contained in the software object 111 and returns a modified software object state 121 to the merchant.
Part of processing the data involves obtaining transaction authorization from a 1 S financial server 170 on a secure network 160. The software object 111 stores data expressed in a way that the data can be transferred, e.g., using XML. In this way, software object data, e.g., the state of a software object, can be transmitted from the merchant server 110 to the eCommerce service provider server 120 and subsequently transferred to a financial institution server 170, e.g., a credit card company, and back for transaction purposes. The local software object 125 at the eCommerce service provider server 120 assumes the data state of the merchant's ECML-based software object 111. As a result, the ECML software component 122 on the eCommerce server 120 acts as a gateway to eCommerce transaction systems, e.g., credit card companies that require private networks.
The eCommerce server 120 may have frame relay point-to-point links with financial institution servers 170 or any type of connection that provides secure transmission of data. As a result, there are typically no unsecured networks traversed between the eCommerce service provider server 120 and the financial institution servers 170.

g In a method for secure data transmission according to the exemplary embodiment of the invention, the local software object 125 on the eCommerce service provider server 120 can call new software objects 126 to add new features. Additionally, the local software object 125 can call additional servers 127. Therefore, upgrades and maintenance of the eCommerce service provided using the service provider server 120 can be implemented to more easily distribute functionality throughout multiple servers.
Additionally, the exemplary embodiment of the present invention improves on data transmission using conventional digital signature techniques in many ways. First, by implementing ECML-based software architecture, an HTTP POST buffer does not suffer from conventional buffer size restrictions. Transmission of ECML-based software components between the merchant server 110 and the eCommerce service provider server 120 utilizes HTTP or HTTPS as the transport protocol. ECML client software running on the merchant server 110 utilizes an HTTP POST request for all such transactions. An ECML data stream is the post buffer of the request. The ECML data stream is an XML
formatted buffer, not the standard HTTP name value pair POST buffer syntax.
Responses to requests by the merchant server 110 from the eCommerce service provider server 120 return to the merchant server 110 as a standard HTTP response from a POST
request.
The format of responses from the eCommerce service provider server 120 are also in XML, not HTML. Implementation of the exemplary embodiment of the invention encrypts a number of fields using Public Key cryptography. Additionally, the merchant's digitally sign messages to the eCommerce service provider server 120. Such messages are signed using a digest of the clear text of the message. This requires that the eCommerce service provider server 120 decrypts the encrypted values before it can verify the signature of the merchant.
It is preferable that the present invention utilize public/private key cryptography, which does not require regeneration of the encryption keys.
The exemplary embodiments of the invention are server-based. Therefore, methods and systems designed according to the invention focus on interaction between two servers. Hence, a user's browser is not involved in an ECML-based conversion between the eCommerce service provider server 120 and the merchant server 140.
Accordingly, implementing the present invention provides secure data transmission between server machines. Such an implementation allows the eCommerce service provider to improve overall response time because the eCommerce service provider server is no longer burdened with rendering an HTML user interface for browsers.
Another advantage of the present invention stems in part from the use of XML
vocabulary --upon which ECML is based-- which puts a highly structured framework around the data to be transmitted. This structure allows for nested data elements, which are not possible with standard URL or POST buffer encoding techniques.
The exemplary embodiment of the invention provides an interface that can handle all activities related to eCommerce. Such activities include "add items to a network shopping cart", online authorizations and settlement. The exemplary embodiment of the invention uses XML and HTTP to communicate directly between the merchant server and the eCommerce service provider server. Therefore, no browser is involved and no graphical user interface must be generated for personal review.
XML describes a class of data objects called XML documents and impacts the document parsing behavior of applications that process them. XML is an application profile or restricted form of the Standard Generalized Markup Language (SGML), which is the international information coding standard to which HTML belongs. HTML
is an application of SGML and is focused primarily on the presentation aspects of Web pages.
By construction, XML documents are conforming SGML documents. XML was developed by an XML Working Group formed under the auspices of the World Wide Web Consortium (WC3) in 1996.
Traditionally, the term "document" has been associated with items such as manuals, letters and proposals as well as invoices, purchase orders and travel requests.
Forms-based information tends to be closely aligned with business transactions having numerical content. Document-based information tends to be used for requests for proposals (RFPs), contracts and so on. However, both of these business communication media are comprised of content arranged according to some predefined structure.

With the influence of the World Wide Web, the properties of traditional forms and documents are converging into dynamic business transactions. These transactions may be used to interchange a wide range of material including product information, pricing proposals and financial and legal settlements. These transactions can be 5 dynamically constructed from data in relational databases and can include descriptive text and graphics from document management systems.
As depicted in Fig. 2, an XML document may be, for example, the text of a printed work or a set of database records. In essence, an XML document may be viewed as a data object meeting certain criteria. Each XML document has both a logical and a 10 physical structure. Figure 2 illustrates the physical structure of an XML
document.
Physically, the XML document 200 is composed of units 210 call entities. An entity 210 may refer fo other entities 220 to cause their inclusion in the document 200.
An XML
document 200 begins in a "root" or document entity 230.
Figure 3 illustrates the logical structure of an XML document 200. Logically, the XML document 200 is logically composed of a declaration 310, elements 320, comments 330, character references 340, and processing instructions 350, all of which are indicated in the document 200 by XML. The logical and physical structures must also nest properly. An attribute 325 is a property of an element 320. Often attributes 325 are used to convey information about the element 320 and hence can be said to provide metadata for the elements 320.
Referring again to Fig. 2, the entities 210 included in an XML document 200 contain either parsed data 240 or unparsed data 250. Therefore, these entities 210 act as virtual storage units. An XML document 200 is often a separate file, but may be a string or even a database record. Parsed data 240 are made up of characters, some of which form character data 260 and some of which form markup data 270. Markup data encodes a description of the XML document's storage layout and logical structure as shown in Fig. 3. XML provides a mechanism to impose constraints on the storage layout and logical structure of the stored data.

To qualify as an XML document, a data object must be well-formed. A data object is well-formed if, taken as a whole, it contains one or more logical elements 320, the boundaries of which are either delimited by start-tags and end-tags or, for empty elements, by an empty-element tag. Also there must be exactly one root element or document element 230, as shown in Fig. 2, no part of which appears in the content of any other element 230. Additionally, to be well-formed, each of any of the entities 210 containing parsed data 240 that is referenced directly or indirectly within the document must also be well-formed.
In the exemplary embodiment of the invention, ECML is an XML-based markup language used to define eCommerce conversations between servers 110, 120 and 170.
ECML acts as an eCommerce middleware, which eliminates the tightly coupled connection that conventional eCommerce systems require merchants to have with payment processing mechanisms. ECML provides an abstraction of various eCommerce functions. The merchant who utilizes ECML-based components does not need to implement the unique requirements of a particular payment processing application.
Rather, the merchant server 110 communicates with a payment service, i.e., a financial institution server 170, using ECML-based software components 112. It should be appreciated that the ECML-based software component 112 may be implemented into a new or existing Web-based eCommerce processing application architecture.
Accordingly, ECML is the language that the software components 112 at the merchant server 110 use to communicate with the eCommerce service provider 120. The ECML-based components 112 allow the merchant to obtain online credit card authorizations, calculate tax and calculate shipping. The ECML-based components 112 also support advanced programming interfaces to allow the merchant to perform back-office functions, e.g., settling the authorized transactions after the goods or services have been rendered. An online merchant may have an application 114 that displays the catalog of goods available for sale. Such an application 114 also manages the customer's shopping experience, including managing a customer's shopping cart.

An ECML-based component 112 creates an XML processor object 113 when a customer decides to purchase goods or services from the merchant. The merchant's application 114 calls the ECML-based component 112 and adds the items to be purchased from the customer's shopping cart into the component 112. The ECML-based component 112 then generates ECML data and sends this ECML data to the eCommerce service provider server 120 in the form of an ECML-based software object 111. The eCommerce service provider server 120 then parses the data of the ECML-based software object 111 and returns the results back to the ECML-based component 112 on the merchant server 110 in the modified software object 121. Results are interpreted by the merchant's application 114, and a result is displayed to the merchant via a graphical user interface, not shown, supported by the server 110.
As mentioned above, it is preferable that the exemplary embodiment of the invention can be implemented using XML. There are two main advantages to using an XML-based language.
First, because the use of XML renders ECML extensible, implementation allows for growth that protects the merchant's investment in software. An eCommerce service provider has the ability to distribute a software object corresponding to a new service feature to a retailer without having to ship, i.e., hand deliver, an entirely new software package every time an eCommerce feature is added. Therefore, by utilizing the invention, an eCommerce service provider can add features and functionality without requiring a complete overhaul of the merchant's ECML client software. Such additions are possible because ECML provides a definition for structuring data, rather than a definition for all data elements. Thus, support for new data elements can be added by the eCommerce service provider, without requiring completely new software on the client server.
Second, an XML-based eCommerce service architecture allows third party vendors to utilize XML to develop components tailored specifically for their particular payment processing applications. This capability is especially significant and beneficial because it allows integration of ECML with a broad array of market available catalog applications, e.g., those produced by iCat, InterShop and IBM.
Payment processing applications can be as complex to implement as catalog applications. In addition to the complexity of implementation, operation of payment processing applications can also be a significant load on merchant servers that are already burdened with rendering dynamic catalog pages from SQL databases. Because the exemplary embodiment of the invention allows integration of payment processing applications with catalog applications, further burdening of the merchant server infrastructure is limited. Thus, seamless integration of a payment processing application with other applications, e.g., catalog and buyer-flow management, results.
A merchant need only integrate a single ECML-based component 112 into his Web site. This ECML-based component 112 not only obtains online authorization, but also calculates tax and shipping costs. In contradistinction, most conventional eCommerce service providers require the merchant to integrate additional tax and shipping components at the merchant server without integration, thus adding to the management burden of the merchant server.
Additionally, the ECML-based components 112 can provide a conventional interface to perform back-office functions such as settlement and returns.
Thus, the payment processing is handled by the eCommerce service provider server 120, which reduces the complexity of implementing and integration of the various applications provided in conjunction with the eCommerce service. As a result, the throughput of the merchant server 110 is increased. This is a significant difference from conventional eCommerce payment processing application architectures. Although conventional payment processing applications provide good "buyer" flow integration, back-office interfaces are much more difficult to utilize.
Essentially, utilization of ECML-based components 112 enables a merchant to bring a Web site online faster, with less cost and complexity. ECML-based payment processing applications also provide a great deal more scalability and reliability than the merchant could afford if he were to implement it on his own.

ECML-based components 112 also provide necessary security during conversations between the merchant server 110 and the eCommerce service provider server 120. SSL security has generally been implemented between the customer browsing the Web and the merchant's Web site. SSL is not sufficient to also secure server-to-server interaction between the merchant server 110 and the eCommerce service provider server 120 because it does not facilitate the authentication of both parties involved in the transaction.
Therefore, to provide improved security during server-to-server interaction, the exemplary embodiment of the invention uses ECML-based components 112 that utilize a Public/Private Key cryptographic system. Such cryptography secures the ECML-based conversation between the two servers. This encryption provides both encryption of the data as well as validation of the requesting merchant.
The exemplary embodiment of the invention also utilizes digital signature technology. A digital signature is the network equivalent of signing a message so that the identity of the sender and receipt by the recipient cannot be denied. In the exemplary embodiment of the invention, the digital signature accomplishes two goals.
First, it ensures that the message is not tampered with during transmission over the unsecured network 130. This is possible because the data within the ECML-based software object 111 sent to the eCommerce service provider server 120 is utilized as part of creating and validating the digital signature. Second, the signature is validated using a public key that belongs only to a specific merchant. This ensures that the specific merchant, or nominally the holder of the merchant's private key, sent the ECML-based software object.
Additionally, according to the exemplary embodiment of the invention, sensitive data fields within the ECML-based software object are also encrypted.
Therefore, sensitive data values are never sent openly on the unsecured network 130.
As a security option, the merchant can also choose to run the ECML-based conversation via the HTTPS (SSL over HTTP) protocol. This operation encrypts the entire ECML-based session. However, this operation incurs a performance penalty involving speed and memory requirements that some merchants might select to avoid.
There are five types of ECML-based conversations related to data transmission between the merchant server 110 and the eCommerce service provider server 120.
As 5 shown in Fig. 4, the method of provisioning and performing an eCommerce service begins in step 400 and control proceeds to step 410. In step 410, to obtain ECML client software, a public key/private key pair is generated by the ECML-based software component 112 at the merchant server 110 and the public key of the public key/private key pair is registered with the eCommerce service provider server 120 as being specific to 10 the merchant server 110. In such a transaction, state information of the public key is extracted and sent over the network using HTTP or HTTPS. Control then proceeds to step 420.
Transmission of an ECML-based software object 111 utilizes an XML-based tag structure. Each ECML-based software object contains at least one data block and a 15 header tag. The data block can contain elements, fields and other data blocks. Each ECML-based software object also contains a header tag, which describes the name and version, e.g., <ECMLv2.0>. In accordance with XML document structure requirements explained above, all opening tags have a corresponding closing tag. The closing tag for the example header is d ECMLv2.0>. A data block may, for example, look like:
<ECMLv2.0> opening header tag <MerchantDataBlock> block opening tag <MerchantID>www.junk.com</MerchantlD> field or element tag </MerchantDataBlock> block closing tag d ECMLv2.0> closing header tag A data block can contain either any number elements or additional data blocks.
The example shown above displays a data block that contains a single element, i.e., <Merchant>D>www.junk.com</Merchant)D>. However, a data block may contain additional data blocks, for example:
<ECMLv2.0> opening header tag <MerchantDataBlock> block opening tag <MerchantID>www.junk.com</MerchantlD> field or element tag <CardConfig>Pre-Auth Only</CardConfig>
<TaxConfig>Sales</TaxConfig>
</MerchantDataBlock> block closing tag </ ECMLv2.0> closing header tag The merchant server 110 initiates registration. The software running on the merchant server 110 both creates a public/private key pair and also digitally signs messages using a SHA 1 message digest. Registration uses cryptographic standards defined by RSA data security as PKCS #1.
Performing registration, as in step 410, is primarily designed to provide a system for cryptographic key exchange. For a new merchant, this process automatically provisions the merchant into a test environment on the specified eCommerce service.
The ECML software-based component 112 on the merchant server 110 generates new public/private key pairs. Semantics of ECML support the transfer of the public key generated by the merchant to the eCommerce service provider server 120. These semantics also allow the eCommerce service provider server 120 to send an updated service public key back to the merchant server 110.

A sample ECML registration data stream generated by the merchant server 110 and transmitted to the eCommerce service provider server 120 is shown below.
<ECMLv2.0>
<RegisterDataBlock>
<PublicKey>exp=00010001 !mod=490a579142e4562d868f6a9cc48fddac4 959ae8b54121ccad9db110a0ac4d6708c45571e4772f891ca211c045blaada Ob6e 1b4b450992a7714e8103296f74827</PublicKey>
<MerchantID>e3baf940216fc55154e16f10a9e0fa4cadcb6e318dad7ba55e ea850bf6d9e169aaf5e4515e85d26b325640e693accae755d3091a51e8b205 d9d 1 a 1 d 1 a8873109</MerchantId>
<HostAddress> 135.25.79.50</IiostAddress>
<Signature>Ofa9baf890d9cd967fa2552f231cb080c4be75bf91dblab3c547 62c975308021398d96c7fade12784d5e9900fd165efc0eddla28dad2944361 916a495b4d8954</Signature>
</RegisterDataBlock>
</ECMLv2.0>
In the above exemplary data stream, there is only one data block defined. The data block is the RegisterDataBlock. Within the RegisterDataBlock, there are four required elements: PublicKey, MerchantlD, HostAddress and Signature. PublicKey is an ASCII representation of the merchant's public key of the key pair generated by the ECML-based software component 112 at the merchant server 110. MerchantlD is a field that is encrypted with the eCommerce service provider server's public key. The Merchant 1D field contains the name of the Merchant. HostAddress defines the host 1P
address that the request is trying to register. Lastly, Signature is an encrypted SHA1 digest of the clear text version of this message.
For the service to accept any ECML-based software object as valid, two things are required. First, the service must be able to decrypt the MerchantlD field.
Second, the service must be able to validate the digital signature. Validating the digital signature requires the clear text representation of the MerchantlD field. This is used to retrieve the public key stored by the eCommerce server provider 120. If the public key cannot be retrieved, then the transaction is not processed, and an error is returned. If the public key is retrieved, then this is used together with the clear text of the ECML
message and the value of the Signature field to determine whether the signature is valid. If it is, then processing continues; otherwise an error is returned. If the service is able to successfully register the client, it will return the following message:
< ECMLv2.0>
<errorblock>
<numerrors>Odnumerrors>
derrorblock>
</ECMLv2.0>
If it is not able to successfully register the client, it will return errors, e.g.:
< ECMLv2.0>
<errorblock>
<numerrors>ldnumerrors>
<error-0>
<errnum>Oderrnum>
<errval>Invalid XML file: No bytes found in stream</errval>
derror-0>
</errorblock>
</ECMLv2.0>
Two data blocks are defined in this ECML response: an ErrorBlock and an Error-0 block. The Error-0 block is part of the overall ErrorBlock. The Error-0 block represents the details of the first error. Subsequent errors are numbered accordingly.
Thus, if there were two errors, a first error block would be Error-0 and a second would be Error-1. The Error-0 block contains an error code, called ErrNum and a text description of the error called ErrVal. This structure for representing errors is consistent for all ECML-based software object transmissions.
Also through registration, a merchant can register a new public key. However, the signature of the ECML-based software object including the new public key data is validated using the original public key that is stored at the eCommerce service provider server 120. Thus, if the signature cannot be validated with the original key, the new public key is not installed on the eCommerce service provider server.
In step 420, the eCommerce service provider 120 sets up an eCommerce service with a payment system gateway and the merchant server 110 architecture is configured. Thus, during step 420, such configuration allows the now registered merchant to set configuration options for his eCommerce store. Such options may include, for example, card authorization, settlement, shipping and tax procedures and data.
Control then proceeds to step 430. In step 430, a transaction is initiated.
Shopping cart information and credit card information is expressed in XML.
Control then continues to step 440. In step 440, the XML representation of the shopping cart and credit card information is sent over a network in HTTP to the eCommerce service provider. Control then proceeds to step 450. In step 450, the eCommerce transaction is processed for authorization after which control proceeds to step 460.
Processing an eCommerce transactions allows a merchant to submit an entire basket of goods to the eCommerce service provider service 120. The ECML-based software component 112 takes the state of a customer's shopping basket who is shopping at the merchant's eCommerce store and generates corresponding ECML data as the ECML-based software object 111. This ECML-based software object is then sent to the eCommerce service provider server 120 for processing. Such processing produces results as an ECML confirmation message, which contains both a result section and an error section. The ECML-based software component 122 makes the result variables, such as total tax, total shipping, grand total and any errors, available to the merchant's software via transmission over the network 130.
An ECML-based software object containing transaction data is utilized to send orders to the eCommerce service provider server 120. The response from the eCommerce S service provider server 120 includes calculation of the total of the order, including tax and shipping. Below is an example of an encrypted and digitally signed ECML
transaction generated by the merchant:
<ECMLv2.0>
<merchantdatablock>
<merchantid>Olcd7a86b6b94ablaa83ca440a23ea0390ba98076d5a964d0291e62 0818827b9e6da7ae77acaafef830fd779a6bda7e160fd210384d2edac2ef675898301 0641 dmerchantid>
<signature>38ba3c52d978dafd56ac170a82c6a4ced2bc74edb98cffdb7c2114b09b 30def045156e29bb7970e7055574b714624817b90d2f9287b0aff95e1b2f526599aa df</signature>
<transactionid> 1002443111 dtransactionid>
<currency>usddcurrency>
<testmode>true</testmode>
</merchantdatablock>
<shopperdatablock>
<shippingaddress>
<same_as_billing>true</same_as_billing>
</shippingaddress>
<billingaddress>
<fname>j ohndfname>
<lname>smith</Iname>

<addressl>307 any roaddaddressl>
<address2></address2>
<city>lincroft</city>
<state_province>njdstate_province>
<zip_postalcode>07738</zip_postalcode>
<email>any@ any.com</email>
<phone>888-111-2222</phone>
<country>us</country>
</billingaddress>
<cardinfo>
<type>3f637ba6b020266b48baeffa4955d92564ffecb98e37f905991 e44fae64f9f3c l3cca03b103c9a2f5b0148db361a53f0321032af19f17da2b7b2c3ca6b497f11 dtype>
<value>da6f1e3285ed3e720934527a5ccOf3660dd35ad93adlbcle9e2bd7981d717 231ccfd7de72b65f4000a11eeac99247dcd7cc5266e61bd8cabb6d78d63faadbf42 dvalue>
<expmonth> 11 dexpmonth>
<expyear>1999</expyear>
</cardinfo>
</shopperdatablock>
<transactiondatablock>
<action>buydaction>
<items>2ditems>
<item-0>

<name>test product</name>
<unitprice>25dprice>
<quantity> 1 </quantity>
ditem-0>
<item-1>
<name>test product</name>
<unitprice>25dprice>
<quantity> 1 </quantity>
</item-1>
dtransactiondatablock>
</ECMLv2.0>
There are three major data blocks defined for the all ECML-based software objects containing transaction data: MerchantDataBlock, ShopperDataBlock and TransactionDataBlock. MerchantDataBlock defines data about the merchant as well as configuration options for the transaction. ShopperDataBlock includes information about the customer. TransactionDataBlock contains data about the transaction that is being submitted to the eCommerce service provider server 120 for processing.
The digital signature validation is performed utilizing the clear text, the merchant's public key, and the value of the Signature tag. The encrypted values are created utilizing the service's Public Key, which allows a valid ECML server to decrypt the values and validate the signature.
The MerchantDataBlock is designed to provide information about the merchant, as well as provide a place for global processing configuration options. The MerchantDataBlock contains the encrypted merchant identification as well as the transaction identification sent to the service. There are four required elements contained within the MerchantDataBlock: MerchantlD, Signature, Currency and ShopperDataBlock. MerchantlD is a string used to uniquely identify the merchant to the system. This value is encrypted with the eCommerce Service provider's public key. It is always required.

Signature is an encrypted digest derived from the clear text version of the ECML
buffer. The value for Signature is automatically generated by the ECML object on the merchant server.
Currency is the abbreviation of the currency being utilized.
In UseTestMode, if the value is true, the merchant is allowed to send transactions that will not have a financial impact to either the merchant or a consumer.
Essentially, this means that the eCommerce service provider server 120 will not forward the transaction onto the financial institution server 170, but instead will return a predictable response that is used for developing and testing systems. The ShopperDataBlock describes the merchant's customer. This data is utilized to perform card authorization, address verification, set shipping options, set shipping destination and billing information. There are three sub-blocks contained within this block. These are:
ShippingAddress, BillingAddress and CardInfo.
The ShippingAddress block contains either all the required shipping fields:
fname - First Name Iname - Last Name address 1 - Street Address address2 - room or suite number - default is blank city state-province zip_postalcode email - default is blank phone country Or contains the field:
Same as billing set to true ' 24 The BillingAddress block includes the supported fields for BillingAddress. The Merchant must supply he fields without a default value when making a call via ECML.
fname - First Name lname - Last Name address 1- Street Address address2 - room or suite number - default is blank city state_province zip-postalcode email - default is blank phone country There are no size restrictions on the data contained in these fields, via the ECML
interface. The CardInfo block is designed for passing credit card data to the eCommerce service. The fields within the block include Type, Value, ExpMonth and ExpYear. The type field indicates the type of credit card being used by the customer, e.g., Mastercard, Visa, etc. The Value field indicates the number of the credit card being used by the Merchant. Both the Type and Value fields are encrypted. ExpMonth indicates the expiration month of the credit card. ExpYear indicates the expiration year of the credit card.
The TransactionDataBlock is designed for describing the details of the transaction. This block contains fields that describe the transaction and sub-blocks) that describe the items being purchased. At least one item is required for an ECML
transaction; an error will be generated if no items are found.
The required fields within the TransactionDataBlock include: Action and Items.
In the Action field, validate and buy are both valid values. The Validate value of the Action field instructs the eCommerce service to calculate tax, shipping and grand total, but not to attempt authorization of the credit card. The Buy value of the Action field instructs the service to calculate tax shipping and grand total and attempt to obtain an authorization of the transaction from a financial institution, configured for this merchant.
The Items field indicates the total number .of items that are part of the transaction. The determination of whether tax, shipping or other calculations are performed is based on configuration parameters set by the merchant directly on the eCommerce service.
5 The Items data block is numbered utilizing a zero-based index. Thus, the first item in the block is named: <Item-0>. There are two required tags for each item: Name and Quantity. The Name tag indicates the name of the product. The Quantity tag indicates the quantity of the product.
Some indication of price for each item is also required. However, this indication 10 can be provided by either a L3UnitPrice tag, which indicates the unit price of the product, or a TotalPrice tag, which indicates the unit price multiplied by the value in the indicated by the Quantity tag:
The eCommerce service has a standard response for transmission of ECML-based software objects containing transaction information from the merchant server.
A sample 15 response from the eCommerce service provider server 120 implementing the SecureBuyTM
service is shown below.
<ECMLv2.0>
<merchantdatablock>
<mcrchantid>www.xmlifc.com<Imerchantid>
20 <transactionid>649493743</transactionid>
</merchantdatablock>
<errorblock>
<numerrors>Odnumerrors>
</errorblock>
25 <merchandiseamountblocka <subtotal>50.00</subtotal>
<taxtype>SALES</taxtype>
<taxamountl>3.00</taxamountl>
<taxamount2>0<ltaxamount2>

<shipamount>S.OOdshipamount>
<total>58.OOdtotal> _ <receipt> 101100</receipt>
dmerchandiseamountblock>
<cardresponseblock>
<avscode>I3davscode>
<cardcode>100dcardcode>
<status>APPROVEdstatus>
<approved>true</approved>
<approvalcode>tntC00dapprovalcode>
dcardresponseblock>
</ECMLv2.0>
If data values are missing, servers are down, cards cannot be authorized, etc., the eCommerce service provider server 120 returns errors to the merchant server 110. The following is an example of a potential error return:
< ECMLv2.0>
<errorblock>
<numerrors> 1 </numerrors>
<error-0>
<errnum>0</errnum>
<errval>Invalid XML file: No bytes found in streamderrval>
derror-0>
derrorblock>
</ECMLv2.0>
Two data blocks are defined in this ECML response: an ErrorBlock and an Error-0 block. The Error-0 block is part of the overall ErrorBlock. The Error-0 block indicates the details of a first error. Subsequent errors, if present, would be numbered accordingly.
Thus, if there were two errors, the first error block would be Error-0 and the second would be Error-1. The Error-0 block contains an error code, called ErrNum, and a text description of the error called ErrVal. This structure for representing errors is consistent throughout all transmission of ECML-based software objects. Depending on the error, the MerchandiseAmountBlock and the CardResponse block may also be returned from the eCommerce service provider server, e.g., when the credit card was declined by a financial institution server 170.
The CardResponseBlock contains data specific to the results provided by the financial institution server 170 utilized to validate and authorize the credit card. An Approved field within the CardResponseBlock represents a summary of the card code field's numeric result.
The Status field provides the eCommerce Service Provider's recommended action. This value is either APPROVE or DECLINE. This is different from the Approved field, in that it combines the results of both the credit card authorization response and the AVS (Address Verification System) response. The merchant can configure the acceptable range of AVS responses for obtaining an APPROVE
result.
Thus, it is possible to have the credit-card-based Approved field set to true, and yet have the Status field recommend a DECLINE, because the AVS return code was not within the merchant's acceptable range.
In step 460, the transaction is settled and actual money is exchanged. Control then proceeds to step 470.
It is important to note that transaction response data values are important to the ECML settlement process, utilized by the ECommerce service providers. The Receipt field in the MerchandiseAmountBlock is the required key value to submit a transaction for settlement. The CardResponseBlock is not directly required for settlement;
however, a merchant can only settle transactions that have an Approved field value of true. Thus, even if the Status field recommends a DECLINE, the merchant can settle any transaction with a valid credit card authorization code. The result of the AVS does not directly impact the merchant's ability to settle the transaction. Once the merchant server receives transaction authorization using the transaction method steps, method steps for settling the authorized transaction are-performed:
The ECML-based software objects transmitted to perform Settlement allow the merchant to complete an order for which there is a valid online authorization.
The authorization gives the merchant the right to collect a specific amount of money when the goods and services are rendered. The authorization does not move money, but it does decrease the available credit of the card holder's account. The authorization will automatically expire in some designated time-period. The transmission of the ECML-based software objects is designed to allow the merchant to capture the funds that have been authorized. This happens after the goods or services have been delivered to the customer. Such ECML-based software object transmission also allows the merchant to submit returns for buyer credit.
The exemplary settlement request from the merchant server 110 shown below requires a valid MerchantDataBlock. This block contains the encrypted MerchantId and the signature for this transaction. The signature is created utilizing the clear text of this message. The clear text is the unencrypted MerchantId value and an empty signature tag set.
<ECMLv2.0>
<merchantdatablock>
<merchantid>37c2568eb6d3591534e0a9e6daa0972089cf9fbcd86b63326b298ff5 abd4bf18dd1fa11847486b8522646c52c5eef1dd3f79faab4badb2e72179bdd07f80c830dm erchantid>
<signature>1a59d663bec689bc4567d293d9dbb7d7ef96fb1049662cc7a79aefbac2 l2fce0f23ff2884c07dd31488426df85a5cc359c088df4dcd1ba411f161e1d458f9595dsign ature>
dmerchantdatablock>

' 29 <orderdatablock>
<order-0>
<orderid>PSJ9GGU1GKS 12GG700GPBK3655</orderid>
<action>CAPTURE</action>
<amount> 1.5</amount>
<currency>USD</currency>
</order-0>
<orders> 1 dorders>
dorderdatablock>
</ECMLv2.0>
The OrderDataBlock contains an OrderId returned as the Receipt field in the response generated and transmitted from the eCommerce service provider 120 in response to the ECML-based software object containing Transaction data. Each OrderId must have a valid authorization code, as explained above in relation to the description of the CardResponseBlock. There can be any number of Orders processed within a single transmission of ECML-based software objects related to settlement. The required fields in the OrderDataBlock are: Orders, OrderId, Action, Amount and Currency.
The Orders Field indicates a count of the number of orders in the OrderDataBlock. There is no limit to the number of orders that can be contained within the OrderDataBlock. The specific order tag utilizes a zero-based index. Within the order tag, a specific order can contain the following fields: OrderId, Action, Amount and Currency.
The OrderId field indicates the receipt value returned by eCommerce service provider server in response to transmission of an ECML-based software object containing Transaction data.
The Action field indicates the action to be performed for the order. Within the Action field, the following are the valid action verbs: CAPTURE, STATUS UPDATE
and CANCEL.

The CAPTURE action verb assumes that an authorization has been obtained and attempts to capture the funds. This action verb requires the AMOUNT field and the CURRENCY fields. A successful return sets the status for this transaction to the value of CAP BATCH.
5 The STATUS UPDATE action verb returns the current status information from the eCommerce service provider server 120. This information is utilized to determine when the transaction has been settled. If the status of the transaction is CAP
BATCH, then the eCommerce service provider server 120 queries a financial institution server 170 to determine whether the settlement batch has been run. If the batch is not complete, the 10 eCommerce service provider server 120 responds with a NO CHANGE. If the batch has completed, the eCommerce service provider server 120 responds with a COMPLETE
if the capture was successful. If the capture failed, the eCommerce service provider server 120 responds with a D DECLINE.
The CANCEL action verb cancels the order and requests a credit on the 15 customer's credit card if the order has settled. If the order has not settled, then it will attempt to void the authorization.
The Amount field is required when the Action field contains the CAPTURE
action verb. The value in the Amount field cannot exceed the value of the original authorization. However, it can be less than the original authorization amount.
20 The Currency field indicates the type of currency for the transaction.
The eCommerce service provider server 120 creates a response that contains an order status value for each of the orders submitted by the merchant server 110.
The following is an example of a service response generated by the eCommerce service provider server 120 to a settlement request by the merchant server 110.

<ECMLv2.0>
<errorblock>
<numerrors>Odnumerrors>
derrorblock>
<transactionresultblock>
<orders>2</orders>
<order-0>
<orderid>JCG9GGU 1 GKS 12GG700GPBK3655</orderid>
<status>NO CHANGEdstatus>
</order-0>
<order-1>
<orderid>CVG9GGU 1 GKS 12GG700GPBK3655</orderid>
<status>CAP_BATCH</status>
</order-1>
dtransactionresultblock>
</ECMLv2.0>
The TransactionResultBlock is returned from the eCommerce service provider server 120 after a settlement request from the merchant server 110 has been processed.
Each processed order contains a block and the status of the order. The status represents the status of the order at the eCommerce service provider server 120. If the value of the status field is NO CHANGE, then the status of the order at the merchant server 110 and the status of the order at the eCommerce service provider server 120 are the same. This is a typical response when a merchant side application is polling the eCommerce service provider server 120 to determine when a transaction has settled.
The TransactionResultBlock includes an OrderId field and a Status field. The OrderId field indicates the value that was returned by the eCommerce service provider server 120 as the Receipt. The Status field indicates the result of the request for this order. Return values can be: NO CHANGE, CAP BATCH, COMPLETE and D DECLINE.
The NO CHANGE return value indicates that the data at the merchant server 110 and the data at the eCommerce service provider server 120 are consistent.
Therefore, a requested action has not completed. The CAP BATCH return value indicates that the transaction was put in the Captured state and made available for the next batch settlement run. The COMPLETE return value indicates that the transaction has been processed and the dollar value has been successfully moved into the merchant's account. The D DECLINE return value indicates that the transaction has been posted in a settlement batch, but has failed.
In step 470, the method ends.
While this invention has been described in conjunction with the specific embodiments outlined above, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, the preferred embodiments of the invention, as set forth above, are intended to be illustrative, not limiting. Various changes may be made without departing from the spirit and scope of the invention.
Preferably, ECML is a generic framework that uses XML vocabulary. However, the vocabulary can change on each ECML-based software object. Although there is a finite vocabulary, a vocabulary subset can change. However, the present invention may be implemented without using XML. For example, the present invention may be used with a proprietary data protocol instead of HTTP. It is foreseeable that merchants will soon be able to design their own software objects. Therefore, it should be appreciated that the benefits of the present invention are not based solely on the use of XML.
While the present invention has been described with reference to specific illustrative embodiments, it is not confined to the specific details set forth, but is intended to cover such modifications or changes as may come within the scope of this invention.

Claims (20)

1. ~A method for providing eCommerce services, the method comprising:
generating a software object;
formatting the software object;
digitally signing using a digest of clear text of data within the software object;
encrypting at least one field within the software object using public key cryptography;
passing the software object across an unsecured network between a merchant server and an eCommerce service provider server; and processing the software object by the eCommerce service provider server;
wherein both the merchant server and the eCommerce service provider server are identified prior to the step of processing the software object by the eCommerce service provider server.

2. ~The method of claim 1, wherein an XML-based markup language is used to format, digitally sign and encrypt the data stored in the software object transmitted over the unsecured network.

3. ~The method of claim 2, wherein an XML-based markup language provides a format for transmission of the software object by establishing a definition for structuring data rather than a definition for all data elements.

4. ~The method of claim 3, further comprising processing data within the software object and generating a modified software object and transmitting the modified software object to the merchant server via the unsecured network.

5. ~The method of claim 3, further comprising generating and transmitting a software object containing an eCommerce service improvement to the merchant server, wherein at least one new data element is added to eCommerce service software resident on the merchant server via the transmission and processing data contained in the software object containing the eCommerce service improvement.

6. ~A system for providing eCommerce services, the system comprising:
an eCommerce service provider server including a first software component and a first XML processor;
a first link coupled between the eCommerce service provider server and a publicly accessible packet-switched network;
a second link between the eCommerce service provider server and a private network;
wherein the eCommerce service provider server receives software objects, generated by a second software component by request of a second XML processor at a merchant server, from the merchant server via the first link and the publicly accessible packet-switched network and wherein the first software component generates a modified software object at the request of the first XML processor and the eCommerce service provider server transmits the modified software object to the merchant server via the first link and the publicly accessible packet-switched network.

7. ~The system of claim 6, wherein the second link is coupled to a firewall within the private network and the firewall is coupled to at least one financial institution server.

8. ~The system of claim 7, wherein a state of the software object is transmitted from the merchant server to the eCommerce service provider server and subsequently transmitted by the eCommerce service provider server to the at least one financial institution server.

9. ~The system of claim 6, wherein both the first and second XML processors read XML documents and provide access to the content and structure of the XML
documents.

10. The system of claim 9, wherein the second XML processor at the merchant server works on behalf of at least one application resident on the merchant server and the first XML processor at the eCommerce service provider server works on behalf of at least one application resident on the eCommerce service provider server.

11. The system of claim 10, wherein the first software component validates the software object transmitted from the merchant server and instantiates a local software object on the eCommerce service provider server with the internal state of the software object.

12. The system of claim 11, wherein the local software object at the eCommerce service provider server assumes a data state of the software object received from the merchant server.

13. The system of claim 11, wherein the local software object on the eCommerce service provider server calls new software objects to add new features.

14. The system of claim 1 l, wherein the local software object on the eCommerce service provider server calls additional servers to distribute functionality throughout multiple servers.

15. The system of claim 6, wherein when the first software component processes data contained in the software object transmitted from the merchant server, the first software component obtains transaction authorization from at least one financial institution server over the second link.

16. The system of claim 6, wherein the second link is a secure network connection.

17. The system of claim 6, wherein a format of responses transmitted from the merchant server and from the eCommerce service provider server are in XML.

18. The system of claim 6, wherein at least one f eld of the software object is encrypted using public key cryptography.

19. The system of claim 6, wherein the software object is digitally signed prior to transmission of the software object to the eCommerce service provider server.

20. The system of claim 19, wherein the software object is digitally signed using a digest of the clear text of data within the software object.