WO2001001300A1 - An internet e-commerce system - Google Patents

Abstract

An electronic commerce system comprising: a series of point of sale terminals providing for point of sale information handling of a business; an interconnection network interconnecting the point of sale terminals to a central database facility; a central database facility for storing information about each of the businesses for access by the operators of the point of sale terminals; and a series of service providers interconnected to the central database facility for meeting requests issued by the point of sale terminals.

Description

An Internet E-Commerce System

Field of the invention

The present invention relates to the field of Internet electronic commerce and. in particular, discloses a hybπd e- commerce system having increased levels of functionality and operabihty Background of the invention

Traditionally, businesses have carried out activities utilising many different forms of communication For example letters, faxes and. more recently, e-mail have been traditionally used to place orders for the goods and services of a business

Recently, the Internet has been undergoing an explosive growth period In particular, the "World Wide Web" has provided a new avenue for the conduct of commercial transactions This has lead to the concept ot "E-commerce" in that commercial transactions can be earned over the Internet so as to facilitate a more optimal form of business operation In particular it allows the direct selling of goods over the Internet from the producer to the consumer

However, the utilisation of the World Wide Web often requires a high level of skill in the creation of HTML pages Java scnpts etc . in order to create appealing and attractive web pages having a high level of functionality Additionally, a large number of different programs and hardware are often required For example, browsers e-mail programs, fax machine or tax software, a HTML editor, an ftp program etc

Further, commercial business arrangements also often require separate Electronic Funds Transfer Point of Sale facilities for the conduct of sales transactions which are often totally separate from any Internet services

As a result businesses, in particular, small business, tend to have a reduced uptake of Internet type operations

Summary of the invention It is the object of the present invention to provide for an E-commerce system having advantageous attnbutes

In accordance with a first aspect of the present invention, there is provided an electronic commerce system compnsing a seπes of point of sale terminals providing for point of sale information handling of a business, an interconnection network interconnecting the point of sale terminals to a central database facility, a central database facility tor stonng information about each of the businesses for access by the operators of the point ot sale terminals, and a series of service providers interconnected to the central database facility for meeting requests issued by the point of sale terminals

Preferably, the system also comprises a senes of suppliers interconnected to the central database facility for meeting requests issued by the point of sale terminals The suppliers can include at least one of an import/export agent, a warehousing agent or a producer The service providers can include one of a third party information vendor providing information upon request, a financial transaction vendor providing financial transaction authoπsation upon request, or an order fulfilment vendor providing order fulfilment upon request The point of sale terminals can include local database information and programs which are preferably downloaded on demand from the central database facility

Access means for accessing the datastore as a member of the general public using a web browser and further means for communicating in a timely manner directly to the Point of Sale merchant and if that merchant can be there then communicating with the merchant in actual time The requests are preferably tranmitted in the form of XML documents or the like to and from the central database facility The request implementation structure can be preferably provided by a software development kit applications programming interface

Substitute The system can also include a series of user mobile data entry devices which interact with the point ot sale terminals in the authonzation of a transaction The mobile data entry device can include one of WAP enabled phones, mobile phones or bluetooth connected devices

Ideally, there is also provided a separate interaction unit such as a Web Browser for users to interact with the central database facility for the viewing of transaction statistics associated with the system The viewing of transaction statistics preferably can include utilising OLAP facilities on the central database

Actions undertaken by the database facility are preferably in the form of workflow steps executed by the facility with the workflow can be spawned by the template structure of the request There can also be provided an interactive graphical database for interacting with the central database facility In further modified embodiments, multiple centralised database facilities are preferably peered and interact with one another to pertorm functions

Brief description of the drawings

Notwithstanding any other forms which may fall within the scope of the present invention, preferred forms ot the invention will now be descπbed by way of example only, with reference to the accompanying drawings in which Fig 1 illustrates schematically the arrangement of a first embodiment,

Fig 2 illustrates the production of workflow in accordance with the first embodiment.

Fig 3 illustrates the process of execution of transactions by a merchant/consumer and IWN engine anangement.

Fig 4 illustrates an alternative arrangment of an embodiment of the invention.

Fig 5 illustrates the vaπous structures in an embodiment of the invention Fig 6 illustrates the carying out of transactions in accordance with an embodiment of the invention, and

Fig 7 illustrates one software architectural structure ot the IWN engine

Detailed description of the embodiments

In the first embodiment, an interactive system is provided for carrying out business transactions over the Internet in a simplified and automatic manner The transactions can include electronic ordenng and distnbution. web site generation and on going maintenance, proactive interaction such as faxing, e-mail and electronic funds transfer Further, the system allows business clients to maintain their own database and allows dynamic access to accounting procedures and management information systems including EFTPOS transactions

Turn to Fig 1. there is illustrated schematically the overall operational environment of a first embodiment The first embodiment 1 is denoted the IWN network and includes vaπous entities interconnected over an Internet environment 2 The elements communicate with one another using XML messaging and CORBA (common object request broker) CORBA is a general purpose communication protocol that allows transparent communications over a network That means that the network is invisible to the development programmer m that they program as if the network is not there

The object onented communications model is used for application interfaces within IWN engine pnvate processes For example, the IWN server cleaπnghouse 30 requests transaction authorisation from a Payment Engine 36 via a CORBA RPC (remote procedure call) The architecture allows distnbution of objects over the network Objects can be wntten in one language (say Java) and referenced using another (say C++) A seπes of java applets and servlets on the web server provide references to objects on other servers through the

CORBA communication interlace The local client entities e g 40 can be configured to run Java applets over an Internet browser type environment such as that provided by Microsoft's Internet Explorer or Netscape s Netscape Navigator

Alternatively, they may be a permanent Java application, integration into a third party point of sale or accounting package, or a currently hardware ot software device

Each of a seπes ot client side elements 41 - 44, 40, 34, 51 , 52 interact with an IWN engine cleannghouse 30 which operates as a cleannghouse for operations The flexibihtv of the arrangement allows tor there to be a client and server relationship in all cases (even when only one machine it is client and server on the same machine) The client has a reference to the server, but the client knows no difference between the local reference and server, as CORBA encoding allows for the whole system to operate in a transparent manner

The IWN engine cleannghouse 30 serves as a XML and CORBA switchboard for the entire system As noted previously, it consists of an message conversion engine 45. workflow repository 46. data object store 48 and a transaction- processing engine 47 The Cleannghouse interacts with all external entities via open protocols such as XML and WML, and internal entities via CORBA CORBA provides a high performance, yet scalable and open infrastructure tor IWN engine components to interoperate Rather than a purely peer-to-peer or purely centralised communications model. IWN engine operates in a hybrid manner The data object store 48 can compπse a relational database and OLAP(On line analytical processing) engine suitable for handling dynamic real-time E-commerce transactions and the OLAP of those transactions

The XML engine cleannghouse 30 provides a core clearinghouse application which interacts with a seπes of peπpheral applications These include a consumer front end ASP 31. a merchant terminal 32, a merchant partner web frontend 33, an eCommerce brokerage type operation 34, general Internet access 35, a payment engine 36 and a messaging engine 38

The merchant terminal can compnse a point of sale (POS) terminal running via a browser 40 for operation by a merchant This terminal can compnse java applets for allowing the terminal to connect to the IWN network by means of a TCP/IP interconnection This component can be deployed to traditional POS developers as a "developers kit" which they can integrate to a greater or lesser degree into their software, to enable their users to connect to the IWN network The POS terminal provides a facility for small to medium sized businesses looking to establish an ecommerce presence In its simplest form, the POS terminal offers a way to clear plastic and cash transactions via the Internet, superseding traditional EFTPOS However. NetPOS also allows Enterprise Resource Planning (ERP) point of sale, accounting, inventory management and order fulfilment to browsers. PCs. NCs (Network Computers) and NC based cash register networks 41 -44

Instead of utilizing point-to-point propnetary communication associated with EFTPOS. the system uses the ubiquity of the Internet to cany out transactions Technically, the relevant API can be implemented as a Java or VB based software application that uses encrypted Internet communications to exchange XML RPC with XMLMarket application services, with, for example, the IWN engine cleannghouse 30 The consumer webfront application service 31 automatically generates an Internet website presence for IWN engine or client's merchants using the information exchanged by devices on the IWN network The website is a virtual representation of the business, autonomously reachable on the Internet Consumers can use the website and make purchases without any kind of prior association with an IWN engine cleannghouse 30 Integration between the POS and website transactions via the IWN engine clearinghouse 30 creates a seamless order entry and fulfilment process

The merchant/partner webfront application service provider 33 is provided to deliver the information to users of the IWN network through any (compliant) World Wide Web browser connected to the Internet Apart from cateπng to the smallest enterpπses. the merchant/partner webfront ASP provides mobility, deployabihty and rapid growth capability to businesses of

Substitute Sheet Both the consumer and merchant/partner ASP are designed to enable conversion of the data to any format, so as to enable it to be viewed on ANY device de mobile phone, web TV, PDA. kiosk etc)

A brokerage facility 34 links websites together in a virtual community The system enables the products of all merchants in the community to be quened in a consistent manner and provide for consumer dnven quenes which aggregate the data For example the customer can specify the product and pπce desired and the database will query all merchants to match the request Consumers expenence a shopping environment, consistent across all vendors within the IWN exchange system

Conversely, other eMalls can present IWN engine generated information or web sites

Business to business functionality enabled by IWN engine also allow merchants to collaborate tor competitive advantage with their major suppliers IWN engine eMall consumers enjoy an overlay or meta-search engine capable of finding products by multiple cnteπa across multiple vendors This is due to the fact that they are able to query not only the IWN engine held by the local client, but also nodes from all over the world

User, connected by devices and in some cases specifically through browser sessions, are typically only connected on a permanent or semi-permanent basis using low speed lines, whereas the cleanng house can be full time connected with high bandwidth, redundant Internet links Components like the POS devices 40 and brokerage services 34 task the IWN engine 30 which means they can leverage its permanent, high performance capability The IWN server cleannghouse contains the business logic (descnbed hereinafter) required to initiate and complete transactions, and can interact with any device which transmits standard message formats such as HTML, WML, XML, IMAP etc and is connected to the Internet It also frees the devices from the requirement to manage multiple connections to multiple parties

Funds transfer within the system is managed a Payment Engine 36 One of the banners to entry of the existing EFTPOS networks into eCommerce/Internet markets is the propnetary nature of the protocols involved It is difficult to either effectively integrate these protocols with the more modern worldwide web paradigm into the SME environment, or for the existing financial institutions to develop an alternative to the Internet XMLMarket merges XML and EDIFACT. (and other standards) by front ending the vaπous propnetary financial networks with an IWN engine

All IWN network process-to-process communications can take place predominantly on top of the TCP/IP protocol suite The IWN network preferably conforms to all relevant RFC and (where applicable) ISO standards

IWN engine is designed to mteroperate with the widest vanety of organisations possible To this end. the extensible Markup Language. XML. is often used to encapsulate all system-system transactions XML provides a self-descπbing document paradigm, these documents are transmitted via HTTP using the XML RPC (XML Remote Procedure Call) standard

