A method for establishing network connections between a client, an originating traceability application and a customer-related computer system in a network and evoking functions on data from both systems

Abstract

A method for facilitating a network connection: providing a network director and a list of resolvable network addresses of traceability applications; providing serialized product items unique identifiers, originated by an originating traceability application within said plurality of traceability applications, a network director receives an initial request comprising said unique identifier from a client, and sends a subsequent request to one or more of said network addresses of said traceability applications, for the purpose of receiving a response whether said traceability application recognizes said unique identifier as the originating traceability application, and network director establishes a connection between client and originating traceability application; and connection to a customer-related computer system; and connection to the client; originating traceability application and computer system exchange data, being processed by a federated function generating additional data.

Description

[0001] A method for establishing network connections between a client, an originating traceability application and a customer-related computer system in a network and evoking functions on data from both systems

[0002] Introduction

[0003] The present invention is a method and system to determine an originating traceability application for a product item using a serialized code and federating the data from the traceability system with the user data from a customer-related computer system.

[0004] Background of the Invention

[0005] Serialization of product items and traceability has become increasingly widespread in recent years. A uniquely identifiable product code on an item is recognized by a computer implemented traceability system in "the cloud", and a response is returned from the traceability system to a user with information about the product item. As the demand for traceability and serialization increases, more and more traceability systems have been implemented.

[0006] Traceability applications are part of computer systems that create and manage serialized codes that can also be aggregated and used in a track and trace system. Traceability applications are here to be understood as systems having capabilities and functions as explained herein.

[0007] For accumulating information about a product item, and later access it via a computer communication network such as in the cloud on the Internet, a product item is marked with at least a unique identifier (uid) and usually an Uniform Resource Identifier (URI) or a Universal Resource Locator (URL). A problem with this information when labelling it on the product is that this type of specific information can be quite extensive in terms of length of text and numbers and symbology that needs to be marked on the product item due to large series of otherwise identical products and a long, detailed specific target URL to address among many other different product targets, and the available space for marking may be very limited. Further it is desireable to be able to access user data from a computer system that belongs to the producer / retailer / brand of the product item along with information that is stored in the track and trace system in order to be able to generate functionality based on information that is exclusive to either system, but when combined, together generates further value. Such information can be related to discount and warranty structures in order to keep track of such functions without any manual operations where the information is easily accessible by scanning the QR-code of the item in question. An example can be the case where a user has purchased a product from a vendor that offers additional warranty in addition to the standard product warranty, where this information is saved in the user profile in the retailers system while the manufacturer that is responsible for ensuring that the correct warranty is enforced will be able to update this information in their track and trace system based on a linking between the two systems. The method can also be used in order to grant discounts wherein information on previously bought items is stored in the user profile's consumer history in the vendor system, and information on the present purchase is provided by the track and trace system.

[0008] The background art has several problems in various related technical fields.

[0009] Marking speed

[0010] A particular problem is that printing or marking QR-codes (or electronic tags of any kind, RFID, NFC, etc) on a production line is relatively time consuming. The more information that is carried by a QR-code the longer time it will take to print it. Effectively this will slow down production speed since today the printing speeds of QR-codes or any type of two-dimensional barcode are generally not keeping up with production lines speeds - at least not for an acceptable cost. It is therefore important to reduce the information in the QR-code to a minimum, including the address to the processing resource.

[0011] Ideally the code mark should be kept very short or small. Please notice that the unique identifier (uid) is really unique in all practical considerations. Another issue, typically for a provider of such traceability systems with several customers, is to direct a myriad of different products to the right instance or system, i.e. the traceability application where the serialized code was created and originated. A resource address as used in the background art should be complete in order to lead to the properly associated application in the traceability system.

[0012] Another situation arises wherein several de-facto independent traceability system vendors need to mutually interact in order to establish an inter company or inter system industry tracing system in order to scale up interoperability. This interaction is required when a party is adding and (or retrieving) information or tracking event(s) about the serialized product item and thus the information about the new event is reflected in the traceability application. Such adding or retrieving of information events may occur during packaging of marked product items, re-packaging of marked product items, border controls, unpackaging of multi-packaged product items, and sale of product items to a supposed end user, or in transfer from one user to another user.

[0013] In a supply chain with a considerable number of companies, participants and stakeholders, and all with varying levels of capabilities and resources, that need to either add tracing events related to a serialized code on the product item to, or sometimes retrieve tracing data related to the serialized code from, another yet high number of independent traceability applications, a one-to-one integration is just not feasible.

[0014] A unique, serialized code of an initially “unknown” product item, wherein the code may be encrypted, is easily routed to an appropriate system among a large number of initially unknown originating traceability system among many potential traceabilty systems, for any initially unknown party, is easily achieved with the current invention. The present invention thus enables a party or any supply chain stakeholder - that does not initially know or have relations with the unique serialized code product item owner, or the originating traceability application, to easily add basically an ad-hoc event, such as re-packaging of containers, customs checking, multi-box unpackaging, product information aquisition by a potential buyer, purchase in the shop to an end user, or the end user conducting owner registration, all events related to the serialized code, when so required. The serial code here can represent not only a product item - but any object associated with a serialized code utilized in a track and trace context such as a serialized code marked packaging box for a contained serialized product item, a serialized marked box container, or a serialized code marked shipping container. This enables and facilitates an extremely efficient “all to everyone” scalable and “incognito” interaction between seemingly “unknown” parties when using a serialized code. The invention solves this problem since if a stakeholder (a user) wishes to add an event (or retrieve data) related to the serialized code, this user in all situations, in a system according to the invention, simply forwards such a request to a single resource location applicable for all serialized codes and applicable to all users and stakeholders within the industry, thus the director of the present invention will link the serialized code (uid) with the resulting correctly traceability associated application without the users need for any knowledge about the serialized code (and thus product) and the originating traceablity application in the system wherein the event is correctly added and managed. Further rules, protocols, parameters and criteria that might be enforced for such interactions, such as for instance authorization and authentications, is not a scope of this invention.

[0015] The present invention is thus related to serialized product items being marked efficiently, carrying a brief initial uniform resource identifier (URI) and in such a way that based on the serialized code, it is easy to establish and facilitate the interaction between stakeholders application in a supply chain and the appropriate originating traceability application.

[0016] US 9,794,321 Trifa et al. relates to a computing system, and a redirector with a rules database, configured to receive an object identifier and contextual information from a client application. Based on that object identifier and the rules database and the contextual information that is analysed against a predefined set of rules, the redirector maps the object identifier and the contextual information to a deduced entry point associated with a specific computer application among a plurality of applications. Then access is provided to said specific computer application to the client application and user.

[0017] That background art employs a rules database in front of the plurality of applications whereby applying the rules on the contextual information will determine which application shall receive the request, and how to respond, based on the same contextual information. In the present invention, each queried traceability application may itself decide whether it is the originating (or managing) traceability application of the uniqueidentifier queried about.

[0018] In comparison with this background art, the current invention does not use any such rules database or analysing logical capability in front of the plurality of applications to determine which application shall process the request or indicate to the applications how to respond.

[0019] Traceability systems of the background art involve a large number of different complex configurations and rule sets that are difficult to generate and then later difficult and demanding to maintain in a redirector rules database. To keep the rules and a redirector database up to date at all times can be a labour and resource intensive task. This maintenance of rules is especially labor demanding when it comes to incorporating all different and fast growing number of user profiles using a client whose context must be mirrored in the rules database in order that the redirector works properly and as intended. In other words, the difficulty and complexity arises partly from changes being made in one or more of the potential traceability applications, and partly from dynamic contextual information from predominantly users and user profiles that change and grow in volume every day and that needs to be updated in the rules database for ensuring the right redirector redirects to the appropriate address of the application, as well as providing the correct contextual information to the traceability applications to provide a response.

[0020] The present invention solves one or more of the above mentioned problems.

[0021] Summary of the Invention

