Messaging interchange system

(54) Title: EXCHANGE SYSTEM OF

MESSAGES (51) Int. Cl .: G06F 15/16 (30) Unionist Priority: 14/03/2008 US 61 / 036.485 (73) Holder (s): NEOMEDIA TECHNOLOGIES, INC (72) Inventor (s): FRANK MUELLER ; STEVEN KEARNS; KEVIN HUNTER (74) Attorney (s): NELLIE ANNE DANIESHORES (86) International Application: PCT US2009036984 of 12/03/2009 (87) International Publication: WO

2009/114710 of 17/09/2009

<img file="BRPI0908751A2_D0001.tif" />

“MESSAGE EXCHANGE SYSTEM

Cross-Reference to Related Order

This application is based on and claims filing priority to the co-pending provisional patent application US serial number 61 / 036,485, filed on March 14, 2008.

Technique Field

This invention relates to messaging systems that allow a user to read a machine-readable code and retrieve a network resource associated with that code (such as an optical messaging system that checks a barcode), and in particular the a message exchange system that allows the interoperability of different messaging systems.

Foundation Technique

Several companies are in the process of developing and deploying systems designed to allow end users to perform operations via client devices (also called access points), such as cell phones, activated by reading machine-readable codes, such as linear (ID) and two-dimensional (2D) bar codes. For the purposes of this specification, these systems are generally referred to as messaging systems (and, in the case of optical barcode scanning, as Optical Messaging Systems (WHO)). Some examples of operations that can be activated by machine-readable code include, but are not limited to:

Launching a web browser for a specific URL

Dialing a phone number

Sending an SMS

Coupon display

Some classes of bar codes and their corresponding operations can be performed properly by any access point that is able to read the particular bar code. An example of this could be a complete URL that is encoded in a 2D barcode, such as a DATAMATRIX code. Any access point that is able to read that barcode and extract the URL would then be able to launch a web browser for that address. For the purposes of this specification, we refer to these as direct or unmanaged codes.

Other classes of bar codes cannot be processed without the involvement of non-resident processes or services at the access point. When the internal coding of the barcode data is proprietary and / or where the data requires interaction with a server-based database to complete the operation, an exchange with the WHO issue is necessary in order to properly complete the intended operation . For the purposes of this specification, we refer to these as indirect or managed codes.

Once WHO systems become more ubiquitous and widely used, it is likely that situations will arise where an access point developed by Company A will be used by users to read Managed Codes issued by Company B. Due to the need for infrastructure involvement Company B, without any interface between this infrastructure and Company A's access points (s), such codes cannot be processed.

It is, therefore, an object of the present invention to provide a methodology and system for providing interoperability between several different messaging systems.

Description of the Invention

The present invention is a message exchange system that provides a method by which individual messaging systems can collaborate and interact in order to allow each system to expand the code support of the other systems. Specifically, the system of the present invention is designed to allow a messaging system that receives an external code (that is, a non-native code for such WHO) to submit that code to the message exchange system for the identification and correction of information routing or redirecting code to the correct messaging system (for example), resolution server. The messaging system has a responsibility to determine the correct owner of the code, providing routing information back to the initial (source) messaging system or forwarding the request to the destination messaging system (the proprietary messaging system) ) and resuming an indication of the function that must be performed back to the initial messaging system using a standardized protocol. The initial messaging system can then translate this information into its own internal formats, and make the intended operation available to the user.

The essential effect of this is that, assuming that Company A and Company B support each other's barcode symbologies, the codes produced by Company B's messaging system can be transparently read and provided by Company A's access points. (and vice versa), thus expanding the reach and interoperability of the two companies, substantially improving the end-user experience, facilitating the adoption by the market of messaging systems and services as a whole.

In support of this objective, the present invention provides the following:

An architecture for the message exchange system

A protocol (MIP) used to exchange information between the message exchange system and individual message systems (that is, the initial and destination systems).

A set of high-level procedures compatible with the messaging systems that will follow in the interaction with the message exchange system.

A numbering system that can be used for proprietary Managed Codes to ensure ubiquitous and unambiguous routing.

Thus, a machine-readable code processing method and system is provided to perform a desired function by reading a machine-readable code with a client device to obtain code data, then transmit the data from the client device code to an initial messaging system, and process the code data in the initial messaging system to determine whether the code data is native to the initial messaging system. If the code data is native to the initial messaging system, then the initial messaging system still processes the code data by executing a function, according to the code data. If the code data is not native to the initial messaging system, then the initial messaging system transmits a resolution request message to a message exchange system, the resolution request message including the code data, and the system message exchange processes the resolution request message to determine routing information for a destination messaging system, where the code data is native to the target messaging system. The message exchange system then allows the resolution request message to be transmitted to the destination messaging system. The destination messaging system receives the resolution message, analyzes the code data from the resolution message, and provides a resolution response message to the initial messaging system. The initial messaging system receives the resolution reply message and performs a function accordingly.

The message exchange system allows the transmission of a resolution request message to the destination message system by determining the route information from the resolution request message, the route information indicating whether (A) the routing information must be returned to the initial messaging system, or (B) the routing information must be used by the message exchange system to forward the request for resolution message to the destination message system.

If the route information indicates that (A) the routing information must be returned to the initial messaging system, then the message exchange system transmits a reply message to the initial messaging system, the reply message including the routing information to the destination messaging system. The initial messaging system uses the routing information from the destination messaging system to send the resolution request message to the destination messaging system. The destination messaging system provides a resolution reply message to the initial messaging system by transmitting the resolution reply message directly to the initial messaging system or client device.

If, however, the route information indicates that (B) the routing information must be used by the message exchange system to forward a resolution request message to the destination message system, then the message exchange system uses the routing information to the destination messaging system to forward the resolution request message to the destination messaging system. The destination messaging system provides a resolution reply message to the initial messaging system, transmitting the resolution reply message to the message exchange system, and the message exchange system forwards the resolution reply message to the message system. initial messages.

In another aspect of the invention, a message exchange system is provided to manage a plurality of independent messaging systems. The message exchange system receives a resolution request message from an initial messaging system, the resolution request message including code data obtained from a machine-readable code. The message exchange system then processes the resolution request message to determine (i) routing information for a destination messaging system, where the code data is native to the destination messaging system, and ( ii) route information indicating whether (A) the routing information should be returned to the initial messaging system, or (B) the routing information must be used by the message exchange system to forward resolution request messages to the destination message system. If the route information indicates that (A) the routing information must be returned to the initial messaging system, then the message exchange system transmits a reply message to the initial messaging system, the reply message including the routing information to the destination messaging system. If, however, the route information indicates that (B) the routing information must be used by the message exchange system for forwarding the resolution request message to the destination message system, then the message exchange system uses the routing information for the destination messaging system to forward the resolution request message to the destination messaging system, the message exchange system receives a resolution reply message from the destination messaging system, and the message exchange system forwards the resolution reply message to the initial messaging system or client device.