Whenever sensitive or financial data is being transmitted. IWN Engine HTTP application servers uses the Secure Sockets Layer (SSL) protocol to encrypt the data stream SSL provides strong encryption to protect the data in transit Participants in the market are pre-screened (to varying degrees depending on their user group) before admission, and authenticated using a non-propnetary protocol such as the RADIUS protocol Using RADIUS ensures a standards-compliant approach to person-to-business authorisation, and transparently provides the option of using strong cryptographic techniques like challenge-response or one-time password algoπthms In business-to-business transactions, X 509 certification is used to authenticate automated users transactions, which are also SSL encrypted X 509 certificates are now available from a number of authoπtative sources both internationally and domestically IWN network centralised and distnbuted subsystems are protected behind industry standard ICSA

The topology in which IWN network distnbuted subsystems are deployed for a given region is dependent on demand, bandwidth availability and commercial agreements From a purely technical perspective, there can be a minimum of one and an arbitraπly unlimited number of each of these distnbuted processing units This provides for extremely large-scale deployments.

S and retains the ability to deploy in a locally customised fashion where geographical, technical, commercial or political constraints apply There are three major distnbuted subsystem oπentations, namely customer, vendor and service

The brokerage WebFront 34 provides a meta-layer on top of arbitrary groups of IWN engine merchants An IWN engine brokerage differentiates itself from other web-mall offenngs by -Otfeπng consumers a consistent shopping metaphor overlay, visually consistent across vendors This is achieved by overlaying a consumer shopping interface with communicates with any IWN engine compliant merchant

-Single transaction payment services across vendors

-Cross- vendor searching and compaπson (at the vendor's discretion)

-The ability to integrate with and search other popular eMalls in the event of an unsuccessful search -An arbitrary number of eMalls across an arbitrary number of vendors

The IWN engine shopping experience features a customer service window tailored for shopping Services include gift tokens, lay-buys, recommendations, favounte merchants, and so on The consumer interface travels with users regardless of the vendor entered This consistency builds trust, and thereby consumer confidence A variety ot mall concepts is envisaged with visual, audio and product placement scenaπos tailored to target markets Workflow operations

The overall operation of the system can be as follows

1 Transaction enters the system from a remote device

2 The network processes the request via its IP address and routes it towards the IWN system

3 The IWN system identifies the request using either "tags" in the messaging format (messaging formats may include XML. WML. HTML), IP address, or the port on which the message was received

4 The IWN system then

(a) Identifies workflow implicated by the transaction and begins to execute that workflow.

(b) Converts the message into a consistent IWN XML DTD to enable the workflow to execute

(c) Stores relevant information in the datastore (d) Forwards messages to appropπate parties

In many cases "persistent processes may be frozen in the system to be fulfilled at a later date

The IWN engine cleannghouse 30 is directly connected to specific providers that are able to fulfil order requests, third party information vendors able to provide information, and service providers that are able to carry out financial transactions such as credit card transactions or the like 36 Also interconnected to the IWN network are suppliers who receive requests for goods, import export agents, warehouse storage facilities and producers Thereby, the IWN Network is designed to handle logistics and inventory management as well as information about business relationships etc

The data/object store is mtenogated by at least five different sets of user groups (Using the OLAP interface), including web base users, point of sale (NETPOS) users 3-6. product mediators 20-22 and product producers 23. consumers, and the client (telecommunications company or bank) When it is desired to query the database, an OLAP interface carπes out a database transaction, returning the results of the query

Substitute Sheet In modified embodiments, the number of servers 30 can be replicated IWN network can then include a seπes ot servers and can be thought of as a seπes of nodes of different sizes There may be one or several network operations centres housing all the applications and a master data-store There are then the client nodes, which are a local replication customised to a demographic and/or political and/or geographical and/or legislative region These users may be a retail point of sale system, or a larger corporate client

The global portion de either the main network or a node situated at a 'client") is differentiated in that all data can be collated and made available through the application server as single source for output in various forms such as HTML, as well as other relevant forms (XML. CMI. WML VRML. SHTML, php. pwp, java objects, etc)

The IWN network is regarded as distnbuted because clients have relevant and alterable data nodes local to their machines Hence relevant local and global database updating is required The IWN network is dynamic because one local or global alteration might create several internal network related operations The local server receives requests from its local user which will either be on the same machine or though the user's local network The server will then either get the information from its local data store or download it from the IWN server The user is able to simply request certain information and the server checks us cache if its there and returns it or otherwise downloads it from the application server (if available) and return and object representing the data

The local components are only relevant to an individual user and or user peer groups and is a subset of the larger client database s Local portions are regarded as local because the portion is local to the user's location

There is one major authoπtative store of information in each region in the servers data object store Non global information (like faxes etc) can be independently stored The global portion has the largest subset of information which is ot interest to customers of clients or client peer groups (for example, \anous on-line web shoppers)

A smaller subset of IWN network information is relevant to a user peer group, and an even smaller subset is of interest to a user The global portion of the IWN network is kept up to date by peπodically up loading local information (this is done when needed, for example, after local alteration) The NETPOS data can be implemented having wπte through capability meaning that when a data update is requested by a NETPOS terminal the data will go straight to the main data source (if available) not just the cache The global portion of the IWN Network also processes information and passes it back to the client, in order to update their local database (again done when needed, for example, after customer alteration) Users access the IWN network using an interface which performs all tasks local to the user The XML engine 46 runs the quenes and return the results to the request source, either the web server or the POS server

The Following Automatic Functions can also be Provided (a) Web page creation and on-going maintenance

The client is able to change a vaπable in their inventory management system locally This in turn automatically updates the global portion of the IWN network which automatically alters relevant web page elements An example is a change of price on the local machine which is then reflected on the web site

(b) Ordeπng and order fulfilment The IWN Network has the functionality to allow point to point real time order fulfilment by facilitating catalogue maintenance (though the inventory system dynamically updating the pπce and the availability of the products) and offeπng direct connection to a third party order fulfilment client (such as FedEx) This includes the ability to set multiple relationships for each customer For example supplier A may set different terms of payment and delivery for each customer The user interface will communicate this order fulfilment cnteπa and will establish and maintain relationships with each customer Each user will also have the option of setting automatic re-order points There re-order points can be set to tπgger the dynamic and

Substitut continual maintenance ot inventory levels in the client s enterprise The main advantage of this order fulfilment system will be its dynamic nature, for example a customer quenes the central database and assuming availability of the product, results in the order lodgement simultaneously with the order fulfilment client and the product client The result will be a dynamic update of the level of inventory in the central database (c) Accounting

By utilising the combination of inventory levels with supply side transactions (any transactions involving the movement of goods or services for a whole-sale pnce, 1 e , between clients) and demand side transactions (with a customer) the

IWN network has the capacity to provide summary information about the financial position of a client in real time These reports will be displayed in a number of ways and in accordance with the accounting conventions of the geographical area It will focus particularly in profits by item type and by supplier (which is a client)

(d) Customer information systems

By providing basic information about a customer and also about any on-line customers who purchase a show interest in products, the IWN network is able to give the various user groups (Merchants, clients, and consumers, etc) information about demographic factors of their customer base Using OLAP technology enables unlimited number of views of the data, and resultant queries It also allows them to track the habits and preferences of consumers and uses intuitive search mechanisms of the network to build personal relationships with the consumer For example by tracking what a consumer has bought it may suggest other related items or similar items by the same supplier The key aspect here is that the data can be viewed and modified by the user s customer representative An application of this is the ability to transact with the on-line customer via chat and other communication means to give detailed information to the on-line customer This is all done directly from the users local IWN network interface

(e) Management information systems (particularly inventory)

The IWN network will enable a variety of management information quenes to be parsed to the user An advantage is that the user is able to access information in real time and access information for the local database which has been entered globally This includes order fulfilment information, information regarding the use and transactions on-line, and all this in combination with traditional point of sale data

From the user s side, the difference is that the information once entered in the local database then periodically updates the global database without any proactive re-enteπng of information

The Proactive Functions

The following proactive functions can be provided (a) Basic daily transactions and electronic funds transfer

While the transactions are all being entered in at the local (clients) level, they are also being periodically updated to the global database without being re-entered This allows the information (local data) to have secure back-up

The establishment ot a secure virtual pnvate network (VPN) will then allow for the free two way transmission of data wherein the local client is able to be updated by the application server of the global database when quenes are made to any particular credit veπfication entity

Traditionally, funds transfer from the point of transaction (being a retail store, home-office, or back office etc) has been handled by a hardware device commonly called an EFTPOS terminal Using a compliant point of transaction system, the user is able to clear a transaction directly through their PC without additional hardware For example, the attached appendix

Substitute She sets out a point of sale development tool-kit (SDK) called IWNcom which enables transmission of data from a traditional PC to the IWN network for clearance The data is descπbed in a DTD and thus open to inclusion in a data-store

The IWN Client SDK (Software Development Kit) is designed to enable third party to integrate their device or applications to take advantage of the IWN network functionality These SDK^'s can be Java constructed and hence can readily be ported to the following devices Windows 95. Windows 98. Linux. Windows 2000. Mac OS. PalmOS. WAP compatible devices. Java Compatible devices. Smart Cards, and Java Cards

The fundament concept behind the SDK is that it initiates a common set of network level communications, secunty management, session management, and then transactions over this secure session Transactions may include (but not limited to) 1 Financial transactions, debit and credit

2 eCommerce transactions (purchasing of products, supply of products etc)

3 Content based information (such as audio and video streaming etc)

4 Bill presentment and payment

5 Electronic ticketing 6 OLAP and other reporting

7 Service provisioning and management (le activation of new services, termination of services)

8 Smart card re-charging

9 Device management related transactions (such as fault reporting etc)

Technically, the SDK has three layers Communications. Network Secunty. and data transmission The communications layer will typically initiate a network connection , detect status of that connection, and respond to vaπous events relating the connection The secunty layer will establish the validity of the user, establish the validity of the server .and then establish a secure connection between both parties It may use SLL, DES. TLS. and other encryption and secunty processes and protocols

The most complex layer is the data layer, which translates information about the client device, and actions on the client device , into a standard document (usually XML or WML documents) for transmission over the secure network Information in this document may include information regarding a merchant, consumer, device, products, services, pπces. geographical, loyalty

The client is able to send/receive e-mail using the same interface they use tor point ot sale transactions and all other group one or two functions

(c) Fax 52

The client is able to send receive faxes using the same terminal These faxes are sent to the IWN network at which point they are distnbuted to the appropriate recipient Incoming faxes enter the IWN network and are filed using incoming CLI records (d) Accounting

Substitute Sheet The client is able to input accounting information and change the pπce of any resource be it labour, stock item or other and this information is peπodically updated to the IWN network Once in the database it can be selectively used for designated areas of the clients web site

(e) Customer Relationship Management The user (local NETPOS terminal user) is able to input customer details and these are updated peπodically to the global database for later retrieval if necessary The local database can draw a seπes of summary reports from the global database or selected information can be stored locally Traditionally these queries are refeπed to as CRM quenes

(f) Management information systems(MIS)

A user may take the CRM information and organise it in such a manner as to enable business rules which are particular to their organisation In such a case they have facilitated a MIS system

(g) Order and order fulfilment

The ability to manually enter an order and then have that order updated to the global database to be later verified and placed and then confirmed or alternatively confirmed immediately

Vendors also uniquely gain synergistic connections with other IWN engine vendors T rough IWN engine, vendors can take advantage of shared warehousing and freight facilities, and economies of scale that they would otherwise not enjoy Essentially a vendor can automate their production chain using IWN engine as the glue This can be facilitated in two ways

1 The IWN engine connects to suppliers directly

2 The IWN client uses established B2B infrastructure and relationships to connect to suppliers An example is if a telecommunications company or Banking institution has a B2B system which communicated via EDI to a motor car company IWN engine would simply connect to the m-house application rather than establishing a new connection to the car company

Although logically one subsystem, the POS interface can be deployed in three distinct configurations A NC Cash Register Svstem 41. standalone NC/PC system 42, and Merchant Partner WebFront ASP 43

Essentially, the IWN server cleannghouse 30 can be unaware of client system topology and the decoupling provided by open standards ensures infinite possibilities for presentation/topology of POS systems into the future The first two cases. NC Cash Register System 41 and Standalone NC/PC System 42 can be identical technically, diffenng only in the number of processing units at a customer premises Inventory, pπcing and other operational data is stored locally Transactions (in both directions) will initially be made using XML, and peπodic reconciliation transactions can be performed to ensure convergent views of data at both the clearinghouse and distnbuted locations In the case 40 where a Merchant Partner is connected using a web browser rather than a dedicated piece of hardware.

POS view of is deployed as the Merchant/Partner WebFront ASP 33 The local data for this vendor can be stored within the Merchant/Partner WebFront ASP 33, however this is completely transparent to both the user and the IWN server cleannghouse The Merchant/Partner WebFront ASP 33 communicates with the IWN server cleannghouse 30 precisely as if it was an NC Cash Register System 41 or Standalone NC/PC system 42 utilising the attached SDK protocol In all cases, the WebFront provides all required functionality to run the point of sale, inventory, order fulfilment, debtors, and creditors functionality ot a SME merchant/partner Offline contingency capabilities can be provided in the case of dedicated hardware/software

In some embodiments, a merchant may already be committed to a particular application that cannot interact with XML. and therefore IWN network Reasons for this can include

Substitute Sheet - A closed, proprietary application forces duplicate data entry to other entities

- The application vendor is not yet committed to XML for business-to-business integration

- Overwhelming market share by a vendor forces a de-facto standard

In order to overcome anv reluctance to adopt the XMLMarket system, legacy applications 44 can be incorporated into the overall system by deploying a developers kit enabling third parties to develop IWN network extensions to their products creating IWN network Extended Applications dEAs) Such an anangement assists in building a critical mass until XML (or subsequent standards) become a common feature of ERP software