[0022] The invention is defined in the present independent claim. The invention provides a method for establishing or facilitating a network connection (606) between a client (200) and an originating traceability application (601) and between said originating traceability application (601) and a customer-related computer system (900 in a network (101) and combining data (650, 950) between said originating traceability application (601) and a customer-related computer system (900), said method comprises:

[0023] - providing a list (550) of a plurality of resolvable network addresses (702) of a plurality of corresponding traceability applications (600, 602, 601);

[0024] - providing a plurality of serialized product items (401), each associated with a unique identifier (400), each said unique identifier (400) originated or managed by an associated originating traceability application (601) within said plurality of said traceability applications (600), all said serialized product items (401) associated with a network address (700) resolvable for a network director (500), a) a client (200) reads said unique identifier (400) and said network address (700) to said network director (500), and sends a first request (300) comprising said unique identifier (400), to said network director (500), b) said network director (500) sends a subsequent request (302) comprising said unique identifier (400) to one or more of said network adresses (702) of said corresponding traceability applications (602, 601), for the purpose of receiving a response (800) whether said traceability application (602, 601) recognizes said unique identifier (400) as originated by said traceability application (602, 601) now recognized as said originating traceability application (601), c) if said response (800, 808) to said subsequent request (302), is a positive or affirmative response (808), then d) said network director (500) establishes a connection (606) between said requesting client (200) and said originating traceability application (601); wherein e) said affirmative responding traceability application (601) establishes a connection (606) to a customer-related computer system (900); g) said customer-related computer system (900) establishes a connection to the user app (200); h) said originating traceability application (601) and said customer-related computer system (900) exchange a first and / or a second set of data (650, 950), g) said first and / or second set of data (650, 950) being processed by a function (960) thereby generating a third set of data (961).

[0025] Embodiments of the invention are described below and rendered in the dependent claims. Brief Figure Captions.

[0026] Embodiments of the invention are illustrated in the attached drawing Figures, wherein

[0027] Fig. 1 illustrates an embodiment of the invention wherein a serialized code (230) from a product item (401) is forwarded to a director (500). Said director (500) obtains an affirmative response thus reaches the originating traceability application (601) within a network of traceability applications (600). The originating traceability application (601) further sets up a connection to a "retailer / vendor" computer system (900) with a first user profile (910), wherein data (650, 950) related to the user (205) associtated with the product item in both systems (601 , 900) is federated and functions are evoked upon the data (650, 950) from both systems (601 , 900) in order to gain fuctionality not accessible in either system (601 , 900) separately.

[0028] Fig. 2 illustrates an embodiment of a part of the invention wherein one of a plurality of serialized product items (401) each are provided with a unique identifier (400). The unique identifier (400) is read into a client (200) which sends a request to a director (500) in order to reach an originating traceability application (601) which originated the unique identifier (400). The director (500) forwards a request with the unique identifier (400) to one of a number of N traceability applications (602) (of which addresses are held on a list (550) readable by the director (500). The director sends the subsequent request (302) one at a time, of which one of them may be the originating traceability application (602, 601), asking whether the receiving traceablity application (602) is an originating traceabiltiy application (601). If no response is received within reasonable time, or if a negative response (802) is received, the director may send a subsequent request (302) to query the next traceability application (602) on the list. The one originating traceability application (602, 601) which receives the subsequent request (302) comprising the recognized unique identifier (400) is the originating traceability application (601), here labeled as traceability application M, returns an affirmative response (808) to the director (500), which haltsfurther querying from the director (500), and the director (500) facilitates a connection (606) between the client (200) and the originating traceability application. Further traceability applications beyond traceability application M (601) are not queried.

[0029] Fig. 3 illustrates that the director (500) facilitates the connection (606) between the client (200) and the found originating traceability application (601).

[0030] Fig. 4 illustrates another embodiment a part of the invention similar to the one in Fig. 1 , with the difference that the director (500) forwards a request with the unique identifier (400) to all of a number of N traceability applications (602) at the same time. The director sends the subsequent request (302) all at the same time, their addresses are held on the list (550) readable by the director (500). The one originating traceability application (602, 601) which receives the recognized request (301) is the originating traceability application (601) , here denoted traceability application M, returns an affirmative response (808) to the director (500), and the director (500) facilitates a connection (606) between the client (200) and the originating traceability application (601). Those not being the originating traceability application need not reply, and may be instructed to do so instead of returning a negative response (802). This saves time, but if the number of potential traceability applications (602, 601) is large, such a query may generate much unnecessary traffic.

[0031] Fig.5 - Fig. 9 illustrate an embodiment of the invention as a step by step illustration. Fig. 5 shows the first step where a user with a user app (201) on a client (200) scans an unique identifier (400) on a product item (401). Please refer to Fig. 2 for a detailed description of the procedure. Eventually, the unique identifier (400) originating traceability application (601) responds to the director (500).

[0032] Fig. 6. illustrates the forming of a connection between user app (201) and the originating traceability application (601) as described in fig. 3.

[0033] Fig. 7 illustrates the establishment of a connection (606) between the originating traceability application (601) and a customer-related computer system (900) wherein the user has a user profile (910), as well as a connection (606) between the customer-related computer system (900) and the client (200). Fig. 8 illustrates the federation of data from user profile (910) in the customer-related computer system (900) and the originating traceability application (601), wherein functions (960) are evoked on the data (650, 950) from both systems further generating data C (961) that can be used internally or stored in either system (601, 900) or transmitted to user app (201).

[0034] Fig. 9 illustrates an embodiment of the invention illustrated in fig. 8, wherein data C (961) is stored in the customer-related computer system (900) and therefrom used in communication with the user via user app (201). An example of the interaction depicted in fig. 9 is that a consumer is buying a new product item (401) etc, a fourth similiar item to the previous three items, thereby evoking a discount automatically. The originating traceability application (601) registrars the purchase and the purchase information combined with previous purchase information and discount structure is used with a function C (960) to generate a discount (data_C) (961) wich is stored in the customer-related computer system (900) and transmitted to the user app (201) on client (200).

[0035] Embodiments of the invention

[0036] The method and system according to the current invention utilises a similar but improved method compared to the background art US ‘321 Trifa patent, but in a faster, simpler, more accurate and less resource demanding way, and further utilizes data from the unique identifier . One of the most prominent and significant differences is that the method and system of the invention does not employ the context aware redirector nor the rules database as described in US ‘321 Trifa, and the task of keeping such a rules database up to date is thus eliminated.

[0037] The invention provides a method for establishing or facilitating a network connection (606) between a client (200) and an originating traceability application (601) and between said originating traceability application (601) and a customer-related computer system (900) as well as between said customer-related computer system (900) and said client (200) in a network (101) and combining data (650, 950) from said originating traceability application (601) and a customer-related computer system (900), said method comprises:

[0038] - providing a list (550) of a plurality of resolvable network addresses (702) of a plurality of corresponding traceability applications (600, 602, 601);

[0039] - providing a plurality of serialized product items (401), each associated with a unique identifier (400), each said unique identifier (400) originated or managed by an associated originating traceability application (601) within said plurality of said traceability applications (600), all said serialized product items (401) associated with a network address (700) resolvable for a network director (500), a) a client (200) reads said unique identifier (400) and said network address (700) to said network director (500), and sends a first request (300) comprising said unique identifier (400), to said network director (500), b) said network director (500) sends a subsequent request (302) comprising said unique identifier (400) to one or more of said network adresses (702) of said corresponding traceability applications (602, 601), for the purpose of receiving a response (800) whether said traceability application (602, 601) recognizes said unique identifier (400) as originated by said traceability application (602, 601) now recognized as said originating traceability application (601), c) if said response (800, 808) to said subsequent request (302), is a positive or affirmative response (808), then d) said network director (500) establishes a connection (606) between said requesting client (200) and said originating traceability application (601); wherein e) said affirmative responding originating traceability application (601) establishes a connection (606) to a first computer system (900); f) said customer-related computer system (900) establishes a connection to the user app (200); g) said originating traceability application (601) and said customer-related computer system (900) exchange a first and / or a second set of data (650, 950), h) said first and / or second set of data (650, 950) being processed by a function (960) thereby generating a third set of data (961).

[0040] Information on how to establish the connection (606) from said originating traceability app (601) to said customer-related computer system (900) may be related to the product item (401) and reside in said traceability app (601) which also may provide information about the user client (200) for which the customer-related computer system (900) may connect.

