AU2001269356A1 - Real-time global tariff and import data system and method - Google Patents

Description

REAL-TIME GLOBAL TARIFF AND IMPORT DATA SYSTEM AND METHOD _

Field of the Invention

The present invention generally relates to systems and methods for providing tariff and import data. More specifically, the present invention relates to computer systems that determine and make such data available over a network.

Cross Reference to Related Applications

This application claims the benefit of priority from commonly owned U.S. Provisional Patent Application Serial Number 60/207,788, filed May 30, 2000, entitled SYSTEM FOR PROVIDING CONTINUOUSLY UPDATED REAL TIME GLOBAL CUSTOMS, TARIFF AND IMPORT DATA VIA A COMPUTER NETWORK; U.S. Provisional Patent Application Serial Number 60/232,088, filed September 12, 2000, entitled GLOBAL PRODUCT IDENTIFICATION SYSTEM FOR DETERMINATION OF TARIFFS; U.S. Provisional Patent Application Serial Number 60/250,407, filed November 30, 2000, entitled MASTER UNIVERSAL TARIFF SOFTWARE; and U.S. Provisional Patent Application Serial Number 60/279,641, filed March 29, 2001, entitled MASTER UNIVERSAL TARIFF SYSTEM AND METHOD, incorporated herein by reference.

Background of the Invention

Over the past several years there has been a simultaneous growth in international trade and global interaction and expansion of the World Wide Web ("the Web"). Increasingly, nations and regions are entering into trade agreements to facilitate increased international trade. World markets are becoming more intenelated and the demands for the importation of goods and services is growing accordingly. Part of the increased demand may also be attributed to the growth of the Web. The Web allows consumers, whether businesses, organizations, or private individuals, to shop the world on-line, from the convenience of a home or office computer.

Unfortunately, despite increased activity and demand, issues sunounding international transactions remain. That is, for each purchase of a product from another country, certain tariffs (or duty) and import taxes are usually applied to the transaction. Tariff rates and tax rates are country specific and change from time to time. Additionally, for each country, duty rates and tax rates tend to vary among types or categories of products, thus multiplying the complexity and volume of duty and tax information. |

Keeping track of such a large volume of information can be a daunting and expensive undertaking for a seller (e.g., retailer or distributor). As a result, fulfillment of international orders emanating from customers located around the globe is attempted by only a small percentage of companies, due to the complexities of shipping across international borders. Of that small percentage that does attempt fulfillment of international orders, most usually only ship to a handful of countries.

5 To enable businesses, organizations, and individuals to more readily conduct international transactions, there is a need for a comprehensive system that provides updated tariff and tax information, as well as other transaction related costs and infonnation. There is a further need for such a system to be a real-time system and for it to be accessible and functional over the Web, or other networks.

Lo Summary of the Invention

The present invention is a system and method for providing real-time tariff and import data over a computer network, preferably including the calculation of total landed cost. A duty calculation engine accesses relevant tariff rates and applies the rate that is applicable to arrive at a duty calculation. An import tax calculation engine accesses relevant databases of country

L5 specific import tax rates, charges and fees and applies them to arrive at import tax costs. A total landed cost calculation engine calculates a total landed cost from the calculated duty (or tariff) and import tax, along with other transaction related costs, such as freight and insurance costs.

A real-time tariff and import data system in accordance with the present invention, may be implemented as a business-to-business ("B2B") system, a business-to-consumer ("B2C") i o system, or as some combination thereof. The system may be accessed over one or more of any of a variety of networks, such as local area networks (LANs), wide area networks (WANs), virtual private networks (VPNs), intranets, extranets, the World Wide Web (the "Web"), the Internet, telephone networks or some combination thereof.

The real-time tariff and import data system includes databases having cunent duty and

! 5 tax rate information for a plurality of countries. These databases are coupled to a set of servers, for example, which host the duty calculation, tax calculation, and total landed cost calculation engines. The servers are accessible by any of a number of types of network enabled devices, such as personal computers (PCs), workstations, other (third party) servers or systems, personal digital assistants (PDAs), telephones, or other such devices. The data in the databases may be i o automatically updated by remote third party sources or they may be updated locally, or some combination thereof. Also, rather than representing each country in the system databases, the real-time tariff and import data system servers may link to third party sources of such tariff and tax information. The databases are kept substantially current, to provide accurate information to customers. The content of the databases may embody trade restrictions imposed between countries. That is, where a country prohibits trade with another country, the real-time tariff and import data system may include a transaction validity checker that alerts the customer that the input transaction is forbidden by one of the countries (e.g., destination country) involved. For

5 example, the United States prohibits the importation of cigars from Cuba. If a customer entered information for such a transaction, the real-time tariff and import data system maybe configured to alert the customer to the trade restriction or may refuse to perform the requested calculations.

Users enter transaction inputs via an electronic device (e.g., PC, workstation, PDA, and/or other network enabled devices configured for user input). The inputs may include one or

.0 more of a PIN (if access is controlled), access code, origin country, shipment (or export) country, destination (or import) country, input code type, product code, transaction value, number of units being bought, unit code, cost of transportation, insurance cost, other (ancillary) costs, transaction currency, conversion cunency, and output format code.

The access code input specifies whether the duties and taxes are calculated within or over

.5 a volume quota for a given product in a given country. The origin country is the country from where the product is considered to be manufactured. The shipment country is the country from where the products are sent. And, the destination country is the country to where the products are to be sent, also refened to as the country of importation. The input code type represents the type of input given for the product code (e.g., HS code or user defined product code). The product

! o code identifies the category of the product. The unit code specifies the units (e.g., pounds, liters and so on) associated with the products, and the number of units tells how many units are being imported (e.g., 10, 000). A desired output format from a predetermined set of output formats can be specified by the user through entry of an output format code. Output formats include duty rate, duty amount, detailed duty, tax rate, tax amounts, detailed taxes, duty and tax rates, duty and

15 tax amounts, detailed duty and tax output, or total landed cost.

The inputs are entered into an on-line request form, which may be an XML (extensible Markup Language) document, for example. Preferably, the present invention includes a Web- based interface that allows users to interact with the system and get duty tariff and import data system servers to produce an output, in accordance with the chosen output format. As a Web

, o accessible system, the real-time tariff and import data system is configured to provide real-time import duty, tax, and total landed cost information for shipments among the various countries represented in the databases. hi the present invention, the real-time tariff and import data system maybe accessed by any of a variety of client device configurations, such as Web user client, a Java client 102B, and an XML client. Regardless of the configurations of the client device, communication between the client device and the real-time tariff and import data system is preferably accomplished using standard communication and format protocols and languages, such as the Internet Protocol and XML. Additionally, communication using encryption and access control mechanisms may be

5 used.

In various embodiments, the present invention may include functionality or links to insurance providers for obtaining insurance cost figures and/ or to transportation providers for obtaining transportation figures. Additionally, the present invention may also facilitate or enable the purchasing of such insurance and transportation, hi such embodiments, the user need not

L0 input insurance or transportation cost information, as the case may be, and the outputs may variously include the system calculated insurance and transportation costs.

The real-time tariff and import data system may provide for customer account and billing, based on use, transactions, or flat fee structures. The system may serve as a back-end system for a third party, or as a front end system that is directly accessible by customers.

L5

Brief Description of the Drawings

The foregoing and other objects of this invention, the various features thereof, as well as the invention itself, may be more fully understood from the following description, when read together with the accompanying drawings, described: !0 FIG. 1 is a representative architecture of the real-time tariff and import data system, in accordance with the present invention;

FIG. 2 is an architecture of a distributed real-time tariff and import data system, in accordance with the present invention;

FIG. 3 is a software architecture for the real-time tariff and import data system of FIG.1 !5 or FIG. 2;

FIG. 4 is a block diagram showing the primary functional components of the software architecture of FIG. 3;

FIG. 5 is a diagram depicting a standard Web browser-based approach to client-server exchange with the real-time tariff and import data system of FIG. 1 and FIG. 2; i o FIG. 6 is a diagram depicting a Java-based approach to client-server exchange with the real-time tariff and import data system of FIG. 1 and FIG. 2;

FIG.s 7 A, 7B and 7C are diagrams depicting XML request string exchange and processing by the real-time tariff and import data system of FIG. 1 and FIG. 2;

FIG.s 8A, 8B and 8C are diagrams depicting Web-based request exchange and processing by the real-time tariff and import data system of FIG. 1 and FIG. 2; and

FIG. 9A and 9B are diagrams depicting Java-based request exchange and processing by the real-time tariff and import data system of FIG. 1 and FIG. 2

For the most part, and as will be apparent when referring to the figures, when an item is 5 used unchanged in more than one figure, it is identified by the same alphanumeric reference indicator in all figures.

Detailed Description of the Preferred Embodiment The present invention is a system and method for providing real-time tariff and import data over a computer network, including the calculation of total landed cost. In the prefened LO form, a duty calculation engine accesses relevant tariff rates and applies the rate that is applicable to arrive at a duty calculation. An import tax calculation engine accesses relevant databases of country specific import tax rates, charges and fees and applies them to arrive at import tax costs. A total landed cost calculation engine determines the total landed cost from the duty calculation and the import tax calculation, along with other transaction related costs, such as transaction L5 value, freight and insurance costs, type of good(s), import, shipment, and export countries.