In an IEA. the functions of the Vendor WebFront are be adapted to the legacy application Inventory, pricing and other operational data can remain stored locally within the application Vendor Webfront transactions (in both directions) are made in (at this stage) XML with the IWN server cleannghouse 30 and periodic reconciliation transactions are performed to ensure convergent views ot data at both central and distnbuted locations To the IWN server clearinghouse 30. the iEA behaves precisely as if it was an NC Cash Register System 41 or a Standalone NC/PC system 42 IWN network extensions are simply used to eliminate redundant data entry, and to ensure synchronisation between the application and the IWN server cleannghouse 30 The IWN Network Extended Application provides all the required functionality to synchronise the point of sale inventory, order and fulfilment functionality of a merchant/partner Offline contingency capabilities are not provided by IWN network, that is they must be provided natively by the legacy application itself

Payment Engine 36

Cuπent technology for funds transfer, transaction cleanng. micropayment services and alternative electronic forms of cash often remain propnetary, non-standard, costly, and difficult to implement Generally banks and credit providers insist on propnetary physical links with propnetary communications protocols and proprietary POS terminals Over the Internet, there is cunently little improvement with the norm being propnetary technologies, uncertainty, lack of standards and rapid change One of the major hurdles a small to medium sized enterpπse (SME) faces in establishing a web-presence is the requirement to solve all of these problems and to re-implement a financial transaction mechanism Often. SMEs generally do not have the financial wherewithal to achieve this, resulting in a major barner to eCommerce adoption The IWN network solves this problem b\ abstracting the interface to multiple financial institutions and other payment transaction enablers via the Payment Engine 36 This subsystem provides a CORBA interface to the IWN server cleannghouse 30 through which all funds transfer, credit authoπsation. sales transactions and merchant payments and receipts can be processed The Payment Engine 36 connects to the vaπous financial organisations via the multiple propnetary mechanisms and point to point links, and is able to leverage higher bandwidth connections and better transaction rates due to economies ot scale Financial transactions are simply another form of XML RPC. earned out using SSL encryption and authenticated with X 509 certificates and processed by the IWN server cleannghouse 30 Vendors enjoy significant benefits from this approach, including economies of scale, the ability to adapt to new technologies immediately, automatic transaction dissection and settlement across vendors, and of course, most importantly simplification Because the IWN Network paradigm is holistic, then this provides the ability to offer vendors differentiated pπcing models for transaction clearance and participation

In the case where a "Client" has already owns a payment engine (such as the Nobil Gateway produced by Keycorp). the IWN engine can talk directly to the resident payment engine as apposed to the financial institutions

Messaging Engine 38

Participants in any market require notification, confirmation, information and communication, between consumer and vendor, vendor and vendor, and consumer and consumer Traditionally, this type of messaging was earned out by telephone

S and post, and more recently by manual facsimile However, the three cπteπa for effective messaging are timeliness, authenticity and convenience Telephony provides low authenticity and convenience tests, post provides low timeliness, and manual facsimile can provide low authenticity

The IWN Messaging Engine 38 provides the IWN server cleannghouse 30 (again through CORBA) with instant capability to generate a message request to any number ot participants Initially. Email 51 and automated facsimile 52 may be provided Over time, IWN network can introduce further services such as paging, voice synthesis and wireless notification services All notifications can be seπahsed and time stamped, allowing a recipient to veπfy message authenticity as required Email messages can be digitally signed where financial concerns exist Finally, participants will be able to nominate prefeπed mechanisms for contact/notification, increasing the convenience level of the system As a result, users will enjoy the convenience ot integrated messaging from a single point

IWN server clearinghouse 30

As noted previously four major conceptual components forge the IWN server cleannghouse Application System Architecturally, the glue between these components is pnmanly the Common Object Request Broker Architecture (CORBA) CORBA provides the flexibility required to implement a scalable solution at a single point, the IWN server cleannghouse mav run on a minimum ot one CPU. or may be distnbuted over multiple CPUs and multiple devices If necessary, the IWN server cleannghouse can be a singular entity for a given IWN eXchange, and multiple Exchanges can seamlessly interact using XML RPC The most immediate consequence of this is that inter-market e-fulfilment chains are entirely possible A worldwide chain of IWN exchanges serving country or continental regions can then be constructed, permitting global shopping with local supply The cleannghouse elements include Data/Object store 48

The foundation of the IWN server cleannghouse 30 is a large scale relational database management system with an object oπented paradigm overlay Consumer and vendor information is stored safely and securely within the Data/Object store 48. and is subject to inherent encryption and access control facilities Database design can accommodate international, multilingual information, incorporate audit trails and implement two-phase commit technology ensuπng reliability of transactions Vendors, participating as merchants or partners can maintain their own local data stores These can be bi-directionally synchronised via XML with the Data Object store Because the Data/Object store is relational. IWN network otters deeply flexible reporting and analysis opportunities to participants

XML Engine 46

XML can be the pπmary messaging service used in the system As such a component which addresses this component is part of the architecture As new standards develop, this engine will be extended to include emerging standards One of the pπmary benefits of XML is that it provides a common language for structunng documents that flow between business partners in a supply chain Since XML documents share a common structure, the process of transforming documents into new data representations is vastly simplified While XML offers far more flexibility and extensibility than either traditional messaging or EDI. XML by itself does not deliver the level of integration required to implement the IWN network The XML Engine 46 adapts other subsystems to communicate using XML. and insulates them from the processes of encoding and decoding XML It provides the infrastructure to manage the integration process over time, securely and reliably route requests, and translate between messages that conform to different Document Type Definitions (DTDs) It also provides the facilities for

Integration of heterogeneous systems across firewalls

Authoπsation and secunty across corporate firewalls Provide guaranteed delivery of messages

Substitute Sheet Support for both document and service based integration

Change management and support for ongoing evolution

Support for XML-based vocabulaπes and technologies

Data transformation and mapping Scalability and performance issues

Workflow repository 45

Workflow is concerned with providing the information required to support each step of the business cycle The IWN network involves a mesh of information and transaction flows between market participants In order to manage these flows, the business rules for each transaction and participant type are encoded and stored within the Workflow Repository 45, a logical entity implemented on top of the data object store It combines rules, which govern the tasks performed, and coordinates the transfer of the information required to support these tasks Workflow Repository tasks may be physically moved over the network between participants or maintained in the IWN server clearinghouse with the appropnate processes given access to the data at the required times Triggers are implemented in the system to escalate exception conditions in the event ot problems within the system The operation of the workflow is depicted in Fig 2 Data 60 sent to the IWN cleannghouse server, if not already in an XML format is forward to a translator 61 for translation into an XML format 62 The XML document is then queued 45 in the workflow repository The workflow repository loops through a process of requesting document objects 64. matching the document against possible types 65, determining what conesponding workflow should be undertaken for the document type 66 The workflow is built 67 and added 68 to the workflow queue Each added portion of workflow is then process from the queue 69 and eventually a response returned 70

Hence, the workflow is spawned from the contents of each XML document Once the document has been revived and converted into a consistent data type, the engine processes the document based on actions relating to XML definition in each document

The first object that is requested is a "Profile" that matches the IWN exchange user with a profile This profile is then matched with elements in the data and from this a workflow is spawned This workflow is comprised on a number of unique "actions" that together form a "graph" that define a particular route for each workflow

Transaction processing engine 47

The IWN network employs a standard 3-tιer client/server application model Server applications can be written as a set of interoperable, modular components using standard computer languages — such as C. C++, and Java The Transaction Processing Engine then runs them in its scalable, high-performance, secure, transactional environment

The Transaction Processing Engine 47 logically sequences interactions, using business rules from the Workflow Repository 45 to process transactions from the XML Engine 46. updating the Object/Data Store 47 along the way It ensures that the business transaction is secure and reliable, and is completed with integπty Some ot the capabilities the Transaction Processing Engine bnngs to the IWN Network include - Distnbuted Transaction Management - servers can participate in a distnbuted transaction that involves coordinated updating of multiple databases The Transaction Processing Engine's transaction management helps ensure that all databases are updated properly, or will rollback the databases to their oπgmal state, assunng that data mtegntv is maintained despite component failures

Su - Transaction Queuing - provides flexibility in how and when transactions should be processed or deferred

- Event Brokerage - allows for posting of system or application events that can be subscπbed to by any authonzed application component in the system

From the above descπption and client specifications, the following product functions may be identified

The IWN server cleannghouse handles the following transactions Transaction veπfication. Modify web-store information. Push / pull merchant website information. Modify inventory levels. Serving of ASPs. Issue Mime. SSL, Queue messages. Prepare reports. Transmit payment receipt numbers, Send lay-buy information to Netpos, Transmit purchase requests to POS

The IWN server clearinghouse deals with the following transaction interactions with the Payment Engine Credit card venfication, Cunency queries. Debit information

The IWN server cleannghouse processes information from the Consumer Web-Front ASP This includes sorting of information, building the various websites and payment methods

The IWN server cleannghouse assists in the operation of the E-Brokerage ASP in addition to the Consumer ASP in the following manner Provides an access point for a customer. Run intelligent queries. Store customer preferences. Allow dispute resolution, Payment methods

The IWN server cleannghouse also allows third-party data interpretation