[0041] As an example, the first set of data (650) read from said originating traceability application (601) may comprise specific properties of said product item (401) which requires a certain age for the user to buy. But the originating traceability application (601) is a track and trace application which does not hold such information on the user's age. However, said second data (950) may comprise information in a user profile (910) on the user's age, the nationality of the user, etc.. The information on product properties from the first set of data (650) combined with the user's age from the user profile (910) in the second set of data (950), and combined with local regulations on age restrictions on such products, may be combined to form a decision whether the user may continue with buying the product item (401).

[0042] In an embodiment of the present invention said function (960) originates in either the customer-related computer system (900) or the originating traceability application (601).

[0043] In an embodiment of the present invention if said response (800, 801) is negative ("no") (801), disregard said response (800, 801);

[0044] In an embodiment of the present invention each traceability application (602, 601) receiving said subsequent request (302) will itself analyze said unique identifier (400) to determine whether it can resolve said unique identifier (400) thereby identifying as an originating application (601) of said unique idetifier (400), or reject I disregard said subsequent request (302).

[0045] In an embodiment of the invention, said director (500) is arranged to send said subsequent request (302) to one by one of each traceability application (602, 601) in said list (550); until said response (800, 801 , 808) is an affirmative response (808). In and embodiment, if receiving an affirmative response, then not sending further subsequent requests (302) to further traceability applications (602) in said list (550).

[0046] Often such unique identifiers (400) are encrypted and the decryption takes place at the originating traceability application (601) in order for it to look up the subsequent request (302) based on the internally decrypted unique identifier (400) in order to determine whether the subsequent request (302) is a properly resolvable request (301) with an originated unique identifier (400) which shall result in an affirmative response (808). Those traceability applications (602) which are not originating traceability applications will normally not be able to even decrypt the subsequent request (302) and shall return a negative response (801) or no response.

[0047] A first advantage of this embodiment is that the time and total work involved for sending further subsequent requests (302) is saved when a positive or affirmative response (808) is received. The number of potential traceability applications in said list (550) may be considerable and can be in the hundreds or the thousands.

[0048] A second further advantage of this embodiment is that it is less energy consuming for the network (101) because no signals or processing energy is required for further queries when said positive or affirmative response (808) is received.

[0049] A third further advantage of this embodiment is that it reduces the traffic on said network (101) compared to querying all potential traceability applications (602) on said list (550).

[0050] A fourth further advantage of this embodiment is that it does not evoke any energy for internal tracing to provide negative response (802) from those traceability applications (602) not queried, nor any return traffic from such not queried on said network (101).

[0051] In an embodiment of the present invention said subsequent request (302) to said application (602) includes contextual information (333), said contextual information (333) comprises an instruction (333, 334) to not return a negative response (801) in case said traceability application (602) is not an originating traceability application (601) of said unique identifier (400). In an embodiment of the invention said director (500) is arranged to send said subsequent request (302) simultaneously to all traceability applications (602, 601) in said list (550).

[0052] An advantage of this embodiment is that it is fast to find the originating traceability application (601), however at a cost of increased traffic for querying an otherwise unneccessary number of potential candidates on the list (550).

[0053] In an embodiment of the invention, if an affirmative "yes" response (808) has not been received when said list (550) of traceability systems (600) is exhausted, then

[0054] - return a response (800, 820) stating that a unique identifier (400) originating traceability application (601) is not found, as response (820) to said client (200).

[0055] In an embodiment of the invention, including in said subsequent request (302) to said application (602) contextual information (333) comprising an instruction (333, 334) to not return any response (800) if it otherwise would return a negative response (801) in case said queried traceability application (602) is not an originating traceability applicaton (601) of said unique identifier (400).

[0056] An advantage of this embodiment is that only the affirmatively responding traceability application (601) returns any response (808), the remaining requested (otherwise negatively responding) traceability applications (602) remain silent about their received subsequent request (302).

[0057] In an embodiment of the invention, said method managing unique identifiers (400) and aggregated track and trace information based on said unique identifier (400), whereby said traceability application (602, 601) conducts the steps of: a) receive contextual information (333) pertinent and applicable to said subsequent request (302) itself together with said unique identifier (400); b) compose a response (800, 808) according to and based on internal rules and instructions associated with said unique identifier (400) and / or said received contextual information (301 , 333). For simplicity this specification uses the term ‘product item’, and then a serialized product item (401) which is associated with a unique identifier (400). However, a physical object or object / systems with means to store a serialized code, a unique identifier (400) with electronic means, is encompassed by the term serialized product item (401), the object associated with the unique identifier (400), such as the product item itself, all logistical containers or transportation devices, tags, labels, packaging, pallets, boxes, RFID, computers, hard discs.. All material objects and media that carry a unique serialized code, a unique identifer (400) are included by the term ‘serialized product item (401). Essentially, if the first request (300) includes a uniquely serialized code, i.e. a unique identifier (400), the unique serialized code, the unique identifier (400) may also be a unique identifier (400) at a hierarchical level of identifiers (400) forming part of an aggregated packaging tree for general track and trace purposes as described, inter alia, by the applicant in US patent 8,423,770, US 8,700,501 and US 10,074,063. Central to the present invention is how to manage the unique serialized code (400) itself and to a lesser extent what it materially represents, since the material and hierarchichal representation is managed by the target traceability application.

[0058] Significantly, the determination of the correct / originating traceability application to be connected to is carried out based on the unique identifier uid and by the properly responding applications among the several traceability applications. (Even other applications not originally intended to respond may in rare occasions be evoked).

[0059] This means that even copies or clones of the traceability application or applications adapted to respond to the unique serialized code from other systems than the originating application can further process the transaction.

[0060] The resource address read from the serialized item (401) described in the invention is partial in the sense that it is incomplete as such and will lead to the intended proper application when using the method of the invention.

[0061] Objectives of the Invention

[0062] One objective of the present invention is to provide a system (100) and a method to reliably connect a client (200) carrying the unique identifier (400) of a serialized product item (401) to an appropriate target traceability application (601) at a customer / manufacturer associated track and trace server.

[0063] More specifically, an objective of the present invention is to provide a method for establishing or facilitating a network connection (606) between a client (200) and an originating traceability application (601) and between said originating traceability application (601) and a customer-related computer system (900) as well as between said customer-related computer system (900) and said client (200) in a network (101) and combining data (650, 950) from said originating traceability application (601) and a customer-related computer system (900),

[0064] More specificall, an objective of the present invention is to provide a method for evoking functions (960) upon the data (950) from said customer-related computer system (900) and data (650) from the originating traceability application in order to create data (961) that could not be obtained from one of the sources of data (650, 950) alone.

[0065] Another objective of the present invention is to provide this connection (606) between the user / client (200) to its intended system traceability application (601), without the disadvantages related to the rules database of the background art and the database mainenance related thereto. Tracing of product items using serialization and aggregation are operated for various clients by expert vendors of traceability systems. The software and technology implemented for each customer is often based on the same core solution but has then has configurations, special developments and adjustments specific to each different customer and their customer system. Another common practice is that each customer has their own tracing system running instance operated on their behalf by the traceability vendor or provider. There are mainly two reasons for this; all the data are kept private and securely for the customer since there is no sharing of resources with other customers (nor other traceability system expert vendors) in any way with other customers that the traceability system expert vendor is operating tracing systems for, on their behalf. Further, the traceability system can be managed without the need of the expert vendor / customers having to wait for common developments of the software by the expert vendor to be distributed for all customers. It also makes operations less complex and efficient for the expert vendor.

[0066] In relation to the present invention, a client (200) is a piece of hardware and / or computer software that is capable of processing computer instructions and computer code and also able to communicate through computer (-enabled) networks and thus connect and communicate with other clients, software and computers. The client (200) device is typically a mobile unit such as a mobile telephone or a tablet. These preferably comprise a device to read a tag, such as a camera to read a barcode, a QR code or other optically encoded data, or means for reading data from RFID tags.

