WO2013165028A2

WO2013165028A2 - Systems and methods for tracking and authenticating serialized items

Info

Publication number: WO2013165028A2
Application number: PCT/KE2013/000032
Authority: WO
Inventors: Patrick Nyachio ATAMBO
Original assignee: Atambo Patrick Nyachio
Priority date: 2012-05-04
Filing date: 2013-05-03
Publication date: 2013-11-07
Also published as: WO2013165028A3

Abstract

The present invention provides systems and methods of authenticating genuine products and detecting counterfeits. The said systems consist of a myriad of services and clients, including at least one Service Registry and User Authentication Service through which the different clients and services, acting as agents within the system, locate and authenticate each other. Genuine products include taggants that have a short, random, concealed string and a visible string of characters which together are used when identifying authentic items. Recipients of items are supplied with the concealed string and a means of matching it with the visible string and thus the product on which it appears, for use in authenticating received items.

Description

SYSTEMS AND METHODS FOR TRACKING AND AUTHENTICATING SERIALIZED ITEMS Field of Invention

[001 ] The disclosed embod iments of the present invention relate to the process of generating taggants, tagging items, tracking the items through distributions channels and enabling the end user to verify the authenticity of the products at the Point-of-Sale or elsewhere at his/her own leisure. As the goods are tracked, disclosed embodiments also allow agents of the manufacturer, or government agents to be able to verify the authenticity of goods remotely using any device that has I nternet access; it is also possible to do remote verification by phone cal ls or via any other commun ication channel avai lable.

Background of the Invention