Logistics companies interactions

Integrate other multinational companies

Integrate other e-commerce programs

Integrate ERP, SAP

The IWN server cleannghouse must be able to handle Product information

Merchant information

Supplier / mediator / customer information

Limited website information

Financial (goods) information

Transactions (+, -, *. /)

Receipts

Tax

Payment method selection

Lay-buy information

Show customer information

Show shipping information

Quotes

Substitute Sheet • Terms of sale

• Price specials, promotions

• Dispute reason codes

• E-mail Send, receive, history • Business reports Sales (per period) customer, supplier, product, employee, inventory, delivery, profit

• Accounting information Accounts receivable, payable, total labour costs, cost ot goods sold, etc

• Faxes

• Web page information (Wizard setup. Product categonsation Webpage administration. Statistics)

The following describes the users interacting within the system Consumers

A consumer is simply defined as a person or party that initiates a transaction with a vendor or multiple vendors within

IWN network Internet consumers use an brokerage or a merchant site created by the IWN Webfront ASP 31 as a user interlace through which transactions are performed Of course, consumers can also initiate transactions physically at the customer premises Customers are also able to spawn their own personal IWN customer interface which is customised to their needs and allows them to conduct specified OLAP quenes of the database (see diagram x - peter ask me for the customer details screen)

Merchants

Individuals or organisations that offer products or services for sale to consumers are defined as Merchants within the IWN network framework They participate in transactions using a spectrum of equipment, from sophisticated propnetary software with XML capabilities through to a simple web browser All transactions, whether cash or plastic, are recorded and tracked on behalf of the Merchant by an instance of the IWN engine thereby allow management information reporting

Mediators

A mediator is a merchant that sells to other merchants They may offer semi-finished goods or components (traditional supplier role), or services that complement or facilitate the production process A freight company, insurance agent graphic designer, vegetable wholesaler or coffee bean supplier may be considered an IWN eXchange product mediator Common mediators include distnbution. warehousing and import/export agents

Enablers

Financial institutions, credit providers, cyber-cash agencies, micro-payment vendors, telecommunications earners, software and web design companies are all enablers within IWN network An enabler provides services to consumers, merchants, and mediators by facilitating transactions as opposed to supplying the goods and services that compnse them Other arkets

The IWN network is based on the open, scalable, business-to-business standards such as XML Because of this, the IWN network can communicate with any other market or partv that also adopts open standards For example. Microsoft is promoting a technology called "BizTalk", which consists of a set of XML DTDs for business-to-business transactions IWN network is automatically compatible with BizTalk as a result

Substitute Sheet Clearing House Functional requirements

The following tables set out in more detail the implementation of the functional requirements of the overall IWN server clearinghouse system

Operation Modify web-store information (From POS)

Inputs Product descπptions

Product Id's

Product pricing information

Product availability

Product preference and placement on web page and in terms ot search quenes and esults

Modify merchant information center

Modify credit card acceptance

Modify store status (open/closed/coming soon)

Unique product placement circumstances such (le Gift opportunities)

Product logistic information

Product compatibility information (product inclusive and exclusive rules)

Processes On upload of product information into the database, and after venfication acceptance, the above information is stored in the database

Substi ute Outputs Confirmation of product catalogue entry Acceptance of product into system

Substitute Shee IWN server cleannghouse evaluates bandwidth availability Time stamp establishes the start time of use Fee is added to user account

Outputs Application delivered tor use and session spawned tor pre-agreed peπod User is charged

Substitute Sheet

Substitute Sheet Request sent to cleaπng house

Replication of data at cleaπng-house and NetPOS

Outputs Confirmation ot purchase Receipt number Delivery details

Substitute Sheet

User Interfaces

Apart from the usual browser interfaces, the POS interface for can be a point of sale hardware device such as the Comm2000 device from Keycorp The configuration at point of sale may include a cash register, customised keyboard and other typical point of sale devices

As IWN network is based on a client/server computing environment, the necessary hardware device required to access the network is a Internet connection to connect to the IWN server cleannghouse server This can be implemented through a third party ISP

Software Interfaces

The software to be interfaced with the IWN network can be a Java client running on a Web browser (Netscape Navigator 3 x Netscape Communicator 4 x. Internet Explorer 3 x) Alternatively, the operating system (Windows 9x, Windows NT, Unix. MacOS) can interact directly using the TCP/IP protocol

As descnbed above, any third party can interact with the system by integrating to it using the IWNCom s development kit as shown in the attached appendix A

(c) Communications Interfaces

The data communication protocol required to use the IWN Network can be the standard TCP/IP protocol The type and speed of connections to the Internet will be vaπed amongst the different users and does not impact the design of the system

POS to XML The POS device provides a direct translation into XML Initially, the POS device opens a TCP/IP connection with the

IWN server The credit or debit card data is then sent to the server The process firstly involves the negotiation of connection and session's with the IWN engine The process involved is slightly different for Credit and Debit For a credit card, the steps include

Substitute Sheet 1 Merchant prompted to swipe card either by the third party software (such as Quicken or MYOB) or by the IWN client side component directly

2 Merchant swipes card

3 Card details sent back to the PC (instead ot remaining in the EFTPOS device) 4 Either information gathered by the third party software and passed to the IWN object or gathered by the object directly

5 IWN Client side Component (either Java based or ActiveX) collects the credit information converts it to AS2805 compliant XML data, and sends it to the server The collection of information can also include (not limited to) product information , merchant information, and information about the terminal The product information is extrapolated from a local data store using either supplied APIs or via customised integration Alternatively the product information can be sent as a batch file at pre-determined intervals

6 The server sends a response back to the client side component which leads to receipt pπntmg and other related retail business requirements

Debit solution from POS The debit solution may include more traditional pin key encryption devices (such as the Com2000 device from

Keycorp), or newer technologies such as WAP and Bluetooth Using the more traditional POS hardware configuration, the system can operate by the following steps

(a) Merchant prompted to swipe card either by third party software (such as MYOB or Quicken) or by the IWN client side component. (b) Merchant swipes card.

(c) A ECR message sent to the EFTPOS Hardware (Which is capable of Key PIN Encryption) (d) The PIN Pad or like device prompts the user to enter a PIN number (usually four digits) The user enters the PIN number

(e) The PIN number is encrypted with 3DES encryption and set back to the computer via an ECR Message The message is either received by the third party application or the IWN client side component The 3DES encrypted message is then sent to the IWN server along with other XML information regarding the transaction including (but not limited to) Product, customer, merchant, and terminal information

(f) The IWN Server passes the PIN to the Acquinng institution (potentially via an internal gateway first) and then through to the issuing bank, the issuing bank then returns a response as to the funds available

An alternative method can compnse the following steps 1 Mercant Swipes card in POS terminal

2 POS encrypts the data (DES usually) and sends it back to the PC

3 Only the AS2805 (or similar financial information) is sent to either

(a) The IWN engine which then forwards it to a financial institution

(b) Directly to the financial gateway 4 Then when the message is confirmed and sent back to the server a new XML document is spawned that sends the transactions details to the IWN server (over the same link)

Substitute Sheet It is also important to identify that information is only stored in the IWN server once the transaction has been approved (besides fault logging and invalid transaction logs)

The debit transaction can be extended to other anangements which utilise non traditional Point of Sale Hardware For example, debit card transactions can be conducted over a mobile phone interface using a WAP enabled phone having Key PIN encryption The process, as illustrated in Fig 3 can proceed as follows

1 Sale transaction agreed upon between Merchant/Retailer 71 and customer 72,

2 Merchant selects debit card on their POS device 73.

3 Merchant enters mobile phone number or initiate SMS message on the POS device.

4 Message sent to WAP or SMS server 74, 5 Message sent to IWN Engine 75,

6 Message forwarded to mobile phone 77 via WAP Gateway 74.

7 PIN entered on mobile phone and encrypted and sent to IWN engine 75.

8 IWN Engine sends encrypted PIN to Acquirer Gateway 78 and Sends Merchant ID to the IWN Engine.

9 IWN Engine waits for response. 10 Acquirer 78 forwards the PIN to the card issuer 79,

1 1 PIN authenticated by the Issuer 79,

12 Response sent to IWN Engine 75,

13 Response forwarded to merchant point of sale 73 ,

14 Sale completed or denied Alternatively, the system can operate to include consumer initiated transactions over WAP This can comprise the steps of

1 Sale completed

2 Merchant selects Debit via WAP/SMS option

3 Consumer Selects Debit via WAP/SMS 4 Consumer enters Merchant ID via WAP interface of mobile 77.

5 Consumer enters PIN via WAP interface,

6 Consumer sends message with PIN (Key Pin encrypted) to the IWN Engine 75.

7 IWN Engine sends encrypted PIN to Acquirer Gateway 78 and Sends Merchant ID to the IWN Engine

8 IWN Engine waits for response 9 Acquirer forwards the PIN to the issuer 79,

10 PIN authenticated by the Issuer 79,

1 1 Response sent to IWN Engine 75

12 Response forwarded to merchant point of sale73

Substitute Sheet 13 Sale completed or denied

Alternatively, the system can operate to include merchant and consumer initiated transactions a Bluetooth network For example, where the merchant has a blue tooth interface and the user has a Bluetooth enabled phone with a Key PIN encryption device, the process for executing a sale can compnse 1 Sale completed

2 Merchant selects Debit via Bluetooth option

3 Merchant swipes card

4 Card and Merchant details sent via Bluetooth to the phone

5 Consumer enters PIN 6 Consumer sends message with PIN (Key Pin encrypted) to the WAP Gateway

7 WAP Gateway sends PIN & card number to IWN Engine

8 IWN Engine sends encrypted PIN to Acquirer Gateway and Sends Merchant ID to the IWN Engine

9 IWN Engine waits tor response

10 Acquirer forwards the PIN to the issuer 1 1 PIN authenticated by the Issuer

12 Response sent to IWN Engine

13 Response forwarded to merchant point of sale

14 Sale completed or denied

Further, where the consumer wishes to inmate a Bluetooth transaction, the transaction can be as follows 1 Sale completed

2 Merchant selects Debit via Bluetooth option

3 Consumer enters PIN into mobile

4 PIN encrypted in SIM card

5 Card details sent via Bluetooth to the POS device 6 Merchant swipes card

7 POS device sends PIN & card details to IWN server

8 IWN Engine sends encrypted PIN to Acquirer Gateway and Sends Merchant ID to the IWN Engine

9 IWN Engine waits for response

10 Acquirer forwards the PIN to the issuer 1 1 PIN authenticated by the Issue

12 Response sent to IWN Engine

13 Response forwarded to merchant point of sale

Substitute Sheet 14 Sale completed or denied

Graphical User Interface (GUI) to the IWN Cleannghouse engine

As each transaction can be stored in the data/object store, a complete overview of each independent IWN Engine system can be made available from a GUI administration window The views provided preferably include

1 Service activation

2 Service Provisioning

3 Work-flow manipulation

4 Logical network overviews 5 View of all "actions" available in the system

6 View and manipulation of work-flow "graphs" representing the logical order of actions in forming any one work-flow

7 View of devices on the network and the role that they play in the network overall

8 Activation of new devices

9 Activation of new clients and related business requirements 10 Activation of new client types (such as an SME Grouping)

1 1 View of logs for each client, device, service

12 Mapping of new datatypes

13 Mapping of existing datatypes to new services or devices