[0067] As an example the client (200) may be a smartphone with an app (201) or any other suitable computer system to interact with a user and communicate. As a further example the client (200) communicates one or more scanned serialized codes (400) from a serialised product item (401) to a track and trace system (601) of a customer system (100) run on a server at a specialist vendor, and exchanges information based on the serialized code (400).

[0068] A user (205) is a person that can interact with such a client (200) to take advantage of the client's (200) capabilities to perform and operate tasks and functions available by the client (200) and its system (100) associated app (201). When a user interacts with a client (200), that interaction is also sometimes referred to as "the user experience".

[0069] A user profile (202) is understood to be an authorization to interact with the client (200) and specific and uniquely identifiable information related to the user that will govern the interaction with the client (200). Such user profile (202) information is very commonly comprising; user name, address, user email, mobile phone number, and user id assigned within the client (200), selected user preferences within the client (200), etc. In an embodiment this user profile (202) is stored in said customer- related computer system (900).

[0070] Within the field of product tracing, aggregated track-and-trace, a serialized code , hereafter referred to as a unique identifier (uid) (200) is associated with the product item (401). Nowadays the serialized code, the unique identifier (uid) (400) is printed as a QR-code or a Data Matrix code since these technologies have the required data storage capabilities. However an RFID, Near Field Communication (NFC) or any suitable data carrier solution for a product item (401) might be used to carry the unique identifer (uid) (400) within the frame of the current invention. Further the product item (401), in addition to the unique identifier (uid) (401), has additional important information associated with the product item (401). One such crucial information element is information or instructions regarding how to locate and access the system (100) that shall handle a processing first request (300) from the user's client (200) - a first request (300) that may involve the unique identifier (uid)(400). This information is typically held in a source related to a web address on the Internet (network) in the format where the other associated information and datasets N .. M on the product may be resolved or parsed and used in the subsequent processing. The techniques for parsing, deciphering, analysing or by some means or methods interpreting these datasets from the incoming request (300) is considered as belonging to the common background knowledge of the person skilled in the art.

[0071] Flexible generic address

[0072] Ideally the resource address (700) on the product item (401) shall be as generic as possible so that the actual location is flexible and it is possible to change it in situations where this will optimise the system (100) operations. Ideally one traceability vendor could have one single address (700) for all products in the market for all their customers such as say. In some cases also the same product item (401) might, and with the same generic (initial) resource address, eventually end up with different processing resources. Consider the following example to explain this effect. The same product, GreatChips, from the same manufacturer, will have the same resource location address. On the product there is no information or way to deduct that these products might have different target systems. Consider that we have product item A and product item B as described above. For the example, a request (300) regarding the unique Identifiers (uid) (400) of a portion of serialized products (401) must be processed on traceability application (601) TA001 located in Brazil, as an other portion of the unique codes (400) representing serialized product items (401) must be processed in Frankfurt on traceability application (601) TA002. It is important to emphasize that these computer resources, the traceability applications (601) TA001 and TA002 are completely independent and separate from each other and hold zero knowledge about the other. As examples, a product item A is marked www.oneadr.com / ABC and a product item B is marked ww .onea r.co / 123, wherein ABC and 123 are their respective unique identifiers (400) uids. Product item A has a unique identifier (uid) (400) created and originated by application TA001 located in, say, Rio de Janeiro, likewise product item B has a unique identifier (uid)

[0073] (400) created and originated by TA002 located in, say, Frankfurt.

[0074] The present invention provides a solution to direct the connection for a product item

[0075] (401) to the correct intended traceability application (601) as explained even though there is no way that this can be resolved or otherwise be deducted solely by the information on the product item (401) itself. The information on the product item (401) as described is hence not sufficient to link a first request (300) to the originating traceability application (601). The method and system of the invention will however bridge the “gap”, e.i. establish the link between the product item (401) and the itended appropriate traceability application (601) by using an intermediary traceability application director (500), hereafter called the traceability director (500). The traceability director (500) can be accessed by clients (200) using the information on any of all product items (401) using the one and constant network address (URI / URL), the network director address (700). The traceability director (500) essentially receives a request (300) from a client (200), or a user via a client (200) , the request (300) comprising a unique identifier (uid) (400), and sends the request (300) to the constant network address (URI / URL), the network director address (700). The traceability director (500) uses a traceability application list or register (550). Essentially the traceability director (500) is a program resource entity that facilitates a client (200) reading a serialized code, namely the unique identifier (400) of a product item (401) to find the intended appropriate originating traceability application (601) and then link them together for further processing and interaction between the client (200) and the appropriate originating traceability application (500). The traceability director (500) is a network computer and computing resource (proxy, network broker, etc), capable of operating and handling such resource as described related to the present invention. The traceability director (500) is implemented in a computer device that links and facilitates a product item (401) having a unique identifier (uid) (400), and the appropriate originating traceability application (601) among a plurality of traceability applications (600)