Brief Description of Drawings

Figure 1 is an illustration of the topology of the present invention.

Figure 2 is an illustration of the interface of the present invention.

Figure 3 is an illustration of the sequence of operations.

Figure 4 is an illustration of the system topology of the present invention.

Figures 5 and 6 are a flow chart of the operation of the present invention.

Best Way to Carry Out the Invention

Although the present invention applies to any machine-readable code technology, such as, but not limited to, linear and two-dimensional bar codes, matrix codes, RFID codes and magnetic stripe codes, the preferred embodiment uses optical image of bars and the like. In this way, the machine-readable code will be referred to here as a barcode, the messaging systems will be referred to here as optical messaging systems (WHO), and the message exchange system will be referred to here as an optical message exchange (IMO).

As such, the following terms are also defined for the purposes of this specification:

Access Point A client device on which a user can initiate a transaction using a machine-readable code, such as an optical code. Examples include cell phones equipped with barcode scanning software, wireless coupon readers, etc.

Direct Code / Code Bar code that contains all the required Unmanaged information necessary to perform the function for which it is intended.

Indirect Code / Barcode Code whose processing requires the involvement of

Managed non-resident processes or services at the access point.

Exchange of Mensa - A system designed to allow individual WHO interacts Optics (IMO to exchange data, in order to be able to review bar codes among themselves.

Exchange Protocol- The protocol through which OMS systems communicate with Bio of Optimal IMO Messages. co

Messaging System A system designed to perform operations for an optical (OMS) end user in response to reading codes, such as dimensional or two-dimensional bar codes.

For the purposes of this specification, a WHO is considered to consist of two distinct classes of devices or components:

• Access points are client devices where an end user initiates a transaction. Typical Access Points may include a cell phone capable of reading bar codes or a network coupon reader. The only basic requirements are that the client device be able to read a machine-readable code, such as a barcode, send it to an external service for processing when and if necessary, and perform an operation in response or display the result of the transaction.

• Resolution Services represent additional processes or systems that are not resident at Access Points that are required to fully process Managed Codes. Typically, these will be networked computers containing databases, etc.

Although an architecture in which Access Points and Resolution Services are physically separated is probably the most common scenario, this invention makes no attempt to limit the internal application of any Optical Messaging System.

As shown in Figure 1, the IMO system uses a “star” topology, in which each individual WHO 2, 4, 6, 8 needs to communicate only with the IMO 10 system. Alternative arrangements are, of course, possible - in particular, adopting a topology in which each individual WHO communicates directly with all other WHO. Such arrangements, however, are difficult to endure as more WHO appear. With the topology in Figure 1, when a new WHO joins the system, each of the other WHO immediately gains the benefit of the new WHO without requiring any changes on their part.

As mentioned earlier, each individual WHO can have its own internal architecture and systems. Member WHOs, however, communicate with OMI 10 through systems known as OMI 16 Portals, as shown in Figure 2.

External codes are submitted to OMI 10 through the OMI 16 Portal, which then handle the internal details necessary to provide the destination (owner) WHO address to the initial (originating) WHO or directly route the request to the WHO from destination and return the result to the initial WHO. Likewise, a WHO can receive requests for resolution of its own codes through an IMO Portal or directly from an external WHO, and will be responsible for providing the appropriate resolution information back to the initial WHO. The link between each individual WHO and the IMO is through the Optical Message Exchange Protocol (OMIP).

The standard sequence of operations for an OMI exchange is illustrated in Figure 3, and with reference to the flow chart in Figures 5 and 6, and is described below.

1. An Access Point 14, which is part of OMS A reads a bar code 18. For the purposes of this specification, OMS A will be referred to as the initial or originating OMS, since it is the initial system with which the user transaction originates

2. Resolution Service 12 at OMS A receives barcode data from Access Point 14, along with metadata about the transaction, using procedures and protocols that are internal to Supplier A, along route 22.

3. Resolution Service 12 at OMS A processes code data from Access Point 14 and attempts to resolve it to determine what actions to take. For example, Resolution Service 12 may attempt to search for a URL from a local database based on the code data, and then return that URL to Access Point 14, so that the Access Point can load the URL in a browser. These resolution techniques are described in Applicant No. US Patent No. 5,978,773 SYSTEM AND METHOD FOR USING A COMMON TRADE ITEM TO ACCESS A REMOTE COMPUTER, the specification of which is hereby incorporated by reference, and also in Applicant's US Patent No. 6,993,573 AUTOMATIC ACCESS OF INTERNET CONTENT WITH A CELLULAR PHONE ENABLED WITH CAMERA, the specification of which is incorporated by reference. Assuming that the Resolution Service is able to recognize the code and resolve it, then that code is considered to be native to the particular WHO.

4. If Resolution Service 12 in OMS A is unable to recognize and resolve the code, then the code is considered to be an external code (that is, it is not a native code) and therefore this request is not one that OMS A can serve by itself. Instead of just stopping and / or returning an error message as in the previous technique, it formats an OMIP Resolution Request message and sends it to the OMI Portal, through the Optical Message Exchange Protocol (OMIP), along the route 24 .

5. The OMI 16 Portal confirms that the request is properly formatted and comes from an authorized source.

6. IMO 10 assigns a single IMO Transaction ID to the Resolution Request, and adds it to the Resolution Request.

7. Using barcode data and transaction metadata, OMI 10 determines which WHO needs to fulfill this request. For the purposes of this specification, the WHO that will fulfill the request will be referred to as the Destination WHO.

8. The IMO Portal 16 allows the transmission of the resolution request message to the appropriate destination WHO by returning the destination WHO address to the original WHO or by forwarding the Resolution Request directly to the Destination WHO along route 26. To determine which of these actions to take, IMO 10 determines the appropriate route information from the initial WHO resolution request, which serves to inform IMO 10 how to handle the transaction.

9. Destination WHO Resolution Request 20 performs the necessary processing to determine the nature of the operation that the end user should see in response to the code 18 scan action.

10. Destination WHO 4 responds directly to the initial WHO 2 (if the resolution request comes from the initial WHO) or via the IMO Portal 16 along route 28 and route 30 (if the resolution request comes from IMO 10) with a message Resolution Response. This message includes the instruction back to the original Access Point 14, about which operation to perform.

11.0 Resolution Request 12 in the initial WHO 2 translates the information in the Resolution Response message into its own internal format, if necessary, and transmits the result back to Access Point 14.

12. Access Point 14 performs the desired operation for the user.

13. Later, IMO 10 provides initial WHO 2 and target WHO 4 WHO reports and financial reconciliation information (dashed arrows 32).

Note that the process described above is synchronous and session oriented - the initial WHO issues a Resolution Request and receives the corresponding Resolution Request Response back as part of the same session, and in sequence. If it is necessary to fulfill its processing load, a single initial WHO may make several Resolution Requests simultaneously to the IMO. Likewise, the IMO may make several simultaneous requests to an individual WHO for resolution. The session-oriented nature of the protocol means that no additional steps need be taken to match requests and responses.

Obviously, there are several cases of exception:

1. The IMO may not be able to determine a WHO for the Resolution Request service. This can happen if an end user scans a barcode that has been malformed, or that has not been produced by any of the WHO member states.

2. The Destination WHO may be offline, unable to be contacted, or the Resolution Request for the Destination WHO may expire.

3. The Target WHO may indicate that the specified barcode data is no longer valid, or, in fact, was not originally produced by it.

4. There may be business reasons for the Target WHO to reject the request to process the request.

In each of the above cases, the IMO will return an appropriate indication back to the initial WHO. In addition, it is possible that participating WHO may support operations (and associated barcodes) that are not available through another company Access Point. For example, OMS A may support bar codes that can post a URL, send an SMS or dial the phone, while OMS B Access Points could only support posting a URL. In such a situation, if the OMS B Access Point is able to scan and send an SMS bar code produced by OMS A, the system as a whole would be able to return the command to an OMS B server, but the action associated with the bar code could not be performed by the end user software.

In order to deal with this situation, part of the metadata that is sent by the initial WHO in the Resolution Request includes the set of operations that the initial Access Point is capable of performing. If the code resolves to an unsupported operation, the Target OMS can detect this, and choose to return a different compatible operation (for example, return a message to be displayed) or simply send an Unsupported Operation error indication back . In the latter case, the initial WHO will take the necessary action to notify the user that the operation could not be completed.

The business model underlying the IMO operates under the following assumptions:

1. It is the OMS that actually solves the order (that is, the OMS of Destination), which has a source of revenue associated with each transaction.

2. WHO Destination Suppliers are willing to share a portion of their revenue with WHO Providers who expand their reach by ordering using their Access Points on behalf of WHO Destination, and with IMO, in exchange for acting as a mechanism for exchange.

Based on this, operations that result in an OMS of Destination resolving or providing content for transactions initiated by an initial OMS will result in the payment of OMS of Destination for both the initial OMS and the OMI. On the other hand, transactions for which the Initial WHO provides occasional content, even if the transaction is initially submitted through the IMO, will not result in payments.

It should be noted that, although most of this specification discusses the case where the IMO connects to WHO providers, who each support their own resolution service, one more case exists. This is the situation in which the company is in the business of providing Access Points only, and does not have its own Resolution Service. This supplier can be served perfectly by the IMO - in this case, the client systems can communicate directly with the IMO Portal or to simplify, they can communicate with a protocol translator system that will accept requests from the Access Points and translate them IMO Protocol.

The business model for a supplier of only one customer would presumably be to collect the share of the revenue offered by the WHO destination providers.

System Functionality

As described earlier, an access point or client device is any device that is able to read or scan a machine-readable code, such as a barcode symbol, and send the code data to an associated messaging system. Examples include cell phones with cameras as imaging devices and the like, which can communicate with the associated messaging system over a cell phone network, known in the art. These devices include an input circuit for reading the desired machine-readable codes, such as a scanner or optical barcode sensor (for example, a camera), and will also include a processing circuit programmed to perform the required functions, as described here, all well known in the art.

The messaging systems (for example, as described in US Patent No. 6,993,573 and / or US Patent No. 6,993,573 mentioned above) will be in network communications with the OMI Portal 16 to access the OMI10 services. For example, these systems can interoperate over a wide area of ​​the network, such as the Internet. In this case, it is simple for the different messaging systems 2, 4, 6, 8 to also communicate with each other via the Internet, for example, in the case where the routing information (address) of the destination WHO is sent from returns from OMI 10 to the initial OMS 2, so that the initial OMS 2 can send the resolution request directly to the destination OMS 4, instead of through OMI 10. The messaging systems will also have a processing circuit programmed to perform the functions described in this document.

The message exchange or OMI 10 is a computer server system programmed to manage resolution requests, determining the correct routing information (such as for database searches), and performing the various IMO functions described here.

OMI supports the routing of both commercial and non-commercial codes. This section of the specification provides a brief description of the various types of codes, as well as an overview of how routing is performed. The codes are divided into three main categories:

Commercial Codes - existing industry standard codes used in public commercial applications. These codes are specified and controlled by existing national and / or international organizations.

IMO codes - a code structure, one of which is specified in this document, intended for unambiguous routing through the IMO. Essentially, IMO Codes are intended to be domain specific equivalent to Commercial Codes, in which they would be cross-WHO providers.

• Proprietary Codes - Individual WHO providers have existing proprietary coding standards. As far as possible, these codes will be supported by the IMO in order to minimize the degree to which WHO providers will have to adapt their systems to support a unified global standard. The main challenge with Proprietary Codes is that there are no likely overlaps between the various systems, making the routing process difficult.

It is important to remember that, when dealing with these various types of codes, the term code can have two different meanings. The first meaning, which often comes to mind, is the physically printed barcode. The second, and perhaps more important, is the numbering plan that is used.

In the case of UPC codes, for example, the Uniform Code Council created a numbering scheme that it called a 12-digit code, in which some of the digits identify the manufacturer and the other digits identify the specific product. In addition, a symbology was defined, describing the way in which the digits of a UPC number would be physically encoded in a machine-readable bar code. The term UPC is often used to refer to both items, causing some confusion.

Whenever possible, the IMO is designed so that it can operate exclusively on the numbering plane, without the need for knowledge of the underlying real symbology, this is because the symbology information may not always be strictly present - some systems may offer the possibility numeric codes are entered by the user, as opposed to being digitized. In this case, if the collection of the numbering plans supported by the IMO is not univocal, the routing may be difficult or impossible.

Commercial Codes

The preferred mode IMO supports the routing of the following commercial product codes (although it can, of course, be extended to others): UPC-A, UPC-E, EAN-13, EAN-8 and ISBN. Each of these types of code is briefly described below.

UPC-A codes

Universal Product Codes (UPCs) have been used in the United States since the 1970s to identify commercial products for cash and inventory control. Variety A uses a numbering plan that is 12 digits in length, structured as follows:

A single digit from the Number System that indicates the code category.

A five-digit Manufacturer Code.

A five-digit Product Code.

A single check digit.

The Digit System digit is intended to reserve various codes for such items as store-only private codes, coupons etc. Manufacturer codes are specific to a particular Number System, so as a result, in traditional UPC codes, the first six digits of the code effectively identify the manufacturer or owner of the code. The manufacturer is responsible for assigning product codes as desired within the support range.

In recent years, as the Internet Protocol Address space began to be exhausted, the UPC governing body realized that the Manufacturer Code space was also at risk of being depleted. As a result, company prefixes of variable length were introduced in January 2005. Thus, at present, company prefixes can vary from 6 to 9 digits in length, leaving 5 to 2 digits for product codes.

UPC-E codes

UPC-E is an 8-digit numbering standard used in situations where the package size excludes the use of the full UPC-A barcode format. UPC-E is also referred to as UPC zero tablet, since the process of transforming an UPC-A into an UPC-E involves removing zeros. As such, each UPC-E can be transformed into an UPC-A equivalent. The reverse is not true - not every UPC-A has an UPC-E equivalent.

EAN-13 codes

The recent success of the UPC codes has led to the establishment of a broader standard, known as European Article Numbers (EAN). Note that Japanese Article Number (JAN) codes are a subset of EAN codes based on a Japanese country code, so for the purposes of this specification, JAN codes are identical to EAN codes. This is a 13-digit numbering pattern, which consists of the following:

A 2 to 3 digit System Code that typically identifies the country of origin. Some exceptions include System Codes 978 and 979, which are reserved for encoding ISBN codes, and 977, which is used for encoding ISSN.

4 to 5 digit Manufacturer Code.

5-digit Product Code.

A single check digit.

The coding of the EAN system has been carefully designed so that UPC codes are actually acquired in the system - if a prefix a UPC code with a single zero, the result is a valid EAN code. In addition, the underlying symbologies are compatible, so that if an EAN created by zero prefixing a UPC code is encoded in the simb symbology, the resulting physical pattern is the same as if the original UPC pattern had been followed.

EAN-8 codes

EAN-8 is a European standard bar code, intended for the same purpose as the UPC-E. Unlike the UPC-E system, however, EAN-8 codes are not created by manipulating EAN-13 codes. Instead, EAN-8 is its own standard numbering, including the following:

Country code from 2 to 3 digits to 5 digits of data.

check digit

Thus, unlike codes EAN-13, UPC-A and UPC-E, it is not possible to extract a part number from an EAN-8 code.

ISBN codes

International Standard Book (ISBN) numbers are 10-character codes. They consist of the following components:

Group Identification Code

Publication Code

Item Number

A single check digit

The lengths of the first three components vary by country and region. When printed, components are usually separated by dashes, although the numbers are placed together at intervals that make it possible to dissect the code without counting the presence of the dashes.

Note that ISBN codes employ a check digit algorithm that works on base 11. As a result, the check digit can have values ​​from zero to ten, where ten is represented as the character X. ISBNs are almost never printed as bar code. Instead, the standard approach is to use what is sometimes called a Bookland code, which is a form of EAN code. An ISBN is normally transformed into a Bookland code by taking the ISBN check character, prefixing the code with the digits 978 to produce a 12-digit string, and then computing and appending the appropriate EAN check digit. The decoding of such a barcode follows the reverse process - the prefix 978 (or, in some cases, 979) is recognized as an indication that the barcode contains an ISBN, and the Group Identifier Code, Publication Code and Number of the Item are extracted properly. If necessary, the complete original ISBN can be retrieved by regenerating the checker character using this extracted information.

Ambiguities

The UPC, EAN-13 and ISBN codes are completely separate from each other - they are 12, 13 and 10 in length, respectively, so that it is always possible to distinguish them from each other. In addition, valid codes can normally be distinguished from strips of random digits of paired lengths using the check digit algorithm supported by each numbering plan.

The UPC-E and EAN-8 codes, however, are both 8 digits long, and their number of planes intersect. The two codes use different bar spacing patterns, which means that it is possible for a barcode scanner to read the printed barcode to unambiguously determine the numbering plane to which a specific barcode belongs. Absent this information, however, it is not always possible to unequivocally determine which space a given 8-digit sequence belongs to - there are digit sequences that satisfy both symbology formatting rules. The valid UPC-E has a 1 in 10 chance of passing the EAN-8 check digit test, and vice versa.

IMO codes

Since the IMO of the present invention supports commercial code routing, it is recognized that there are many applications in which commercial codes are not available or are not suitable. WHO vendors have historically addressed this need by creating their own proprietary numbering standards - in fact, applications using proprietary numbering systems have so far been developed and deployed to a greater degree than those using commercial codes. Unfortunately, the fact that these individually developed numbering plans were created independently creates an interoperability challenge, as a given code can combine the numbering systems of more than one WHO provider, in much the same way as one a given sequence of digits can be valid for both EAN-8 and UPC-E.

As a result, the present invention includes a new numbering system available for use by IMO suppliers. This proposed system is designed as a high-level WHO industry standard, similar to the way that UPC is the high-level standard for retail. This allows for the independent generation of numbers by WHO providers, without fear of duplication, and is also designed to ensure that the numbers accordingly will not conflict with existing commercial codes. As a result, the ownership of any code generated according to this standard can always be determined unambiguously (at least, at the WHO level) and, therefore, routing can be performed unambiguously. Tracking which code belongs to which customer within a particular WHO would still be the responsibility of the WHO provider itself.

WHO providers are not required to adopt this new numbering standard; however, the IMO's ability to successfully route existing owner number systems will depend on additional metadata that may or may not always be available. As such, suppliers are encouraged to comply with this numbering standard, generating codes that can reasonably be found by external readers.

IMO codes have at least an OMS identification prefix and an item identification number. An example of an IMO code could have the following characteristics:

They are all numeric, allowing the maximum number of barcode symbologies to be used to encode them. (Some symbologies cannot encode non-numeric characters. Others can, but not as well).

They are of variable length, allowing short codes to be created for situations where space is valuable, without restricting the total number of unique codes that can be created.

They are always an odd number of digits in length. This avoids confusion with UPC-A, UPC-E, EAN-8 and ISBN commercial codes and the QODE Number system currently in use by NEOMEDIA TECHNOLOGIES.

They cannot be 13 digits in length. This avoids conflict with EAN-13 codes.

The first digit of the code is never zero. Some WHO vendors may adopt proprietary barcode formats that have a fixed capacity as opposed to a variable one and that store information as binary numbers instead of strips of characters. In such a system, there may be no simple way for this supplier to distinguish between, say, a code of 123 and a code of 00123.

Specifically, an IMO code has the following components:

<td>Component</td><td>Length</td><td>Contents</td>

<td>ID ID length WHO</td><td> 1</td><td>Indicates the length, in digits, of the portion WHO ID code</td>

<td>WHO ID</td><td>1 to 9</td><td>Indicates the particular WHO who issued this code</td>

<td>Item ID</td><td>variable</td><td>Defined by WHO provider</td>

<td>Verifying digit</td><td> 1</td><td>Checksum computed according to algorithm documented below</td>

Table 1

Each participating WHO will issue a unique WHO ID number, which will be used in the creation of the IMO Codes by this WHO Provider. There is no fundamental reason why a particular supplier cannot have more than one WHO ID, however, currently, there is no compelling reason for more than one to be issued per supplier. The format of the item ID field is left completely up to the particular WHO Provider, allowing for any desired owner substructure. While the WHO Supplier only generates codes with its own WHO ID, there is no fear of collisions between suppliers. Thus, the WHO ID is parallel depending on the Manufacturer ID of the UPC numbering system.

The check digit is calculated using the same algorithm used by the EAN-13 symbology. Thus, the check digit is correct if the following relation applies: (SUM (odd digits) + 3 * SUM (same digits)) mod 10 == 0

As an example, it is assumed that the seller with WHO ID 16 wanted to encode a

IMO code with Item ID 123. In this case, the code would be 2161235, where:

The first 2 indicates that the next two digits are the WHO IDs.

16 represents the WHO ID.

123 represents the Item ID.

The 5 is the check digit:

+ 6 + 2 + 5 + 3 * (1 + 1 + 3) = 30 mod 10 = 0

The requirement that the code be odd in length (not 13 digits long) may require that padding be added at times. If, in the case above, the item ID to be encoded is 12 instead of 123, the resulting code would naturally have been six digits in length. In this case, the WHO Vendor has the option of filling either the Item ID field (ie encoding the Item ID as 012) or the WHO ID field (ie encoding the WHO ID as 016 instead of 16, and change the WHO ID Length accordingly). The choice is left to the WHO Provider. Note that, in cases where the WHO Provider creates its own interpretation of the Item ID field to have an internal structure, it may not be possible for the WHO Provider to complete this field, without destroying the meaning of the code. In this case, filling in the WHO Supplier Length field is the only alternative.

WHO providers can obviously choose to use their own internal numbering standards in the Item ID field. In this way, an existing owner code could be transformed into an IMO Code involving the owner code with the WHO Supplier Length, WHO Supplier Fields and Verifier Type, making the code unambiguously routable at the cost of a few digits extra. This parallels, to some extent, the way that international phone numbers are routable unambiguously, prefixing them with International Country Codes.

This system, therefore, imposes a minimum extrapolation of three digits (or only two if compared to a similar system that has a check digit). This system therefore offers the following code numbers:

<td></td><td colspan="2">IDdeOMS</td>

<td>Total Code Length (Digits)</td><td>1 - 9 (1 digit)</td><td>10 - 99 (2 digits)</td>

<td> 5</td><td> 100</td><td> 10</td>

<td> 7</td><td> 1.000</td><td> 100</td>

<td> 9</td><td> 1.000.000</td><td> 100.000</td>

<td> 11</td><td> 100.000.000</td><td> 10.000.000</td>

<td> 15</td><td> 1.000.000.000.000</td><td> 100.000.000.000</td>

Table 2

As stated earlier, Owner Codes represent the category of codes currently supported by existing WHO providers. An example is the number system of NEOMEDIA QODE.

Due to the likelihood of conflicts between the various owner numbering systems, the IMO cannot reliably route Owner Codes without additional information. Fortuitously, most suppliers using such proprietary numbering systems also use some form of proprietary (or at least less used) barcode symbology. Thus, in situations where the code was automatically read and, therefore, the symbology is known, these codes can be prorated to their owner using the symbology information.

Routing Process

This section of the specification describes how the IMO goes about requesting routing code.

The IMO operates on the assumption that all codes fall into one of three categories:

Unique Codes are those in which a particular WHO provider has the exclusive right to provide content for the specific code. All Owner Codes fall into this category, as do all IMO Codes, since in both cases the specific code originates from, or is assigned to, a specific WHO Provider. In addition, certain Commercial Codes may fall into this category if the owner of the Commercial Code decides to establish an exclusive relationship with a particular WHO Provider for the treatment of this group of codes (it is a fundamental premise that Commercial Codes are owned by the company that organized its issuance, and therefore have the right to determine how these codes are treated, if they so wish).

Non-routable codes form the second category. This category includes Commercial Codes for which no WHO Provider can offer content, as well as codes not supported by IMO. The IMO is not able to assist in providing content for these codes. As such, individual WHO providers will be free to provide content for these codes as they see fit, or to provide error messages back to the user indicating that the code cannot be repaired.

Non-Exclusive Codes were the final category. This category includes business codes that have not been exclusively assigned to a specific WHO Provider, but to which one or more WHO Providers can provide content (for example, multiple providers may each have relationships with online bookstores and, therefore, they may be able to serve ISBN codes that were not exclusively assigned by the publisher to a particular destination).

Each WHO is required to submit any code that is not exclusively assigned to it to the IMO in order to determine whether this code is assigned exclusively to another WHO. If the code is not exclusively assigned to another WHO, the system offers the option to the initial WHO to then provide its own content, or accept the content of another WHO. As such, IMO procedures and protocols are designed to handle any of the following situations:

QMS A reads a code that is answered exclusively by itself (native code).

In this particular case, WHO A is not required to submit the code to the IMO. WHO A can simply serve the code as if the IMO did not exist.

QMS A reads a code answered exclusively by QMS B (external or non-active code).

In this case, WHO A recognizes that the code is not exclusively assigned to itself. As a result, it submits the code to OMI, which provides OMS A with the correct OMS B routing address or simply routes the code to OMS B for resolution. OMS B will compensate OMS A and OMI for this transaction.

QMS A reads a code that is not routable by QMS (external or non-native code).

In this case, WHO A recognizes that the code is not exclusively assigned to itself. As a result, it submits the code to the IMO. The IMO recognizes that it cannot verify the code, and returns a suitable indication to WHO A. WHO A is then free to process the request as it sees fit.

QMS A reads a code that is not exclusively provided by another WHO, but to which one or more other WHO can provide content (external or non-native code).

In this case, WHO A recognizes that the code is not exclusively assigned to itself. As a result, it submits the code to the IMO. The IMO determines, using the procedure discussed below, which WHO the order will be routed to. The chosen WHO will compensate the WHO A and the IMO for this transaction.

QMS A reads a code that is not exclusively served by another WHO Provider, to which one or more other WHO Providers can provide content, but to which QMS A prefers to provide its own content (external or non-native code).

In this case, WHO A recognizes that the code is not exclusively assigned to itself. As a result, it submits the code to the IMO, but with an indication that it would prefer to provide content, if possible. The IMO determines that this code is not exclusively assigned to another WHO, and therefore returns an indication to WHO A that it is free to provide the content.

Thus, payments are only made in situations where the final content is provided by a different WHO than the one that initiates the transaction. Thus, OMS A is not charged for any transaction in which OMS A ends up providing the content, even if the code was submitted to OMI as part of the overall processing. Routing Conventions

The IMO routing is fundamentally based on the owner of the code to be served. Ownership is determined based on a combination of barcode symbology, code type and a WHO Routing ID, which may vary depending on the type of code. As stated earlier, for Owner Codes, barcode symbology is used to determine the owner of the code, and is generally sufficient for routing purposes.

Table 3 below indicates the quantities that make up the WHO Routing ID for the other types of codes:

<td>Code Type</td><td>Routing ID</td>

<td>UPC-A and UPC-E</td><td>Digit of Numerical Series + Manufacturer Code</td>

<td>EAN 13</td><td>System Code + Manufacturer Code</td>

<td>ISBN</td><td>Group Identifier Code + Author Code</td>

<td>IMO codes</td><td>WHO ID</td>

<td>EAN-8</td><td>0 entire code</td>

Table 3

Note that EAN-13 codes that carry ISBN codes within them could be transformed into their ISBN format before routing processes were carried out.

In the absence of symbology information, ambiguities between UPC-E, EAN-8 are resolved based on the country of origin of the order - if the order comes from North America, a code that corresponds to both the UPC-E and EAN-8 standard will be interpreted as UPC E-. Otherwise, it will be interpreted as an EAN-8. Although it is not impossible, it is assumed that it is highly unlikely that a product marked with an EAN-8 code will be present in North America. The reverse (a product marked with a UPC-E found in Europe) is a little more likely, however ambiguity rules are only applied when the symbology is not known (usually as a result of manual entry) and when the code also matches with the two formatting rules UPC-E and EAN-8.

The IMO will support transaction routing based on the following quantities:

Initial WHO

Barcode Symbology

Barcode routing ID

The rules that the IMO applies to routing transactions assume that, in the case of Non-Exclusive Codes, individual WHO participants will reach business agreements for the code groups that will be cross-prorated, and the terms of which will take place. WHO Suppliers will submit this information to the IMO so that the routing rules can be executed automatically.

In particular, in addition to the rules necessary for the application of Unique Codes, the IMO will support routing rules that support the following:

Allow a given initial WHO to direct all of its Resolution Requests to a specific barcode symbology for a given target WHO. A scenario in which this might be appropriate would be if several WHO were able to resolve UPC codes, and the initial WHO wanted their traffic to be directed to a particular destination.

Allow a given initial WHO to direct requests for particular combinations of symbology and Routing ID to a specific Target WHO. A scenario in which this may be appropriate would be if multiple WHO were able to resolve the subsets of the UPC code space, and the initial WHO wanted some of its traffic to be directed to one destination and part to another destination.

In the absence of a more specific rule, allow all Resolution Requests for a specific barcode symbology to be routed to a particular Target WHO. This covers the case where a special symbology is used by only one WHO, allowing the routing of such WHO owner codes.

Finally, transaction routing will support an option whereby a particular initial OMS can prevent transactions from going to a specific Destination OMS through the OMI routing process. This may be appropriate in situations where only one WHO provides content to a given category of codes, but the two WHO have not been able to reach a mutual agreement on the financial terms, or when there are other agreements in which they would not use each other's codes . This would allow these WHO to participate in the global IMO structure for other types of code, but essentially would not see each other for this particular type of code, without the need to explicitly pre-filter the codes they sent to the IMO. Such rules would have to have valid reasons, and be approved by the IMO.

IMO System Architecture

The architecture of the IMO system consists of two types of systems: Portals and a Directory. As shown in Figure 4, these systems are logically connected in a star topology, with the Directory in the center.

Portal systems are responsible for all direct transaction processing in the system. The systems of individual WHO providers contact a Portal through an OMIP, in order to request resolution information from a digitized code. They also record the results of each transaction.

The Directory acts as the central repository of routing information for the system. As routing information is updated over time to reflect the inclusion of WHO providers, the assignment to the code varies for providers etc., this information is updated in the Directory. The individual Portals are updated periodically from the Directory and, thus, will propagate the information through the system within the update time. A search engine is more secure than a shipping system, where Portals are less likely to be poisoned by inadvertently accepting dishonest information. The system may contain a means by which the Directory can request that the Portal schedule a search out of sequence so that the information can be updated more quickly than the normal update interval. In addition, the directory periodically uploads and collects accumulated transaction records from Individual Portals. This process thus creates a central repository of all transactions that have been served by the system, as long as the billing and payment calculations from WHO to WHO can be performed. Note that the Directory itself is not involved in individual settlement transactions.

Over time, it is expected that the OMI system as a whole will process a significant number of transactions per unit of time. The following factors in the architecture and design of the system allow the entire system to achieve a high transaction rate:

Installations of Individual Portals are all pairs, in which any individual Portal is able to correctly identify or route any request for resolution. As such, it is very simple to scale the system horizontally by adding additional Portals, and to distribute the load accordingly. Among other things, this also allows Portal facilities to be deployed, if necessary, in locations that will minimize the network distance between them and the WHO facility.

Individual Portal transactions are stateless. As a result, within a specific Portal physics installation, it is very simple to use conventional load balancing techniques to distribute the load across multiple servers. This also helps with reliability, as it allows individual servers to be added and removed from the asset pool as needed for system maintenance etc.

The OMI Protocol is based on HTTP or HTTPS. Individual Portals will be designed to support persistent connections, allowing a single connection to fulfill multiple requests for resolution, if desired. This reduces the effective protocol overhead associated with HTTPS implementations.

The actual data needed to perform good transaction routing is relatively small. As such, individual Portals are likely to wipe out most of the information stored in the cache, decreasing the number of physical accesses to the database on a per transaction basis. Most of the steady state database load would be log records.

Any system that is central to the business models of companies must have a high degree of reliability in order to guarantee grid performance.

Individual Portal installations will typically be built using industry standard techniques, involving redundant or fault tolerant server systems and network equipment. In this way, a typical configuration would contain no single point of failure from a hardware point of view, and would probably use hardware load balancing to distribute the individual transaction load to individual physical servers and also to divert traffic away from one server that has failed or needs to be taken offline for maintenance. In addition to employing the latest hardware to maximize individual installation time, there will be a minimum of two physically separate Portal installations. Each of these facilities must contain a complete replica of the data needed to route transactions and, therefore, will be completely interchangeable for use in real time. As a result, if a network failure or main equipment failure prevents an individual OMS from accessing the IMO, the Initial WHO will be able to move to another IMO facility and continue its operations as needed.

Specifically:

The system will be designed in such a way that each individual Portal has a unique DNS name, allowing an individual Portal to be selected specifically for a given transaction.

Portals will share a common DNS name that will be the primary one used for individual transactions under normal circumstances.

Thus, under normal circumstances, the Initial WHO will normally attempt to first connect using shared DNS. If that fails, the Initial WHO may attempt to use the individual names in sequence. Like this:

Under normal circumstances, when all Portals are operational, a dynamic DNS system can distribute the transaction load across the various Portals.

If one of the Portals has to be shut down for maintenance etc., the DNS system can be updated to exclude the Portal. After the time required for this DNS update to propagate through the various caches, it will have the effect of diverting all traffic to the other Portals.

If a Portal is unavailable due to an unexpected hardware failure or network interruption, the repetition logic involving the names of individual Portals allows an Initial WHO to find a working Portal without having to wait for a DNS update.

Because it is not involved in individual transactions, the Directory system does not need the same type of distributed application. If the directory is temporarily down or has to be shut down for maintenance, overall system performance is not affected in any way. The worst case scenario is that updates required for routing information would have to wait until the Directory was restored for operation, and the Portals might have to generate more than normal transaction records. This does not suggest that the directory will be built to standards lower than individual Portals, but only that it is not necessary for the system architecture to deal with the complexity of having several physically separate Directories, with the data synchronization issues.

Security, in the IMO system, is necessary at several levels:

Physical Security

The physical security of any system involving financial transactions is obviously critical, since without physical security, data security cannot be maintained. The installation of individual Portals and the installation of the Directory will be in the data control security centers. In particular, IMO Portals will not be installed in the physical facilities of WHO providers.

Communication security.

The nature of the communications must be such that fraudulent transactions cannot be entered into the system, and valid transactions cannot later be repudiated.

Optical Message Exchange Protocol (OMIP)

An overview of the information that is carried in the Resolution Request and Resolution Request messages is provided below. The nature of the message formats is extensible so that additional fields can be added as needed. WHO systems are only needed to support such fields marked as mandatory.

The fundamental protocol is implemented using XML over HTTP or HTTPS. Thus, all requests and responses are XML documents under normal circumstances. Responses will use HTTP 200 OK status codes only in the event of errors in the system.

There are four fundamental messages supported by the system:

WHO Resolution Request

This message is sent from a WHO to the IMO requesting the resolution of a particular code.

IMO Resolution Response

This message is sent from the IMO to the WHO, in response to a WHO Resolution Request, and carries the information that indicates the action that the WHO should take in response to the code.

IMO Resolution Request

This message is sent from the IMO to an OMS requesting the resolution of a particular code.

WHO Resolution Response

This message is sent from WHO to IMO, in response to a Resolution Request, indicating the action that must be carried back to the initial WHO.

Thus, the normal sequence of operations is as follows:

The initial WHO, recognizing that it has received a scan of an external code, sends a WHO Resolution Request to the IMO.

The IMO determines the Destination WHO according to its routing rules, and transmits the Destination WHO address back to the Initial WHO or forwards an IMO Resolution Request to that WHO.

The Destination WHO determines appropriate action to take, and returns this information to the Initial WHO or the IMO in an WHO Resolution Response message.

The IMO passes the result back to the Initial WHO, when necessary, in an IMO Resolution Response message.

In situations where the IMO determines that a code cannot or should not be routed, steps 2 and 3 are omitted, and the IMO sends the IMO Resolution Reply message immediately back.

The WHO Resolution Request includes the data fields indicated in Table 4 below.

<td>Field</td><td>Required?</td>

<td>Initial WHO ID</td><td>Yes</td>

<td>Initial WHO Transaction ID</td><td>No</td>

<td>End of Transaction</td><td>Yes</td>

<td>Barcode Data</td><td>Yes</td>

<td>Barcode Symbology</td><td>Yes</td>

<td>Device Information</td><td>No</td>

<td>User Demographics</td><td>No</td>

<td>Access Point Capabilities</td><td>No</td>

<td>Preferred Local Action</td><td>Yes</td>

Table 4

In addition, the route information can be used in the message format above, which will indicate to the IMO whether the routing information should be returned back to the original WHO or used by the IMO to forward the Resolution Request directly to the destination WHO. This can be as simple as a flag or the like.

The IMO Resolution Request includes the data fields indicated in Table 5 below.

<td>Field</td><td>Required?</td>

<td>Initial WHO ID</td><td>Yes</td>

<td>Initial WHO Transaction ID</td><td>No</td>

<td>End of Transaction</td><td>Yes</td>

<td>Barcode Data</td><td>Yes</td>

<td>Barcode Symbology</td><td>Yes</td>

<td>Device Information</td><td>No</td>

<td>User Demographics</td><td>No</td>

<td>Access Point Capabilities</td><td>No</td>

<td>IMO Transaction ID</td><td>Yes</td>

<td>Target WHO ID</td><td>Yes</td>

Table 5

The WHO Resolution Response includes the data fields indicated in Table 5 6 below.

<td>Field</td><td>Required?</td>

<td>Action</td><td>Yes</td>

<td>History Restrictions</td><td>No</td>

<td>Target WHO Transaction ID</td><td>No</td>

Table 6

The IMO Resolution Response includes the data fields indicated in Table 7 below.

<td>Field</td><td>Required?</td>

<td>Action</td><td>Yes</td>

<td>History Restrictions</td><td>No</td>

<td>Target WHO Transaction ID</td><td>No</td>

<td>OMI Transaction ID</td><td>Yes</td>

Table 7

Table 8 below describes each of the message fields in the various OMIP messages:

<td>Field</td><td>description</td>

<td>Point of Sale Capabilities Access</td><td>This optional field that indicates which categories of Shares the Access Point is capable of running. If omitted, it will be assumed that the Access Point is capable of supporting all defined operations.</td>

<td>Action</td><td>This field indicates the action to be taken by the Initial WHO. Defined actions include: • Launch HTTP / HTTPS URL. • Dial a phone number. • Send an SMS. • Present a coupon. • Display data (for example, text, HTML) other than Launch command where the Action takes the data itself, at the rather than a reference to these. • Initial WHO to provide the appropriate Action (used to indicate that IMO has not provided an Action) The format of the Action field allows both: • Several sequential Actions to be specified, so that an Access Point can be commanded to do several things. • Several possible Actions to be specified, where the Access Point must answer for choosing the first Action that he is able to implement.</td>

<td>Barcode Data</td><td>Barcode Contents</td>

<td>Symbology of the Code of Bars</td><td>Identification of the specific symbology in which the bars was encoded. A special keyboard symbology is included to support the case where information is entered by the user, rather than digitized.</td>

<td>Target WHO ID</td><td>The value in this field identifies the WHO that originated the transaction.</td>

<td>WHO Transaction ID for Destiny</td><td>This is an optical field that allows the OMS of Destination to uniquely identify the transaction using its own internal system, independent of the 1D of the Transaction of IMO. If provided, the IMO will record this information in your own transaction store, and will also return it to the Initial WHO. This amount can be used for post-fact reconciliation and for audit purposes.</td>

<td>Device Information</td><td>This is an optical field that provides model and manufacturer information about the Access Point device that originated the transaction.</td>

<td>History Restrictions</td><td>Indicates whether or not the access point can save the order or response information for later reuse by part of the end user. Possible values: • The data cannot be reusable. (Suitable for situations where the user must physically re-examine a bar code in order to repeat the operation.) • Barcode data can be stored. (Suitable for situations where the recall by the user is acceptable, but a server transaction must occur at each time.) • Response data can be stored. (Suitable for situations where it is acceptable for information to be redisplayed without consulting the server again, as as storing coupon data for display and subsequent redemption). Note that 'Access Points are not required to immolate ment a historical feature - this information intended to allow WHO to have restrictions on how items can be saved to pass these restrictions on to other WHO. If this data is omitted, the Access is free to choose your own behavior.</td>

<td>Preferred Local Action</td><td>This field indicates whether the Initial WHO would prefer to provide content for this transaction if allowed. If this field is defined and if the specific code is not assigned exclusively to a specific Target WHO, the IMO will return an Action that authorizes the Initial WHO to provide the Action.</td>

<td>IMO Transaction ID</td><td>This field contains a number that uniquely identifies this specific transaction to the IMO. This amount can be used for post-fact reconciliation and audit purposes</td>

<td>Initial WHO ID</td><td>The value in this field identifies the WHO that originated the transaction.</td>

<td>WHO Transaction ID Initial</td><td>This is an optical field that allows the Initial WHO uniquely identify the transaction using your own internal system, regardless of the IMO Transaction ID. If provided, the IMO will record this information in its transaction store itself, and will also return it to the WHO Destination. This value can be used for reconciliation post-fact and for audit purposes.</td>

<td>Transaction Source</td><td>This optical field indicates the source of this transaction: • Direct scanning of a barcode • Data entered by the user • Retrieving the history list from a scan of previous bar code. • Retrieving the history list of previously entered data.</td>

<td>User Demographics</td><td>This is an optical field that provides information about the end user of the Access Point. This information can be used by the Target WHO to refine the process resolution. The defined subfields include: • User language (user's preferred language) • Country (indicates where the user is located) • Genre • Age Additional fields will be added as requested WHO Suppliers.</td>

Table 8

Security is, of course, of utmost importance in any system that manages or involves financial transactions. The IMO includes the following security features:

In the incoming OMIP channels:

Each individual Resolution Request requires authentication.

OMI optionally has SSL encryption on its input channels, with the additional option of using symmetric public keys to further guarantee the security of the OMS-to-OMI channel.

Resolution requests are accepted only from addresses with predefined IP or ranges of IP addresses. This allows orders from legitimate sources to be approved, while helping to prevent unauthorized people from using the system, even if authentication information is compromised.

On the outbound OMIP channels:

Each individual Resolution Request can generate authentication, if required by the target WHO.

The IMO optionally supports SSL encryption on its outbound channels, with the option of using symmetric public keys.

As stated earlier, it is an assumption of the core business that participating companies see the extended reach provided by IMO participation as being beneficial to them, and so they will be willing to bear the financial costs of participating in the exchange. In particular, in many situations, this means that the Target WHO will be willing to compensate the Initial WHO for having met one of its barcode symbols. The IMO has all the necessary records and data processing required for cross-company billing in support of IMO operations.

The IMO fee structure depends on the following items:

Initial WHO

WHO of Destination

Bar code symbology

Message Quantity

Payment schedules are established by the Initial WHO, and can be general (for example, I will pay $ 0.02 to someone who examines one of my codes) or specific (for example, I will pay WHO B $ 0.03 for each one of my verified UPC codes). The two can be combined, with specific rates taking precedence over general rates. In addition, the rate card can be differentiated so that the message fee changes based on the total number of messages delivered on a monthly basis.

Note that IMO does not attempt to implement any variable rates on demand (eg revenue sharing), however, it does provide full transaction-to-transaction reports for participating WHO companies, allowing them to reconcile such issues with each other if appropriate. . In addition, fees are applied only to requests for resolution that result in the destination WHO providing the resolution service - no charge comes from requests that result in an error condition, or if responsibility for providing any action is delegated back Initial WHO. Finally, the IMO alone will impose a fee on each successful resolution delivered, in order to offset its own operating costs.

The IMO will serve as a financial intermediary between the participating WHO, thus simplifying its own financial processing. The IMO will provide each participating WHO with monthly summary statements indicating the number of transactions processed by and on behalf of each WHO, and corresponding net payment resulting from or to the IMO.

IMO will grant each WHO access to the detailed report, including record downloads, associated with all transactions originated by or provided by WHO.