A real-time tariff and import data system in accordance with the present invention, may be implemented as a business-to-business ("B2B") system, a business-to-consumer (B2C) system, or as some combination thereof. The system maybe accessed over one or more of any of a variety of networks, such as local area networks (LANs), wide area networks (WANs), virtual i o private networks (VPNs), intranets, exfranets, the World Wide Web (the "Web"), the Internet, telephone network, or some combination thereof. The real-time tariff and import data system may serve as a front-end system, directly accessible by those seeking tariff, import tax and/or total landed cost data for a transaction. In other embodiments, the real-time tariff and import data system may serve as a back-end system, coupled to a front-end international transaction 25 system, for example.

Part I - Hardware and Software Architecture

FIG. 1 shows a representative architecture 100 implementing the present invention. Architecture 100 includes a set of client devices 102 configured to access the real-time tariff and import data system 120 via the Internet 104. Access to the real-time tariff and import data i o system may be provided via a standard router 106 and firewall 108.

In accordance with the prefened embodiment, the real-time tariff and import data system 120 makes information accessible regarding tariffs in approximately 225 countries for approximately 5,800 products listed in the Harmonized Coding System (HCS), which are represented as established country-based product Harmonized System (HS) codes. Along with information on various customs duties, applicable tax rate information is provided for a plurality of products, and vital information necessary or useful for doing business in various countries. Such information is stored and managed by a database management system 140.

Preferably, the real-time tariff and import data system 120 includes the following 5 characteristics:

(1) High Level of Availability: To simultaneously accommodate the needs of clients around the globe, the system is preferably accessible for substantially 24 hours a day, 7 days a week, for a total availability rate of approximately 99%, or more. To accomplish such high availability, the system architecture accommodates a minimal mean-time-to-recovery (i.e., not

LO more than a few seconds), which may be accomplished, at least in part, with customary redundancy, "hot spares", and fail-over mechanisms. As examples, for a 99% availability rate, the system can not be down for more than 88 hours per year (i.e., up for 8,672), and for an availability rate of 100% the system is down for 0 hours per year (i.e., up for 8,760).

(2) High Level of Transparency of System Faults: Owing to the recovery mentioned

L5 above, client-users are substantially unable to detect that a system fault has occuned. In a worst- case scenario, response time of the system is only prolonged by a few seconds, rather than producing enor messages or terminating jobs.

(3) Ability to Cope with a High Volume of Transactions: User traffic is an important factor to take into consideration with regard to bandwidth use. Indeed, the width of the

20 bandwidth is an important element in the system response time. The following table, Table 1, presents the number of concunent users that can be supported, depending on the kind of bandwidth used (calculated for a connection lasting in the order of 15 seconds):

*These values are estimates and may vary, but they are useful as guidelines in choosing !5 connection types.

TABLE 1 - Concunent Users (4) Tamper-Proof Data and Transaction Security: Use of a variety of security mechanisms, discussed in detail below, provide for control of access to data and protection o databases against attacks via the Internet, and ensures the confidentiality of clients' transactions.

(5) Accuracy of the information contained in databases 146: Customs information varies 5 from country to country. Additionally, countries often pass new laws that change tariffs from one year to the next, or even in the course of the same year. The real-time tariff and import data system 120 allows for the expedient integration of these changes, by accommodating automated information distribution and database updates. Database updates may be accomplished locally, remotely (possibly via third party systems), or some combinations thereof, as discussed in more

LO detail with respect to FIG. 5.

The hardware architecture shown in FIG. 1 embodies the characteristics outlined above. The real-time tariff and import data system architecture 120 includes a cluster of front end application servers 130, as a first logic or application layer, coupled to a back end database management system 140, as a data layer. In the architecture of FIG. 1, the application servers

L5 132 and 134 are accessible via the Internet through a local network 112, which includes router 106 and firewall 108. Firewall 108 protects servers 132 and 134 from Internet attacks by filtering and controlling access to the servers, which is discussed in more detail below.

Generally, one of the major factors in the reliability of a Web site is the reliability of the servers used to host the Web site. Each of application servers 132 and 134 serve as intelligent

20 relief systems to the other; they "know" (i.e., monitor) each other's status, which aids in the processes of load balancing and fault recovery.

While FIG. 1 shows the application layer to include two application servers, a greater number of servers may be used and they may be located at geographically local or remote locations, or some combination thereof. The architecture of FIG. 1 offers scalability, in that

! 5 more servers may be easily added. In the prefened embodiment, an increased number of servers allows increased availability. Additionally, the processing load of the various application object components that are to be executed at a given time on the servers is dynamically balanced among the clustered application servers 130. In the prefened embodiment, the applications running on servers 132 and 134 are written in object oriented code. i o Both application servers, 132 and 134, are configured to respond to client requests, so that they can easily share the load. A load-balancing module distributes requests between servers 132 and 134, such modules are known in the art and not discussed in detail herein. If one server (e.g., server 132) is no longer responding, all requests must then be directed towards the other server (e.g., server 134), or other servers if there are more than two application servers. The load-balancing module is replicated on both (or all) application servers, which allows the application servers to ensure continuous request distribution, regardless of which server(s) go down. To ensure system fault tolerance, status information is also replicated on each application server. Thus, even minor faults can be hidden from users, leaving application processing

5 substantially unaffected.

In FIG. 1, the application layer clustered servers 130 are coupled to the data layer 140 via a local network 122 that includes a switch 124 and firewall 126. The database management system 140, or data layer, includes the data servers 142 and 144 and the databases 146 that include all of the tariff and other import data. In the prefened form, database 146 includes a set

LO of shared RAID (Redundant Anay of Inexpensive Disks) external disks . RAID systems are known in the art and not discussed in detail herein. In the prefened form, the data layer servers 142 and 144 of FIG. 1 are Microsoft SQL servers, clustered using standard clustering technology (e.g., such as that provided by Microsoft Corporation of Redmond WA).

The architecture of the data layer 140 is designed to provide maximum data availability.

L5 That is, if one server (e.g. server 142) breaks down, the other server (e.g., server 144) takes over in a manner that maintains transparency to users. Therefore, transactions that are taking place during a database management system 140 fault will not be interrupted, since the requests sent to the faulty server will be automatically transfened to the active server. Since both data layer servers 142 and 144 are connected to RAID external disks 146, disk faults can be dealt with one

2 o disk at a time, without halting tasks. Using background monitoring, a problem with one disk can be detected before a fault occurs so that the damaged disk can be replaced before service is interrupted.

Both servers 142 and 144 share a "heartbeat" connection, are part of a local network, are linked to the Internet, and require the use of dual Ethernet network interface cards, in the

^»5 prefened embodiment of FIG. 1. In this configuration, the database servers 142 and 144 have public IP addresses in order to facilitate data updating operations, but this can expose the servers 142 and 144 to attacks from the Internet. To protect against such attacks, firewall 126 is used to filter requests to the database servers 142 and 144. Thus, only the logical layer servers 132 and 134, i.e., the servers used for updating data (replication), will be able to access the database i o servers 142 and 144, and server 132 and 134 are also protected by firewall 108.

The databases 146 of database management system 140 includes the following information or databases:

(1) Customs tariff and taxes databases,

(2) Customs infonnation databases on various countries, and (3) System client databases (where the system maintains client-user accounts).

As previously mentioned, real-time tariff and import data system 120 may include multiple application servers in different locations to provide a more robust fail-over solution, in case of major disaster at one site, as is shown in FIG. 2. As previously mentioned, the real-time 5 tariff and import data system 120 is preferably a Web-accessible system. Therefore, a request may be submitted to a Domain Name Server (DNS) 250 which then returns up to two specific IP addresses. Since the real-time tariff and import data system 120 has multiple servers in different locations, in this embodiment, the DNS server 250 returns the optimal address 252 and the second best address 254. The optimal address 252 can be defined as the one with the lowest LO latency and with an acceptable load.

To provide a fail-over solution and to provide high availability, the client application 260 must react when the response is not sent back after an acceptable timeout. It is prefened that after an acceptable timeout expires, the request is resent a certain number of times to the DNS server 250. To use this feature, a toolkit or client application 260 is configured support the .5 following:

(1) multiple IP addresses in response to it's address resolution request, and

(2) the ability to try to connect using the second IP address, if the first IP address attempt is unsuccessful.

Preferably, the DNS server 250 always returns up to two JJP addresses, so if the optimal so application server 130A (with DB management system 140A) is down, the client application 260 (or device) redirects the request to the second best application server 130B (with DB management system 140B), after an acceptable timeout as been expired. However, if the client application 260 or toolkit does not support this feature, only the optimal IP address will be available to the client application 260. To have a full fail-over proof client application 260, the !5 timeout is preferably set to be about 10 seconds. Also, when the timeout expires, the client application 260 is configured to re-send the request, alternating from the optimal server 130A to the second best server 130B.

The prefened embodiment of a software architecture 300 of the real-time tariff and import data system 120 is shown in FIG. 3, which serves as the system's logical structure. This i o logical structure allows for optimal use of resources from different servers. The application servers 132 and 134 support transparent replication, load balancing and fail-over for both the dynamic generation of Web pages (i.e., at the presentation layer) and components (i.e., at the logical layer components).

The real-time tariff and import data system 120 main application object components 400 are shown in FIG. 4 and described below.

(I) A TFeedClient object component 402 includes all relevant information for customers (e.g., corporate customers) known to the system and provides methods for accessing specific customer information, which maybe stored in customer accounts.