[0076] In essence, the invention makes it possible to use a single resource address, the constant ( or "static") network address, the network director address (700) to the network director (500) for one or more product items (401), each product item (401) being marked or associated with an unique identifier (uid) (400), and, using the network director (500) to (re)direct (510) the request (300) with the unique identifier (uid)(400) to its unique identifier ((uid)(400) - originating appropriate application (601) amongst a plurality of potential traceability applications (600) - of which only one appropriate originating application (601) shall process the request (300, 302).

[0077] Further, in an embodiment of the invention, the network traceablity application director (500) is arranged to customize the response (800) from the appropriate originating traceability application (601) based on contextual information (333) based on the request (300, 302) itself.

[0078] Even though this description has adopted the assumption that on one single resource address, the network application director address (700), pointing to one network traceability application director (500) and from a plurality of product items (401), several resource addresses (700, 700') on a product item (401) might be employed as long as they resolve and connect to the network traceability application director (500) .

[0079] In an embodiment of the invention it enables even higher efficient use of the application director (500) in situations where it is possible or feasible that the product item (401) can carry more information without other penalties or disadvantages relating to the QR-code or the employed marking technology itself, its printing and marking onto the product items (401). In its simplest and most basic form a tracing system, a traceability application (600, 602, 601) receives an incoming subsequent request (302), in other words basically a unique identifier (uid) (400), processes the subsequent request (302), and then responds with a response (800, 801, 808). In this situation basically the traceability application (602, 601) has two pieces of information, the unique identifier (uid) (400) itself and an adress (707) to send the response back to. The information and response behaviours sent back will be governed by the rules set up by the traceability application (602, 601) for that unique identifier (uid) (400). The “richness” of a response (800) for a product with a unique identifier (400) uid can vary with related to the application external information that follow the request. In this patent specification we will refer to this as contextual request information (CRIx) (333). The contextual information CRIx (333) is all information created or otherwise captured outside the application that is sent in the subsequent request (302) to the traceability application (602, 601). This contextual information (CRIx) (333) might be a user profile (202) identifying information about the user - or transactional information such as time or ip-address, cookies etc, or other network or session information. Especially a user profile (202) in the subsequent request (302) that is recognized and managed by the traceability application (601) is valuable for orchestrating the best possible response (800, 808, (801)) to the subsequent request (302). The amount and nature of the contextual request information CRI (333) is only limited by an actual transaction itself at any given time. By way of example we will explain how contextual request information CRI (333) may influence the response from the application. Using our example above, w^ff oneaar.com / ABC, a subsequent request (302) where contextual request information CRI (333) is not used, the response (800) from the correct originating traceability application (601) will be “Hello World”. Any and all subsequent requests (302) will have the very same response (800) for this situation.

[0080] Now we will consider how a request (300, 302) that sends contextual request information CRI (333) to the traceability application (602, 601) along with can change its response (800) based on the contextual request information CRI (333) or parts of the CRI. The contextual request information CRI (333) has an IP-address that resolves and indicates that the user is within Norway. The application is now sending another response based on this information for the same uid=ABC as described earlier. The response from the server, instead of “Hello World” is now in Norwegian language: “Hei pa deg Verden I”

[0081] The way traceability systems based on codes and serialized codes are designed, there are two main categories of contextual request information CRI. The difference between these two categories are important to understand as they will have a different impact on how the CRI is used. Therefore for the invention we denote CRIx and CRIn. CRIx is external contextual information that is not known or controlled by the application. This is information that is typically about the request and the transaction itself, typically but not limited to IP-address, time, browser details, client information, versioning information, etc.

[0082] CRIn is contextual information that is native and in full or in part known and managed by the application. For instance when a request is incoming the user might pass along the request that the user has UserlD=332 that is managed by the application. In other words the application has essential information about the request user.

[0083] For a very “rich” incoming request the contextual request information might effectively be conflicting with each other. In an embodiment of the invention, the originating traceability application (601) will have internal processing that will decide what is the appropriate response (800) even the incoming has information that considered isolated would have triggered different responses, as only a response for “consideration CRIx” is possible. Some contextual request information CRI (333) will therefore be overruled in favour over another that is indicating a particular response behavior - say for instance language.

[0084] In general terms - the native contextual information CRIn is the strongest information and will in most cases be the governing response indicator.

[0085] Again using the above example the native contextual information CRIn will now again change the response to the client (200) and user. Previously the CRIx indicated that the user was in Norway and the response was given in Norwegian as per originating traceability application (601) rules. This time however some native contextual information CRIn was also sent to the request (302). A Spanish user (Pedro) has a user profile (202) and that particular user has in that user profile (202) managed by the originating traceability application (601) selected that responses shall be in Spanish. One might perceive that this user was on travel in Norway when he desired to get access to the application by a request (300). The external contextual information CRIx that indicated a Norwegian response based on the IPaddress is now by the application decided to be overruled by the user's own user profile (202) information about the response behavior. The response (800) back to the client (200) will therefore now be “Hola Mundo y Pedro”.

[0086] The same unique identifier uid (400) with current invention responds differently based on the unique identifier uid (400) and the contextual request information CRI (333) whereby the response (800) might comprise a video message one time, and a text message another time, all based on the contextual request information CRI (333).

[0087] For the current invention the response (800), after the subsequent request (302) has been received by the application (602, 601), is that it is the traceability application

[0088] (602, 601), that processes the subsequent request (302) and decides and processes the response (800) and its behavior back to the client (200). The director (500) that sits in front of the plurality of traceability applications (600) does not hold any such rules or capabilities to that effect. The traceability application (602, 601) will have internal rules and methods for processing (or not) the subsequent request (302) and determining and processing the response (800) based on the incoming contextual request information CRI (333) with external CRIx and the potential native CRIn in combination being transferred to the traceability application (602, 601) in the subsequent request (302). The response (800) by the traceability application (602, 601) is also concerning the correct return location, the response address / location (707) for the originating traceablity application (601) and mapping for the response (800) further based on the unique identifier uid (400). The traceability application (602, 601), may after being determined as the originating traceability application (601) communicate with the user client (200) and any number of external applications (if otherwise allowed and possible) to further obtain information to decide how to respond. For instance, the originating traceability application (601) may receive a language setting, configuration or another preference setting from an external system that was facilitated by the user's client (200). Importantly this is still to be considered internal handling or handling rules and protocols by the originating traceability application (601), since the originating traceability application (601) is still in full and absolute control of the processing and analysis when preparing the best response and connection session (606) to the user and / or the client (200), because it is only to the user and / or client (200) the traceability application is “accountable” and answerable. All external information received and processed "internally” whatever the source by the traceability application is such only to be considered suggestive.

[0089] For instance a response (800) could simply be returned to w w. answer. com / 44 based on unique identifer uid (400) ="ABC" for one given set of contaxtual request information CRI (333). However, since the CRI (333) so dictated the response (800) returned was “Authentic product” to www:anysite.com by JSON.

[0090] Importantly a response (800) may according to an embodiment of the invention not merely be determined and / or limited by the originating traceability application (601) alone. If the user and / or the user's client (200) client application (201) or application(s) has either forwarded contextual request information CRI (333) during discovering the correct originating traceability application (601), or later requested it after or during a session has been successfully established; then the originating traceability application's (601) response may be devised and composed due to a possible interaction with other external applications. As an example, if the initial request (300) came from an Amazon shopping app and that application managed a user profile (202) and the user's shopping details, the originating traceability application (601) could interact with the Amazon app (201), and related Amazon servers and databases to furnish a response (800) in the native Amazon app (201) where both applications contribute data in the response (800). The Amazon (native) data could be for instance concern a purchase order number and several other data natural to the app behavior, and further the Amazon app (201) could display or access a tracing history of a uniquely identified (400) product item (401) by data provided by the originating traceability application (601) exclusively.

[0091] One type of response (800) that is particularly useful is wherein the originating traceability application (601), based on the unique identifier uid (400) received and the rules ascending from that specific unique identifier uid (400), can invoke, trigger, map, and launch various other applications, whether these are internal to the traceability application “ecosystem” or external applications such as the Amazon shopping app (201) described above.

[0092] In an embodiment of the invention the response (800) may also forward and feed data and / or interfaces to target websites or other clients based on the rules that are associated with the unique identifier uid (400) in the originating traceability application (601). Significantly such a rules or response deciding method sets on how to potentially respond given the current circumstantial data, responded to any “random” application or client (200) is directly detected or derived from the unique identifier uid (400) within the originating traceability application (601), or, as an alternative, the response (800) might be also instructed by a client (200) in some situations as part of setting up a session. From this perspective the originating traceability application (601) can be considered as a context-reacting originating traceability application (601).

[0093] In an embodiment of the invention the format of the response (800) from the originating traceability application (601) might be of part contextual request information (333) sent from the requesting client (200) or its user where such specification or instructions are included. The format might be http, JSON, API, etc., only limited to the available formats and technologies available at the time of the subsequent request (302). The format and instructions about how to respond might also be established during or after establishing a session, transaction, or communication between the requesting client (200).

[0094] In an embodiment of the invention it enables a plurality of applications to interact with each other to access data relating to a unique identifier (400) comprising a serialized code, and additional data concerning the product, including but not limited to aggregated track and trace data which includes the logistical and supply chain history. Its important that the user experience hence is realized by a co-operation and orchestration between the originating traceability application (601) and its interaction with a plurality of external applications. The negotiation, handshaking, authentication, authorization, protocols, encryption schemas, session and transaction handling, implementation and necessary technical systems and methods, etc, to have two or a plurality of systems / applications interact with each other and the originating traceability application (601) in order to essentially permanently or transiently share data for any given situation and scenario is not further described herein.

[0095] The invention is particularly useful for a traceability application vendor when operating several traceability server systems (100) for several different customers sharing a common global network entry point, i.e. , a network director (500) for all customers and serialized product items (401) marked by unique identifiers (400).

[0096] A plurality of product items (401) are each provided with a unique identifer (uid) (400) and the common resource (virtual and partial) address, a network director address (700) which is used by a client application (201) in the client (200) for directing an initial request (300) to an application director (500).

[0097] The network director (500) is a computer implemented software which comprises a list (550) or register of traceability applications (602) that potentially can handle the subsequent request (302). The list is accessible to the network director (500), but does not have to be directly accessible by the client (200). For security reasons it may be restricted that the client cannot access the list (550) directly. The list (550) contains reference information about the resource address (702) for each potential traceability application (602, 601) on the list (550) and all the necessary information that is required to ask a traceability application (602, 601) for whether a unique identifier (400) was created and originated by or is managed by the queried traceability application (602, 601). Importantly the director (500) does not have to process, interpret or analyse the initial request (300) for any purpose or process, interpret or analyze the external contextual information CRI (333) received by the client (200) or the user. It will only forward it “as is” as a chunk of data in the subsequent request (302) to the traceability applications (602). The list / register (550) managed by the network director (550) must initially be created and then later managed by the network director system (100) owner(s). This list (550) typically is updated manually or at regular intervals. The present invention does not concern itself with how the list is managed as it is considered a task expected to be satisfactorily handled by someone skilled in the art.

[0098] In an aspect the invention is comprises the following steps;

[0099] The client (200) sends an initial request (300) comprising the unique identifier (400) read from the product item (401) to the application director (500) and including contextual information, both native CRIn and external CRIx as if and when available. The application director (500) will then based on the traceability application list (550) determine which traceability applications (600) shall be forwarded the request (300). This is achieved as the application director (500) will convey the unique identifier (400) to the potential traceability applications (600, 602, 601) and ask for a response (800) back whether the unique identifier (400) was created and originated by or managed by the queried traceablitiy application (600, 602, 601). In its basic form this is a binary response of yes / no nature. A “No” response (801) is returned from a nonoriginating traceability application (602). A “Yes” or affirmative response (808) is returned from an originating traceability application (601) which recognizes the unique identifier (400).

[0100] There are several methods and strategies that the network director (500) can employ for contacting the traceability applications (602) on the list (550), and in such a way lower the traffic burden and as well shorten the time to receive an affirmative "yes" response (808) from theoriginating traceability application (601) among the potential traceability applications (602). For instance a sequential approach might be used, please see Fig. 2, wherein the application director (500) simply starts on top of the list (550) and asks that traceability application (602, 601) whether it is the originating traceability application (601), please see Fig. 2. If the answer (800, 802) is "no", the next application (602, 601) on the list will be asked, and so on, until an affirmative response (800, 808) "yes" is received and the originating traceability application (601) has been found. Then the network director (500) does not have to proceed further on the list (550). This may be advantageous if some of the empirically most used I most queried traceability applications on the list (550) are sorted to the top and the list (550) in descending order. Another strategy is to ask all traceability applications (600, 602, 601) on the list (550) simultaneously and filter all the incoming answers from the application to find the affirmative response (808) "yes" and then the originating traceability application (601) has been found. Or there might be other strategies that can combine the above or use grouping or sorting of the list that will lead to the answer in a faster or more efficient way. The method can also be designed and optimised to reduce network traffic load. In an embodiment of the invention, the network director (500) can comprise an analysing method, algorithm or tool that will employ an efficient query method based on the list.

[0101] In an embodiment of the invention, an initial (300) or subsequent request (302) is encoded as an Uniform Resource Identifier (URI) or Universe Resource Locator (URL), the size of the request is usually less than 1 KB in size, so the network load of transmitting an initial (300) or subsequent request (302) is trivial.

[0102] Further, in an embodiment of the invention, it is possible to distribute the traceability application list (550) by creating and managing copies (550') that can be distributed on one or more network director replicas (500') that can be used in the same manner as network director (500) in a load balancing schema. This will enable optimization of network traffic, for instance larger regions might have one director copy / replica (500') such that a “local” request (300) is routed to that network director (500') first and such reduces the latency of the request (300) to a director coming from that region.

[0103] After the originating traceability application (601) has been identified by the director (500), the director (500) facilitates (606) a direct session and further transactions between the client (200, 201) and the originating traceability application (601). After the session and connection (606) between client (200) and originating traceability application (601) has been confirmed, the director (500) communication is dropped from the request and the task for the initial (300) and subsequent request (302) is completed for the network director (500).

[0104] In an embodiment of the invention, the director (500) might generate and store a secured request log. In an embodiment of the invention, the contextual information (333) may be passed to the originating traceability application (601), which may potentially use this information to further compose the best response (800) to the client (200).

[0105] Essentially prior art uses contextual information (i.e. information external in relation to the application itself) for two main purposes; firstly routing a request to the correct application resource, and then having the resource compose a response based on said contextual information.

[0106] In comparison to prior art, the current invention is exploiting two fundamental and constantly present attributes of traceability systems that are based on using unique identifiers, "uid"s. Firstly, any such traceability application is capable of responding conclusively based on the uid only whether the uid was created and originated by that particular application. That means that the uid on a product or any object associated with the uid can be used without any contextual information whatsoever to determine the right traceability application for the uid in question. The traceability application only needs the unique identifier uid to determine this. Secondly, when the uid has been recognized by the application, in reality the traceability application has the capabilities and the sufficient internal information to itself compose a customized response to the request. If not, it can simply demand or request such information from the user or the requesting client as per session and requirements.

[0107] In one embodiment of the invention, a traceability application might not have created the unique identifier (400) itself or it was not originated within that particular traceability system. However, due to the architecture of the total overall traceability system, the traceability application within the present invention manages the unique identifier (400) and as such is the originating traceability application(601) and a correct entry point to the overall traceability system as a whole. It is such per definition the correct, originating traceability application (601) even if there are underlying or connected systems that actually created the unique identifier (400). That is to say, that in this situation a plurality of applications that are coupled, linked or otherwise connected with other, the originating traceability application (601) is considered to be where the first point of entry for the unique identifier (400) that can be determined or discovered, even thus the originating traceability application (601) per se might not be the creator of the unique identifier (400). The definition of the traceability application used by the invention is then expanded to also encompass an application that manages said unique identifier (400) by having been delegated authority and ascendancy of a system that originally created and originated the unique identifier (400).

[0108] Another problem with prior art that is solved with the current invention relates to the contextual information that is particularly related to a given user. This information is what has the highest information density about how the application should behave since this contains the “wishes”, preferences and chosen configuration parameters of the user. However, this creates a problem for prior art since this information must be considered sensitive and shall to the least possible extent be stored outside the application. This fact might limit in practice the -contextual information accessible by the redirector as described in prior art.

[0109] There are no such limitations for the current invention since this contextual information is used and processed by the originating traceablility application (601) or client application (201).

[0110] Moreover, in the current invention, the traceability application (601), once having made the connection (606) with the client based on the unique identifier (400)affirmativeresponse (808) only, can, during the communication and session, ask for this type of information to drive the response and interaction forward.

[0111] In other words, even the current invention can make use of external contextual information from the user and client, the basic technical effect is to find, locate access the right and originating traceability application (601), and realize that once this is achieved the originating traceability application (601) itself will handle the remainder of the communication essentially in the same way if the unique identifier (400) and product (401) in fact had a native resource address to the originating traceability application directly.

[0112] Reference numbers

[0113] Advantages over background art Serialization and unique codes for every single product item is now getting increasingly prolific. Regulations and new standards for serialization and track and trace are now in 2024 one of the drivers for the demand, development and use of such systems. For instance is the European Digital Product Passport (DPP) such an upcoming regulation. This has created an emerging industry for specialized companies that develop and operate serialization and trace and trace systems for brands and manufacturing companies. This however creates a new problem where a consumer or participants in the supply and logistical chain must relate to a huge number of such vendors handling serialization on behalf of a large number of companies and the associated products items they manufacture and sell. The problem arises because when there are so many providers of such systems the users of them will simply get lost in the "serialization and track and trace jungle." Formally it might not be strictly technically correct - but one way to illustrate the problem is to consider the following scenario: If there are 20000 companies (small as well large) that are serializing their products, will a consumer have to download 20000 different serialization / tracking apps from each company in order to scan the unique codes on their product items ? It is quite clear that for this to work as a larger and efficient system for the participants some technical adaptations are required. The "workload" the consumer and other participants must be reduced to a minimum for such a system to work in practical terms.

[0114] Imagine a user that buys say 50-200 different product items from different manufacturers within a month. The user now wants, based on a unique identifier of the serialized product item, or might even be required by regulations, to interact with the originating (or managing) traceability system for the unique identifier (and thus the serialized product) for various purposes. To find out which traceability system to connect to directly (even though possible) from a myriad of brands and their associated tracking and tracing systems, and further again their associated third party systems (a system B type system) will be an overwhelming and a daunting task. Not scalable in practical terms. Brands and product types are in their millions and tracking and tracing systems will maybe be their hundreds or even thousands. It is evident that for this critical product tracing to work as a "ecosystem" for DPP and similar regulations and purposes, the serialized product item itself must be able to provide information so as for facilitating a user client to be automatically connected to the originating traceability application and a user related database without the user having any special knowledge of the user client system.

[0115] Prior art does not describe a physical product item or package where the unique identifier (400) itself is used to autonomously find and locate its originating traceability application (one 601 among many 602's) (601) among hundreds or even possibly thousands of traceability applications (602). In the current invention the unique identifier / code on the product item and one resource for the director (500) is sufficient. Thus a user / client will with this invention be able to use federated functions and access data for the same across several independent systems after first locating the original traceability system.

[0116] US 9,794,321 Trifa et al. relates to a computing system, and a redirector with a rules database, configured to receive an object identifier and contextual information from a client application. Based on that object identifier and the rules database and the contextual information that is analyzed against a predefined set of rules, the redirector maps the object identifier and the contextual information to a deduced entry point associated with a specific computer application among a plurality of applications. Then access is provided to said specific computer application to the client application and user.

[0117] In contrast to Trifa, the below mentioned US patent publication US2023 / 0360093A1 with inventor Magnar L0ken solves several major problems related to Trifa: Trifa is using a rules database that based on these rules routes a request from a user to an application amongst several other potential applications. However Trifa does not use a unique serial code on the product item itself to locate or determine the originating application. Further it never inquires a potential originating traceability application prior to sending the request to the application selected by the rules database.

[0118] The present invention relates to operate federated functions and related federated data use / exchange / creation between two independent computer systems, wherein there are two different user identities managed by two independent computer systems respectively, a first user identity on a first server and a second user identity on a second server, but where the two user identities actually representing the same user and user identity accessing the functions from a client. A system and method for setting up such a data exchange line is described in US patent publication US2023 / 0360093A1 with inventor Magnar L0ken. A Same User in the context of this description and invention is a user that has one single identity, that have several different and independent user profiles managed in two or more independent computer systems where these user profiles are based on or is rooted in the same user identity.

[0119] This means that for instance a given person Anna Smith that has a specific social security number, say, will be her Identity (Same User). However Anna Smith can have several different user profiles such as for instance for streaming on Netflix as well as having another user profile for her internet banking account both based on her identity.

[0120] Note. With in a given computer system it is quite normal to denote and associate Anna Smith and her user profil with a suitable identity, (an internal system ID) - say UserlD=6878T4356. However in the context of this invention this strictly would be method and parameter to recognize and manage this particular specimen of the same user profile within the system for Anna Smith (her identity).

[0121] In one aspect of Magnar L0ken's patent publication US2023 / 0360093A1, it solves a problem represented by the problem that user identities shall mutually not be exchanged between the first and the second server, and that problem does not necessarily be present here. But it further describes a method and system for establishing an intermediate user identity which may be recognized or resolved as the first user identity by the first server, and recognized or resolved as the second user identity by the second server. For example a track and trace application, a so-called traceability application has product item-related data such as manufacturing and packaging data, transport related data, customs related data, re-packaging and repackaging location data, storage and storage location data, sales point data and even data related to ownership when purchased.

[0122] But the traceability application, which may be a Brand Owner's track & trace application for the serialized product item with its unique identifier code, would not typically contain any user profile and the user's relation to the retailer / vendor.

[0123] The retailer / vendor may have a user database with millions of users, each user having its user I identity, with a user profile with age, martial state, nationality, state address, phone number, e-mail address, member status, user preferences, a record of previously purchased items, including possibly previously items of the same type as the presently requested serialized product item, discounts based on previous purchased items, etc., which are data controlled by the retailer / vendor server. The retailer / vendor's user database shall not contain all the track & trace information which belongs in the traceability application based on the unique identifier of each serialized product item. The user database may even be owned by the retailer / vendor, but the owner just wants to keep the user database and the traceability application separate. There are both technical as well as legal and other reasons for a brand owner to operate a "private" consumer database system separated from a serialization and track and trace system. Separation here shall be understood as two systems under the management and control of the brand owner (manufacturer) however they have a technical separation. However this type of separation is a limitation if the brand owner wants to facilitate federated functions to the consumer / user across these two independent systems. Also such a consumer system can be independent to even a higher degree outside the brand owners control. Imagine Company Alfa is operating a serialization system for product A, but has an agreement with Company B to, for certain products, facilitate federated functions and federated data for a mutual consumer, this is not possible with background art in the field of serialized product items.

[0124] An advantage of the invention described in Magnar L0kens US patent publication, two computer systems may exchange / share data in order for their combined data to be used as transient; a single amalgamated data source in the communication related to the user. For the consumer / user and client this interactions may appear seamlessly as one source.

[0125] A further problem to the user and / or the client is, when the the user's client, e.g. a handheld computer such as a smart phone, having scanned or read a unique identifier code on a truly serialized product item, how to efficiently find the originating traceability application which has issued or is managing the unique identifier code?

[0126] In this "ecosystem" a user client will have the need to use an autonomous serialized product item to find and connect to the originating application, but also further couple the originating application with other de facto independent systems / applications in order to provide the necessary across systems data and functions as provided in the given examples. Within the context of this invention and description Same User Federated Functions are functions processed conjointly by two independent computer systems where each independent data set for the same user in each independent computer system are transiently amalgamated as one single data source as function input.

[0127] Same User Federated Generated Data are data sets created by Same User Federated Functions.

[0128] So an advantageous achievement of the invention is

[0129] - to find an originating traceability application amongst a plurality of potential traceability applications for a given / scanned unique identifier (400) on a product item (401).

[0130] - to transiently couple and access data sources across independent computer systems A (601) and B (900) for a user client (200) / system ,

[0131] - and further enable and facilitate federated functions across those same systems using this coupled data source.

[0132] These federated functions will also generate new data and data sets that will be managed between the systems.

[0133] The term product item (401) may be rather widely defined, it may not necessarily be a serialized, uniquely identified tin can (401) with a unique identifier (400), a uniquely identified aircraft spare part (401), a uniquely identified transportation pallet (401), shipping container (401), packaging box (401) or any other transportation unit.

[0134] Examples

[0135] Imagine that a user / consumer (205) has a user profile (202) in a customer- related computer system (900). Regardless of being logged in on the customer-related computer system (900),

[0136] [or not (then the user should sooner or later log in on the customer-related computer system (900) when an originating traceability system has been found)],

[0137] - The user has a user client (200) which is arranged to scan unique identifiers (400) on serialized product items (401).

[0138] Specifically when based on the present inventor's redirector (500) use: The user's client (200) has scanned the unique identifier (400) of a product item and sent the unique identifier (400) in an initial request to the redirector (500) which in turn via the subsequent request eventually has found the originating traceability application (601) for the unique identifier (400). See claim 1 below.

[0139] Imagine that the consumer's client (200) has been connected to the originating traceability system (601),

[0140] - there is a function in the system (in originating traceability system (601) or in the user client (200) [or in the system (B) for securing to the user (205) a warranty extension for a given product. - The consumer (205) is qualified in the originating traceability application (601), system A, except for one last criterium: The function requires that the consumer must have a resident address within the state of Colorado (in other words the function it will check that this is the case)

[0141] The data regarding residential addresses is not available in the originating traceability system (601), system A.

[0142] However using the invention this data is available within the customer-related computer system (900) with a user profile (202) for the user (205), system B. By using the invention and coupling the two independent data sources data by federating them, the function can now be processed.

[0143] The outcome "yes - resident of Colorado" will be stored and managed in A, B or both for later reference, and a transaction may take place.

[0144] In order to complete the transaction, having used the client, scanned the unique code and the network director finds the serialized product item in the originating traceability application, which may hold track and trace of the product item, such as the location, the list price, customs related data, and warranty rules related to the product, user age restrictions, whether the product is recalled, etc., the user of the client must, e.g. as part of a product warranty to be valid according to warranty regulations of Colorado, have a resident address within the State of Colorado. Such State of Residence information about the buyer is normally not found in the code originating or managing track & trace database related to the serialized product item itself, "system A", but may be found in the customer related database "system B" based on the User identity (205) and her user profile (202) which would hold the name, postal address, residence address, which would be relevant here, date of birth, and a purchase history record of many various products obtained in purchases involving "System B".

[0145] Or the user of the client in a similar situation to the one outlined above, in order to have legal access to buy the uniquely code marked product item, e.g. alcohol, in the State of purchase, be 20 years or more. Such additional information about the buyer is not found in the code originating or managing track & trace database related to the serialized product item itself, "system A", but may be found in the customer related database "system B" based on the User identity (205) and her user profile (202) which would hold the name, address, date of birth, which would be relevant here, and a purchase history record of many various products obtained in purchases involving "System B".

[0146] For the user on the user client - the experience is seamless across the various computer systems and their data sources.

[0147] With upcoming regulations that also involves tracing of products for recycling, such as Digital Product Passport in Europe (DPP) mentioned above, this invention makes it efficient for a consumer / user / client to interact with the originating system as well as any number of any other related systems that might have functions and data about the user client that can be invoked by the unique identification / serialized code carried by the the serialized product item. Methods for doing this without exchanging user identifications and non- shareable parts of user profiles internal to these systems are important. One method for managing this is described in the above mentioned Magnar L0ken's patent publication US2023 / 0360093A1. A difference from background art where data for a user client is exchanged over two independant computer systems, is that for the present invention, the originating traceability application (601), the first system A, e.i. is initially not "known" or otherwise identified by the user or the user client (200) when the unique identifier is scanned, nor when the initial request from the user system / client (200) is initially transmitted / sent to the redirector (500). This is to say that with a serialized product item for which the user client does not know about the originating traceability systems, the redirector (500) is necessary for facilitating the connection with that originating traceability application (601), "system A". Subsequently the found originating traceability application (601), so-called "System A" may provide an address to the customer related database (900), independent system B, and connect it with the user client (200).

[0148] So a problem solved is how to connect a user client (200) and two independent systems , a known unique identifier code's (400) initially unknown code originating application (601) "system A", and a customer related database (900) "system B", without initially knowing which systems that are involved when the user client (200) reads the unique identifier (400), nor when sending the initial request to the redirector (500) for finding an originating traceability application (601) as per providing the unique identifier of the product item.

[0149] A client (200) in this context might be any computer implemented systems that might scan and forward a product item code. For instance this might be the case at a tracking point such as a loading dock or similar where the code is user for tracking and tracing, or a smart phone carried by the user and able to connect to the redirector (500) on a web address (700).

[0150] The federated function(s) that is / are processing the federated data source might be residing in the originating traceability system (601) and the new data generated by the combined function might be managed by the originating traceability system (601). It is also possible that the federated function is native to the user client (200) application or the customer-related computer system (900), or managed through a combination of the above.

Claims

CLAIMS1. A method for establishing or facilitating a network connection (606) between a client (200) and an originating traceability application (601) and further between said originating traceability application (601) and a customer-related computer system (900) as well as between said customer-related computer system (900) and said client (200) in a network (101) and accessing and enabling processing data (650, 950) from said originating traceability application (601) and said customer-related computer system (900) by which said first and second data (650, 950) can be combined for the client (200), said method comprising:- providing a network director (500);- providing a list (550) of a plurality of resolvable network addresses (702) of a plurality of corresponding traceability applications (601 , 602);- providing a plurality of serialized product items (401), each associated with a unique identifier (400), each said unique identifier (400) originated or managed by an associated originating traceability application (601) within said plurality of said traceability applications (602), all said serialized product items (401) associated with a common network address (700) to said network director (500), a) said network director (500) receives an initial request (300) comprising said unique identifier (400) from a client (200), b) said network director (500) sends a subsequent request (302) comprising said unique identifier (400) to one or more of said network addresses (702) of said corresponding traceability applications (602, 601), for the purpose of receiving a response (800) whether said traceability application (602, 601) recognizes said unique identifier (400) as originated by said traceability application (602, 601) now recognized as the originating traceability application (601), c) if said response (800) to said subsequent request (301), is a positive or affirmative response (808), then d) said network director (500) establishes a connection (606) between said requesting client (200) and said originating traceability application (601); wherein e) said originating traceability application (601) establishes a connection (606) to a customer-related computer system (900);f) said customer-related computer system (900) establishes a connection to the client (200); g) said originating traceability application (601) and said customer-related computer system (900) exchange data (650, 950), h) said data (650, 950) being processed by a federated function (960) thereby generating additional data (961).