[002J The invention disclosed herein relates to counterfeit prevention and detection methods. In particular, it concerns providing a means of authentication of physical objects, such as products or documents, especial ly by the final recipients or consumers of the said objects. In this case and in a vast majority of such cases, the victim and greatest loser is the final user/consumer of the counterfeit goods. With proper appl ication, the disclosed embodiments would deter counterfeiter from introducing their counterfeit products into the market and l imit trade in contraband and stolen goods.

[003] Enabl ing final users to easily detect counterfeits is the most effective method of el im inating counterfeits from the market because every single item eventually finds it way into the hands of the presumed consumer, or final user. This is especially helpful as compared to anti-counterfeit methods that depend on agents randomly checking goods to verify their authenticity since agents can only check so many items. The specific area of anti-counterfeit technology under which the em bodiment of the invention disclosed herein l ies is item ised serialisation, where individual objects are serialized and can thus be identified individually within the distribution chain. The disclosed embodiment of the invention adds security features to serialised items and the distribution process that make it difficult to sel l counterfeit products. In addition to this, the system provides an easy way for consumers to verify the authenticity of purchased products at their own leisure and at the point of sale.

[004] According to the International Anti-Counterfeiting Coal ition, ' it is estimated that counterfeiting is a $600 bi llion a year problem. In fact, it's a problem that has grown over 10,000 percent in the past two decades, in part fuelled by consumer demand. ' [005] With the plural of anti-counterfeit technologies in the market, counterfeiting is actual ly on the rise, the world over, especially for electronic goods and pharmaceuticals where the products are of a h igh value and the margins are high. A study by the Counterfeiting Intel ligence Bureau (C1B) of the International Chamber of Commerce (ICC) estimates that counterfeit goods make up 5 to 7% of World Trade. Counterfeits resu lt in a sign i ficant loss of revenue either through brand dilution when counterfeits are substandard or through loss of revenue when they are of a quality close enough to the genuine goods.

[006] Due to the magnitude of problems posed by counterfeits there have been great efforts to el im inate them from the market or at the very least, to reduce their prol iferation to a minimum, many of these efforts being technological inventions aimed at aiding a process of differentiating genuine goods from counterfeits. It is towards this end that the embodiments of the invention herein are aimed. No doubt, the significance of this invention cannot be measured by any one uniform standard because to some consumers, mainly owing to their financial limitations, counterfeits offer a cheaper route towards fulfi lment of wants, whereas to Governments, Anti- counterfeit agencies and manufacturers, counterfeits pose great dangers to the economy and national security.

[007) With the advent of internet and cloud computing, there is a plural of technological solutions that are yet to be explored and taken advantage of in the fight against counterfeits, theft and diversion. It is currently possible for manufacturers to have a transparent distribution channel at a negl igible cost, and whi le this wou ld help fix the problems, it is yet to be ful ly uti l ised. The embodiment of the invention presented here, shows j ust how that could be done, efficiently.

[008] Prior Art

[009] There is a great deal of prior art aimed at fixing the counterfeiting problem, employing a myriad of approaches that it is impossible to cover them al l here. I n addition to th is, a majority of the prior art is at al l relevant to the disclosed embodiment of the invention. To create a picture of what prior art exists and show where the disclosed invention sits in the picture we wil l describe a smal l subset of the relevant prior art.

[010] The idea of ascertaining authenticity with use of a random control number and a serial number goes as far back as 1972 where it can be found in the Un ited States (US) Patent number 3,833,795. While this is a great idea, if someone saw a single item, they can easily make copies and pass them off as genuine and to address this problem the solution offered is changing the random control number each time the serial number is read. The problem with changing the serial number all the time is that it may only be efficiently done if only one entity makes or tracks the changes and thus has complete autonomy over the items, this is hardly ever the case in the distribution chain. The idea of a serial and random number has also been employed in various areas including mobile phone pre-paid cards that have the random section concealed using a scratch off label. While this works great for items that require the user to feed in the revealed random number in order to use them, they are problematic for items that will not require users to do so. A simplified version of this has been employed by an anti-counterfeit solution called mPedigree made by a non-profit organisation by the same name. mPedigree that has only a random number concealed by a scratch-off label, and it requires the buyer to send in the revealed number to a mobile network short code in order to authenticate the item, which is both expensive, at the very least to network operators, and cumbersome.

[Oi l] The idea of concealing at least a part of the item's identification information is furthered in the European Patent Specification EP 0 647 342 B l which discloses a method of authentication which involves keeping the random sections concealed inside the packaging of the items or in the return cards. This approach, while it may work for forensics and warranty verification, it fails for consumers since a consumer may easily be duped into purchasing a counterfeit item. Even for forensics, there is still a great problem where a counterfeiter simply copies all the identification information on genuine items and sneaks the counterfeit items into the distribution chain, leaving forensic experts with no means of verifying authenticity of items.

[012] There is also the idea of issuing certificates of authenticity that can be found in the US Patent 5,267,756 coupled with registration of purchased items. The said item registration is done over the phone, by the customer calling a registration hotline and having the item registered in their name or from a database list. The problem with this approach is that it is time consuming, cumbersome, and expensive and very difficult to scale.

[013] There are various parts of the present invention that employ prior art, such as labelling of products, generation of random codes, Service Oriented Architecture, methods of authentication among many others. One of the key deficiencies in the prior art is the fact that the technology that allows the buyer to verify authenticity forces the buyer to validate all the purchased items at the Point-of-Sale, something which, to say the least, is problematic for large purchases. Compounding this problem is the fact that nothing in the prior art deals sufficiently with the very real life situation where a buyer purchases several items from several manufacturers.

[014] Of note, is the US Patent 7,686,321 B l that discloses a method of dealing with many products, from many manufacturers but discloses applicability with one database as the source of all the authentication system. The disclosed method requires a Product Code separate from the items' public Unique Identifier, this means that for a seller to employ this method, before an item can be authenticated, he/she wi ll be required to enter data twice, doubling the work that needs to be done in order to make a sale, and reducing the efficiency with which he/she can work. The problem is compounded by the fact that the retailer has to wait to be informed by the system if he/she needs to enter the public Unique Identifier of the item, before proceeding, causing even further delay. Another big problem with this disclosure is the fact that it does not militate against sale of stolen or diverted goods as the system does not verify ownership before providing authentication.

[015J The US Patent 7,752, 1 37 B2 discloses a method of working with multiple database servers and for various products and manufacturers, but it requires users to select the product from a provided list, before being directed to the appropriate server. This is highly inefficient as it would consume a lot of time selecting the correct item being purchased as opposed to making the system simply know the item being purchased. This approach would not work for busy retail outlets.

[016] On the matter of transfer of ownership, the patent application US 2004/008823 1 handles the matter in a rather detailed manner, although it falls short when it comes to dealing with the real life scenario where there are many manufacturers and many products and thus many sources of data.

Brief description of the invention

[017] The disclosed embodiments of the present invention relate to the process of generating taggants, tagging items, tracking the items through distributions channels and enabling the end user to verify the authenticity of the items at the Point-of-Sale or elsewhere at his/her own leisure. As the goods are tracked, disclosed embodiments also allow agents of the manufacturer, or government agents to be able to verify the authenticity of goods remotely using any device that has Internet access; it is also possible to do remote verification by phone calls or via any other communication channel available.

[018] The embodiments in this disclosure are concerned with producing documentation after a sale to a presumed end user that would enable the end user to verify the authenticity of the purchased items. To enable this, a business-to-business co-operation platform has been designed and within it, parties in the distribution chain may interact and share information with the aim of enabling the end user to authenticate items. Since the final sel ler of the items is expected to be the one authenticating the items, and would be unable to sel l items that he/she cannot authenticate, it is paramount that every player in the distribution chain be able to verify the authenticity of purchased items. To determine authenticity, the ownership of any given item is tracked to the very end and only the Recogn ised Owner of an item can sel l it, and once sold, the sel ler loses ownership of the item in the system and thus any given item can only be sold once. To al low tracking, every single item and bulk packages containing several items are serialised. Buyers are able to verify that the ownership of purchased items has been transferred to them, and thus the authenticity of the items. Since an item can on ly have one owner at any given time and that any Recognised Owner can sell an item only once, counterfeiters would be deterred from copying genuine serial numbers as they would neither be able to transfer their ownership to the buyer nor provide evidence of transfer of ownersh ip to the buyer. Also, since the retai ler sel l ing to the end user must provide documentation to aid in authenticating the item, they wou ld be deterred from buying goods without getting ownership transferred to them. To ensure that all retai lers provide authentic sale documentation, end users are al lowed to verify their sale documentation with a third party with whom the retai ler must register al l documentation produced.

[019) For the embodiment of the invention in this disclosure to function, the manufacturer or any other presumed originator of products must have a product code for each product to be tagged. These Product Codes can be issued by an organisation that manages them and ensures that no two products share the same product code. With a Product Code in hand the originator of a product (from here on assumed to be the manufacturer) proceeds to generate Item Numbers and Authentication Codes for his/her manufactured instantiations of her/his product, which are then saved in a database in relation to each other. The Product Codes are then prefixed to the Item Num bers and the resulting string is considered a Serial Number and may be encoded into a barcode and printed on a tag or saved on an RF1D, or any other mach ine suitable readable medium. A random Authentication Code generated is then generated for every Serial Number and added to the tag baring its associated Serial Number after which the said Authentication Code is concealed and the said tag affixed on an instantiation of the product. A unique Serial Number is used on every tag created and the tags affixed on every instantiation of the products employing the technology disclosed herein. The Serial Number is universally unique among all products tagged that use the disclosed technology because the Product Code is different for every product. The Serial Number and Authentication Code form the Authentication Information. Item Numbers and by extension, Serial Numbers may however be retired period ically, perm itting reuse.

[020] The sale documentation can then be used to verify the contents of the sale by comparing Authentication Codes provided on the sale documentation in relation to their paired Serial Numbers as indicated on the sale documentation. There must be clear rules of picking out Serial Numbers and Authentication Codes from the sale documentation, and rules for pairing them correctly. Once the Authentication Codes and Serial Numbers have been paired correctly, the buyer can verify that al l items in the sale have been included in the sale documentation. After th is the buyer can proceed to authenticate the purchased items by comparing Authentication Codes provided on each item with that on the documentation that has been paired with the Serial Number on the item. I f the Authentication Codes match, then the item is genuine, if they don't match, then the item is not genuine. G iven that the Serial N umbers are unique, items tagged with a taggant containing the a aforementioned Authentication I nformation can be validated by sending the Authentication Information as a query to the manufacturer's server via mobile network Short Code, or a web form.

[021 J To enable the creation of the said documentation, items require to be tagged in a manner that would be meaningfu l for the produced documentation, and that wou ld al low easy verification by the end user. The disclosed embodiment tackles serial isation of individual items in a sale with the added security feature of a concealed Authentication Code. The embodiments described in the present invention can work over a computer network, which is the preferred embodiment, or over telephone with the role of the different servers in the network being replaced by individuals with access to the relevant data.

[022] Documentation in the main embodiment covers printed Sale Receipts but the invention can work equal ly as wel l for emailed documentation, mobi le phone text messages (SMS), data stored in a vendor issued smart card, data stored in a buyer's onl ine account with the vendor, a mobi le appl ication receiving the data via Near Field Communication (N FC), or on any media that can store and al low d isplay of formatted data. That is to say that, an online retailer may send valid sale documentation for the sake of authenticating the item in print with the courier, on emai l, or avai l it on line for viewing. A large retai l chain may opt to issue smart cards on which documentation issued to buyers are stored. A smal l retai ler may issue Sale Receipts that double as the aforementioned sale documentation. [023] After releasing items into the d istribution chain, the manufacturer keeps track of the change in ownership of every individual item. In order to track ownership, the manufacturer maintains a database of owners (Recognised Owners) of the items. At the onset, the manufacturer is the Recognised Owners and once the items are sold, the ownership transfer is registered in the manufacturer^'s database of owners. For an ownership transfer to occur the current Recognised Owner makes a request to the server hosting the Owners Database and requests that specific items be transferred to a new owner, and in the event of an error, this action can be reversible for a whi le. The new owner, assumed to be a buyer, should be able to veri fy the items transferred to him. I nformation made avai lable to the new owner should include the Serial Numbers of the largest bulk packages transferred and the number of individual units, assum ing a bu lk package purchase. Only bulk package details wi ll be revealed and the number of individual items in the bulk package provided for verification. In order for a buyer to access this information, they wi l l be required to provide order/del ivery information, as supplied by the sel ler to the manufacturer. Where individual items not packaged in a bulk package are transferred, then the detai ls of these individual items will be issued.

[024] In the disclosed embodiments of the invention, it is envisioned that the solution wil l work in situations where there are a myriad of manufacturers making a myriad of products avai lable. The said products would be sold in a plural of retail outlets stocking several products in al l manner of combinations. In order for an anti-counterfeit system to function in a most secure manner in such an environment, it would require a great deal of decentral isation of data. Decentralisation of data here means that every manufacturer should be al lowed to record ownersh ip and Authentication Information about h is products. A Service Oriented Architecture (SOA) based business-to-business cooperation system that wou ld al low j ust that, is part of the disclosed embodiment of the invention. The system has a central ised Service Registry and Authentication Server, and a plural of Cl ients and Services.

[025] Whi le the system, in and of itself, does not authenticate items, it provides a means of authenticating them. For a seller to sell an item, all that is needed is for them to own that item, although random authentication requests may be made by the manufacturer, but that is only meant to keep the retai lers in check, the buyers have to authenticate what they purchase themselves. The buyer may be an end user or a resel ler. Resel lers must enter their order/del ivery information into a device that can access the manufacturer's Owners Database and veri fy that the detai ls of their del ivery match those on their del ivery note. The resel lers who make the purchase can reject an ownership transfer within a stipulated time frame, and the sellers can also reverse a transfer, effectively cancel ling it. End users can verify authenticity by using documentation received, and can verify that the documentation is correctly registered with a third party by making a request to the said third party responsible for registering the said documentation. Access to the said third party may be by phone using USSD and/or SMS and/or via the Internet using a web form and/or by any other suitable means avai lable. Using the said documentation, end users shou ld be able to generate certificates of authenticity from manufacturers' websites, mobile application or desktop application, or by any other means provided by the manufacturer.

[026) Also possible, is status changes on items, such that sel lers of items can determine if items are avai lable for retai l, on transit or in storage. The Recognised Owners could be al lowed to change the status of items they ow n as an added security measure, and thus providing better security against theft and fraud. That is to say that a seller cou ld mark al l his items as in storage, and thus they cannot be successful ly retai led. An on transit status would be very helpful, especial ly to security agents looking to verify if items found on transit should indeed be on transit. A stolen status can be added to information stored in relation to items as wel l so as to check against highway robbery and ensure that the system is on the lookout for stolen goods. Information may be made available to certain entities based on the status, for instance, security agents may be able to authenticate Serial Numbers of items in transit, and consumers those of items marked as available for retai l.

[027] On the business-to-business system, any given request from any given client needs to be made to the correct server and since clients do not have a complete record of servers and what the said servers manage there is need for a Service Registry. The Service Registry directs the clients to the Servers that manage and track information relating to specific Serial N umbers based on the Product Code. Th is is to say that in this system, the Product Code acts as a routing code and is used to determ ine where information regard ing any product can be gotten from. Any client seeking information regard ing any given item simply reads the item 's Serial Number and sends it to the Service Registry, which in turn returns al l the necessary information regarding the Originating Service for that Product Code.

[028] There may be situations where a packet contains many small items that can be sold as individual units, this presents an interesting case for authentication, and for this, a viable solution entai ls having a single concealed character on the smaller items, alongside one or two visible characters forming the authentication code for that item. The Serial N umber of the containing package or a few of the last characters of the said Serial Number could also be present on the smaller individual items. This is ample security as a counterfeiter would never be able to accurately guess the authentication codes of all the items in the package. When entering data from the smal ler items into the Point-of-Sale system, it may require manual entry of data if there isn't enough space for a barcode. While the Serial Number on the containing package could suffice for such small items, RFID would solve space problem for more valuable items.

Brief description of Drawings

[029] Fig I has a tag 100 containing, a Product Serial Number 103, a scratch off label 102 concealing an Authentication Code 101 and a QR-Code 104 encoding of 103.

[030] Fig 2 is a flow chart showing the steps involved in producing 103 and 101 that can then be printed on tags.

[031 ] Fig 3 is a drawing of a Sale Receipt 300 designed to be used when checking purchased goods for authenticity, and an enlarged drawing of a list 309 of comma 315 separated concatenated 101 , 103 pairs 317.

[032] Fig 4 shows the general architecture of the system that enables seamless sharing of information between a plural of entities using a Service Oriented Architecture (SOA).

[033] Fig 5 has details on interactions between a plural of 401 with plural of 403 in the business-to-business cooperation system 500, with the various elements serving different roles.

[034] Fig 6 is a block diagram of an alternative process of retrieving 101 for the 103 of items owned by a retailer.

[035] Fig 7 is a drawing of a process 700 by which all items are verified automatically as users scan or enter 103 into a client able to verify authenticity; for instance when goods intended for sale are being scanned with the intention of being added to the current sale.

[036] Fig 8 shows a process 800 of generating sale documentation, 300, which are produced in 502.

[037] Fig. 9 shows the process 900 of registering a sale with the service 501. This process requires the 502 be logged into the 501, thus revealing the User Unique Identifier of the seller.

[038] Fig 10 shows the process 1000 of verifying registered sale documentation. This process is performed by a consumer and via a consumer client 504.

Detailed Description of Drawings

[039] The following is a detailed description of the better embodiments of the invention that have been contemplated and by no means are they the only possible embodiments. The description relies heavily on the drawings which are reference severally. None of the drawings are drawn to scale.

[040] Fig 1 has a tag 100 containing, a Product Serial Number 103, a scratch off label 102 concealing an Authentication Code 101 and a QR-Code 104 encoding of 103. The features of

100 make it valuable in detecting counterfeits. 103 can further be split into two portions; Product Code 105 and the item number 106, 105 and 106 are concatenated such that they appear as one Serial Number, for ease of reading, there may be a separator between 105 and 106, such that the difference is clearly visible on the tag. For instance, with the separator being a hyphen, "LJGARX I 9TTRS" would be "LJG AR-X 19TTRS". In this embodiment, 103 and

101 are derived from the set of case-insensitive alphanumeric characters; this means that there are a total of 35 characters available for the generation of 101 and 103. The invention also envisions a situation where instead of encoding the 103 in a QR-Code other types of bar-codes are used; RF1D or any other taggant that may also be used. It is also possible to have a situation where an RFID is used to store the 103 and no printed value of the same is available on the tag, thus requiring anyone reading the Serial Number to have an RFID reader. Another possible embodiment would involve only the Serial Number being typed, either using Optical Character Recognition (OCR) fonts to permit machine reading or fonts intended only for humans to read. In all the cases 103 is unique across instantiations of all products while 106 is unique across all instantiations of the same product; an instantiation of a product is an item. 102 is random and in some embodiments consists of two alphanumeric characters which makes it difficult for anyone to guess the value correctly as there are 1 ,225 possible values. 103 is designed to be unique for all items bearing a tag 100, although some manufacturers may decide to retire them a while after the product expires or after it is considered to have left the supply chain following a sale to an end user.

(041 ) Fig 2 is a flow chart showing the steps involved in producing 103 and 101 that can then be printed on tags. In 201, a plural of 106 is generated, either in sequence or at random, ensuring that the same number is not generated more than once over a certain period; Serial Numbers may be given a validity period after which they may be re-used, this would allow for a shorter 103 thus taking up less space and making them easier to type. Each of the 106 generated is then concatenated with the 105 of the instantiation of the product to form 103. In 202 for each 103 a random 101 is generated; since 101 is random, guessing the correct value would only be by chance for a single tag, and even more improbable for a larger number of serials. For instance, in an embodiment where 101 has 2 case insensitive alphanumeric characters, the probabil ity of making the correct guess is 1 ,225 for one item, 1 ,500,625 for two items and 1 ,838,265,625 for three items. It is thus not possible for someone who doesn't have access to the actual values of 101 to accurately arrive at them simply by guessing. In 203 an Item Unique Identifier is generated for the item, this is best made unique for every item produced by a given manufacturer; this is very useful where the manufacturer may want to share some information about the item without revealing the Product Code. Item Unique Identifiers should not be in any way related to the 105, 106 or 103 and it should not be possible to determine the correct value of 105, 106 or 103 by using the Item Unique Identifier. Item Unique Identifiers should be unique throughout the manufacturer's database, even if the database handles several products. In 204, the final stage of this process, the generated numbers are stored in the database while preserving the relationship between 101, 103 and the Item Unique Identifier. At this point in the process, there is a database of 103 and 101 pairs ready to be printed on tags, on the items or their packaging. Tags or any other relevant taggants are then created 205 and affixed on instantiations of the product for which the 103 and 101 were generated. The 101 is concealed using the necessary or available means. After the items are tagged, they may be packed into bulk packages which are also in turn tagged in a manner sim ilar to that of the individual items and released into the Distribution Chain 206. Before the products can be sold, the manufacturer, country distributor or whoever the originator of the product is registered as the recognised owner of all the items and their respective bulk packages.

[042] Fig 3 is a drawing of a Sale Receipt 300 designed to be used when checking purchased goods for authenticity, and an enlarged drawing of a list 309 of comma 315 separated concatenated 101, 103 pairs 317. 317 is separated by a hyphen 316 in order to make it easy to determine where the 103 ends and where the 101 begins; 309 is a feature on 300. Any other usable or convenient character can be used in place of 315 or 316; for instance, a semicolon would work as 315 or 316 easily. 300 has several features which make it easy for a buyer of goods that have a tags containing 103 and a concealed 101 to verify the authenticity of goods. In 309 the constituent 317 items are delimited with commas 315, and a hyphen 316 used to separate the constituent 103 and 101 of 317. 300 has additional details that can be used to verify the authenticity of the document, which includes: the name of the outlet from which the sale was made 301, the address of the outlet 302 the till number 303 of the till that produced the receipt, the date 304 and time 305 of the sale, the branch of the outlet number of the outlet 307 and the sale number 306 for that particular sale. The name of items in a sale may also be displayed 308. Features present in 300 are intended to provide a means of verification of authenticity of 300 and that of purchased goods. In addition to the above listed features, 300 has a Documentation Number 310 and an Access Code 311. 310 is a Unique Identifier for the documentation and is unique across all receipts produced across all tills and organisations. 311 is random and short, its main purpose is to serve as a safeguard against individuals gaining access to information about a 300 simply by guessing the 310. Save for 309 and its constituents features, 310 and 311, the features of 300 are very well covered in prior art. 311 could be hashed by 502, for security reasons, before being sent to the 501. 501 may hash it still for security purposes or it may be left intact. Instead of or alongside hashing, encryption could be used as well.

[043] 300 is meant to be used by a buyer of goods to verify the authenticity of goods tagged with a 103 and 101, either using a tag sim ilar to 100 or any equivalent. To verify authenticity, the buyer reveals the 101 of an item, locates the 103 of the item on the 300 from the relevant 309, in the 317 that has the same 103 as the one on the 100, and then compares the 101 provided on the 300 against that on the 100. If the 101 for the 103 is on the 300 the same as on the 100 on the purchased item, then the item is authentic, and is they are different, then the item is not genuine.

[044] Fig 4 shows the general architecture of the system that enables seamless sharing of information between a plural of businesses and entities using a Service Oriented Architecture (SOA), in the one embodiment of the invention. This architecture is designed to work on a computer network and can function equally as well over a Local Area Network(LAN), Wide Area Network(WAN), the Internet or any other kind of computer network; al l requests in 400 are made via a network of some sort, most likely via the Internet. Communication between the different entities in the system can be done securely via TSL, SSL or any other available and/or suitable means of securing communication on a network. Here 401 represents any client that wants to access any service 403 with the exception of the Authentication Server 404 and the Service Registry 402; 402 and 404 are essential services in this architecture and are thus located in a publicly published location, and 404, being the Authentication Server requires no prior Authentication. All services on this system can be accessed using any of the currently existing methods of consuming services, and thus services would be published as such; SOAP and REST are particularly suitable candidates. For 401 to access a 403: First they send the information they have, 103 for instance, to 402 which in turn sends back a Server Unique Identifier for the target 403 and information on how to access the 403 in question, for instance, an IP Address where the desired 403 will be found, a domain name or a URL. 401 then makes a requests 404 to be logged into the 403 in question by sending the Server Unique Identifier received from 402, a user name and password. 404 then responds by sending back an Authentication Token. After a client acquires an Authentication Token, it then proceeds to make a request to the desired 403 sending the Authentication Token, the User Unique Identifier and the intended command. 403 then verifies the authenticity of the Authentication Token with 404 by sending the Authentication Token, Source I P Address, and User Unique Identifier. The server then sends a response to indicate validity of the Authenticity Token, this may simply be the text 'Valid' or 'Invalid'. If the client is successfully authenticated, 403 processes the request and gives the expected response. As an additional measure 403 may provide its own Authentication Token to 401 for use in subsequent requests after initial verification of the Authentication Token; this may serve to preserve the session for a certain amount of time, a useful feature for a busy client.

[045] The design of 400 ensures that any given 403 doesn't need to maintain or manage a database of all val id users or available services within the system and any given 401 need not store information about any 403 in the system. This decentralisation of services means that no one needs to share sensitive information with a third party that they cannot control. In a database, 402 stores a record of all services in the network, their location on the network and how they can be accessed, Product Codes of products managed and tracked on those services, key words relevant to the respective services, service owner name and any other information that may be deemed useful in locating a desired service. The location and mode of access of a service, as stored on 402, could be simple as a URL to a SOAP service. The concept of SOA, Service Discovery and Service Registry are not new and are very well known in the art. 404 on the other hand will contain information of al l User Unique Identifiers, User Name, Login and Passwords. These are used by clients to gain access to 403 in this architecture, relieving 403 from the need to manage user internally. In order to establish trust and be a User in 404 one needs to be added into the database, this can be done via a specialised form or even directly using SQL and methods of doing so are well known in the art. Methods of generating Passwords, User Names and Unique Identifiers are also well known in the art and are thus not covered in detail here. [046J The main advantage of the architecture 400 is the fact that any given 403 that goes down the system would function just as well. Also, it is very easy to introduce redundancy in the essential servers 404 and 402 since 400 permits mu ltiple instantiations of them to exist. In addition to this, anyone can easily create a local cache of al l the 403 that they access frequently, effectively having a local backup of 402. This would result in a more efficient and rel iable and robust system. Also, there is no reason why any given 403 cannot have its own local version of 404 for cl ients it interacts with frequently, effectively elim inating the need for 404 in those specific instances. A lso, the fact that the password is only sent once to a lim ited number of 404, means that the system is more secure in that the risk of passwords being exposed are minimal.

[047] Fig 5 has detai ls on interactions between a plural of 401 with a plural of 403 in the business-to-business cooperation system 500, with the various elements serving di fferent roles. 500 has various roles that would be assumed by the various entities in the system. The Originating Service 505, for instance, may be owned by a manufacturer, local representative of the manufacturer, a regional distributor or any other agent on behalf of the manufacturer; for the sake of simpl icity it is assumed that the manufacturer owns the 505 that tracks and manages his/her products. 505 is a very important 403 in the system as it is where al l the vital and authoritative information on any given product from the manufacturer running the said 505 resides. 505 has a database of al l 103 and their respective 101, the respective Recognised Owners of al l manufactured items and any other add itional information that may be relevant; for instance Item Un ique Identifiers and Parent Container Unique Identifiers. The system 500 is designed to hand le a plural of 505 just as easi ly as it would handle a single central ised 505. The User Unique Identifier of the Recognised Owner is associated with an item to indicate ownership, and a historical ownership aud it trai l may be maintained to show how and when items change ownership over time; this can simply be done by creating a new ownership record every time the owner changes. A Parent Container Unique Identifier is the Item Unique Identifier of a 103 used in the tagging of bulk containers; al l the contents of the container are then l inked to that 103 via a 'Parent' field in the database table that would contain the Item Unique Identifier of the said 103 as Parent Container Unique Identifier. This approach allows for multiple levels of containment where a given Parent Container Unique Identifier may be parented to another Parent Container U nique Identifier which is used to tag a larger bulk container that contains bu lk containers and so on. The database of 103 may have a field for distinguishing between bulk containers and individual items; th is can be ach ieved by simply having an 'is container' field that can either be set to 'True' or 'False' and possible a 'number of items' fields that would have the total number of items in the container.

[048] 503 is Distribution Client, a 401 that accesses the 505 and gives it instructions to transfer goods from the current Recognised Owner, the seller, to a new Recognised Owner, the buyer, after a transaction. The 503 can also be used, by the buyer, to verify the transfer of purchased goods from 505. In order to transfer goods, 503 simply sends the list of 103 to be transferred, the User Unique Identifier of the intended Recognised Owner, and possibly a sale number to the relevant 505 requesting a transfer of ownership, this is the Transfer Request. A Transfer Request is only valid whilst the 503 is logged in on the relevant 505 with the current Recognised Owner's credentials. The 503 may range from a single mobi le unit, such as a PDA, for a small distributor, to a large server, interfacing with 505, as a client, whi le serving a plural of clients for a large distributor; what makes 503 a client is the fact that it interfaces with 505 as one. In the case of a small mobile unit 503, the unit would have an application into which the user enters the information they need acted upon, and allows the user to make the intended request; this is very similar to units used by courier services, and in warehouses to track the movement of goods. Transfer Requests result in a transfer of ownership of the listed 103 within 505 immediately and the transfer remains reversible and can be cancelled by either party during a specified window period. Cancelation of ownership transfers is aimed at permitting the parties correct any errors that may arise from the transaction or any mistakes on the transaction. Once a new Recognised Owner transfers ownership of items whose transfer can still be cancelled by the old owner, the old owner should no longer be able reverse the transfer. Notifications could be sent to the different entities affected by any given transfer as status of the transfer change, especially when ownership is transferred and when the transfer cancelation window period ends.

[049] A unit acting as a 503 could have a bar-code scanner or RFID reader, to ease the process of imputing the l ist of 103. 503 can be used by a buyer to verify the transfer of goods to a buyer's account whilst logged on to the relevant 505 with the buyer's credentials, Transfer Verification Request. In order to verify the transfer of goods, a 503 sends the sale number, and the User Unique Identifier of the old Recognised Owner to a 505, requesting a list of all items whose ownership was transferred in the referenced sale. After making a Transfer Verification Request, the new Recognised Owner in turn then receives a list of all items in the sale in question, which can then be verified physically; the list may contain the quantities of individual items transferred. The manufacturer or manufacturer's representatives are the first sellers in the distribution chain, and thus, the first users of a 503 at the point where goods are introduced into the Distribution Chain. There is a myriad of methods, covered in the prior art, by which goods may be tracked as they traverse the Distribution Chain and, thus, there is no need to describe a solution for the entire distribution chain beyond what is covered here.

[050] During the ownership transfer process, the minimum information is shared between parties in order to keep as much of the information as possible secret. This means that if a certain bulk container is being transferred, while the ownership of all its contents will be changed in 505, only the 103 of the said container will be sent by the 503 and thus only that need be revealed. With this approach, before a package is broken down, its contents do not need to be known to those handling it. Information sent to 505 need only include the 103 of the largest unit in a sale. For example the sale of a large bulk package containing two dozen small bulk packages of 10 units, should only include the 103 of the large bulk package; neither the 103 of the small bulk packages contained in the large bulk package, nor the 103 of contents of small bulk packages would be sent. In our example, only one item is sent to the 505. If all the individual units in our example had been in the list sent to the 505, the list would have 240 items. Had all the small bulk packages in our example been sent to the 505, then the list would have 24 items. With the 103 of the parent container in the Transfer Request to 505, the 505 would change the Recognised Owner of the entire large bulk package, effectively changing the Recognised Owner of the 24 small bulk packages it contains, which in turn would effectively change the Recognised Owner of the 10 units contained in each of the small bulk packages. It is possible to change the ownership of the contents of a bulk package because the 103 on the package is associated with the Item Unique Identifier, which acts as a Parent Container Unique Identifier, and is thus associated with the Item Unique Identifiers of the contents of the bulk package. Disclosing only the largest units in the sale minimize the amount of work involved in making the transfer and also in physically checking them, for greater security, the number of individual units in the largest bulk unit should also be included in the Transfer Request, and in the response to Transfer Verification Request. This system ensures that a seller can never sell items that they do not own and thus makes it difficult to sell stolen goods or counterfeits as the buyer is able to check and confirm that the ownership of goods purchased was transferred to him/her, by making a Transfer Verification Request.

[051] The Retailer Client 502 is a 401 that registers all final sales with the Document Registry 501 and 505 in order to avoid dupl ication of sale documents, their 310, and 103; this lim its the abi lity of fraudulently sel ling counterfeits by copying existing 103. To this end, al l 300 and their contained features are registered 502. The contents of a sale and thus those of 300 are also registered with the relevant 505. Only items managed and tracked by a 505 wi l l be registered as sold with that 505. For example, if as sale has five different products from five different manufacturers, the instantiations of specific products in the sale wil l be registered with their respective manufacturers' 505. Only essential information on 300 is sent to the respective 505, and this includes: 310, "relevant 309", 304, 305, 303, 306, and 307. Whi le 301 and 302 are considered essential, they need not be expl icitly sent to 505 as the user registering the sale is logged in and these detai ls are avai lable as part of the account information on 404. To explain "relevant 309", with the example of a sale document with five different products from five different manufacturers, it would be as fol lows: each of the five 505 each managing one of the five products for the manufacturers wi ll only receive the relevant 309 and 308. I n one embodiment, 502 requests the 101 of every 103 in a sale from the respective 505 and if it's successful for al l the items in the sale, proceeds to send information about the 300 to 501 and 505. When sending the details of the sale, parts of 103 may be removed from 317 thus sending only a subset of 309. Together with the 309 of al l items in the 300, 501 also receives 310, 311, 303, 304, 305, 306, and 307 in a sale registration request from 502. 501 in turn verifies from relevant 505 that the information sent is correct for all 317 in the sale; for a situation where a partial 103 is avai lable, there may be need for 502 to send an Item Un ique Identifier to 501 in order to enable verification of 317 from the relevant 505.

[052] In an alternative embodiment, 600, 502 stores al l the 103 and their respective 101 local ly after receiving them from the 505. This embodiment al lows 502 to generate 300 even when there is no access to 505. For the l ist 103, 101 pairs to be stored local ly, the 502 has to request the l ist from the relevant 505. This can be done by the 502 requesting a l ist of all items managed and tracked by a 505 for which the logged in user is the Recognised Owner. An alternative approach wou ld be, the 502 requesting a l ist for al l items contained in a specific bulk container by simply send ing the 103 of the container in question. In response, 505 sends a l ist of 103, 101 pairs and their respective Item Unique Identifiers. Once the 502 receives the list, the 505 sends a l ist of hashed, one way encrypted, 317 in the format that it should be sent to 501 ; this means that if the 317 contains a subset of 103, then the hash will on ly include that same subset 103. A longside the hashed 317, the Item Unique Identifier is sent to ease matching of the data received from 502 when registering a 300 without having to verify authenticity, or registration from 505. When a subset of 103 is sent to 501, an ideal choice would be a few, four for instance, of the last characters on the 103.

[053] 500 also depicts a Consumer Client, 504, that may be used for verification of registration of 300 and thus l im it cases of fraud resulting from individuals creating their own counterfeit items with their own 101 and 103, and producing their own 300. This would also deter the sellers from sell ing an item with the same 103 more than once, or even creating a 300 with the same 310 more than once. The deterrence is because the consumer may easily check and verify the detai ls on his/her 300 and the counterfeiting and fraud would be easi ly detected. A 504 can be an appl ication made avai lable on any medium that can communicate via a computer network and has a means of displaying data. Val id candidates for 504 include al l computing devices and mobi le phones.

[054] Fig 6 is a block diagram of an alternative process of retrieving 101 for the 103 of items owned by a retai ler. The retailer simply makes a request for al l 101 from 505 that he/she wants to have local ly which are supplied to his/her 502. For security purposes, the data may be encrypted and could include Item Unique Authentication Codes where necessary. The 505 in turn sends hashed values of the content that the 502 would subm it in order to register a sale of the same to the 501. I nformation that 501 wou ld receive from 505 includes the Verification Hash of every item whose 103 is on the l ist and the Recognised Owner's User Unique Identifier of the items. The Verification Hash is the one way encrypted(hashed) resultant string from concatenating, 101, at least a subset of 103 and where relevant, Item Un ique Identifier. With the hash and Recognised owner, 501 can authenticate data sent by a 502 without having to check with 505. This approach makes it possible for the systems to function and for 300 to be produced and registered even when there exists an unreliable network connection or the 505 is unavailable.

[055] In Fig 7, the drawing shows a process 700 by which all items are verified automatical ly as users scan or enter 103 into a cl ient able to verify authenticity; for instance when goods intended for sale are being scanned with the intention of being added to the current sale. The process begins with reading the serial 103 which is checked on for existence in 505 and, if it exists, that the user of 401 has access to it 703. I f the user has no access or the 103 doesn't exist in 505 the 401 gets an ambiguous error response. The error response has to be ambiguous so as to ensure it can't be used to arrive at val id values 103. If the 103 is val id and the user of 401 has access to the 103, meaning that the user is the Recognised Owner, then a response message OK' is sent to the 401 in response 704. The incident is then logged for future auditing 705. Users of any 401, and by extension any 401, have access only, to the 103 for which they are the Recognised Owners. This is to say, for access to be granted, ownership must be verified; this is done by verifying that the User Unique Identifier of the logged in 401 user is the same as User Unique Identifier associated with the 103 in the relevant 505. This same feature may be used when verifying authenticity of goods by the manufacturer's agents or by security agents. To verify authenticity, an agent would enter information regarding the location where the goods have been found, and the 103 of any the goods or their bulk package into a cl ient, portable or otherwise. The agent would then use the cl ient to submit the entered data to the relevant 505, which would in turn verify that the received 103 should be in the subm itted location. The submitted location information shou ld include the User Un ique Identifier of the owner of the prem ise and the physical address of the location.

[056] Fig 8 shows a process 800 of generating sale documentation, 300, which are produced in 502. This process starts at 801 where the 103 of the items in a sale are read into the 502. The process 700 may be employed to veri fy individual 103 as they are read in 801. 801 can be done by scanning 104 with a bar-code scanner, by entering the numbers manual ly, from another appl ication via an A PI or from a fi le of any acceptable format. Once the 502 has all the items in the sale loaded into memory, it marks al l the 103 in the list as Unprocessed; this can be done by having a dictionary of 103 and their respective Processed Status and setting the Processed Status to False. 502 then starts processing the list of 103, moving on to 802 where 502 checks the l ist of 103 to see if it has any unprocessed items; in 801 al l items are unprocessed and thus the result of 802 should be always "yes" for the first time around. In 803, 502 determ ine if the 101 of the read 103 are avai lable local ly or if they need to be loaded from the server. In the event that they are not avai lable local ly in a request made by 502 via a computer network to the remote 505 serving as the Originating Service for the item in question; it is also possible to analyse the entire l ist of 103 in the sale and determ ine which items are managed and tracked by the same 505 and make a single request for al l such, thus reducing the number of trips made to the same server. To request 101 from a 505, the 502 sends: a list of relevant 103, the User Unique Identifiers of the sel ler, a valid Authentication Token and a Term inal Identifier if the 401 serves more than one Point-of-Sale terminal. If any request for the 101 in a sale fai ls, then the 502 is obligated to remove that item from the 300 or cancel the entire process. Assuming that the user of 502 is properly authenticated, the ownersh ip of the items in question is checked 806 by the 505 to verif that the 103 submitted are owned by the user logged into the 502 making the request. If verification fails for the submitted 103, the incident is logged 807, an error notice issued to 502 by 505. In the event that the 505 received a list of 103, a failure in one is considered a failure of the entire request. From 807, after the error is logged, the 502 continues processing the list of 103 moving back to step 802. If the Recognised Owner is verified, then 505 proceeds to issue the 101 for the 103 provide; a 101 is issued for every 103 provided in the event a list of multiple 103 is sent.

[057] When issuing 101, 505 may determine, at random for any given number of transactions, that the buyer should be forced to reveal and provide the 101 of any of the given 103 for validation, in step 808. This random, forced, validation requirement is indicated by the 505 when it hashes the 101 supplied to the 502. The hashing is done using a secure one way encryption algorithm, such as SHA- 1 , in step 810. The hash algorithm used should be known to the 502 and it is best if al l 505 use the same algorithm for simplicity. In the event that the 505 determines that the 101 doesn't need to be verified, it is sent by 505 to the 502 without being hashed in 809. Once the 502 receives the 101, it is stored in memory, in relation to its 103 unti l the process 800 is terminated.

[058] After it is determined that the 101 of any given 103 can be found locally in step 803, 502 proceeds to locate the 101 locally in step 805, by searching the local database for the 103 and then picking its corresponding 101. After the 101 is picked, it is stored in the memory of 502 in relation to its 103 until the process 800 is terminated. After 805, the process 800 continues in 811 as it would for 101 that were retrieved from a remote source.

[059] In 811, the 502 checks the received 101 to see if it has been hashed and if it is, then the 502 will request the 101 on the item with the selected 103, and provide an input field for the same, possibly as a pop-up window. In 812, the seller asks the buyer to reveal the 101 on the selected item, and the buyer in turn reveals the 101 and furnishes the seller with the revealed 101. In 813 the seller enters the provided 101 which is hashed with the same hash algorithm as the one provided by the 505. The 502 then compares the two hashes 814 and if they are not exactly the same, then a notice is given 502 and the incident is logged, 807. In a different embodiment, the 505 can request the 101 of a specific random item, from 502, instead of sending a hashed 101. If the hashes compared in 814 are the same, then the process moves back to 802 where the 502 checks for an Unprocessed 103. The move to 802 is also made from 811 i f the 502 finds that the 101 is not hashed; that is to say that the current 103 is fully processed at this point and the process begins for the next 103.

[060] The process wi l l continue returning to 802 when it completes processing any given 103 from the list of 103 from 801 , unti l it has processed al l items in that l ist. When there are no more Unprocessed 103 to be found in step 802, 502 reads the 101 of al l the 103 processed successful ly from memory and formats them appropriately for the intended medium of output 815, possibly a Cash Sale Receipt l ike 300. In 815 any other additional information is added to the output in the appropriate manner, for a Cash Sale Receipt, al l other relevant features can be added at this point. In 815, appropriate features from prior art may be added to the output, such features inc lude: product names, quantities, dates, name of establ ishment and al l similar features on 300. 502 then generates a Sale Unique Identifier, 310, a random 311 , and other appropriate features of 300 in step 816. The generated features are added to the formatted, but incomplete, 300 in the appropriate locations, already reserved and left empty in step 815; step 816 need not occur after 815, either can occur before the other.

[061 ] I n some embodiments, a random 311, may be generated and would be used along with the 310, to access the document from 501 wh i le in some embodiments, only a random 310 may be generated to be used alone. 310 is required to be unique throughout the system 400, in order to enable this, every client 502 has a Til l Number 312 that is prefixed to the Local Receipt Number 314, to give a unique 212. That is to say that the 312 part is always the same for every individual til l and only the 314 needs to be different; 314 may be sequential or random and can consist of numeric or alphanumeric characters. Once al l the relevant information is added, depending on the intended use of the documentation produced, it is the output using the relevant mode. In the preferred case, the document doubles as a Sale Receipt, 300, and is thus printed. After all the necessary features of the output are added and it has been formatted appropriately, the documentation is produced as output, in the desired manner 817.

[062] Fig. 9 shows the process 900 of registering a sale with the service 501. This process requires the 502 be logged into the 501, thus revealing the User Unique Identifier of the sel ler. The intention of this process is to ensure that al l 300 produced are verifiable and the information therein is never duplicated. Registration of sales ensures that any given 103 is used only once and every 310 produced only once, at least over a predeterm ined amount of time. For example, 103 or 310 may be reused one year after they are registered with a 501 and thus considered out of circulation, the old records would be maintained for future auditing. For 502 to successfully perform process, it needs to get relevant sale information 901 that went onto 300 in 800. Relevant information from process 800 used in process 900 includes, 103, 101 pairs and the 312 of the 300. Since 800 and 900 would most likely run from the same device and the data needed for step 900 can be stored in the memory of the device. Storing the information required by process 900 in the memory of 502 while perform ing process 800 would avail the information for retrieval from memory and in process 900. An alternative way of sharing information between the processes 800 and 900 would be for the process 800 to store the information in a database and the process 900 querying the database for relevant information. A database storing information from the process 800 would have 311, 310, 309 and its constituent 317 and their relationships.

[063) In 902, 502 then determines if the 501 or manufacturer restricts the portion of 103 sent to 501. For the sake of privacy, security or both, restrictions may be put in place requiring that only a specific portion of the 103 is sent to 501 leaving the rest of the 103 withheld from 502. Withholding a portion of 103 is intended to make it difficult for anyone, save the buyer of the goods, to identify the specific products in the sale registration. When only a portion of 103 is sent, either the last four characters or the first four characters after the 105 are sent, sending the entire 106 would also be acceptable. In the event that only a portion of a 103 can be sent, then 502 must retrieve the Item Unique Identifier 904 of the 103 and the Server Unique Identifier 905 of the 505 that manages and tracks the items that have the 105 that forms part of the 103. The Server Unique Identifier and Item Unique Identifier are both retrieved from 505 by a 502, and they could be provided during process 800 as the 101 are being retrieved to reduce the number of requests. 905 is followed by extracting the subset of 103 that is to be sent to 501 in step 906. The Sale Unique Identifier is then generated, although the 310 may be used as the Sale Unique Identifier, which would require 502 to read its value from memory where it would have been left after process 800 is complete. From step 902, where 103 is sent to 502 in its entirety, 502 proceeds directly to 903.

[064] After all the relevant information including 103, 101 and 310 is collected, 502 sends the data to 501 via an API 907. In the event only a portion of a 103 is to be sent submitted, then the 502 must also send the Item Unique Identifier of the 103 and the Server Unique Identifier of the 505 to handle the 103 when making the registration. 311, whenever it is available, is also sent in step 907. On receiving the data, 502 immediately checks for duplication of data 908 within the local database of registered 300 documents. The check for duplication ensures that any given 103 and 310 is submitted only once thus preventing duplication. In the event that there is at least one duplicated item in the 300 being registered, the submission is rejected and incident logged in 909. If there are no duplicate entries in the submitted data, the constituent 103 and supplied 101 are checked and verified with the respective manufacturer's 505. This is done by looping through the 103 or partial 103 and for every 103, sending the corresponding, 101, 103 and where a partial 103 is used, the Item Unique Identifier relevant 505 for verification. When making the verification request to a 505, 501 must also send the User Unique Identifier of the seller for the sale to be verified. The 505 then verifies that the respective 103 or Item Unique Identifier and the 101 match, after which it checks if the User Unique Identifier of the 502 making the registration is the same as that of the Recognised Owner. In the event that the manufacturer is unable to verify the validity of the information provided, then 501 rejects the submission and logs the incident in process 909. If the manufacturer verifies the information provided, then the submission is accepted by 501 and each 103 sale registered with the respective manufacturer 910. After an item's 103 is registered with the 501 and 505 it is considered to no longer be in circulation, and thus out of the distribution chain. The information sent to the manufacturer to register a 300, and thus a retailer's sale includes: 103 or a portion of 103, 101, 310, the seller's User Unique Identifier and where necessary, the Item Unique Identifier. Using 312 and 311, it is possible to transfer ownership of the item if the manufacturer provides the means via a web application, mobile application, or any other relevant means. Transfer of ownership and Certificates of Authenticity are detailed to a good extent in prior art.

[065 j Fig 10 shows the process 1000 of verifying registered sale documentation. This process is performed by a consumer and via a consumer client 504. To initialise the process the consumer enters the 310 into a 504 in step 1001. After receiving a 310, 504 sends it to 501 which in turn checks if the 310 on the 300 that is the subject of the request exists 1002, and if it does not exist the user of the 504 is allowed to make correction 1003. A security measure may be added in 1002 whereby every run of 1002 would take fixed amount of time, and a limit set on the number of erroneous 1002 made within a stipulated duration; for instance, after a client fails three times, it is not allowed to do any further searches for five minutes, but is able to report a case of fraud in 1004. If a user elects not to correct erroneous input in 1003, he/she is given the option 1004 to report fraud in or exit the 504. If he/she elects to report a fraud 1009 in relation to the 310, he/she will be requested to enter the 310 again, and some contact information if the system does not have the user's contacts already, after which the client will exit; these reports once made are saved in 501 and may be followed up by authorities.

[066] In the event that the 310 exists, the system checks if the user has access to the 310 in 1005. Checking for access to a specific 310 is particularly helpful if the 504 is accessed using a consumer' mobile phone and the request is made via USSD, as the 310 can be associated to that phone number, or by a web browser that can accept cookies as they can be used to associate the browser with that 310 for a certain amount of time. A 504 can have existing access to the 310 because it was used to access it at a certain point in the past using the correct 311, or because the 300 whose 310 is being used, does not have a 311. If a 311 is required and the 504 has no access to the entered 310, the user is requested to enter the 311 in step 1006, after which the 310, and 311 are verified in step 1007 and if there is no match the user can make corrections 1008 or alternatively, if he/she elects not to, the user can then elect to report fraud in step 1009. If the 311 issued by the user is correct, the document details are displayed in step 1010 and the user can verify that the information therein is the same as that in 300. If the information is not the same, then the user can make fraud report, and if it is the same, the user can exit the 504. The 501 may automatically restrict access to the first user to successfully access a given 300, track all views to the detai ls of 300 while looking for suspicious activity, advice users of 501 of all subsequent views of 300 keeping a count of the views, or, if a 311 is available, automatically change the 311 after the first view.

[067] The details displayed on the 504 include a list of all the 103 or partial 103 sent to the 505, the date 304, time 305 and location 302 of the sale, and the name of the seller/retailer. Verification of a 300 is done by manually going through the 103 or partial 103 provided on the 504 by the 501 and locating them on the provided 300 to verify that the listed 101 is correct. The user of the 504 may opt to check specific items on the 300 and would thus look for the target item's 103 or partial 103 on the 300 and match the 101 provided on the 504 with that on the 300. Where partial 103 are provided, it may occur that the subset of the source 103 are the same, and thus require the user of the 504 to verify that all the 103 that would have same partial 103 are represented in the 300. Verification of similar partial 103 can be done by counting the number 103 on the 300 that would have the same resultant partial 103 when the relevant is extracted and verifying that the 504 has the same exact number of the same partial 103. It should be easy for a user to determine the section of 103 used in partial 103 and thus a simple and consistent approach is best, the simplest being using the last four characters of 103. [068] Different embodiments of this invention may fol low different ru les in producing a usable equivalent of 300. In one alternative embodiment, the list of 101 and 103 may be provided in two separate documents and a simple rule on how to match them provided. An example of two separate documents is where two documents one containing a list of unnumbered 101 in a single column and another containing a l ist of unnumbered 103 in a single column. Where two documents are provided, pairing of 103 with their respective 101 done based on their position from the top. In this case, first 103 pairs with the first 101 and the second 103 pairs with the second 101 and so on.

[069] An alternative embodiment could use mobi le phone text messages, where the sel ler takes the buyers phone number and sends a l ist of 317 to the phone number provided from his 502. In this embod iment, it is even possible to have the 317 sent from the 501 instead and thus have the 501 producing the 300 equ ivalent. It is also possible to send 300 via emai l, make it avai lable onl ine in a user account, save it in a smart card or even display it on a mobi le phone via the I nternet or NFC. The most important issue in relation to sale documentation is that identifiable 103 and 101 are presented in a manner that al lows them to be easi ly paired together so that they can be used in authentication items.

[070] In principle, the described system can be implemented over the phone by people making phone cal ls and playing the various roles of cl ients and servers.

[071] In some embodiments 105 and 106 may be represented separately and encoded in different bar codes. 105, whether as represented on 300 or represented separately, work more or less in a sim i lar manner as a domain name would in the DNS system and 402 acts a lot l ike a DNS server. That is to say that 402 translates 105 into a network location that can be used by the interested 401 to access the 505 that manages and tracks items tagged with that 105. This is a key component of 400 that is m issing in anti-counterfeit solutions in existence, and as a result, with 400 it is possible to create a platform on which multiple players can engage and interact with relative security and freedom. With 105 and 402, it would take very m inimal work for a manufacturer to introduce a new product and thus a new 105 into the market as he/she need not worry of how the retai ler, distributors or any other stake holders wi ll get that information. A ll that he/she has to do is register the 105 and it's corresponding product with the 402 after which any 401 looking for the 505 managing and tracking that 105 wil l find it. [072] For the sake of security or in order to keep volumes sold secret, especially when using partial 103 for registrations to 501 , 400 cou ld introduce new servers between 501 and 505. These servers would be th ird party proxy servers acting as 505 to verify the partial 103 and their corresponding 101 on behalf of the Originating Service. In order for a proxy server solution to work, the manufacturer would require access to several registered proxy servers whose Server Un ique Identifier they would give to 502 to be supplied to 501 in place of the actual Server Unique Identifier. With access to several proxy servers, the 505 would pick the server to use at random. Use of a proxy would ensure that the information on 501 can't be easi ly used to determ ine where the item came from, thus making it di fficu lt for those with access to 501 to determine the sale volumes of manufacturers using subm itted data. While the preferred embodiment assumes a single 501 in 500, there is no reason why there can't be a plural of 501.

[073] In the preferred embodiment, every request from any given 401 is made directly to the appropriate 403 and therefore there is a need for a mechanism that would allow them to easi ly locate the target 403. 402 and 105 provide a mechanism for this. When a 401 seeking information regarding a given 103 sends that 103 to 402, the 105 is extracted and used to determ ine the 505 that handles information relating to the product that the item is an instance of. To determine the 505 managing product assigned the extracted 105, 402 searches its database for the said 105 and its associated 505. Once the correct 505 is found, 402 sends its access information, which would include a URL or I P address and the 505's Server Unique Identifier, to the 401. The name of the product may also be sent if the 505 supports it and if the 401 requests it. When, the 105 is used to d irect the 401 to the correct 505, 105 is function ing as a routing code. A request for 501 should produce a list of available 501 since these wil l never be that many.

[074] In an alternative SOA arch itecture, 402 cou ld act as a switch, sitting between 401 and the desired 403 and passing requests on, in such a scenario. In this architecture, no request would ever be made directly to any given 403 and instead, al l requests would be routed through the 402 to their destination service

[075] The 505 may al low statuses for products that confer certain specific capabi lities to the Recognised Owners and to other concerned parties. For instance, a status 'stolen ' that reveals the serials to law enforcement authorities that a certain Serial N umber is that of a stolen item, or status On transit', which confers law enforcement the ability to verify that indeed a Serial Number should be on transit. In the event third parties are given access to certain pieces of information, they will require a means of communicating with 505 and thus must have a 401 that can work with the system 400 and by extension 500. There could also be a status available for items on retail, that would al low end users to verify the owner of the items on the shelf simply by sending the 103 to the appropriate entity, most likely in this case a 501 that can in turn communicate with the appropriate 505.

[076] In some cases, if the manufacturer sees fit, a 103 may have the last character not included in bar code encoding, such that, for instance, for the 103 "LJGARX 19TTRS" only "LJGARX 19TTR" would be bar-coded. This makes the tags more secure, for as long as the last character is random, since leaving the last character out of the encoded part of the 103 makes copying the 103 more cumbersome as it would entail manual work and it is proof that the counterfeiter has or had access to the genuine items. With this, verification of the authenticity and ownership for items marked as available for retail can be more secure since it increases the likelihood that anyone sending the correct 103 has seen it and is not making random guesswork. With this technique, a shopper can simply enter the 103 on the item and send it to the 505 acting as the Originating Service of the said item, either directly or via a third party, who would in turn send back information regarding the item and its location which the shopper can then verify. The information sent to the shopper for confirmation could include the physical address and name of the retailer, the name of the product, the expiry date and any other relevant physical information. In this embodiment, 101 may still there and concealed from plain view but failing to include a character or more in the barcode is a form of concealment since not the entire 103 is machine readable, and thus is concealed from the equipment reading it. For a 103 that includes characters not included in the barcode, or on whatever machine readable medium is used on the taggant, the need for a 101 is reduced since the characters not in included in the barcode can play the role of 101. For this approach to work, the part encoded must be unique.

[077) Another alternative embodiment involves a scenario where 101 has a few characters exposed, or one is exposed and one concealed where only two characters are present in 101. This is particularly useful in situations where a packet has several small items that cannot accommodate a complete tag 100. To make it more usable, a few of the last characters of 103 may also be included and thus making it easy to identify the source packet for the items. To get the full 103 one would have to look at the parent container. [078] For the sake of securing the 103 database and to ease detection of data breaches, the manufacturer can opt to use only a certain percentage of generated 103, say only 80%, selected by random, and storing information of the ones used on taggants in a completely separate database. When items are then released into the market, the manufacturer would be able to detect data breaches in two possible ways: One way would be, if unused 103 are stored in a separate secure database or multiple secure databases managed by several individuals, periodical audits of the database of used items would be done, and if any of the unused 103 appear to have been detected or sold, the manufacturer wil l know that there is a data breach and it can be easily traced, especially if the 101 provided for them was correct. The other solution would be for the manufacturer to track the percentage of 103 detected in the supply chain and if it exceeds the percentage of used 103, then a breach has occurred. In the second approach, it would be difficult to determine where the breach occurred as opposed to the first approach where al l that needs to happen is for the manufacturer to find the seller of the offending 103. In the first approach, the database of unused 103 could be split between several trusted entities in order to minimise the possibility of collusion.

[079] It is possible for a product to have multiple instances of 101 for the sake of authentication in different areas. For instance, an item could have 101 at the bottom of the container or package, and this can be used by field agents or the retailer to verify authenticity. Such instances of 101 may also be required by manufacturers in order for them to allow the status of products be changed to "available for retail", effectively ensuring that only genuine products are available for retail.

[080] Several embodiments of the inventive concept have been described here by way of example and are by no means intended to limit the scope of the invention. Several changes can be made to the said embodiments, by one skilled in the art, while still maintaining the same general inventive concept.

[081] While in the preferred embodiment there is only one 404, there is no reason why in alternative embodiments there cannot exist multiple instances or 404 or even a situation where every 404 manages its own database of users. There is no reason why multiple systems of authentication should not exist concurrently. When multiple 404 are used, the information sent to 403 alongside the authentication token would have to include the identity of the authenticating 404 in one form or the other.

[082] While the main embodiment covers transfer of items fol lowing a sale, the invention can be employed in any form of transfer of serialised items that can be authenticated.

Claims

CLAI MS

1 . Item authentication documentation produced for use in authenticating serialised items by fol lowing simple rules that guide how the said documentation may be used to authenticate the said items by a recipient of the said items and the said documentation, the said documentation bei ng produced fol lowing a sale, a transfer or a change in custody of the said items, with the said items hav ing been indiv idually tagged with a serial number and at least one authentication code, wherein the said documentation includes at least one or more serial numbers and their respective authentication codes.

2. The item authentication documentation of claim 1 , wherein a documentation number is included on the documentation in such a manner that the unique identi fier can be easi ly identified in the said documentation.

3. The item authentication documentation of claim 2, wherein an access PIN consisting of one or several randomly selected numbers or alphanumeric characters included in the documentation.

4. The item authentication documentation of claim I , wherein the said documentation is sent to the buyer via emai l.

5. The item authentication documentation of claim I , wherein the said documentation an SMS.

6. The item authentication documentation of claim I , wherein the said documentation is on print.

7. The item authentication documentation of claim 1 , wherein the said documentation is writable memory into an electron ic med ium .

8. The item authentication documentation of claim 1 , wherein the said documentation is issued at the Point-of-Sale.

9. The item authentication documentation of claim 1 , wherein the said documentation is produced at the Point-of-Sale.

1 0. The item authentication documentation of c laim I , wherein the said documentation is split among two related documents and simple rules on how to associate the contents of the said two documents given

1 1 . Method of producing documentation in relation to a sale, transfer, or change in custody of items, such that the said documentation can be used in verifying the authenticity of the items that have been tagged with said serial numbers and authentication codes, said method comprising:

a. reading the l ist of one or several serial numbers to include in the said documentation; b. searching for and locating the authentication code associated with each of the serial number;

c. retrieving the authentication code of every serial number in the said l ist;

d. formatting serial numbers and authentication codes for output;

e. producing the output in an appropriate medium, and;

f. providing the produced output to the i ntended recipient.

12. A method according to claim 1 1 , wherein a documentation number is generated and added to said documentation.

1 3. A method accord ing to claim 12, wherein the said documentation is registered with a third party by sending the said documentation number and at least a part of the said serial numbers and their respective authentication codes to the said th ird party server which in turn stores the received data.

14. A method according to claim 1 3, wherein the said third party server gives access to the information it receives regarding the said documentation, to holders of the documentation using the said serial number.

1 5. A method according to claim 1 3, wherein only a part of the serial numbers alongside their respective authentication codes and respective their item unique identifiers are sent to the said third party server.

16. A method according to claim 1 3, wherein an access PIN is generated, included on the said documentation and sent to the said third party server alongside the rest of the data.

1 7. A method according to claim 1 6, wherein the said third party server gives access to the information it receives regard ing the said documentation to holders of the documentation using the said serial number and the access PIN.

1 8. A system for helping clients locate authenticating servers that tracks serialised instantiations of managed products, the system including:

a. at least one cl ient; b. at least one computer network through which the request is made and a response received; c. at least one serv ice registry receiving requests for access information;

d. a database of al l product codes and access information of the authenticating servers; e. a means of determ ining the product code from a received string and;

f. a means of locating the correspond ing access information for any given product code.

19. A method of determin i ng the target originating service that tracks and manages serialised instantiations of a product, said method including:

a. assigning product codes to a plural products, creating and populating a database of product codes and their respective originating services;

b. for every i nstantiation of the said products generating item number, the said item number being un ique for al l instantiations of the said products, and combining the said item numbers with the said product codes i n a manner that al lows for the said product codes to be extracted from the resu lting un ique serial numbers for every product;

c. tagging every instantiation of the product with its own unique serial number, and releasing the tagged instantiations of the product into the distribution chain;

d. a cl ient receiving a request including any serial number from any of the said instantiations of the said products;

e. the said cl ient making a request that includes the said serial number to the service registry hosting the said database, the said service registry extracting the product code from the serial number, searching and locating the corresponding access information in the said database.

20. A method according to clai m 19, of directing the said cl ient to the said target originating service, wherein the said service registry sends the access information back to the cl ient which in turn uses that information to make the request directly to the target originating service.

2 1 . A method according to claim 1 9, of directing the said cl ient to the said target originating service, wherein the said service registry sits between the said target originating service and the said client, channel l ing requests to the target authentication service on behalf of the said client.

22. A method accord ing to clai m 20, wherein the access information is U RL.

23. A method according to claim 20, wherein the access information is a network address.

24. A method according to claim 20, wherein the access information is a phone number.

25. A method of transferring ownersh ip of serial ised items where a third party maintains ownership records in a database that reflects what is owned by whom, the method including: a. the initial owner making a request to the said third party requesting that the said record of ownership of speci fic serial ised items owned by him/her be changed to reflect ownership by the new owner, by sending a l ist of serial numbers, his/her user unique identi fier and the user unique identifier of the new owner; b. the th ird party effecting the requested change in the said ownership record immediately by associating the serial number in the said l ist of serial number with user unique identifier of the new owner;

c. the third party giving a grace period with in wh ich either the previous owner or the current owner recognised in the ownersh ip record may cancel the transfer in the ownership and thus reversing the transfer.

26. A method accord ing to claim 25, wherein the immediate previous owner of the said items loses the right to cancel a transfer once the new owner transfers the said items to a new owner even if the said grace period is yet to end.

27. A decentralised business-to-business cooperation system that aids in sharing of information between business entities and helps make their interactions transparent while retaining security, wherein the said system consists of:

a. a plural of cl ients;

b. a plural of servers and; c. a service registry that has a database of al l products, their respective product codes, a database of all servers that manage information about the said products, information on how to reach the servers, the unique identifier of the said servers and information on the entity running the said servers.

28. Decentralised business-to-business cooperation system of claim 27, wherein the said system has an authentication server that manages al l the users in said system and authenticates users trying to access any given server within the said system.

29. A method of authentication in a decentralised system that el iminates the need for every server to maintain its own database of users, wherein the said method includes;

a. the cl ient attempting to access a target server making a request to an authentication server to be logged into the said target server by sending a login, password and the server unique identifier of the target server; b. the said authentication server responding with an authentication token valid for use on ly from the specific I P address of the said cl ient and val id for use only in the said target server by the said cl ient;

c. the client issu ing the said token in a request to the target server;

d. the target server verifying the validity of the suppl ied authentication token by sending the authentication token, the said client's I P address and the user unique identifier of the user accessing the target server to the authentication server used by the said cl ient and from the said authentication server requesting confirmation that it indeed issued the said token to the said user on the said I P address;

e. the authentication server checking its local database of valid session for the authentication token and comparing it to the suppl ied data and; f. the authentication server sending either a confirmation of the authentication or rejecting the authentication token, a rejection of the token indicating that the authentication token is not valid and; g. the target server taking the response and authenticating the user if the authentication server confirms the authentication token or giving the user an error message if the authentication server rejects the authentication token.