14 Automated audit trails 15 Activation of peeπng to other engines

OLAP Processing

The data in the data/object store repository can be quened using OLAP techniques (online analytical processing). ROLAP (Relational Online Analytical Processing), MOLAP (Multi-dimensional on-line analytical processing) . and other similar techniques OLAP (online analytical processing) enables a user to easily and selectively extract and view data from different points-of-view Hence, this provides an extremely flexible query tool that enables multi-dimensional queries OLAP uses a multi-dimensional data base where each data element is stored as a highly discrete piece of information OLAP can find the intersection of two to "n" relationships between the data

The IWN architecture uses the following techniques to extract information from the data-store 1 Any device or access point either compatible with or understood by the IWN engine (in terms of data and network compatibility) sends a query to the associated server (le WAP server. HTTP server) or connects directly to the IWN engine

2 The message format is converted to the appropπate data type for the IWN engine

3 The message is recognised by the Engine as an OLAP query

Substitute Sheet 4 This spawns a connection to the IWN Servlet Engine which launches a servlet to mange the query

5 The servlet then sends all queries to the Workflow Repository Manager that protects the IWN data-stores from external tampenng

6 The Workflow Repository Manager connects to the data base and returns all relevant information to the Servlet 7 The Servlet then returns the response to the Engine and the transaction is processed and sent back to the appropriate device

The OLAP architecture is novel in that it deals with ubiquitous devices and multiple queries from any ot. but not limited to. the following Web Browsers. WAP Devices. WebTV Devices, Java enabled devices (le that can run a JVM), Kiosks. ATM's (Automated Teller Machines) The OLAP architecture can be designed to accept queries from any device (Sending valid requests) and return response to that said device (using valid responses)

Peeπng multi-instances of the engine

Distributing various instances of the engine allows each engine to link together and appear to be one engine under particular circumstances This enables two owners of the engine to enter into commercial agreements to contπbute client collateral to increase the momentum of their commercial endeavours For example, it company A has 100 merchants using their engine and company B has 100 merchants, they are able to peer their engines to enable any consumer seeking merchants to query all 200 merchants

This process can be enabled via a secure socket connection between the engines and the ability for a OLAP query on one engine to access a business rule to query another engine/s and the IP address of the other engine/s Much like a search engine, the Servlet technology then opens a session with the foreign engine and awaits the complete query of all local and foreign engines before returning the response to the user

Obviously vanous modified embodiments and alternative representations are possible For example, in Fig 4 there is illustrated an alternative representation of an embodiment of the present invention Vaπous interactive devices, for example shop front point of sale terminals 80, Internet device 81. WAP devices 82. Kiosk terminals 83. PDAs 84 and Web TV devices 85 are each equipped with an Sdk to convert transactions into an XML document in accordance with associated document type definitions The XML documents are sent to the XML engine 86 for action and storage The XML engine in turn provides a senes of modules for interaction with the data store These include an OLAP module 87. logistics module 88, client billing system 89. loyalty modules 90 and brokerage portal 91 and bank cleaπng house 91 Further, in vaπous embodiments, the IWN engine 86 can be paired with other engines 94 and undertake other transactions with legacy applications and other internet system 95 Fig 5 illustrates an alternative architectual anangement and Fig 6 illustrates the processing of a transaction in accordance with the aforementioned pπnciples, with Fig 7 illustrating an alternative view of the architecture of the IWN Engine

It would be appreciated by a person skilled in the art that numerous vanations and or modifications may be made to the present invention as shown in the specific embodiments without departing from the spiπt or scope ot the invention as broadly described The present embodiments are. therefore, to be considered in all respects to be illustrative and not restπctive

Substitute Sheet Appendix A

Login DTD

<'DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4 0 Transitional/ /EN" >

< ' -- saved from url= ( 0063 ) http //dev.indwide net/milestones /milestone-

4/xml/dtd/logm. dtd -->

<HTML><HEAD>

<META content=" text/html ; charset=wmdows-1252 " http-equιv=Content-Type>

<META content="MSHTML 5.00.2919 6307" name=GENERATOR>< /HEAD>

<BODY><XMP>< ' —

IWN Login DTD

Version. $Id. login. dtd, v 1.4 2000/06/05 03.04 46 dth Exp $

Milestone: 4 —>

ENTITY ιwn_elements " login" > ENTITY logm_elements (request | response) "> ENTITY request_elements "authentication" > ENTITY response_elements "authentication? , code, description, options? " ENTITY authentιcatιon_elements " ( id, password⁷ ) dsa"> ENTITY optιons_elements "workflow+ " >

ELEMENT lwn (%ιwn_elements ; )> ATTLIST lwn version CDATA #REQUIRED> ATTLIST lwn session CDATA #IMPLIED>

ELEMENT login ( %logm_elements ; ) >

ELEMENT response ( %response_elements ; ) > ELEMENT request ( %request_elements ; ) >