2. The method of claim 1, wherein said federated function (960) originates in either the customer-related computer system (900) or the originating traceability application (601).

3. The method of claim 2, wherein if said response (800, 801) is negative ("no") (801), disregard said response (800, 801).

4. The method of any of claims 1-3, wherein each traceability application (602, 601) receiving said subsequent request (302) will itself analyze said unique identifier (400) to determine whether it can resolve said unique identifier (400) thereby identifying as an originating application (601) of said unique identifier (400), or reject I disregard said subsequent request (302).

5. The method of any of the preceding claims, wherein said director (500) is arranged to send said subsequentrequest (302, 301) one by one to of each traceability application (602, 601) in said list (550); until said response (800, 801 , 808) is an affirmative response (808), and- then not send further subsequent requests (302) to further traceability applications (602) in said list (550).

6. The method of claim 5, wherein said subsequent request (302, 301) to said application (602) includes contextual information (333), said contextual information (333) comprises an instruction (333, 334) to not return a negative response (801) in case said traceability application (602) is not an originating traceability application (601) of said unique identifier (400).

7. The method of any of the preceding claims, wherein, if an affirmative response (808) has not been received when said list (550) of traceability applications (600) is exhausted, then- return a response (800, 820) indicating "originating traceability application (601) not found” to said client (200).