5 (2) TFeedMsgPKCS object component 404 is configured to customize security levels to client specifications. Data exchanges may be conducted in encrypted or plain-text format. For encrypted transactions, this object component 404 can encrypt and decrypt messages, however, this function requires that public and private access keys be installed in both the customer's system (or client device) and on the application servers 130.

LO (3) TFeedReqMsg object component 406 prepares received client requests for the other system components. Requests may use the HTTP protocol, may be made directly from the components Java installed in the customer's system or may use an XML format, as described in greater detail below. The TFeedReqMsg object component may be instantiated using any one of these sources.

L5 (4) TFeedRespMsg object component 408 prepares a response to a client request and transmits the response to the client (via TFeed-Servlet, if needed). Responses are directly delivered using HTTP protocol or using an XML format from the TFeedRespMsg object component 406, as described in further detail below with respect to the data exchange process.

(5) TFeedXMLMgr object component 410 manages the exchange of information between 2 o the real-time tariff and import data system 120 Web site and clients using an XML format.

(6) TFeedDFeeCalc object component 412 calculates duty fees (i.e., customs charges). This component is also refened to as the duty calculation engine.

(7) TFeedHSCtryData object component 414 provides the tariff for a country and for a specific conesponding HS code. This object component is used by TFeedDFeeCalc 412 to

25 perform customs charges calculations.

(8) TFeedHSCtryTax object component 416 provides the tax rate for a country and for a specific HS code. This object component is used by TFeedTaxCalc 418 below.

(9) TFeedTaxCalc object component 418 applies the tax rate for a product, according to the HS code provided and the country of import, to determine the tax charges This component is i o also refened to as the import tax calculation engine.

(10) TFeedBilling object component 420 manages the customer account billing process.

(I I) TFeedLog object component 422 keeps a running log of all client requests fed into the database. This information may be used as a reference for operating difficulties reported by clients or for cases in which a customer wishes to contest a bill. (12) TFeedServlet object component 424 manages incoming requests sent via a Web browser and outgoing responses, using HTTP protocol.

(13) TFeedTTLCalc object component 426 calculates the total landed cost for a transaction, using the calculated duty from the duty calculation engine 412 and the import tax

5 calculation engine 418, along with other transaction date (e.g., insurance and transportation costs).

The content of the databases may embody trade restrictions imposed between countries. That is, where a country prohibits trade with another country, the real-time tariff and import data system may include a transaction validity checker (e.g., a TFeedValidTrans component, not

LO shown) that alerts the customer that the input transaction is forbidden by one of the countries (e.g., destination country) involved. For example, the United States prohibits the importation of cigars from Cuba. If a customer entered information for such a transaction, the real-time tariff and import data system may be configured to alert the customer to the trade restriction or may refuse to perform the requested calculations.

.5 In various embodiments, the present invention may include functionality or links to insurance providers for obtaining insurance cost figures and/ or to transportation providers for providing transportation figures. Additionally, the present invention may also facilitate or enable the purchasing of such insurance and transportation. In such embodiments, the user need not input insurance or transportation cost information, as the case may be, and the outputs may i o variously include the system calculated insurance and transportation costs.

Returning to the database management system 140 of FIG. 1, a variety of operations are involved in maintaining data integrity, as discussed below. Database security requires that customer (or user) security measures be established. Therefore, security audits may be conducted on a regular basis to verify access to the database and authentication may be required for access

!5 to database 146. SQL Server offers two authentication modes:

(1) Windows NT Authentication Mode: SQL Server can use Windows NT to authenticate users. User accounts are managed and defined in Windows NT and the access rights (and roles) are defined on the SQL Server.

(2) Mixed Mode: Previous modes can be used along with the authentication mode above, i o which requires that an account be created, with username and password, on the SQL Server.

This account is saved in the system tables of the SQL Server.

In the prefened embodiment, the mixed mode is used, since it requires no control over the network and its clients (e.g., NT accounts and client network management). However, users who have different roles may also be defined on the SQL Server. By "role" it is meant that a group of users is treated as a single unit, to which access permissions can be applied. The access permission attributed and/or deleted for one role is applied to all of the users who share that role. The following table, Table 2, shows a list of predefined roles on the SQL Server. New roles may be defined to control access to the tables and/or procedures of any database.

TABLE 2 - Predefined Roles

SQL Server also has a powerful "Profiler" that records and analyzes all of the operations executed by the SQL Server (i.e., database management servers 142 and 144). The resulting reports can be saved in a text file or in an SQL Server table. Audits regarding access to the servers 142 and 144 may therefore be conducted by recording the following information: access granted; access denied; procedures used; sessions established; and user accounts used. All of this information provides an excellent support tool in establishing who has done what and when.

To protect the databases 146, backup operations are preferably conducted. Generally, there are three methods for performing data backups: (1) Offline (Cold) Backup: Database services are halted; backup operations are then carried out and the database is put back on line. During this time, the database is not available.

(2) Online (Hot) Backup: Database services are active, the database remains on line, but no access is granted during this operation.

5 (3) Active Online Backup: The database is active and is accessible by the applications.

In the prefened embodiment, option 3 above is used, since it allows backup during normal operations without interruption. This option also allows around-the-clock access. Although this operation minimally increases the server load, it is still advisable to carry out these operations during the hours when the load is at its most stable.

LO Since there is such a heavy reliance on the database content for producing accurate cost figures, a significant challenge is to guarantee that the information contained in the databases is accurate. One way to ensure the accuracy of data is to perform database updates using the functions of the SQL Server. For example, data replication provides a fast and effective way of distributing information and reducing dependency on a central database server. SQL Server

L5 allows users to replicate data from one SQL Server to another SQL Server, or to several other types of databases by different makers (e.g., Oracle, Sybase or IBM DB2). The SQL Server replication function is based on the "publish and subscribe" model in which one database infonnation server plays the role of a "publisher" while the others play the role of "subscribers", as is shown in FIG. 5. A publisher is the database system or server that makes data available for

2 o replication, and may be the "owner" or source of the data. In FIG. 5, database changes may be sent from a client device 102, for example, to a publisher database system 502. Publisher 502 maintains a list of publications (i.e., data for distribution) and subscribers for the publications. A subscriber may be a database server (e.g., servers 142 and 144) that receives and updates (or replicates) its own database data with the updated publication. Subscriber 1 504 and Subscriber

! 5 2 506 may be systems, clients, or servers which are not directly a part of the real-time tariff and import data system 120.

Generally, there are two types of subscriptions:

(1) The "pull" subscription, in which the subscriber (e.g., 142, 504, or 506) requests regular updates from publisher 502. i o (2) The "push" subscription, in which publisher 502 distributes the changes to various subscribers (e.g., 142, 504 and 506) when changes occur or according to a predefined plan.

Database management system 140 supports at least three types of replication between a publisher and subscribers:

(1) Snapshot Replication: As its name indicates, this type of replication takes a photo or a snapshot of the data to be published at a given moment in time. These snapshots can be taken according to a plan or upon request. Snapshot replication uses very few system resources.

However, all of the subscriber data is refreshed. All information is transfened to the subscribers, which requires a high-performance bandwidth for high volumes of data. 5 (2) Transactional Replication: In this type of replication the changes made at the publisher level are distributed on a continuous basis or at established intervals to one or several subscribers. This type of replication is most appropriate for cases in which only one publisher is available and updates are done on this publisher. Thus, subscribers could upload changes and update their data at a predetermined time. LO (3) Merge Replication: This type of replications allows publisher 502 and subscriber 142,

504 and 506 to operate independently of each other and to periodically reconnect to update or consolidate their respective data. hi the case of the real-time tariff and import data system 120 Web site, transactional replication is prefened. Updates on customs data are carried out on a server that plays the role of L5 a publisher and all changes are distributed to subscribers.

The following steps allow implementation of replication functionality on a server that will play the role of a publisher:

(1) Installation of one version of the database;

(2) Definition of publications and articles (including table sets, information to be 2 o replicated);

(3) Configuration of publication mode (for transactional replication);

(4) Definition of a publication frequency (for data transfer to subscribers);

(5) Definition of subscribers (e.g., database servers and in client database servers); and

(6) Configuration of different firewalls or proxies for replication via the Internet.

25 The flow diagram of FIG. 6 illustrates a process 600 used to manage users that access services provided by the real-time tariff and import data system 120. First, a user operating client device 120A that wishes to use the services completes request form 802 (see FIG. 8A), which is made available on the real-time tariff and import data system 120 Web site. The form 802 is sent to the Web server, 132 or 134, and processed by a dynamically generated page using the i o TFeedClient object 402 (see FIG. 4). Next, a customer manager using device 602 accesses the reformed request 604 and validates the request by verifying the user properly entered required infonnation contained in request form 802 (e.g., username and PIN 606). The application server 130 sends a user authorization 608 to client 102 A. Customer manager 602 may open a customer (or user) account using device 602 via, for example, a Web interface. Customer manager 602, preferably, e-mails confirmation to the customer that an account has been opened. Thereafter, the customer can carry out transactions using the real-time tariff and import data system 120 by logging in, without interaction with the customer manager 602. In some cases, installation of client components maybe required on the customer's client device, as described with respect to

5 FIG.s 8A-9B. hi some embodiments, the real-time tariff and import data system 120 maybe configured to bill its customers for usage, based on, for example, number of Web site hits, transactions processed, or requested outputs. Customer account related information (or billing data) may be stored in databases 146 (or other databases) and a mechanism maybe established for customer