ELEMENT authentication (%authentιcatιon_elements; ATTLIST authentication type CDATA #REQUIRED> ATTLIST authentication algorithm CDATA #IMPLIED> ELEMENT id (#PCDATA)> ATTLIST id type CDATA #IMPLIED>

ELEMENT password (#PCDATA)> ELEMENT dsa (#PCDATA)>

ELEMENT code (#PCDATA)> ATTLIST code type CDATA #REQUIRED> ELEMENT description (#PCDATA)>

ELEMENT options ( %optιons_elements ; )

ELEMENT workflow (#PCDATA)>

ATTLIST workflow id CDATA #REQUIRED>

< /XMPx /BODYx /HTML>

XML Login Request

<^,xml version-" 1.0 " ⁷>

<'DOCTYPE lwn (View Source for full doctype . ) >

<'-- Comment-->

<ιwn versιon="0 4">

<logm>

<request>

< ' --

IWN Users can login either by their email address or their IWNUserlD. example :

<ιd type=" email ">foo@bar . com</emaιl> <password>foo</password> or

<ιd>959818</ιd> <password>foo</password> —>

<authentιcatιon type=" lwnuser "> <ιd type= "email ">bottlefastθtelstra com</ιd> <password>mercnant< /password> </authentιcatιon>

Sub i </request>

</logm>

</ιwn> XML Login Response

<?xml versιon=" 1.0 " ⁹> < ! DOCTYPE lwn > <'-- comments -->

<ιwn versιon="0.4' sessιon= " 6d518aa77a49d8bc823037111dd877d6931d6245 " > <logm>

<response> <code type=" login" >0</ code>

<descπptιon>Logm Successful</descrιptιon> < ' — These are the workflows that the user is allowed to execute.

In this case, tne user can now

- Request a Purchase ID

- Request a Transaction Status

- Logout

<optιons> <workflow ιd= "2 " >Logout</workflow> <workflow ιd= " 3 " >Purchase ID</workflow> <workflow ιd="7 ">Transactιon Status</workflow> </optιons> </response> </logm> </ιwn>

Substitute Sheet Purchase DTP

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional / /EN" >

<!-- saved from url= (0066 ) http ^•/ /dev mdwide.net/milestones/milestone-

4/xml/dtd/purchase .dtd -->

<HTML><HEAD>

<META content= " text /html , charset=wmdows- 1252 " http-equιv=Content-Type>

<META content= " MSHTML 5 . 00 . 2919 . 6307 " name=GENERATOR>< /HEAD>

<B0DYXXMP>< ¹ - -

IWN Purchase DTD

Version : $ Id : purchase . dtd , v 1 . 4 2000 / 06 / 05 03 : 04 : 46 dth Exp $

Milestone: 4

< i -- <ιwn> children --> <' ENTITY % ιwn_elements "purchase ">

<ι-- <purchase> contains either <request> or <response> --> < i ENTITY % purchase_elements "request j response"

< ' -- <request type=". "> --> < [ENTITY % request_types "purchase | purchaseid | purchasereversal purchaseauthorize ">

<'-- <request type= "purchase" > children —>

<' ENTITY % purchaserequest_elements "source, delivery, payment, products⁷, cost">

< ' -- <request type= "purchasereversal "> children —> < 'ENTITY % purchasereversal_elements "purchaseid" >

< ' -- NOTE: purchaseid and purchaseauthorize have no children other than

<authentιcatιon> -->

< < -- so they are not specified here, as <authentιcatιon> is a required element

<' — <authentιcatιon> children -->

< > — NOTE: digital signatures /hashes would be added here -->

<! ENTITY % authentιcatιon_elements "(id, password?) | dsa">

<!-- <response> children --> < i ENTITY % response_elements "authentication?, code, description, rrn', options? ">

<'-- <optιons> children --> <' ENTITY % optιons_elements "workflow+ ">

< ' -- <payment> children --> <' ENTITY % payment_elements "card I ιwnuser">

<'-- <source> children -->

< ' ENTITY % source_elements "pos web" >

< ' -- <delιvery> children --> < [ENTITY % delιvery_elements "address | pos " >

< ' -- <card> children --> < [ENTITY % card_elements "name'' , number, expiry, account">

<'-- <products> children --> < > ENTITY % products_elements "product* " > <! ENTITY % pos_elements " termmalid" >

<'-- <source/pos> children --> <! ENTITY % web elements "client, server ">

<'-- <delιvery/address> children --> < [ENTITY % address_elements 'level?, number, street, suburb, city, state, country, postcode" >

< i -- <products/product> children --> <' ENTITY % product_elements "productid, name?, description?, unit, quantity, cost*">

Substitute Sheet <ι-- <products/product/quantιty> children --> < [ENTITY % quantιty_elements "cost*">

< ' ELEMENT lwn (%ιwn_elements ; ) > < [ATTLIST lwn version CDATA #REQUIRED> < [ATTLIST lwn session CDATA #IMPLIED>

< ! ELEMENT purchase ( %purchase_elements ; ) > < [ATTLIST purchase id CDATA #IMPLIED> <' ATTLIST purchase authorize CDATA #IMPLIED>

<'-- <request> elements -->

< ' -- <request> must contain <authentιcatιon> , and either purchase reversal children or purchase request children --> <!ELEMENT request (authentication, ( ( %purchasereversal_elements ; ) | (%purchaserequest_elements ; ) ) ?) > < > ATTLIST request type (%request_types ; ) #REQUIRED>

< i -- <request/authentιcatιon> elements --> <! ELEMENT authentication ( %authentιcatιon_elements ; ) > < [ATTLIST authentication type CDATA #REQUIRED> < [ATTLIST authentication algorithm CDATA #IMPLIED> < ' ELEMENT id ( #PCDATA) > < 'ATTLIST id type CDATA #IMPLIED>

< ! ELEMENT ema11 ( #PCDATA) >

< [ELEMENT password (#PCDATA)> < ! ELEMENT dsa ( #PCDATA) > <!-- <request/purchaseιd> elements —> < ! ELEMENT purchaseid ( #PCDATA) >

< ' -- <request/source> elements -->

<! ELEMENT source (%source_elements ; ) >

< ' -- <request/source/pos> elements --> <! ELEMENT pos (%pos_elements ; ) > <! ELEMENT termmalid (#PCDATA)> <'-- <request/source/ eb> elements --> < ! ELEMENT web ( %web_elements ; ) > < ! ELEMENT c11ent ( #PCDATA) > < ' ELEMENT server ( #PCDATA) > <'-- <request/delιvery> elements -->

< [ELEMENT delivery (%delιvery_elements ; ) >

<'-- <request/delιvery/address> elements --> < ' ELEMENT address ( %address_elements ; ) > <! ELEMENT street (#PCDATA)>

< ! ELEMENT suburb ( #PCDATA) > < ! ELEMENT city ( #PCDATA) >

<! ELEMENT state (#PCDATA)>

< ! ELEMENT country ( #PCDATA) > <' ELEMENT postcode (#PCDATA)>

< ' -- <request/delιvery/pos> elements --> <>-- < [ELEMENT pos (#PCDATA)> —> < i -- <request/payment> elements -->

< ! ELEMENT payment ( %payment_elements ; ) >

<ι-- <request/payment/card> elements -->

< ! ELEMENT card ( %card_elements ; ) > <! ELEMENT name (#PCDATA)>

< ! ELEMENT number ( #PCDATA) >

< ' ELEMENT explry ( #PCDATA) >

< [ATTLIST expiry month CDATA #REQUIRED>

< [ATTLIST expiry year CDATA #REQUIRED> <! ELEMENT account (#PCDATA)>

< ' -- <request/products> elements -->

Substitute Sheet <' ELEMENT products ( %products_elements ; ) >

< ' -- <request/products/product> elements --> < i ELEMENT product ( %product_elements ; ) > < [ATTLIST product merchantid CDATA #REQUIRED> <! ELEMENT productid (#PCDATA)> < 'ATTLIST productid type CDATA #IMPLIED> <! ELEMENT description (#PCDATA)> < ! ELEMENT unit ( #PCDATA) > < 'ATTLIST unit name CDATA #REQUIRED>

<'-- <request/products/product/quantιty> elements -->

<! ELEMENT quantity ( %quantιty_elements ; ) >

< [ATTLIST quantity number CDATA #REQUIRED> <! ELEMENT cost (#PCDATA)>

< [ATTLIST cost currency CDATA #REQUIRED>

< 'ATTLIST cost name CDATA #REQUIRED>

< 'ATTLIST cost rate CDATA #IMPLIED> <^ι-- <response> elements -->

< ' ELEMENT response ( %response_elements ; ) >

< ! ELEMENT code (#PCDATA) >

< [ATTLIST code type CDATA #REQUIRED>

< ' — <! ELEMENT description (#PCDATA)> —> < ' ELEMENT rrn ( #PCDATA) >

< ' -- <response/optιons> elements --> <! ELEMENT options ( %optιons_elements ; ) > < ' ELEMENT workflow ( #PCDATA) > < [ATTLIST workflow id CDATA #REQUIRED>

< /XMP>< / BODYx /HTML>

Substitute Sheet Purcase ID Request

<?xml versιon=" 1.0 " '> <!DOCTYPE lwn >

< ' -- comment—>

<ιwn versιon="0 4" sessιon=" 6d518aa77a49d8bc823037111dd877d6931d6245 ">

<purchase>

<request type= "purchaseid" >

<authentιcatιon type=" lwnuser " > <ιd type= "email ">bottlefast@telstra com</ιd> <password>merchant</password> </authentιcatιon> </request> </purchase> </ ιwn>

Purchase ID Response <?xml versιon= " 1.0 " ⁷> < ' DOCTYPE lwn >

<'-- comment -->

<ιwn versιon="0 4" session-" 6d518aa77a49d8bc823037111dd877d6931d6245 "> - <^ι-- specifies the id of the purchase -->

<purchase ιd= "acs233d23dacad" >

<response> <code type= "purchase ">128</code> <descrιptιon>Purchase ID Successfully Assιgned</descπptιon>

<optιons> <workflow ιd= " 2 " >Logout</workflow> <workflow ιd=" 4 ">Purchase</workflow> <work low ιd=" 7

Status</workflow> </optιons> </response> </purchase> </ιwn>

Substitute Sheet Purchase request

<?xml versιon= " 1.0 " ?>

< i DOCTYPE lwn (View Source for full doctype . . . ) >

<!-- comment --> <ιwn versιon="0.4" session-" 6d518aa77a49d8bc823037111dd877d6931d6245 " >

<! -- if this purchase should be automatically processed set the authorize flag to true from a POS unit this will almost always be true, but from a web client, the authorization will most likely be false, to allow the merchant to manually authorize the purchase via email /messaging .

—> <purchase ιd="acs233d23dacad" authorize;" true" > <request type="purchase ">

AUTHENTICATION

—> authentication type= " lwnuser ">

<ιd type= "email ">bottlefast@telstra. com</ιd> <password>merchant< /password> </authentιcatιon>

< ' -- SOURCE

Valid Types: web, pos the source of this document --> <source> <pos>

<termmalιd>12346</termιnalιd> </pos>

If source is web, <clιent> specifies the customers IP address. <server> indicates the IP address of the web server serving the request.

IP/FQDN are both valid.

<web> <clιent>203.122.33.l</clιent>

<server>www. ind ide . net</server>

</web>

—> </source>

DELIVERY DETAILS

Valid Types: address, pos (point of sale)

If delivery details are absent, and source is web they will try to be looked up via the sessionid

If delivery details are <pos>, it is assumed the goods were taken from point of sale.

<delιvery>

<address> <unιtx/umt> or <levelx/level> are optional

<number></number>

<streetx/street>

<suburbx/suburb>

<cιtyx/cιty> <statex/state>

<countryx/country>

<postcodex/pos code>

</address>

</delι ery> or

<delιvery>

<pos/>

</delιvery>

—> <delιvery> <pos /> </delιvery>

Substitute Sheet PAYMENT DETAILS (SENSITIVE) Valid types: card, lwnuser

Note the lwnuser id may be looked up using the card number for other projects such as loyatly. --> <payment> <card> <name>Card N. Holder</name> <number>456400000000</number> month can be the following. 01, 02, ... , 11, 12 1, 2, ... , 11, 12 January, February, ... , November, December Jan, Feb, . , Nov, Dec year can be the following: 00, 01, . , 98, 99 (+2000) 2000, 2001, ... , 2998, 2999

—>

<expiry month="01" year="01" />

<!-- valid account types are credit, cheque, savings, etc. will be supported in a later release

—>

<account>credιt</account>

</card> <! -- Alternately, <ιwnuser> can be used to lookup the credit details via the IWNUserlD or email

<lwnuser>

<id>3</ιd>

<password>foo</password> </ιwnuser> or

<ιwnuser>

<emaιl>foo@bar . com</emaιl>

<password>foo</password> </ιwnuser>

—> </payment> PRODUCTS Optional. The <products> collection may be ommitted entirely if desired.

—> <products> Each product must contain a product id and a merchant id. This allows for multiple products /merchants per purchase request (example Virtual Mall) --> <product merchantιd=" 99 "> <productιd name and description are optional

—>

<name>foo</name> <descrιptιon>600gram bar of foo</descπptιon> unit and unit name refer to the quantity of the product. examples . 1 x 600ml milk

<ιd>l</ιd>

<descrιptιon>mιlk</descrιptιon>

<unιt name="ml ">600</unιt>

<quantιty number="l">...</quantιty> 3 x 3kg bag of oranges

<ιd>2</ιd>

<descrιptιon>3kg bag of oranges</descπptιon>

Substitute Sheet <unιt name="kg">3</unιt> number="3"> .. </quantιty>

—>

<unιt name= "kg" >l^/unιt>

currency codes conform to ISO 4217

--> <quantιty number="2">

< ' -- cost tags are optional withm <quantιty/> tags.

There may be an arbitrary amount of cost tags here.

They are not used for calculation of price at all They are solely used for reporting/accounting.

It is up to the merchants discretion which costs they send with each purchase request

Cost names are arbitrary.

Costs withm the <quantιty> tag refer to each unit, not to the group of products.

—>

<cost name="cost" currency="AUD">100</cost> <cost name= "pretax" currency="AUD">200</cost> <cost name="sale" currency="AUD">220</cost> <cost name-" staffdiscount " currency="AUD" rate=" 10% ">20</cost> <cost name="dth-fee" currency="AUD" rate= " 10%">20</cost> <cost name="GST" currency="AUD" rate=" 10% ">16</cost> <cost name=" subtotal " currency="AUD" >176</cost> </quantιty> <■ —

There may be an arbitrary number of <cost> tags withm each

<product> tag.

For a description, see above.

Cost tags here are also optional. Cost tags inside <product> refer to the pricing of the entire

<quantιty> of products.

—>

<cost name="foo" currency="AUD">10</cost>

<cost name="quantιtytotal" currency="AUD">362</cost> </product>

</products> COST Cost outside the <products> tree is mandatory

This value is the actual value that will be passed to the financial switch for credit/debit.

—> <cost name="total" currency="AUD">362</cost> </request> </purchase> </ιwn>

Substitute Sheet Purchase Response

<?xml versιon= " 1.0 " '>

<!DOCTYPE lwn (View Source for full doctype . . . ) >

IWN Purchase Response Sample Document

Version- Sld: purchase-response. xml , v 1.4 2000/06/05 03:05-08 dth Exp $

Milestone- 4

Version corresponds to the Milestone release id corresponds to the Purchase ID

->

<ιwn versιon="0.4" sessιon= " 6d518aa77a49d8bc823037111dd877d6931d6245 " >

<purchase ιd= "acs233d23dacad' >

<response> <code type="purchase">0</code>

<descrιptιon>Purchase Successful</descrιptιon> <rrn>ιwn0032114125511234</rrn>

< ' --

- Request Transaction Status

- Request Purchase Authorization

- Request Purchase Reversal

- Logout

—>

<optιons>

<workflow ιd=" 2 ">Logout</workflow>

<workflow ιd=" 5 ">Purchase Authoπze</workflow> <workflow ιd=" 6 ">Purcnase Reversal</workflow>

<workflow ιd="7

Status</workflow>

</optιons>

</response>

</purchase> </ιwn>

Substitute Sheet

10 IWN Transaction SDK

API User Guide

15

20

Substitute Shee Contents

Preface 39

Associated Documentation 39

Overview 40

Communications 40

Sessions 40

Transactions 40

Sample Session 40

Terminology 43

Objects 44

Session Object 45

Transactions Collection Object 46

Transaction Object 47

Products Collection Object 48

Product Object 49

Properties 50

MerchantlD Property (Session Object, Transaction Object. Product

Object) 51

Route Property (Session Object) 52

ServerAddress Property (Session Object) 53

ServerPort Property (Session Object) 54

SessionlD Property (Session Object) 55

TerminallD Property (Session Object) 56

Transactions Property (Session Object) 57

Amount Property (Transaction Object) 58

CardExpiryMonth Property (Transaction Object) 59

CardExpiryYear Property (Transaction Object) 60

CardName Property (Transaction Object) 61

CardNumber Property (Transaction Object) 62

Substitute Sheet Code Property (Transaction Object) 63

CurrencvTvpe Property (Transaction Object) 64

Description Property (Transaction Object) 65

Products Property (Transaction Object) 66

RRN Property (Transaction Object) 68

SessionlD Property (Transaction Object) 69

SystemTrace Property (Transaction Object) 70

TransactionlD Property (Transaction Object) 71

Count Property (Transactions Object) 72

Count Property (Products Object) 73

Item Property (Transactions Object) 74

Item Property (Products Object) 75

Methods 76

Login Method (Session Object) 77

Logout Method (Session Object) 78

Add Method (Transactions Collection Object) 79

Delete Method (Transactions Collection Object) 80

Send Method (Transaction Object) 81

Add Method (Products Collection Object) 82

Delete Method (Products Collection Object) 83

Events 84

Enumerations 85

Error Codes 86

Substitute Sheet Preface

This document is provided to assist a developer in utilising the IWN Transaction SDK in the development of a client application that is to perform transactions using the IWN Transaction System.

Associated Documentation

This document can be used in conjunction with the IWN Engine Client Specifications.

Substitute Sheet Overview

The IWN Transaction SDK consists of an ActiveX EXE containing several classes that are used to collect, format, verify and send transactions to the IWN Transaction System, and receive, parse and provide the results of those transactions to a calling application.

Communications

The IWN Transaction Classes communicate with the IWN Server over TCP/IP using specially formatted documents for transferring information. Each Transaction type may perform any number of Transactions with the IWN Server. For a Transaction the flow of information is as follows:

A TCP/IP Connection is established between the Client and the rWN Server.

The Client sends a Request Document to the IWN Server.

The IWN Server sends a Response Document to the Client.

Sessions

The IWN Transaction Systems utilises Session management to provide tracking, reconciliation and to ensure the integrity of Transactions.

When a Client creates an instance of the Session Object, it can call the Logon method which will request a Session from the IWN Server. Once the IWN Server has issued the Client with a valid Session, the Client can use that Session to send Transactions.

A Client uses the Merchant Details provided to identify and authorize itself to the IWN Server.

Transactions

The following Transaction types are currently supported: PURCHASE, REVERSAL, AUTHORIZE and STATUS

Sample Session

Here is a typical usage scenario.

This section refers to code in the iwnExαmple Visual Basic project distributed with the iwn component.

Substitute Sh The calling application will typically create an PNN session object when it loads or initialises.

It will then set the following Session object properties: o ServerAddress o ServerPort

The calling application may then ensure it has contact with the IWN engine and call the Session objects Login method, passing the Merchants Username and password.

The Login method should return true or false and set an error depending on whether the Login was successful. The application may wish to rectify any problems and try the login again should the login have failed.

It the Login method returns True, the the Merchant has been issues a valid session and may now commence with committing transactions.

To perform a transaction, the calling application would execute the Session objects Transaction collections Add method, which will return a valid transaction object. When the Add method is called, the IWN transaction server is contacted for a valid transaction number to use. If this failed, then the Add method will return null. The calling application should check the validity of the Transaction object returned by the Add method before it attempts to use it.

When it has obtained a valid transaction object, the calling application must then set the following properties of that transaction, before the transaction can be committed: o CardExpiryMonth o CardExpiryYear o CardName o CardNumber o Currency Type

The calling application can then create Product objects within the Transaction object to represent the difference products, prices and quantities for the transaction. The calling

Substitute Sheet application can add a Product object to the Transaction by calling the Transactions objects Products collection Add method. The Add method will return Product object, whose properties can be set to indicate the desired product, quantity and unit cost.

The calling application can repeat this step to add any number of products to the transaction before it is commited.

Before the Transaction is committed, the calling application can adjust the amount for the transaction by setting the Transaction objects Amount property. This allows for adjustments such as discounts, part payments or credits. If there are no products added, the calling application must explicitly set the Transaction objects Amount property or the Transaction will have the default value of 0.

When the calling application wishes to commit the transaction, it can simple call the Transaction objects Send method, which will send the transaction to the IWN engine, and return True if successful or False if the transaction failed.

Substitut Terminology IWN Server

The rWN Transaction Server.

Client

The calling application, in which objects of the IWN Transaction Classes are created.

Transaction

A single network transaction. Indication the sending of data to the IWN Server and the receipt of information from the IWN Server. This DOES NOT indicate a financial transaction. A transaction is considered complete when a valid Request Document has been sent to the

Server and a valid Response Document has been received from the IWN Server

Request Document

The rvVN Transaction Classes use a special message format for transferring information between a Client and the ΓΫVN Server. As in a Transaction, a document is sent and a document is received. A document transferred FROM the Client TO the TvVN Server is a Request Document.

Response Document

As with the Request Document, the Response Document is sent FROM the IWN Server TO the client after the server has received and processed a valid Request Document.

Purchase

A Purchase is a type of credit transaction. Within the scope of the IWN Transaction SDK it is considered a virtual transaction. A Purchase may constitute several Transactions, depending on the requirements of the Purchase. (See Transaction)

Reversal

A Reversal is a type of credit transaction. (See Purchase) Session

Substitute Sheet Objects

Substitute Sheet Session Object

Parent: (none) Children: Transactions Default Property: (none) Properties

Login Email as String Password as String

Logout (none)

Comments

A single session object is created, it's parameters are set and the login method is called. Once a successful login has occurred the session object can be used to create transaction objects. Transaction objects cannot (read should not) be created if there is no current valid session, or if the session object is not connected to a valid session.

Substitute Sheet Transactions Collection Object Properties

The Transactions Collection object exists within the session object and holds all the Transaction objects that have been created within the session. The Transactions Collection object can be enumerated in For Each statements to retrieve each Transaction object in sequence.

Substitute Sheet Transaction Object Properties

Methods

omments

A Transaction Object is created within the Transactions Collection object when there is a valid session present in the Session object. A Transaction object is created, its properties set, and the send method is called. Transactions will exist until explicitly killed or until as session has ended.

Products Collection Object Properties

The Products Collection object exists within a Transaction object and holds all the Product objects that have been created within the transaction. The Products Collection object can be enumerated in For Each statements to retrieve each Product object in sequence.

Substitute S Product Object Properties

Methods

omments

A Product Object is created within the Products Collection object in a valid Transaction Object. A Product object is created, its properties set. The product details are issued with the Transaction when the parent Transaction object is committed.

Products will exist until explicitly killed or until the parent Transaction Object has terminated has ended.

S Properties

Substitute Sheet MerchantlD Property (Session Object, Transaction Object, Product Object)

The MerchantlD property contains the Merchant ID for the Session, Transaction or Product.

Syntax objSession. MerchantlD

Data Type

String

Comments

The MerchantlD property can be set before an active session. Unless explicitly set, MerchantlD' s for Transaction and Product objects will assume the value of MerchantlD in the Session object.

Example

With objSession

.MerchantlD = "99" End With

Substitute Sheet Route Property (Session Object)

The Route property is used to specify a gateway IP address to use when sending transactions.

Syntax objSession. Route

Data Type

String

Comments

Setting the Route property will modify the system routing table by adding a static route to the IP address or hostname specified by the ServerAddress property via the IP address specified in the Route property. The Route property can be set any number of times during the life of an active session and the next Transaction to be commited will use the route specified.

If the IP address supplied with the Route property does not exist as a valid interface, the routing table will not be modified but the Route property will retain the IP address given. Currently there is no way to determine if a call to the routing table was successful, but future versions will support notification of the Route entry.

Example

This code will add a route to the system routing table specifying that all traffic for iwnengine.indwide.net should go through the interface 192.168.0.10 With objSession

.ServerAddress = "iwnengine.indwide.net"

.Route = "192.168.0.10"

End With

Substitute Sheet ServerAddress Property (Session Object)

The ServerAddress property specifies the address of the IWN engine server that the Session should communicate with.

Syntax objSession.ServerAddress

Data Type

String

Comments

The ServerAddress property is required before the Session objects Login method can be called. The ServerAddress property can (read should) only be set once before the session is validated. Setting this property during a valid session will not (read should not) take effect until the Session is terminated and a new Session is created.

Example

With objSession

.ServerAddress = "iwnengine.indwide.net"

.ServerPort = 5005 End With

Substitute Sheet ServerPort Property (Session Object)

Sets the TCP port used to communicate with the IWN engine server specified with the ServerAddress property.

Syntax objSession. ServerPort Data Type String Comments

See ServerAddress Property (Session Object)

Example

With objSession

.ServerAddress = "iwnengine.indwide.net"

.ServerPort = 5005 End With See Also ServerAddress Property (Session Object)

Substitute Sheet SessionlD Property (Session Object)

The SessionlD property containts the Session ID for the active session.

Syntax objSession. SessionlD

Data Type

String

Comments

The SessionlD property is automatically assigned a value when a session is created by executing the Login method. Functionality has been provided to set the SessionlD property of a Session object to support the future ability to resume sessions between invocations of the Session object. This functionality is not currently available and setting the SessionlD before or after a session login will not (read should not) affect any transactions that are committed within the scope of the session.

Example

Substitute TerminallD Property (Session Object)

The TerminallD property contains the TerminallD for the session.

Syntax objSession. TerminallD

Data Type

String Comments

The TerminallD is required before a valid session can be obtained.

Example

With objSession

.TerminalD = "TI001" End With

Substitute Sheet Transactions Property (Session Object)

The Transactions Property returns a single Transaction object or a Transactions collection object.

Syntax

Set objTrαnsαctions = objSession. Transactions Set objTrαnsαction = øby^'Se.« on.Transactions ^'n<iex) Set objTrαnsαction = objSession.Transac ons(nαme) objSession

Object. A Session object. objTrαnsαctions

Object. A Transactions collection object. objTrαnsαction

Object. A Transaction Object. index

Long. Specifies the number of the Transaction within the Transactions collection. Ranges from 1 to the value specified by the Transactions collection's Count Propery. name

String. A Transaction ID.

Data Type

Object (Transaction or Transactions Collection)

Comments

Example

Substitute Sh Amount Property (Transaction Object)

The Amount property contains the amount for the transaction.

Syntax objSession.Amount

Data Type

Long

Comments

The amount property is represented in base units of currency. Example, for SAUD, the long contained in the Amount property would represent cents.

The amount property represents the amount for the transaction. This must be set by the application if the amount for the transaction is different than the amount calculated as the total of the associated product objects. The Amount property will (read should) default to the total of the associated product objects when the transaction is commited.

Example

With objSession

.Amount = 133414 End With

Substitute She CardExpiryMonth Property (Transaction Object)

The CardExpiryMonth property represents the 2 digit expiry month of the credit card specified by the CardNumber property.

Syntax objSession. CardExpiryMonth

Data Type

Integer

Comment

The CardExpiryMonth Property accepts and Integer in the range 1 - 12 representing the 2 digit month of the expiry date on a credit card. If the value given when setting the CardExpiryMonth property is outside this range, then the property defaults back to 0 and the transaction will return an error indicating an invalid expiry date when an attempt is made to commit the transaction.

Example

With objSession

.CardExpiryMonth = 4

.CardExpiryYear = 0 End With See Also CardExpiryYear Property

Substitute Sheet CardExpiryYear Property (Transaction Object)

The CardExpiryYear property represents the 2 digit expiry year of the credit card specified by the CardNumber property.

Syntax objSession. CardExpiryYear

Data Type

Integer

Comments

The CardExpiryYear Property accepts a year value as an integer in both 2 and 4 digit format. If the specified Integer is between 0 and 99 it is assumed that this represents a 2 digit date between the year 2000 and 2099. If the specified Integer is between 2000 and 2099 it is assumed that this represents a 4 digit date between the year 2000 and the year 2099.

See Also CardExpiryMonth Property for handling of values outside the accepted ranges.

Example

See CardExpiryMonth Property.

See Also

CardExpiryMonth Property.

Substitute CardName Property (Transaction Object)

The CardName property contains the full name of the card holder of the credit card specified in the CardNumber property.

Syntax objSession . CardName

Data Type

String

Comments

Example

See Also

CardNumber Property (Transaction Object)

Substitute Sheet CardNumber Property (Transaction Object)

The CardNumber property contains the card number of the credit card that is referenced by the transaction.

Syntax objTrαnsαction . CardNumber Data Type

String

Comments

The CardNumber property is required before a transaction can be committed.

Example

This example represents setting the credit card details for a transaction object. The card details shown here would be from a card belonging to John Citizen with a number of 4502 0000 0000 0000 that expires on January 2000. With objTransaction

.CardNumber = "4502000000000000"

.CardName = "John Citizen"

.CardExpiryMonth = 1

.CardExpiryYear = 0 End With See Also

CardName Property (Transaction Object) CardExpiryMonth Property (Transaction Object) CardExpiryYear Property (Transaction Object)

Substitute Sheet Code Property (Transaction Object)

The Code property returns the response code received from the IWN Engine after a Transaction has been committed.

Access

Read Only

Syntax objTrαnsαction .Code

Data Type

Integer

Comments

Example

See Also

IWN Engine Error and Return Codes

Substitute Sheet CurrencyType Property (Transaction Object)

The CurrencyType property contains the the Currency type of the amount specified in the Amount property.

Access

Read/Write.

Syntax

ObjTrαnsαction. CurrencyType

Data Type iwnCurrencyType

Comments

The value contained in the CurrencyType property represents a value from the iwnCurrencyType enumerator.

Example

The following example would set the result in a Transaction for $100.00 Australia Dollars. With objTransaction

.CurrencyType = AUD

.Amount = 10000 End With See Also Amount Property (Transaction Object)

Substitute Sheet Description Property (Transaction Object)

The Description property returns the description property received from the IWN engine after a transaction has been committed.

Access

Read Only.

Syntax ob/Traπi'αctrøn.Description

Data Type

String.

Comments

Example

Dim sDescription As String sDescription = objTransaction.Description

See Also

Code Property (Transaction Object)

RRN Property (Transaction Object)

Substitute Sheet Products Property (Transaction Object)

The Products property returns a single Product object or a Products collection object.

Access

Read Only.

Syntax

Set objProductss = objTrαnsαction. roducts Set objProduct = objTrαnsαction.Products(index) Set objProduct = objTrαnsαction.Products(nαme) objTrαnsαction

Object. A Transaction object. objProducts

Object. A Products collection object. objProduct

Object. A ProductObject. index

Long. Specifies the number of the Product within the Products collection. Ranges from 1 to the value specified by the Products s collection's Count Property. name

String. A Product ID. This can be identified as the Product objects ProductID property.

Data Type

Object (Product or Products collection)

Comments

Example

The following example would retrieve the Product object for a product with a product id of 131001 from the Products collection in the Transaction object.

Substitute Sheet Dim objProduct As Product

Dim objTransaction As Transaction

Set objProduct = objTransaction.Products("131001")

The following example would iterate through all the products in the Transaction objects Products collection and display the Product objects ProductlD property.

Dim objTransaction As Transaction

Dim iCount As Integer

For iCount = 1 To objTransaction. Products. Count - 1

Debug. Print objTransaction. Products(iCount). ProductlD

Next

See Also

Product object.

Substitute Sheet RRN Property (Transaction Object)

The RRN property returns the receipt number of the response received from the r N engine after a transaction has been committed.

Access

Read Only.

Syntax objTrαnsαction . RRN

Data Type

String.

Comments

Example

Dim sRRN As String sRRN = objTransaction.RRN

See Also

Code Property (Transaction Object)

Description Property (Transaction Object)

Substitute Sheet SessionlD Property (Transaction Object)

The SessionlD property returns the Session ID of the parent session under which the Transaction was created.

Access

Read Only.

Syntax objTrαnsαction. SessionlD

Date Type

String

Comments

Example

See iwnexample example.

See Also

Session object

SessionlD Property (Session Object)

Sub i SystemTrace Property (Transaction Object)

The SystemTrace property returns the system trace code of the response received from the IWN engine after a transaction has been committed.

Access

Read Only. Syntax objTrαnsαction .SystemTrace Date Type

Integer.

Comments

Example

Dim iSystemTrace As Integer iSystemTrace = objTransaction. SystemTrace See Also

Code Property (Transaction Object) Description Property (Transaction Object) RRN Property (Transaction Object)

Substitute Sheet TransactionlD Property (Transaction Object)

The TransactionlD property returns the transaction id of the transaction object.

Access

Read Only.

Syntax obj Transaction. TransactionlD

Date Type

String.

Comments

The TransactionlD property is automatically assigned by the IWN engine through the Session object when the Transaction object is created. After the transaction has been created, the transaction id cannot be changed.

Example

See Also

Substitute Sheet Count Property (Transactions Object)

Returns the number of items in the Transactions collection.

Access

Read Only.

Syntax objTrαnsαctions. Count

Date Type

Long.

Comments

Example

See Also

Substitute Sheet Count Property (Products Object)

Returns the number of items in the Products collection.

Access

Read Only.

Syntax objProducts. Count

Date Type

Long.

Comments

Example

See Also

Substitute Sheet Item Property (Transactions Object)

Returns a Transaction object from a Transactions collection. The Item property is the default property of the Transactions object.

Access

Read Only Syntax objTrαnsαctions. ltem(index) objTrαnsαctions. Item(key) index

Long. A number in the range of 1 to the value of the Transactions object Count property. key

String. The transactions id of an individual Transaction object.

Date Type

Object. Transaction object.

Comments

Example

See Also

Substitute Sheet Item Property (Products Object)

Returns a Product object from a Products collection. The Item property is the default property of the Products object.

Access

Read Only Syntax objProducts.lte (index) objProducts.Item(key) index

Long. A number in the range of 1 to the value of the Products object Count property. key

String. The product id from an individual Product object.

Date Type

Object. Product object.

Comments

Example

See Also

Substitute She Methods

Substitute Sheet Login Method (Session Object)

The Login method contacts the IWN engine and requests a session in which to transfer transactions.

Syntax

Password) objSession

Required. Object. Session Object. Email

Required. String. Email address, also referred to as usemame. Password

Required. String. Password associated with the supplied username.

Return Type

Boolean

Comments

The Login method contacts the IWN engine, requests a session and retrieves a session id. If the Login method is successful, the Login method will return True. If the Login method cannot obtain a session id for any reason it will return False and set an error.

Example

See Also

Logout Method (Session Object)

SessionlD Property (Session Object)

Substitute Sheet Logout Method (Session Object)

The Logout method closes a session created by the Login method and clears any stored session information.

Syntax objSession.Logout Return Type

Boolean

Comments

The Logout method will close a open session and clears all session related data.

Example

See Also

Login Method (Session Object)

Substitute Sheet Add Method (Transactions Collection Object) Adds a Transaction object to a transactions collection. Syntax

Set objTrαnsαction = objTrαnsαctions. Add objTrαnsαction

If the Add method returns True, contains the new Transaction object. objTrαnsαctions

Required. The Transactions collection object.

Return Type

Object. Transaction object.

Comments

The Add method contacts the FNN server for a valid transaction id. If the Add method can obtain a valid transaction id, then it will return a valid Transaction object.

Example

See Also

Substitute Sheet Delete Method (Transactions Collection Object)

This method has been disabled and is under review. It should not be utilised in a calling application.

Deletes a Transaction object from a Transactions collection object.

Syntax

Return Type

Comments

Example

See Also

Substitute Sheet Send Method (Transaction Object)

Commits a transaction to the IWN engine.

Syntax objTrαnsαction. Send

Return Type

Boolean.

Comments

The Send method queues a transaction for sending to the IWN engine. If the Send method was able to successfully que the transaction, it will return True. If the Send method is unable to queue a transaction, it will return False and set an error. The Send method is asynchronous, a return value of True does not indicate that the transaction was sent successfully, it only means that the transaction was successfully queued. When a transaction is sent, the Send method will raise the Response event in its parent Session object, indicating whether the transaction was successfully sent. If the Send method successfully transmits the transaction to the IWN engine and receives a valid response, it will set the values of the Code, Description and SystemTrace properties to those received in the response.

Example

See Also

Substitute Sheet Add Method (Products Collection Object) Adds a Product object to a products collection. Syntax

Set objProduct = objProducts. Add objProduct

If the Add method returns True, contains the new Products object. objProducts

Required. The Products collection object. Return Type Object. Product object. Comments Example See Also

Substitute Sheet Delete Method (Products Collection Object)

This method has been disabled and is under review. It should not be utilised in a calling application.

Deletes a Product object from a Products collection object.

Syntax

Return Type

Comments

Example

See Also

Substitute Sheet Events

Substitute She Enumerations

Substitute Sheet Error Codes

S

Claims

Claims

1 An electronic commerce system comprising a seπes of point of sale terminals providing for point of sale information handling of a number of businesses. an interconnection network interconnecting the point of sale terminals to a central database facility. a central database facility for stoπng information about each of said businesses for access by the operators of said point of sale terminals, and a series of service providers interconnected to said central database facility for meeting requests issued by said point of sale terminals

2 A system as claimed in claim 1 further compnsing a seπes of suppliers interconnected to said central database facility for meeting requests issued by said point of sale terminals

3 system as claimed in claim 2 wherein said suppliers include at least one ot an import/expert agent, a warehousing agent or a producer

4 A system as claimed in any previous claim wherein said service providers include one of a third party information vendor providing information upon request, a financial transaction vendor providing financial transaction authoπsation upon request, or an order fulfilment vendor providing order fulfilment upon request

5 A system as claimed in any previous claim wherein said point of sale terminals include local database information and programs which are downloaded on demand from said central database facility 6 A system as claimed in any previous claim wherein the point of sale terminals to interact with the said main remote data-store wherein any changes to the local datastore are peπodically updated to the main datastore. and where relevant produced as part of the clients web page

7 A system as claimed in any previous claim further compnsing access means for accessing the datastore as a member of the general public using a web browser and further means for communicating in a timely manner directly to the Point of Sale merchant and if that merchant is there then communicating with the merchant in actual time

8 A system as claimed in any previous claim wherein said request are tranmitted in the form of XML documents or the like to and from said central database facility

9 A system as claimed in any previous claim further compnsing a senes of user mobile data entry devices which interact with said point of sale terminals in the authonzation ot a transaction 10 A system as claimed in claim 9 wherein said mobile data entry device include one of WAP enabled phones, mobile phones or bluetooth connected devices

1 1 A system as claimed in any previous claim further compnsing a separate interaction unit for users to interact with said central database facility for the viewing of transaction statistics associated with said system

12 A system as claimed m claim 1 1 wherein said viewing of transaction statistics includes utilising OLAP facilities on said central database

Substitute Sheet 13 A system as claimed in any previous claim wherein requests are provided by a software development kit applications programming interface

14 A system as claimed in any previous claim wherein actions undertaken by said database facility are in the form of workflow steps executed by the facility 15 A system as claimed in claim 14 wherein said workflow is spawned by the template structure of said request

16 A system as claimed in any previous claim further compnsing an interactive graphical database for interacting with said central database facility

17 A system as claimed in any previous claim wherein multiple centralised database facilities are provided and interact with one another to perform functions

18 An electronic commerce system substantially as herein before descnbed with reference to the accompanying drawings

19 A method of conducting commercial transactions substatantially as hereinbefore descnbed with reference to Fig 3 of the drawings 20 A method of conducting electronic commerce substantially as hereinbefore descnbed with reference to the accompanying drawings

Substitute Sheet