8. The method of any of the preceding claims, said method managing unique identifiers (400) and aggregated track and trace information based on said unique identifier (400), whereby said traceability application (602, 601) conducts the steps of: a) receive contextual information (333) pertinent and applicable to said subsequent request (302, 301) itself together with said unique identifier (400); b) compose a response (800, 808) according to and based on internal rules and instructions associated with said unique identifier (400) and / or said received contextual information (301 , 333).

9. The method of claim 8, wherein said unique identifier (400); and said network address or location (700) are included in a QR code or similar scannable label on said serialized product item (401).

10. The method of any of claims 1-, wherein said network director (500) is arranged to send said subsequent requests (302, 301) simultaneously to all traceability applications (602, 601) in said list (550).

11. The method of claim 10, wherein said subsequent request (302, 301) to said traceability application (602) includes contextual information (333) comprising an instruction (333, 334) to not return a negative response (801) in case said traceability application (602) is not an originating traceability application (601) of said unique identifier (400).

12. The method of claim 11 , wherein, if an affirmative response (808) has not been received when said list (550) of resolvable network addresses / locations (702) directing to traceability applications (600) is exhausted, then- return a response (800, 820) which is a unique identifier (400) originating traceability application (601) “not found” response (820) to said client (200).

13. The method according to claim 12 said method managing unique identifiers (400) and aggregated track and trace information based on said unique identifier (400), whereby said traceability application (602, 601) conducts the steps of: a) receive contextual information (333) pertinent and applicable to said subsequent request (302, 301) itself together with said unique identifier (400); b) compose a response (800, 808) according to and based on internal rules and instructions associated with said unique identifier (400) and / or said received contextual information (301 , 333).