LO access of the billing data. There are at least two possibilities in this area:

(1) a Web interface that gives access to a secure environment for billing data, or

(2) a replication of billing data within the real-time tariff and import data system 120, allowing for a connection between a billing database and an accounting system.

The billing data maybe use or fee information contained in customer account-related tables.

L5 Preferably, the real-time tariff and import data system 120 Web site includes a management section where access to billing data is password restricted, but with proper access allows account access for billing, payment or status.

An activity log is preferably generated to monitor server operations, which may be used for billing, as well as other purposes. Activities logged with respect to server operations may

2 o include client related transaction or system performance information (e.g., enors, processor utilization, and so on). That is, a log file may contain information concerning the sources of requests (e.g., IP Addresses, PIN numbers), requested product data, the date of the request and the date and type of infonnation responses sent to clients. This file could be used by network operations or information technology personnel to resolve operations problems. The activity log

25 functionality may also include importing and maintenance information.

A significant part of the real-time tariff and import data system 120 Web site, outside of the database content and user functionality, is its security system. Access is denied to hackers and content is be protected to ensure that it remains precise and consistent. Thus, access to content is controlled, restore mechanisms are implemented, and content integrity is maintained. i o The application servers 132 and 134 used in the prefened embodiment provide the best security technology of its kind, with secure, flexible, and easy-to-confϊgure architecture. The application server secures network applications through known, optional encryption, authentication and authorization functions, based on secured SSL RSA sockets, X.509 digital certificates and access control lists (ACLs). Together, all of these security functions allow the system to determine the user of the provided services. Access to some application server 132 or 134 services is controlled through user and user group definition. The term "user" refers to a human (e.g., a customer), a computer application, client device or a remote server. This security technology maybe extended to all types of devices and users that access server resources.

5 ^' ACLs are data structures that control access to resources. Each control list entry contains a set of access permission parameters associated with a user or a user group. Access permission allows the system to carry out certain kinds of operations on server resources. Access permission maybe positive (i.e., authorization for certain kinds of operations on specific objects) or negative (i.e., prohibition of some operations on specific objects).

L o The application servers may be configured for a variety of levels of authentication. In the prefened form, application servers 132 and 134 are configured to use at least one of two processes to authenticate the users: passwords and encryption certificates. For minimal authentication, the process based on the password allows users to provide a password and their user name to access server resources. This process is based on the authentication process defined

L5 in the HTTP protocol. A drawback to this process lies in the fact that passwords and usernames are traveling over the Internet in plain text format. For a more comprehensive and powerful authentication system, in the prefened embodiment, encryption is used in the form of encryption certificates. These certificates are issued by a Certificate Authority (CA), such those certificates issued by Verisign, Inc. of Mountain View, California. so It is important to ensure that the mformation that passes through the Internet network circulates in an encrypted channel, and thus cannot be seen or altered. Therefore, application servers 132 and 134 include an SSL implementation used in distributed applications, such as 128-bit SSL Global Server IDs by Verisign. SSL Version 3 allows for connection encryption and is the standard default protocol used to establish private and encrypted communications between

25 two applications within a non-secured network. A digital certificate (or digital ID) is required on the server (e.g., server 132 or 134) for this protocol. A digital certificate allows the server to prove its identity with clients or other servers before a private connection is established. Moreover, for greater security, application servers 132 and 134 can be configured to provide two- way authentication for clients and browsers. In those cases, two-way authentication requires that i o the client system to have a digital certificate. Digital certificates are then cross-authenticated. Part II - Preparing and Processing Requests

In order to properly prepare the duty, import tax, or total landed cost of an item, a prefened set of transaction related inputs are required. Preferably, as discussed above, a request is sent from a client (e.g., client device 102) to the real-time tariff and import data system 120 via a Web site interface. In such an embodiment, the real-time tariff and import data system 120 guides the user to enter all needed inputs of the client by providing a well-structured request template or form with syntactic and semantic validation. Table 3 provides the prefened input requirements and their definitions for the request. (See also Appendix H for more information about input validation). The client's request is processed by application servers 132 and 134 of the real-time tariff and import data system 120. After processing, the real-time tariff and import data system 120 returns a response to the client.

Parameter Definition

LO PIN Number Personal identification number of the client provided by real-time customs tariffs and import data system 120.

Access Code A code that specifies whether the duties and taxes are calculated within or over a volume quota for a specific product in a specific country. If the specific quota is not known by the client, the client choose

L5 "Without" from the Web page request form. (See Appendix F).

Origin Country The country where the product is considered to be manufactured. If the product(s) are classified by the real-time tariff and import data system 120, this input is optional since it already resides in database

146 for each HS code. Otherwise, an origin country code is entered in the request and the country code in database 146 is not used. See

Appendix A B for a sample of countries and conesponding country codes.

Shipment Country The country from where product(s) are sent (i.e., the country of exportation). See Appendix A/B.

! 5 Destination Country The country to where products are sent (i.e., country of importation).

See Appendix A B. Input Code Type A code that represents the type of input specified for the Product Code parameter in the request. See Appendix G. Product Code Either user defined product code or the established HS code in the

10 system database. If a user-defined product code is entered, that user defined product code is used for the entire transaction. If the user uses an HS code, a valid HS code of the destination country is required.

Transaction Value Value of goods in the currency specified as the transaction currency parameter. Number of Units Number of units specified for the Unit Code parameter.

Unit Code If a user-defined product code is entered, a unit code (see Appendix C) and conesponding unit type (see Appendix D) specified by real-time tariff and import data system 120 must be entered. If an HS code was entered, the appropriate unit code and conesponding unit type are required. The user may be requested to send up to 10 different Unit

Codes and Numbers of Units, in the prefened form.

Cost of Transport The cost of transportation, in the cunency specified for the transaction cunency parameter. In some embodiments, this parameter may be

LO generated upon request by the real-time tariff and import data system

120 or a third party system coupled thereto.

Insurance Cost The cost of insurance, in the cunency specified for the transaction cunency parameter. In some embodiments, this parameter may be generated upon request by the real-time tariff and import data system

L5 120 or a third party system coupled thereto.

Other Costs The amount of other costs, in the currency specified for the transaction cunency parameter. Transaction Currency The cunency code used for the amount specified for the transaction

(e.g., U.S. Dollars). See Appendix A B.

20 Conversion Currency The currency code used for the results to be provided by real-time tariff and import data system 120, for any output format under which dollar amounts are presented. See Appendix A/B.

Output Format Selected by entry of one of the predefined output format codes provided by real-time tariff and import data system 120. See

25 Appendix E.

TABLE 3 - User Inputs

hi the prefened embodiment, a user can obtain the duty, tax and total landed cost associated with an international sale and shipment of one or more products by entering the above i o inputs. Preferably, the real-time tariff and import data system 120 guides the user to properly enter inputs. When entering the required inputs (previously discussed), the user determines whether to use its own product codes or standard HS codes in the request. If the user uses its own product codes in requests, those product codes can be entered into the system during a classification phase, as part of a user/customer account setup, so that they will be recognized when forming requests. Thereafter, the user can send requests using its own set of codes or the HS codes, either will be valid for the specified unit type. If real-time tariff and import data system 120 also requires a weight unit for the entered product, the request can contain any valid unit code representing a weight: grams, kilograms, pounds, and so on.

5 The real-time tariff and import data system 120 requires all measurement units to precisely calculate duties and taxes. Even when using HS codes in the request, the user must include all required units. If a unit is omitted, real-time tariff and import data system 120 returns an enor message indicating that a unit is missing. For example, certain countries require more than one measurement unit to calculate duties and taxes, or have "multiple units". For example,

LO assume that a user plans to import wine from the United States to Canada. Canadian authorities calculate duties and taxes depending on the number of wine bottles being imported and the volume of pure alcohol. Therefore, the user needs to send two unit types in the request: a number of wine bottles and pure alcohol volume.

The real-time tariff and import data system 120 provides a default unit code for each unit

L5 type known to the system, see Appendix D. When referring to Appendix D, the "Unit Base" column represents the default unit code. All other unit codes from the same unit type have a conversion factor based on the default unit code. Specifying the default unit code in the request typically reduces the response time, since the real-time tariff and import data system 120 will not need to perform a units conversion.

20 hi the prefened embodiment, there are at least three methods for exchanging data between users' (e.g., customers with accounts) client devices and the real-time tariff and import data system 120 Web site. These methods provide users with a large range of request structure possibilities. According to these methods, a client may be a Web user client 102A, a Java client 102B, and/or a client using XML stringl02C, as examples. Because of its open-ended, flexible

! 5 and self-descriptive characteristics, the prefened embodiment uses XML technology to exchange infonnation with each type of client device. Thus, an XML format for the information exchanged between the clients and the real-time tariff and import data system 120 Web site is defined. That is, XML is used as a universal data exchange format, regardless of the type of client, as defined below. i o 1. XML Clients - To accommodate access by XML clients 102C, the real-time tariff and import data system 120 provides an HTTP service that accepts user inputs as part of a text/XML request from a client, as can be appreciated with respect to FIG.s 7A-C. XML technology is used because it is supported by a variety of programming languages and by Web scripts, such as VBscript or Javascript. XML technology is derived from SGML, a relative of HTML, and defines a syntax for understanding and a format for data processing information. XML syntax includes a series of tags used to insert markers into a document, and is generally known in the art. For example <Product> marks the beginning of the definition of a product and </product> marks the end. A product definition in XML can be written as follows:

5 <product hscode=" 12124560" country="ca" quantity="5000" />

Once analyzed, this XML block will be interpreted as an entity containing three attributes: "hscode," "country," and "quantity." An application can directly retrieve the value of a particular attribute without taking into account the order of the attributes within the document.

Generally, XML technology is open-ended and flexible. For example, an attribute

.o "Price" may be added to a Document Type' Definition (DTD) document in order to support the specific needs of a new client application, but the existing client applications would not be affected, since they would continue to search for valid, previously defined attributes. The DTD document is used to validate its conesponding XML documents, thus ensuring that the XML format respects the format specified in the DTD document, so is much less prone to having or

.5 causing enors. An XML document can be defined without using a DTD document, but use of a DTD document is prefened. Generally, applications access an XML document using a series of functions defined in a DOM (Document Object Model). A DOM is an XML application that provides a standard programming interface that allows an application to use the information defined within an XML document. FIG. 7A illustrates, at a top level, the interaction between the

! o real-time tariff and import data system 120 and XML client 102C. An XML request message including an XML request string 702 is sent to and processed by server cluster 130 (including servers 132 and 134). Server cluster 130 returns an XML response message including an XML response string 704, as discussed in further detail below.

The communication between client device 102C and real-time tariff and import data is system 120 is shown in flowchart 710 of FIG. 7B. FIG. 7C shows a detailed view of the components involved in carrying out the steps of flowchart 710. hi step 712, a client application 780 of client 102C gathers user input data to generate one or more client application request messages 742. In step 714 of FIG. 7C, using the data, the client application 780 generates a plurality of requests, i.e., Request 1 716A, Request 2 716B, and Request n 716C. When possible, i o generating multiple requests allows for more efficient, parallel processing. An XML generator 756 uses a request message DTD 740 and the client application request message 742 to generate an XML request message 754. To create the XML request message, for each request, an XML request string 702 is created, in step 718. Preferably, the XML request string 702 is encrypted in step 720 and, in step 722, XML request message 754 is formed. In step 724, a sender 768 transmits XML request message 768 to server cluster 130.

Several components included on the real-time tariff and import data system servers, i.e., server cluster 130, facilitate communication with client 102C. Server cluster 130 receives the XML request message 754 from sender 768. The received XML request message 754 is parsed 5 by an XML server parser 744. A parser is a tool used for grammatical analysis, which includes a syntax analyzer, that can interpret tags and retrieve information from them. Generally, the parser performs on a document in accordance with a conesponding DTD, which contains a tag description used in the XML document being parsed. Thus, a DTD document (e.g., DTD request message document 740) specifies the particular XML format for XML request message 754,

1 o identifying the tags that may or may not appear in XML document 754.

XML server parser 744 decrypts the XML request string 702 contained within XML request message 754 and then parses XML request string 702. Parser 744 extracts input values and security attributes from the request XML request string 702, assuming security mechanisms are used. After the security attributes have been approved, the real-time tariff and import data L5 system 120 matches the user input product code with the appropriate HS code in database 146, assuming a user-defined product code was not entered. If using an HS code, system 120 validates that the HS code is conect for the specified destination country. If an enor occurs, an XML response string containing the enor message is sent back to the client 102C. Enors may be caused by invalid XML request values, invalid XML request node names, invalid inputs or

2 o invalid security attributes, as examples.

Parsing XML request string 702 allows a request message object 764 to be created and passed to the real-time tariff and import data system application 138. The user's values, and any other needed values, are extracted and the duty calculation engine 412, tax calculation engine 418, and total landed cost engine 426 process the request, as required, in step 726, to produce a

!5 response message object 762. XML generator 758 generates an XML response message 752 from the response message object 762 and a DTD response message document 746. A sender 770 transmits the XML response message 770 to client device 102C.

Returning to flowchart 710 of FIG. 7B, client device 102C receives the XML response message 752, in step 728. XML client parser 766 on client 102C parses the XML response i o message 752, in step 730, to obtain the XML response string 704 and then decrypts the XML response string, in step 732. XML client parser 766 creates a response message 744 from XML response string 704 and DTD response message document 746 (which is also available to client 102C). Response message 744 includes the requested duty, tax, and/or total landed cost data and is passed to client application 780. Implementation of the prefened approach to processing XML documents (i.e., requests and responses) takes place in several steps:

(1) Definition of DTD document 740 for requests from clients,

(2) Definition of DTD document for responses 746 from the real-time tariff and import 5 data system 120, and

(3) Implementation of XML parsers (e.g;, parsers 744 and 766), which retrieve data from XML documents and convert the data into objects.

As mentioned, a DTD document 740 is used to create the structure of the XML request string (see Appendix L). The DTD document 740 ensures that the request is properly formed for L o processing by the real-time tariff and import data system 120. The following is an example of a valid XML request message 754 prepared and sent by XML client 102C: <!DOCTYPE TARIFFMESSAGE SYSTEM 'ΗTTP://WWW.^β£π COM:7001/MESSAGE.DTD"> <TARJFFMESSAGE ENCRYPTIONMETHOD- " 1 " L5 DTDVERSION = "l">

<![CDATA[ ENCODED XML REQUEST ]]> </TARΓFFMESSAGE>

The Text attribute ([CDATA[...]]) in the TariffMessage request contains a valid XML request string encrypted with a secret key that is provided to clients. An example of a valid XML i o request string (before it is encoded) is as follows:

<!DOCTYPE TFEEDREQUEST SYSTEM

'ΗTTP://WWW.FFE55 RE.COM:7001/TARREQUEST.DTD''> <TFEEDREQUEST> PΓN="XXXX" 25 ORIGΓNCOUNTRY="CA"

SfflPMENTCOUNTRY="CA"

DESTΓNATIONCOUNTRY="CG" OUTPUTFORMAT=" 1 "> <CURRENCY TRANSACTIONCUR="CAD"

J O CONVERSIONCUR="CAD"/>

<DTREQUEST ACCESSCODE="2" INPUTCODETYPE=" 1 "

PRODUCTCODE="010111" VALUE="500000" COSTOFTRANSPORT="50" ΓNSURANCECOST="50" OTHERCOST="50"> <UNITS> <UNIT NBOFUNIT=" 1 " UNITCODE="4"/> </UNITS> </DTREQUEST> </TFEEDREQUEST> 5 An example of XML response string is as follows:

<!DOCTYPE TFEEDREPLYSYSTEM

'ΗTTP://WWW.)^ /TE.COM/TARREPLY.DTD"> <TFEEDREPLY> <TFEEDREPLY STATUS="0" HSCODE="1212121212" MESSAGE="OK" NOTES="">

1 o <DUTY DUTY="500"/>

</TFEEDREPLY>

2. Web (i.e., ActiveX/COM) Clients - The real-time tariff and import data system 120 accommodates Web clients 102 A using ActiveX/COM components, as shown in FIG.s 8A-C. With this type of client, a standard Web browser 806 is used by the client 102A, as is shown in L5 FIG. 8 A. Using a browser, a client 102A generates a request 802, e.g., an HTML form, and transmits the request 802 to the real-time tariff and import data system 120. Request 802 is serviced by the application servers 130. Request 802 contains all of the required information for conducting duty, import tax, and/or total landed cost calculations, depending on the user's selected output. Request 802 is well formed, since the client is prompted to enter all inputs

2 o needed to process the request and the inputs are preferably validated. As discussed with respect to FIG. 4, a servlet 424 on server cluster 130 picks up request 802, retrieves the data (i.e., inputs) and processes the request by calculating the requested duty, import tax and/or total landed cost.

A more detailed view of the configuration of client 102 A is shown in FIG. 8B. An ActiveX/COM component 810 is loaded onto client device 102A to make the functionality of the

25 real-time tariff and import data system 120 available to the client application 820, via Web browser 806. Functionally, component 810 acts as a translator between the client's Web-based application 820 and the real-time tariff and import data system 120 functionality. Component 810 simplifies processing by translating client application requests into XML requests 802. All of the XML formatting and encryption is done by component 810. Loading component 810 on i o client 102A may require registration with the real-time tariff and import data system 120, depending on the embodiment. To use component 810, an encryption method is set internally, when encryption is used. The encryption method defines the encryption key to be used for communication with the real-time tariff and import data system 120. Setting the encryption method is accomplished using the appropriate "set" methods of component 810. Additionally, inputs 812 entered via the client's Web-based application 820 are incorporated into XML request 802 using appropriate set methods of component 810. Use of such set methods for assigning attribute values is known in the art, so not discussed in detail herein. The following is a prefened embodiment of an interface definition used by the 5 ActiveX/COM component 810 with client application 820: interface ISingleRequestSession : IDispatch