14. The method of claim 13, wherein said customer-related computer system (900) comprises a first user profile (910) associated with a user (205), said first user profile (910) comprising said second set of data (950).

15. A system of transiently coupling data sources across independent computer systems using a unique identifier, such system comprising, assigning a unique identifier (400) to a serialized product item (401) such that, when said unique identifier (400) is read or scanned by user client (200), such unique identifier (400) is transmitted by an initial request (300) to a network director (500), said network director (500) having a list (550) of network addresses (702) to a plurality of traceability applications (602), such that said network director (500) is arranged to send a subsequent request (302) containing said unique identifier (400) to one or more traceability applications (602) on said list (550) wherein each traceability application (602) attempts to identify said unique identifier (400) as originating from or managed by said traceability application (602) until one of said traceability applications (602), an originating traceability application (601) identifies said unique identifier (400) and responds affirmatively (808) to said network director (500),and as a result to said affirmative response (808), said network director (500) is arranged to establish a direct connection (606) between said originating traceability application (601) and said user client (200), such that said user client (200) is enabled to transmit data to said originating traceability application (601), and said originating traceability application (601) is enabled to transmit data (650) back to said user client (200), enabling said originating traceability application (601) to process additional data (950) from a customer-related database (900) and provided a federated response to said user client (200).

16. A system according to claim 15, wherein the additional data (950) from said customer- related database (900) comprises data from a user profile (202) for the user (205) of said client (200).

Images