{ HRESULT ProcessRequest();

HRESULT setEncryptionKey([in] BSTR EncryptionKey);

1 o HRESULT setEncryptionMethod([in] BSTR EncryptionMethod);

HRESULT setDtdVersion([in] BSTR DtdVersion); HRESULT getHSCode([out,retval] BSTR* HSCode); HRESULT getStatus([out,retval] BSTR* Status); HRESULT getMessage([out,retval] BSTR* Message); L5 HRESULT getCustomTarifRate([out,retval] BSTR*

CustomTarifRate); HRESULT getPerUnitCusTarif([out,retval] BSTR* PerUnitCusTarif); HRESULT getProductBaseUnit([out,retval] BSTR *

ProductBaseUnit);

2 o HRESULT getDutyAmount([out,retval] BSTR * DutyAmount);

HRESULT getTaxCount([out,retval] int* TaxCount);

HRESULT getCategory([inJ int index, [out,retval] BSTR* Category);

HRESULT getTaxRate([in] int index, [out,retval] BSTR* TaxRate);

HRESULT getPerUnitTax([in] int index, [out,retval] BSTR* 25 PerUnitTax);

HRESULT getTaxBaseUnit([in] int index, [out,retval] BSTR*TaxBaseUnit);

HRESULT getTaxAmount([in] int index, [out,retval] BSTR* TaxAmount); i o HRESULT getTaxName([in] int index, [out,retval] BSTR* TaxName);

HRESULT getSumTaxes([out,retval] BSTR* SumTaxes);

HRESULT getValue([out,rerval] BSTR* Value);

HRESULT getCostOfTransport([out,retval] BSTR* CostOfTransport);

HRESULT getInsuranceCost([out,retval] BSTR* hisuranceCost); HRESULT getOtherCosts([out,retval] BSTR* OtherCosts); HRESULT getTotalLandedCost([out,retval] BSTR* TotalLandedCost); HRESULT getServerAddress([out,retval] BSTR* ServerAddress); HRESULT setPinNumber([in] BSTR PinNumber); 5 HRESULT setShiρmentCountry([in] BSTR ShipmentCountry);

HRESULT setOriginCountry([in] BSTR OriginCountry); HRESULT setDestinationCountry([in] BSTR DestinationCountry); HRESULT setOutputFormat([in] BSTR OutputFormat); HRESULT setProductCode([in] BSTR ProductCode); L o HRESULT setValue([in] BSTR Value);

HRESULT setUnit([in] BSTR NbOfUnit, [in] BSTR UnitCode, [in] int Unitfridex);

HRESULT setCostOfTransport([in] BSTR CostOfTransport); HRESULT sethιsuranceCost([in] BSTR hisuranceCost); L5 HRESULT setOtherCost([in] BSTR OtherCost);

HRESULT setCunency([in] BSTR Cunency); HRESULT setConversionCunency([in] BSTR ConversionCunency); HRESULT setInputCodeType([in] BSTR InputCodeType); HRESULT setAccessCode([in] BSTR AccessCode); i o HRESULT getNotes([out,retval] BSTR* Notes);

HRESULT getTaxNote([in] int index, [out,retval] BSTR* TaxNote); FIG. 8C illustrates a client-side view of a method 850 of interaction between client 120A (with the ActiveX/COM component 810) and the real-time tariff and import data system 120. Component 810 receives inputs 812 and creates one or more conesponding requests 856A-C, in 25 step 854, according to the appropriate DTD. Using the DTD minimizes the potential for XML enors, because the XML request string 802 built is inherently valid and well formed. Encryption and decryption will also be valid, minimizing the potential for encryption enors. As an example, the request 856A, in step 858, is formed into an XML request string 802, using a ProcessRequest() method of component 810. Component 810 sends XML request string 802 to 10 server 132 and/or 134. hi step 860, the real-time tariff and import data system 120 processes the requests and returns an XML response to component 810. The response will be in the form of an XML response string 804 that provides duty, tax, and/or total landed cost values, in accordance with the user's selected output. Component 810 decrypts the XML response 804 with an appropriate encryption key (i.e., the public key of system 120). The XML response string 804 is then parsed by component 810. All values are extracted from the XML response string and set in the component. The client application retrieves desired values from the response by using the appropriate "get" method 814 for each value needed. Each response value has its appropriate

5 "get" method. The values are combined in step 864 and provided to the client application 820, in step 866.

3. Java Clients - The real-time tariff and import data system 120 provides a set of Java classes, embodied in Tariff.jar 910, loaded on the client 102B that prepares and sends an XML request 902 to the server 132 or 134, as is shown in FIG. 9A. An application (e.g., client

LO application 920) uses the Java classes 910 by calling one method to pass a request object 912 and by receiving a reply object 914. Using Java to prepare and send XML request string 902 is similar to the use of ActiveX/COM component 810 discussed above. Tariff.jar 910 acts as a translator between client application 920 and the real-time tariff and import data system 120. That is, Java classes 910 allow XML requests to be sent by client 102B and XML responses to be

15 received by client 102B .

To use the Java classes 910, the classes must first be added to the client's class path or project environment, which makes the Java classes available to the client application 920. An encryption method and encryption key must also be set in the Tariff.jar 910 classes to facilitate secure communications. Thereafter, processing a request merely requires calling one method,

2 o ProcessRequestQ, and passing a request object containing the input parameters discussed previously (see also Appendix H).

The ProcessRequest() method of Tariff.jar 910 builds a valid XML request string from the user's inputs. This approach minimizes XML enors, since the XML request string will necessarily be valid and well formed according to its DTD. Also, given that the

25 ProcessRequest() method builds the request, encryption and decryption will also be valid, minimizing encryption enors. After building the XML request string 902, the Java classes 910 send the XML request to servers 132 andl34, receives the XML response message, and decrypts the XML response string 904 therefrom. The Java classes 910 decrypt the XML response string 904 with the appropriate encryption key (e.g., system 120's public key). i o The Java classes 910 parse the XML response string. All values are extracted from the

XML response string 904 and set in the Java classes. A response object 914 is then returned to the client application 920. These values can be retrieved by the client application 920 by calling the appropriate "get" methods of the response object. Each response value has its appropriate "get" method. All values can be retrieved and output in client application 920. FIG. 9B shows a client-side view of a method 950 of interaction between a client application 920 and server cluster 130. <In step 952, the client application 920 gathers the inputs from the user and generates one or more request objects, 956A-C. hi step 958, the Java classes 910 receive the request object 912 (or 956A) and gets the needed inputs from the request object and

5 then creates an XML request string 902. The request string 902 is then sent (in an XML request message) to the real-time tariff and import data system 120 servers 132 and 134, which processes the request, in step 960. An XML response string (in a response message) is then returned to the Java classes 910 from the servers 132 and 134. The Java classes 910 get data from the XML response string and form response objects 914, in step 962. The response includes the duty, tax,

LO and/or total landed cost, as requested by the user. The client application 920 retrieves values from the response objects 914 by calling the appropriate "get" methods and combines the values, in step 964. The values are then output to the client application 920, in step 966. Part III - Calculations

The following is the prefened embodiment of the manner of calculating duties and taxes

L5 associated with an international transaction. The methods are implemented by the duty calculation engine 412, import tax calculation engine 418, and total landed cost calculation engine 426, previously discussed with respect to FIG. 4. The duty calculation engine 412 accesses relevant tariff rates for a specified product and destination country from the database 146 and applies the lowest of such applicable rates to arrive at a duty calculation. The import tax

2 o calculation engine 418 accesses relevant databases of country specific import tax rates, charges and fees and applies them to arrive at import tax costs. The total landed cost calculation engine 426 determines the total landed cost from the duty calculation and the import tax calculation, and any other relevant costs (e.g., transportation and insurance costs).

The inputs for the various engines are gathered from the XML request process previously

25 described. The inputs for the various engines are described above in Part II and Appendix H.

Validation of the inputs is performed as the data is input into appropriate fields of, for example, a Web-based request form. The validation occurs by testing inputs against field-based validation criteria, described in Appendix H. Appendix I identifies the returned values for each of the ten (10) possible output formats of the prefened embodiment. so

1. Duty (or Tariff) Calculation

The following tables identify the steps taken by the duty calculation engine 412 to calculate the duty (or tariffs) for a given international transaction. At a macro level, the steps include selecting a duty rate, converting currencies, and calculating the duty fee. The tables include object oriented pseudo code describing calls and method steps used in the process and also describes enor codes applicable to the various steps.

Table 4 below shows the steps for selecting a duty rate for a given set of inputs.

TABLE 4 - Duty Rate Selection

Table 5 shows the steps for converting between cunencies among countries, which is useful in the calculations, since typically the origin country, shipment country, and destination country may have different cunencies.

TABLE 5 - Cunency Conversion

Table 6 shows the steps for calculating the duty (or tariff), which incorporates the steps in

Table 4 for selecting a duty (or tariff) and the steps of Table 5 for converting cunencies.

Step Processing quantities Tables:

UnitCode TariffDescription

Information:

UnitCode.UnitType

UnitCode.ConversionFactor TariffDescription.UiiitCode

Methods:

If Request.ProductBaseUnit = TarifiDescription.UrritCode, Then

ConvertedQuantity = Request.NbOfUnit

Else If the unit type of Request.ProductBaseUnit is different from the type associated with the product unit measure; Then Enor code: S560 - The base unit of the products is incompatible with the base unit specified in the request.

Else ConvertedQuantity = Request.NbOfUnit * UnitCode.ConversionFactor Remarks: To find out the base unit type, refer to the

UnitCode.UnitType field. Step Processing te duty AddValoremFee = (ConvertedApplicableFees * _TariffData.AddValoremRate)

PerUnitFee = (ConvertedQuantity * TariffData.PerUnit)

If the tariff calculation method is "Applied Both" TariffData.CalculationMethod = 10 Then

DutyFee = AddValoremFee + PerUnitFee Else If the tariff calculation method is "Applied Greatest"

(_TariffData.CalculationMethod = 20) Then

If AddValoremFee > PerUnitFee Then DutyFee = AddValoremFee

Else DutyFee = PerUnitFee Else If the tariff calculation method is "Applied Smallest"

(__TariffData.CalculationMethod = 30) Then

If AddValoremFee > PerUnitFee Then DutyFee = PerUnitFee

Else DutyFee = AddValoremFee

TABLE 6 - Duty Fee Calculation

2. Tax Calculation

The following tables identify the steps taken by the import tax calculation engine 418 to calculate the tax for a given international transaction. At a macro level, the steps include selecting a tax rate and calculating the applicable taxes. The tables include object oriented pseudo code describing calls and method steps, and also describes enor codes for the various steps.

Table 7 below, shows the steps for selecting a tax rate for a given set of inputs.

Step Processing

4. Convert per-unit Applicable to output formats 4, 6, 7 and 9 taxes For each tax selected, the applicable per-unit tax must be converted if it is greater than zero. If the conversion cunency of the request

(Request. ConversionCurrency) is the same as the country's customs tariff cunency (Country. TariffsCunency) Then

ConvertedPerUnitTax = Taxe.TaxPerUnit Else If the country's customs tariff cunency is "USD" Then

ConvertedPerUnitTax = Conversion of per-unit tax from

"USD" to the conversion cunency of the request (See Table

5) Else USDPerUnitTax = Conversion of per-unit tax to "USD (See Table

5) ConvertedPerUnitTax = Conversion of USDPerUnitTax to the conversion cunency of the request (See Table 5)

TABLE 7 - Tax Rate Selection

Table 8 shows the steps for calculating the import tax, which incorporates the steps in Table 6 for selecting a tax rate and the steps of Table 5 for converting cunencies.

Step Processing t quantities Table:

UnitCode

Tax Information:

UnitCode.UnitType

UnitCode.ConversionFactor

Tax.UnitCode Methods:

If Request.ProductBaseUnit = Tax.UnitCode Then ConvertedQuantity = Request.NbOfUnit

Else If the unit type of Request.ProductBaseUnit is different from the type associated with the product base unit Then Enor code: S560 - The base unit of the products is incompatible with the base unit specified in the request.

Else ConvertedQuantity = Request.NbOfUnit * UnitCode.ConversionFactor

Remarks:

To find out the base unit type, refer to the UnitCode.UnitType field.

TABLE 8 - Import Tax Calculation

3. Total Landed Cost (TLC) Calculation The TLC engine uses the output from the duty calculation engine and the tax calculation engine, along with user inputs described in Part π, to arrive at a total landed cost, as follows: TLC — Duty Fee + Import Taxes + Price of Goods + Cost of Transport + Insurance Costs + Other Costs

The invention may be embodied in other specific forms without departing from the spirit or central characteristics thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by appending claims rather than by the foregoing description, and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. APPENDIX A B - Country and Currency Codes

Following is a list of country and cunency codes:

APPENDIX C - Unit Codes

Following is a list of unit codes:

GRAMS OF POTASIUM HYDROXIDE (KOH)

GRAMS OF POTASSIUM OXTDE (K2O)

GRAMS OF SODIUM HYDROXIDE (NaOH)

GRAMS OF SUCROSE (C12H22O11)

GRAMS OF TOTAL SOLUBLE SOLIDS

GRAMS OF URANIUM (U)

GRAMS OF ZINC (Zn)

GRAMS PER 1% BY WEIGHT OF SUCROSE

GRAMS PER THOUSAND UNITS

GRAMS VOLATILE ORGANIC COMPOUND(VOC)

GROSS (i.e. 12 DOZENS)

HECTOGRAM OF GOLD (Au)

HECTOGRAM OF PLATINUM (Pt)

HECTOGRAM OF SILVER (Ag)

HECTOLITER

HECTOLITER OF PURE ALCOHOL

HORSE POWER

IMPERIAL GALLON

IMPERIAL TON

INCHE

IU (INSULIN UNIT)

KILOGRAM (SEMI-GROSS WEIGHT)

KJLOGRAM OF 90% DRY SUBSTANCE

KILOGRAMS

KILOGRAMS CHOLINE CHLORHYDRATE (C5H14CLNO)

KILOGRAMS DIPHOSPHORUS PENTAOXIDE (P2O5)

KILOGRAMS DJROTASSIUM OXIDE (K2O)

KILOGRAMS DIPOTASSIUM PENTAOXIDE (K2O5)

KILOGRAMS DRY AIR

KILOGRAMS DRY WEIGHT

KILOGRAMS METHYLAMINE (CH5N)

KILOGRAMS NET/EDA

KILOGRAMS NET/MAS

KILOGRAMS NITROGEN (N)

KILOGRAMS OF NAMED SUBSTANCE

KILOGRAMS OF ANHYDIOUS MORPHINE CONTENT (C17H19NO3)

KILOGRAMS OF CHROMIUM (Cr)

KILOGRAMS OF COPPER CONTENT (Cu)

KILOGRAMS OF FISSILE ISOTOPE(KFI) KILOGRAMS OF FISSIONABLE MATERIAL

KILOGRAMS OF GOLD (Au)

KILOGRAMS OF HYDROGEN PEROXIDE (H2O2)

KILOGRAMS OF IPJDIUM (Ir)

KILOGRAMS OF LEAD CONTENT (Pb)

KILOGRAMS OF MAGNESIUM (Mg)

KILOGRAMS OF MANGANESE (Mn)

KILOGRAMS OF MOLYBDENUM (Mo)

KJLOGRAMS OF NICKEL (Ni)

KILOGRAMS OF OSMIUM (Os)

KJLOGRAMS OF PALLADIUM (Pd)

KILOGRAMS OF PHOSPHORUS PENTOXIDE (P2O5)

KJLOGRAMS OF PLATINUM (Pt)

KJLOGRAMS OF POTASIUM HYDROXIDE (KOH)

KILOGRAMS OF POTASSIUM OXIDE (K2O)

KJLOGRAMS OF RHODIUM (Rh)

KILOGRAMS OF RUTHENIUM (Ru)

KILOGRAMS OF SILICON (Si)

KILOGRAMS OF SILVER (Ag)

KJLOGRAMS OF SODIUM HYDROXIDE (NaOH)

KILOGRAMS OF SUCROSE (C12H22O11)

KJLOGRAMS OF TOBACCO CONTENT

KILOGRAMS OF TOTAL SOLUBLE SOLIDS

KJLOGRAMS OF TUNGSTEN CONTENT (W)

KILOGRAMS OF URANIUM (U)

KILOGRAMS OF VANADIUM (V)

KILOGRAMS OF VOLATILE ORGANIC COMPOUND(VOC)

KILOGRAMS OF ZINC (Zn)

KILOGRAMS ON DRAINED WEIGHT

KILOGRAMS PER 1% BY WEIGHT OF SUCROSE

KILOGRAMS PER THOUSAND UNITS

KJLOGRAMS/BR (Gross)

KXLOGRAMS/TOTAL ALCOHOL

KXLOLITER

KILOMETER

KXLOWATT

KLLOWATTS/HOUR

LITER

LITER OF PURE ALCOHOL

APPENDIX D - Unit Type

Following is a list of unit types:

APPENDIX E - Output Format Codes

Following are output format codes:

APPENDIX F - Access Codes Following are output format codes:

APPENDIX G - Input Code Types

Following are input format codes:

APPENDIX H - Requested Values and Data Validation (Input)

APPENDIX I - Returned Values (Output)

If Customs Tariff Rate is equal to 999999, the product is prohibited in the specified country.

Claims (1)

1. A real-time global tariff and import data system comprising:

   A. a data storage system, comprising a set of tariff and duty data including, for each of a plurality of countries, a set of product codes and conesponding duty rates and import tax rates;

   B. an input mechanism, configured to accept a set of transaction information including origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, and transaction cunency;

   C. a duty calculation engine, configured to calculate a subject product duty as a function of said duty rate and said set of transaction information; and

   D. a tax calculation engine, configured to calculate a subject product import tax as a function of said tax rate and said set of transaction information.

   A system as in claim 1, wherein said data storage system is coupled to a remote data source configured to supply at least a subset of said set of tariff and duty data.

   A system as in claim 1 , wherein said data storage system is coupled to a remote data source configured to update said set of tariff and duty data.

   A system as in claim 1, further comprising:

   E. a Web server system, coupled to said duty calculation engine and said tax calculation engine, wherein said Web server system includes a Web page generator configured to generate said input mechanism as a set of Web pages.

   A system as in claim 4, wherein said Web server system is accessible via one or more wired or wireless networks from a group of networks comprising:

   1) the Internet;

   2) the Web;

   3) a virtual private network;

   4) an extranet;

   5) an intranet;

   6) a telephone network; and

   7) a satellite network. A system as in claim 1, wherein said tariff and import data system includes or is configured to access international transaction restriction information, said system further comprising:

   E. a transaction validater, configured to verify that said set of transaction inputs complies with relevant said international transaction restriction information.

   A real-time global tariff and import data system comprising:

   A. a data storage system, comprising a set of tariff and duty data including, for each of a plurality of countries, a set of product codes and conesponding duty rates and import tax rates;

   B. an input mechanism, configured to accept a set of transaction information including origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, and transaction currency;

   C. a duty calculation engine, configured to calculate a subject product duty as a function of said duty rate and said set of transaction information; and

   D. a tax calculation engine, configured to calculate a subject product import tax as a function of said tax rate and said set of transaction information; and

   E. a total landed cost engine, configured to calculate a total landed cost from said subject product duty, said subject product import tax, and a set of ancillary cost information.

   A system as in claim 7, wherein said ancillary cost information includes costs from a group comprising:

   1) insurance costs; and

   2) transportation costs.

   A system as in claim 7, wherein said real-time global tariff and import data system is coupled to a transportation system configured to generate a transportation cost associated with said set of transaction inputs, wherein said transportation cost comprises at least a portion of said ancillary cost information.

   A system as in claim 9 wherein said real-time global tariff and import data system is enabled to procure transportation services via said transportation system. A system as in claim 7, wherein said real-time global tariff and import data system is coupled to an insurance system configured to generate an insurance cost associated with said set of transaction inputs, wherein said insurance cost comprises at least a portion of said ancillary cost information.

   A system as in claim 11 wherein said real-time global tariff and import data system is enabled to procure insurance coverage via said insurance system.

   A real-time global tariff and import data system comprising:

   A. a data storage system, comprising a set of tariff and duty data including, for each of a plurality of countries, a set of product codes and conesponding duty rates and import tax rates;

   B. an input mechanism, configured to accept a set of transaction information including output format code, origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, and transaction cunency;

   C. a duty calculation engine, configured to calculate a subject product duty as a function of said duty rate and said set of transaction information; and

   D. a tax calculation engine, configured to calculate a subject product import tax as a function of said tax rate and said set of transaction information; and

   E. an output mechanism, configured to selectively invoke said duty calculation engine and said import tax calculation engine as a function of said output format code, wherein said system includes a set of predetermined output formats with each output format having a unique output format code, and wherein each of said output formats includes at least one of subject product duty infonnation or subject product tax information.

   A system as in claim 13, wherein said at least one of subject product duty information or subject product tax information include information chosen from a group comprising:

   1) duty rate;

   2) duty amount;

   3) tax rate;

   «

   4) duty amount; 5) detailed duty; and

   6) detailed tax.

   A real-time global tariff and import data system comprising:

   A. a data storage system, comprising a set of tariff and duty data including, for each of a plurality of countries, a set of product codes and conesponding duty rates and import tax rates;

   B. an input mechanism, configured to accept a set of transaction information including output format code, origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, transaction cunency, and ancillary cost information;

   C. a duty calculation engine, configured to calculate a subject product duty as a function of said duty rate and said set of transaction information; and

   D. a tax calculation engine, configured to calculate a subject product import tax as a function of said tax rate and said set of transaction information; and

   E. a total landed cost engine, configured to calculate a total landed cost from said duty, said import tax, and ancillary cost information; and

   F. an output mechanism, configured to selectively invoke said duty calculation engine and said import tax calculation engine as a function of said output format code, wherein said system includes a set of predetermined output formats with each output format having a unique output format code, and wherein each of said output formats includes at least one of duty or tax rate or amount infonnation.

   A system as in claim 15, wherein said input mechanism is configured to accept XML requests comprising said set of transaction information.

   A real-time global tariff system, accessible via a network, comprising:

   A. a data storage system comprising duty data including, for each of a plurality of countries, a set of product codes and conesponding duty rates;

   B. an input mechanism, configured to accept a set of transaction information including origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, transaction cunency, and ancillary cost information; C. a duty calculation engine, configured to calculate a subject product duty as a function of said duty rate and said set of transaction information;

   D. a Web server system, coupled to said duty calculation engine, wherein said Web server system includes a Web page generator configured to generate said input mechanism as a set of Web pages; and

   E. an output mechanism, configured to selectively invoke said duty calculation engine and wherein said Web server system is configured to generate a Web page presenting said duty.

   A real-time global import tax system, accessible via a network, comprising:

   A. a data storage system comprising import tax data including, for each of a plurality of countries, a set of product codes and conesponding import tax rates;

   B. an input mechanism, configured to accept a set of transaction information including origin country, shipment country, destination country, product code, transaction value, quantity of product units, transaction currency, and ancillary cost information;

   C. a tax calculation engine, configured to calculate a subject product import tax as a function of said tax rate and said set of transaction information;

   D. a Web server system, coupled to said tax calculation engine, wherein said Web server system includes a Web page generator configured to generate said input mechanism as a set of Web pages; and

   E. an output mechanism, configured to selectively invoke said tax calculation engine and wherein said Web server system is configured to generate a Web page presenting said tax.

   A method of providing real-time global tariff and import data over a networked computer system, said method comprising:

   A. establishing in a data storage system a set of tariff data and duty data, including for each of a plurality of countries, a set of product codes and conesponding duty rates and import tax rates;

   B. entering at a client device a set of transaction inputs including origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, and transaction cunency;

   C. transmitting said set of transaction information to a tariff and import data system; D. calculating a subject duty, as a function of a product duty rate and said set of transaction information;

   E. calculating a subject import tax, as a function of a product duty rate and said set of transaction information; and

   F. transmitting said subject duty and said subject import tax to said client device in substantially real-time.

   A method as in claim 19, wherein said client device and tariff and import data system are remote to each other and parts C and F include transmitting over one or more wired or wireless networks from a group of networks comprising:

   1) the Internet;

   2) the Web;

   3) a virtual private network;

   4) an extranet;

   5) an intranet;

   6) a telephone network; and

   7) a satellite network.

   A method as in claim 19, wherein said tariff and import data system includes a Web server system, said method further comprising in part B:

   B.1 generating a set of Web pages for accepting said set of transaction infonnation; and B.2 validating said set of transaction information against predetermined syntax and semantic constraints.

   A method as in claim 19, wherein a plurality of output formats are stored in said tariff and import data system and each output format has a conesponding output format code, wherein part P includes:

   B.1 entering a subject output format code; and wherein said method further comprises:

   G. outputting one or more of said subject duty, and said subject import tax at said client device in an output format conesponding to said subject output code. A method of providing real-time global tariff and import data over a networked computer system, said method comprising:

   A. establishing in a data storage system a set of tariff data and duty data, including for each of a plurality of countries, a set of product codes and conesponding duty rates and import tax rates;

   B. entering at a client device a set of transaction inputs including origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, and transaction cunency;

   C. transmitting said set of transaction infonnation to a tariff and import data system;

   D. calculating a subject duty, as a function of a product duty rate and said set of transaction information;

   E. calculating a subject import tax, as a function of a product duty rate and said set of transaction information; and

   F. calculating a total landed cost as a function of said subject product duty, said subject product import tax, and a set of ancillary information; and

   G. transmitting one or more of said subject duty, said subject import tax, and said total landed cost to said client device in substantially real-time.

   A method as in claim 23, wherein said ancillary cost information includes costs from a group comprising:

   1) insurance costs; and

   2) transportation costs.

   A method as in claim 24, wherein said tariff and import data system is coupled to a transportation system and part F comprises:

   F.1 generating a transportation cost associated with said set of transaction inputs, wherein said transportation cost comprises at least a portion of said ancillary cost information.

   A method as in claim 25, wherein part F further comprises:

   F.2 procuring transportation via said transportation system.

   A method as in claim 24, wherein said tariff and import data system is coupled to an insurance system and part F comprises: F.1 generating an insurance cost associated with said set of transaction inputs, wherein said insurance cost comprises at least a portion of said ancillary cost information.

   28. A method as in claim 27, wherein part F further comprises:

   F.2 procuring insurance via said insurance system.

   29. A method as in claim 24, wherein a plurality of output formats are stored in said tariff and import data system and each output format has a conesponding output format code, wherein part P includes:

   B.l entering a subject output format code; and wherein said method further comprises: H. outputting one or more of said subject duty, said subject import tax, and said total landed cost at said client device in an output format conesponding to said subject output code.

   30. A method of providing real-time global tariff data over a networked computer system, said method comprising:

   A. establishing in a data storage system a set of duty data, including for each of a plurality of countries, a set of product codes and conesponding duty rates and a plurality of output formats wherein each output format has a conesponding output format code;

   B. entering at a client device a set of transaction inputs including origin country, shipment country, destination country, subject product code, transaction value, quantity of product units, transaction cunency and subject product code;

   C. transmitting said set of transaction infonnation to a tariff and import data system;

   D. calculating a subject duty, as a function of a product duty rate and said set of transaction information;

   E. transmitting said subject duty to said client device in substantially real-time; and G. outputting said subject duty at said client device in an output format conesponding to said subject output code.

   31. A method of providing real-time global import tax data over a networked computer system, said method comprising:

   .

   3 A. establishing in a data storage system a set of import tax data, including for each of

   4 a plurality of countries, a set of product codes and conesponding import tax rates

   5 and a plurality of output formats wherein each output format has a conesponding

   6 output format code;

   7 B. entering at a client device a set of transaction inputs including origin country,

   8 shipment country, destination country, subject product code, transaction value,

   9 quantity of product units, transaction cunency and subject product code;

   LO C. transmitting said set of transaction information to a tariff and import data system;

   Li D. calculating a subject import tax, as a function of a product import tax rate and said

   L 2 set of transaction information;

   .3 E. transmitting said subject import tax to said client device in substantially real-time;

   .4 and

   L5 G. outputting said subject import tax at said client device in an output format

   L6 conesponding to said subject output code.