FR3102283A1 - DEVICE, SYSTEM AND METHOD FOR PROVIDING SUPPLIER OBJECTS FROM AN ANTIMEMORY - Google Patents

Abstract

A device, system and method for providing provider objects from a cache memory are provided. The received provider objects represent the items provided by the provider systems. Provider objects are categorized based on their reusability and / or context characteristics and are stored as categorized. A request is received for one or more items provided by said or more provider systems. A stored and categorized provider object is determined to meet criteria associated with the query, including one or more respective reusability and context characteristics of the provider object. In response to determining that the provider object, which meets the criteria, is believed to be currently valid, a response corresponding to the provider object is provided.

Description

DEVICE, SYSTEM AND METHOD FOR PROVIDING PROVIDER OBJECTS FROM A CACHE

Domain

The specification generally relates to databases, and more specifically to an apparatus, system, and method for providing provider objects from a cache.

Context

The provision of various products including, for example, travel-related goods and services (eg, flights, hotel reservations, and the like) typically requires that various discrete entities exchange data defining various aspects of the products. Examples of such entities, in the context of travel-related products, include airlines, travel agencies, end users, reservation systems and the like. Although these entities can be configured to exchange data in a standardized format, (e.g. according to the New Delivery Capability (NDC) standard based on XML Extensible Markup Language in the context of travel-related products), however, they may employ different mechanisms to initiate the data exchange.

Summary

One aspect of this specification provides a method comprising: receiving, at one or more servers, provider objects representing items provided by one or more provider systems; categorizing, on said one or more servers, provider objects by one or more reusability and context characteristics; storing, on said one or more servers, on one or more memories, the provider objects as categorized; receiving, on one or more servers, from a requesting device, a request for said one or more items provided by one or more provider systems; determining on said one or more servers that a provider object, stored on said one or more memories, meets the criteria associated with the request, including one or more respective reusability and context characteristics of the provider object; and in response to determining that the provider object, which satisfies the criteria, is deemed to be currently valid, providing, by one or more servers, to the requesting device, a response corresponding to the provider object.

In some embodiments, categorizing the provider objects by reusability includes: categorizing the provider objects by one or more of the respective characteristics and respective combinations of one or more respective elements represented by the provider objects; and determining that the respective reusability of the provider object meets the criteria associated with the request comprises: determining that the provider object represents one or more of the same characteristics and a same combination of said one or more elements requested by the request .

In some embodiments, categorizing provider objects by context characteristics includes: categorizing provider objects by one or more respective contexts in which a respective provider object was requested, personalization, geographic location, type of customer and a category of respective items represented by the provider objects; and determining that the respective context of the provider object satisfies the criteria associated with the request comprises: determining that the provider object represents one or more of a same respective context of the request, a same personalization, a same geographical location, the same type of customer and the same category of said or several elements requested by the request.

In some embodiments, determining that the provider object, which satisfies the criteria, is estimated to be currently valid includes: determining that a current time does not exceed one or more of an estimated expiration time and a Estimated Time-To-Live (TTL) value of the provider object.

In some embodiments, the method further comprises: using, on said one or more servers, a reusability-determining machine learning model and a context-determining machine learning model to respectively categorize objects provider by reusability characteristics and context.

In some embodiments, the method further includes: using, on the one or more servers, a machine learning model of validity estimation to determine that the provider object is estimated to be currently valid.

Another aspect of this specification provides a server comprising: one or more memories; a communication interface; and a controller configured to: receive, via the communication interface, provider objects representing items provided by one or more provider systems; classify provider objects by one or more reusability and context characteristics; storing, at said one or more memories, the provider objects as they have been categorized; receiving, via the communication interface, from a requesting device, a request for one or more items provided by said one or more provider systems; determining that a provider object, stored in said one or more memories, meets the criteria associated with the request, including one or more respective reusability and context characteristics of the provider object; and in response to determining that the provider object, which satisfies the criteria, is deemed to be currently valid, providing the requesting device, via the communication interface, with a response corresponding to the provider object.

In some embodiments, the controller is further configured to categorize the provider objects by reusability by: categorizing the provider objects by one or more of the respective characteristics and respective combinations of one or more respective elements represented by the objects supplier; and determining that the respective reusability of the provider object satisfies the criteria associated with the query comprises: determining that the provider object represents one or more of the same characteristics and a same combination of said one or more elements required by the query .

In some representation modes, the controller is further configured to categorize provider objects by context characteristics by: categorizing provider objects by one or more of a respective context in which a respective provider object was requested, a personalization, a geographic location, a type of customer and a category of respective items represented by the provider objects; and determining that the respective context of the provider object satisfies the criteria associated with the request includes: determining that the provider object represents one or more of a same respective context of the request, a same personalization, a same geographical location, the same type of customer and the same category of said or several elements requested by the request.

In some embodiments, the controller is further configured to determine whether the provider object, which satisfies the criteria, is deemed to be currently valid by: determining that a current time does not exceed one or more estimated expiration and an estimated Time-To-Live (TTL) value of the provider object.

In some embodiments, the controller is further configured to: use a reusability-determining machine learning model and a context-determining machine learning model to categorize provider objects based on reusability and context characteristics, respectively .

In some embodiments, the controller is further configured to: use a validity estimation machine learning model to determine that the provider object is estimated to be currently valid.

Another aspect of this specification provides a computer-readable durable medium storing a computer program, wherein execution of the computer program is to: receive, on one or more servers, vendor objects representing provided items by one or more provider systems; categorizing, on said one or more servers, the provider objects by one or more reusability and context characteristics; store, on said or more servers, on one or more memories, the supplier objects as categorized; receiving, on one or more servers, from a requesting device, a request for one or more items provided by one or more provider systems; determining on one or more servers that a provider object, stored on one or more memories, meets the criteria associated with the request, including one or more respective reusability and context characteristics of the provider object; and in response to determining that the provider object, which satisfies the criteria, is currently deemed valid, providing by one or more servers, to the requesting device, a response corresponding to the provider object.

In some embodiments of the computer-readable durable medium, categorizing vendor objects by reusability includes: categorizing vendor objects by one or more of respective characteristics and respective combinations of one or more respective elements represented by the provider objects; and determining that the respective reusability of the provider object meets the criteria associated with the request comprises: determining that the provider object represents one or more of the same characteristics and a same combination of said one or more elements required by the request .

In some embodiments of the non-computer-readable durable medium, categorizing provider objects by context characteristics includes: categorizing provider objects by one or more of a respective context in which a respective provider object has been requested, a personalization, geographic location, customer type, and category of respective items represented by the vendor objects; and determining that the respective context of the provider object satisfies the criteria associated with the request comprises: determining that the provider object represents one or more of a same respective context of the request, a same personalization, a same geographical location, the same type of customer and the same category of said or several elements requested by the request.

Another aspect of this specification provides a computer program product comprising program code instructions stored on a computer readable medium for performing the method steps according to any of the method aspects and realization set forth above when said program runs on a computer.

For a better understanding of the various examples described herein and to show more clearly how they can be implemented, reference will be made, by way of examples only, to the accompanying drawings in which:

illustrates a system for providing provider objects from a cache, according to non-limiting examples.

illustrates an example structure of one or more servers for storing and providing provider objects, according to non-limiting examples.

illustrates a method for providing provider objects from a cache, according to non-limiting examples.

illustrates the system of FIG. 1 machine learning training modules for providing provider objects from a cache, according to non-limiting examples.

illustrates the system of FIG. 1 categorizing provider objects for storage in a cache, according to non-limiting examples.

illustrates the system of FIG. 1 providing a provider object to a requesting device based on a current validity of the provider object, according to non-limiting examples.

illustrates examples of provider objects as categorized, according to non-limiting examples.

detailed description

FIG. 1 depicts a system 100 for providing provider objects from a cache. Supplier objects, in the examples set forth herein, may include data objects and/or data records that correspond to products and/or items, such as travel-related goods and services (eg. g., flights, hotel reservations, vehicle rentals, and the like), provided by a provider system. More specifically, the products and/or items set forth in the examples below may be airline tickets and related services (e.g. checked baggage services, in-flight food, entertainment, and the like). However, the systems and methods discussed below can also be applied to various other types of data objects and/or elements.

Delivery of the items mentioned above is typically controlled by a supplying entity, such as an airline in the case of the items mentioned in connection with the examples provided herein. System 100 includes one or more vendor systems 104 (e.g., one or more servers or other appropriate computing devices) which in this example are managed by one or more vendor entities. System 100 may include a plurality of supplier systems 104, each managed by a respective supplier entity (eg, other airlines), although only one supplier system 104 is shown by way of example. Supplier objects may be in any suitable format including, but not limited to, Edifact recommendations in the context of a Global Distribution System (GDS) based data exchange, bid records in the context of data exchanges based on the New Delivery Capability Standard (NDC) and/or any other appropriate format. Indeed, supplier objects may include data objects and/or data records, storing for example an Edifact recommendation or an NDC offer and/or any other relevant data representing at least one element provided by the supplier system 104 .

Each Supplier Object defines an item, or a combination of items that may be offered for purchase (e.g. by end users of the items) including but not limited to one or more of flights, rail travel, hotel accommodation, airport lounge access, seat upgrades, checked baggage service, in-flight food, entertainment and the like.

In the examples discussed below, each provider object may define a flight managed by the provider entity and/or ancillary services associated with the flight. Each provider object therefore contains various fields. Some fields define item attributes, such as product object identifiers (e.g. service identifiers, item identifiers, product identifiers, and the like), locations, dates, and schedules corresponding to the products (e.g. flight schedules and other itinerary data). The type of fields and/or data of a provider object can depend on a type of provider object. For example, supplier objects corresponding to flights may include flight identifiers, while supplier objects corresponding to other travel-related items such as a train travel offer, hotel, access to airport lounge and/or an offer for an upgrade to a premium seat, may include information related to train travel, hotel, lounge, premium seat, etc.

As will be described below, system 100 further includes network 116 and brokerage server 120. Network 116 includes any combination of local and wide area networks, including the Internet, such that components of system 100 can communicate. Intermediation server 120 generally acts as an intermediary between client device 112 and supplier system 104, so that, for example, client device 112 can request products from supplier system 104 and/or more than one provider system 104, via intermediary server 120.

As described, system 100 further includes a cache server 121 that caches and/or stores provider objects received from various sources in system 100 including, but not limited to, provider system 104. as will be explained below, cache server 121 further provides responses that include provider objects stored in a cache to a requesting device, such as client device 112, for example, via broker server 120 While servers 120, 121 may be two separate devices, the functionality of servers 120, 121 may be combined into one server 125 and/or implemented in a cloud environment using a plurality of servers and/or one or more multiple servers.

As illustrated, cache server 121 maintains cache and/or memory 126 which may be implemented as one or more memories. Memory 126 contains vendor objects as received at cache server 121 from various vendor object sources in system 100. Cache server 121 may implement machine learning models to categorizing the provider objects by one or more reusability and context characteristics, and storing the provider objects in memory 126 as categorized; cache server 121 may also determine whether a stored and categorized provider object is currently valid, as described in detail below.

In the present example, the client device 112 may be operated by a travel agent entity and therefore generate and transmit requests for vendor objects (e.g., representing purchasable products) to the provider 104, via intermediation server 120, on behalf of end users (eg travelers). System 100 may include a plurality of client devices 112, although only one client device 112 is shown in FIG. 1 for illustration. Stated another way, broker server 120 mediates between client device 112 and provider system 104 and receives requests from client device 112.

As will be explained in more detail below, in some examples, before brokerage server 120 requests a provider object from provider system 104, which corresponds to at least one item provided by the provider system 104, the intermediation server 120 may request the provider object from the cache server 121 which determines whether a provider object, stored in the memory 126, satisfies the criteria associated with this request, including one or more respective characteristics of provider object reuse and context.

Further, when it is determined that a provider object stored in memory 126 meets the criteria, cache server 121 may judge whether the provider object is deemed to be currently valid. When the provider object is deemed to be currently valid, cache server 121 provides the provider object to intermediation server 120 which passes the provider object to client device 112 in response to the request.

Therefore, provider objects already received, stored, and categorized can be used, by intermediation server 120, to respond to the request, rather than requesting a provider object that satisfies provider system 104's criteria. such an example may reduce the query response time compared to the query of a provider object that satisfies the criteria of the provider system 104. In addition, such an example may further reduce the bandwidth usage between the intermediation server 120 and the provider's system 104, as well as reducing the processing resources of the provider's system 104, such as by generating another provider object that meets similar criteria used to previously generate a provider object (p eg, the provider object stored in memory 126 used to respond to the request).

In still other examples, brokerage server 120 may first request provider objects that meet the criteria for a request from provider system 104. When provider system 104 does not respond within a period of time given threshold (which may be a fixed time period and/or a dynamic time period based on historical response times for provider system 104 at the time provider objects are requested), brokerage server 120 may communicate with cache server 121 to provide client device 112 with a provider object that satisfies the criteria of the request. In such instances, the provider system 104 may be down and/or busy and therefore such instances may again reduce the time to respond to a query compared to waiting for the response from the provider system. 104.

In general, requesting and/or ordering of items represented by provider objects occurs in system 100 via an exchange of messages, for example between intermediation server 120 and provider system 104. These messages may therefore be associated with provider objects and may include messages for one or more of: a request for provider objects; a query for other information associated with provider objects; providing provider objects; ordering items represented by provider objects, and the like.

Further, brokerage server 120 may provide vendor objects to client device 112 as received from vendor system 104 and/or brokerage server 120 may modify the vendor objects into another format.

As shown, system 100 further includes an event hub device 127 that can receive messages associated with provider objects from provider system 104. Event hub device 127 may include a surrogate for at least intermediation server 120 such that messages received by at least intermediation server 120 are received at event hub device 127. For example, when provider system 104 transmits a message and/or a response to intermediation server 120 that includes a provider object, the message and/or response may first be received at event hub device 127 and then forwarded to intermediation server 120. Stated differently, when provider objects are requested from a provider system, the provider objects may be pushed to the event hub device 127 to make them accessible to other components of the system 100, other than a current instance of the server intermediary 120, as will be described in more detail below. Indeed, event hub device 127 may be configured to receive messages and/or responses that include provider objects from all provider systems 104 of system 100. Such "traffic" may be "time real-time" and include messages generated due to provider objects requested by client device 112. However, in other instances, such traffic may not be "real-time"; in these examples, a component of system 100, such as a traffic generator which may be a component of intermediation server 120 and/or a separate component, and the like, may automatically and/or periodically request provider objects one or more supplier systems 104 via messages, for example to have a record of offers for flights to given destinations on particular dates; these requests can be transmitted and/or triggered by the intermediary server 120.

Cache server 121 generally receives from event hub device 127 provider objects generated by provider system 104 for storage in memory 126. For example, event hub device 127 may push messages and/or provider objects to cache server 121 and/or cache server 121 may request messages and/or provider objects from event hub 127 device.

As illustrated, system 100 further includes a machine learning model training system 129 that can receive messages from the event hub device 127, and generate machine learning classifiers for the implemented machine learning models. in cache server 121.

Before discussing the functionality of system 100 in more detail, certain components of cache server 121 will now be described in more detail with reference to FIG.2. While cache server 121 is described as a stand-alone device and/or separate from intermediation server 120, in other examples the functionality of cache server 121 may be distributed among other components of system 100 and/or the functionality of cache server 121 can be at least partially combined with intermediation server 120.

As shown in FIG. 2, cache server 121 includes at least one processor 220, such as a central processing unit (CPU), and the like. Controller 220 is interconnected to memory 222 storing application 223, memory 222 being implemented as a durable, computer-readable medium (e.g., a suitable combination of volatile and non-volatile memory subsystems including any one or more random-access memories (RAMs), read-only memories (ROMs), electrically-erasable programmable read-only memories (EEPROMs), flash memories, magnetic computer storage, and the like). The controller 220 and the memory 222 are generally composed of one or more integrated circuits (ICs).

Controller 220 is also interconnected to a communication interface 228 which allows cache server 121 to communicate with the other components of system 100 (i.e., brokerage server 120, hub device events 127, and the like) via the network 116. The communication interface 228 thus includes all the necessary components (e.g., network interface controllers (NICs), radio units, and the like) to communicate via network 116. The specific components of communication interface 228 are selected based on the nature of network 116. Cache server 121 may also include input and output devices connected to controller 220, such as keyboards, mice, monitors, and the like (not shown).

The cache server 121 components mentioned above can be deployed in a single enclosure or in a distributed format. Therefore in some examples, cache server 121 includes a plurality of processors which may either share memory 222 and communication interface 228, or which each have separate communication interfaces and associated memories.

As shown, memory 222 may include memory 126 (and/or a portion thereof). However, in other examples, the memory 126 can be external to the cache server 121 and can be accessed by the controller 220, for example via the communication interface 228. Indeed, the memory 126 can be distributed among all the components suitable for System 100.

Memory 222 also stores a plurality of computer-readable programming instructions executable by controller 220 as various applications, including application 223. Those skilled in the art will understand that controller 220 executes application instructions. 223 (and any other relevant application) in order to implement various actions defined by the instructions contained therein. In the description below, the controller 220, and more generally the cache server 121, are supposed to be configured to implement these actions. It will be understood that they are thus configured via the execution (by the controller 220) of the instructions of the applications stored in the memory 222.

Running application 223, as discussed below, configures cache server 121 to: receive vendor objects representing items provided by one or more vendor systems 104; categorize provider objects by one or more reusability and context characteristics; storing, on one or more memories 126, the provider objects as categorized; receiving, from a requesting device (eg, client device 112), a request for one or more items provided by one or more vendor systems 104; determining that a provider object, stored in one or more memories 126, meets the criteria associated with the request, including one or more respective reuse and context characteristics of the provider object; and in response to determining that the provider object, which satisfies the criteria, is deemed to be currently valid, providing the requesting device with a response corresponding to the provider object.

While application 223 may be implemented programmatically, in other instances application 223 may be implemented using machine learning models. In yet other examples, application 223 may combine a programmatic implementation with an implementation using machine learning models. Indeed, as shown, memory 222 further stores machine learning models ("MLMs") 235 which can be used, by controller 220, to categorize provider objects by one or more reuse and context characteristics. , and determine if a provider object is currently valid.

Machine learning models 235 may include models and/or algorithms based on neural networks and/or deep learning and/or machine learning, and the like, including but not limited to: a model generalized linear regression; a random forest model; a support vector machine model; a gradient boosting regression model; a decision tree model; a generalized additive model; evolutionary programming models; Bayesian inference models, reinforcement learning models, and the like. However, any suitable machine learning model and/or deep learning model and/or neural network model is within the scope of the present examples.

While the structure of Provider System 104, Client Device 112, Intermediation Server 120, Event Concentrator 127, and Machine Learning System 129 is not described in detail, Provider System 104, client device 112, intermediation server 120, event hub device 127, and machine learning system 129 may have a similar structure in cache server 121 but adapted to the respective functionality of provider system 104 , client device 112, brokerage server 120, event hub device 127, and machine learning system 129.

Attention is now directed to FIG. 3 which illustrates a flowchart representing a method 300 for providing provider objects from a cache. The operations of method 300 of FIG. 3 correspond to machine-readable instructions which are executed by the cache server 121, and in particular the controller 220. In the example illustrated, the instructions represented by the blocks of FIG. 3 are stored in memory 222 for example, such as application 223 (and/or machine learning models 235). The method 300 of FIG. is one possible way to configure controller 220 and/or cache server 121 and/or system 100. Further, the following discussion of method 300 of FIG. 3 will lead to a more advanced understanding of System 100 and its various components.

The method 300 of FIG. 3 need not be implemented in the exact sequence shown, and likewise the various blocks may be implemented in parallel rather than in sequence. Accordingly, the elements of process 300 are referred to herein as "blocks" rather than "steps". The method 300 of FIG. 3 may also be implemented in variations of system 100 of FIG. 1. In particular, while method 300 is described as being implemented by cache server 121, the functionality of cache server 121 may be combined into a single computing device that implements method 300. Otherwise, the functionality of cache server 121 may be distributed among a plurality of servers and/or computing devices that implement method 300; for example, a different computing device may be used to implement each computational learning model 235. As such, the blocks of method 300 may be implemented by one or more servers and/or computing devices.

In block 302, controller 220 and/or one or more servers receive vendor objects representing items provided by one or more vendor systems 104.

In some examples, provider objects may be received as messages (e.g., Extensible Markup Language [XML] format) associated with provider objects representing items provided by one or more provider systems 104. In some examples, messages may have more than one format. The messages may be associated with supplier objects which may include NDC offers or Edifact recommendations (e.g. conforming to a GDS format) and the like, and/or be in any suitable format; the message format may therefore depend on the capability of the provider systems 104 and/or message sources, and/or whether the provider systems 104 and/or message sources operate on a data exchange format based on NDC or GDS and/or another type of data interchange format.

Furthermore, the messages can be received from the device of the pole of events 127; indeed, the controller 220 and/or said one or more servers may receive all messages received at the event hub device 127. However, the messages may be received from any suitable message source in the system. 100.

In a block 304, the controller 220 and/or one or more servers categorizes the provider's objects according to one or more reusability and context characteristics.

In instances where categorization of Provider objects by reusability occurs, such categorization may include, but is not limited to: categorization of Provider objects by one or more of the respective characteristics; and respective combinations of one or more respective items represented by the vendor objects (e.g., the respective items comprising products provided by the vendor's systems 104; however, the respective items represented by the vendor objects may correspond to the criteria included in a request from client device 112 as described in more detail.

In instances where categorization by context characteristics of provider objects occurs, such categorization may include, but is not limited to: categorization of provider objects by one or more elements of a respective context in which an object respective provider was requested, customization, geographic location, customer type, and category of respective items represented by the provider objects. For example, a vendor object may be personalized based on a geographic location from which a request giving rise to a vendor object was received and/or whether the vendor object is intended for customers with a airline loyalty card and/or to customers with a particular airline loyalty status, and the like (e.g. a type of customer) and/or whether a provider object is public or private (e.g. to anyone , or for some customers).

For example, controller 220 and/or one or more servers may categorize provider objects using machine learning models 235.

In one example, a given machine learning model 235 may include a machine learning model determining reusability to categorize a provider object based on reusability, which may include, but is not limited to: categorizing the provider object by one or more respective characteristics of the provider object and respective combinations of one or more elements represented by the provider object. For example, the characteristics used to categorize the supplier object may be characteristics of the supplier object itself, such as a flight on a given day, as represented by the supplier object, the fact that the supplier object either for a particular class of seats on the flight (e.g. economy, premium, business, first, and the like), a passenger type code (i.e. whether the offer concerns an adult, a child, etc.), a number of baggage items included for the flight and the like, whether the offer is public (it can be open to everyone) or private (it can be open only to one particular person and/or to persons), and the like. So, for example, the supplier object for a given flight on a given day, for a given class and a given number of bags can be categorized as reusable for flight requests on the given day, for the given class and given number baggage; however, the supplier object cannot be reused for flight requests on the given day, for the given class but for another number of bags.

In another example, a given machine learning model 235 may include a context-determining machine learning model for categorizing a provider object based on characteristics of the context, which may include, but is not limited to: categorizing of the provider object by one or more of the respective contexts in which a respective provider object was requested, personalization, geographic location, customer type, and category of respective items represented by the provider object . In particular, provider objects provided by provider system 104 may be customized based on certain types of characteristics of a request for the provider object, such as the context characteristics listed above. For example, a given price of a vendor object and/or items offered by a vendor object, and the like, may be customized based on the context characteristics of a query for the vendor object (eg. a request that is issued from England for a given flight may result in a supplier object that is different from a request for the same flight that is issued from France); that is, a provider system 104 may implement a set of rules and/or context logic when providing a provider object in response to a request; categorizing a provider object based on characteristics of the context may include categorizing the provider object in a way that simulates (and similarly) the ruleset and/or context logic implemented by the provider system 104. This categorization may otherwise be referred to as segmentation in that a provider system 104 may provide provider objects in a segmented and/or contextual manner.

Accordingly, block 304 may include the use of a reusability-determining machine learning model 235 and a context-determining machine learning model 235 to categorize provider objects according to reusability and context.

In a block 306, the controller 220 and/or one or more servers store, in one or more memories 126, the objects of the supplier as categorized.

In block 308, controller 220 and/or one or more servers receive, from a requesting device, a request (e.g., message) for one or more items provided by said one or more provider systems 104. For example , a query can include criteria (eg, for a flight, such as origin, destination, date, and the like) that can be used to search for supplier objects stored in memory 126. These criteria may correspond, at least in part, to one or more categories of reusability and context characteristics based on which provider objects are stored in memory 126. A request for one or more items provided by one or more provider systems 104 may generally be generated by client device 112 (e.g., a requesting device may include client device 112) and received by intermediation server 120, which may request the item(s) provided by one or more provider systems 104 cache server 120. Thus, at block 308, a requesting device from which a request is received (p. ex. at cache server 121) may include client device 112 and/or broker server 120.

In a block 310, the controller 220 and/or one or more servers determine whether a provider object, stored in one or more memories 126, satisfies the criteria associated with the request, including one or more respective reuse and context characteristics. of the provider object.

For example, determining that the respective reusability of the provider object meets the criteria associated with the query may include: determining that the provider object represents one or more of the same characteristics and a same combination of said one or more of the elements requested in the request.

Similarly, determining that the respective context of the provider object meets the criteria associated with the request may include: determining that the provider object represents one or more of a same respective context of the request, a same personalization, the same geographical location, the same type of customer and the same category of the item(s) requested in the request.

When a provider object, stored in one or more memories 126, satisfies the criteria associated with the request (e.g., a "YES" decision at block 310), in a block 312, the controller 220 and/or one or more multiple servers determine whether the provider object that satisfies the criteria is currently deemed valid.

For example, a given machine learning model 235 may include a validity estimation machine learning model for determining a criticality and/or validity of a provider object which may include, but is not limited to, determining the current validity of the provider object. For example, a provider object may include a time-to-live (TTL) field that typically indicates a duration that a provider designates as the provider object's validity period (e.g., a duration, such as 30 minutes, during which a quoted price for a flight may be valid). However, provider objects may be valid longer than the TTL field lifetime; for example, a flight associated with the vendor object may occur six months after the date the vendor object was generated, and a quoted price may not change and/or expire for a given period of time that is longer than the duration of the TTL field (eg four months), and/or the period given may be based on loadings (eg flights) and/or seasonality. Therefore, in these examples, the machine learning model 235 can determine the criticality and/or a validity of a provider object by determining that a current time does not exceed one or more of a time expiration time estimated and an estimated (or unestimated) TTL value of a provider object. In fact, the terms "criticality" and "validity" can be used interchangeably.

Accordingly, method 300 may further include using, at controller 220 and/or one or more servers, a validity estimation machine learning model 235 to determine that the object of provider (stored in one or more memories 126) is deemed to be currently valid.

When the provider object that satisfies the criteria is judged to be currently valid (e.g., a "YES" decision at block 312), at block 314, controller 220 and/or one or more servers provide, at requesting device, a response corresponding to the provider object (eg, stored in one or more memories 126).

When the controller 220 and/or one or more servers determines, in block 310, that no provider object satisfies the criteria associated with the request (e.g., a "NO" decision in block 310) and /or when controller 220 and/or one or more servers determine, in block 312, that the provider object that satisfies the criteria is not currently valid (e.g., a "NO" decision in the block 312), in block 316 the controller 220 and/or one or more servers may request and receive from provider system 104 a provider object that meets these criteria. Unlike the rest of method 300, block 316 may be implemented by intermediation server 120 and not cache server 121. When a provider object meeting the criteria is received from provider system 104 (e.g., (instead of being retrieved from one or more memories 126), in another example of block 314, the controller 220 and/or one or more servers provide the requesting device with a response corresponding to the provider object received from the provider 104; in these examples of block 314, the middleman server may provide this response. Further, the provider object that meets the criteria may be received via event hub device 127 which provides the provider object to cache server 121 for storage in one or more memories 126.

Alternatively, block 316 may be implemented, prior to block 310, and when no response is received from the provider's system 104 within a threshold time period, block 310 may be implemented. Indeed, any appropriate criteria for intermediation server 120 to determine whether to request a provider object from cache server 121 or provider system 104 is within the scope of this specification. For example, broker server 120 may include rules and/or instructions implemented by a controller thereof to determine when to request a provider object from cache server 121 or provider system 104. For example, a request from client device 112 may be highly personalized and/or personalized for a given user (e.g., client) and brokerage server 120 may implement rules that coerce a request for an object. highly personalized and/or personalized (e.g., based on query data) provider object to be requested from provider system 104. Similarly, a request from client device 112 may be for a high-quality provider object (e.g., as determined using predefined rules, which may include, for example, indicating that a longer response time is acceptable) and brokerage server 120 may implement rules that force requesting a high quality provider object from provider system 104 to be requested. However, any other caching server 121 bypass criteria are within the scope of this specification.

When no provider object meets the query criteria and/or no valid provider object meets the query criteria, the response returned at block 314 may be a null response.

Although certain aspects of the method 300 have been generally described with respect to one provider object provided in response to a request, it is understood that the method 300 may be used to provide multiple provider objects in response to a request. For example, cache server 121 may: determine (e.g., at block 310 and block 312) that a plurality of provider objects, stored in one or more memories 126, meet the criteria associated with the query , including one or more respective reusability and context characteristics of the provider object; and in response to determining that the plurality of provider objects that meet the criteria are deemed to be currently valid, providing the requesting device with a response corresponding to the plurality of provider objects. In still other examples, one or more servers may implement block 316 in parallel with block 310, block 312, and block 314, such that the plurality of provider objects provided to the requesting device include provider objects from said one or more memories 126 and supplier objects received from supplier's system 104. The rest of the method 300 can be adapted accordingly.

An example of the method 300 is described below, including an example of training machine learning models 235. Attention is first drawn to FIG. 4, which illustrates system 100, but without network 116. Rather FIG. 4 shows communication links between the components of the system 100 which are represented therebetween by double-ended arrows; these communication links may include network 116. Alternatively, FIG. 4 is similar to FIG. 1, with like components having like numbers. In particular, FIG. 4 illustrates an example of training machine learning models 235 as implemented on cache server 121.

FIG. 4, event hub 127 receives messages 401 from provider system 104 as described above. 401 messages, as depicted, include vendor and similar objects. The event hub 127 provides the messages 401 to the machine learning model training system 129 which generates the classifiers 436 for the machine learning models 235 and provides the classifiers 436 to the corresponding machine learning models 235 implemented on the cache server 121.

For example, as shown, the cache server 121 implements a machine learning model determining reusability 235-1, a machine learning model determining context 235-2, and a machine learning model estimating the validity 235-3. Thus, machine learning model training system 129 generates appropriate classifiers 436 for each of these machine learning models 235 implemented on cache server 121.

As shown, event hub device 127 may further provide provider objects 402 of messages 401 to cache server 121. While provider objects 402 are shown as different from messages 401, provider objects 402 can be received from cache server 121 as 401 messages.

Attention now turns to FIG. 5 and FIG. 6 which illustrates an example of the method 300.

Attention is first directed to FIG. 5, which is substantially similar to FIG. 4 but without the machine learning model training system 129, with similar components having similar numbers. FIG. 5 shows cache server 121 receiving (e.g., block 302) two provider objects 402-1, 402-2.

As shown, cache server 121 implements machine learning models 235-1, 235-2 to categorize (e.g., block 304 of method 300) provider objects 402-1, 402-2 according to reusability and context characteristics.

As shown, machine learning model 235-1 categorizes provider object 402-1 into an "A" category of reusability, and categorizes provider object 402-2 into a category "B" of reusability . Similarly, machine learning model 235-2 categorizes provider object 402-1 according to category "A" of context characteristics, and categorizes provider object 402-2 according to category "B" of characteristics of context. Although such an example is simplistic, it is understood that machine learning models 235-1, 235-2 can categorize provider objects 402-1, 402-2 according to any appropriate category of reusability characteristics and/or context and/or any other appropriate category (e.g. as indicated by machine learning classifiers 436). A vendor object 402 may be categorized into more than one category; more detailed examples of provider objects, as categorized, are described below with respect to FIG. 7.

For example, cache server 121 may categorize provider objects 402-1, 402-1 by reusability by categorizing provider objects 402-1, 402-1 by one or more of respective characteristics and respective combinations of one or more respective elements represented by provider objects 402-1, 402-1.

Similarly, cache server 121 may categorize provider objects 402-1, 402-1 by context characteristics by categorizing provider objects by one or more of a respective context in which a respective provider object 402 -1, 402-1 was requested, a customization, geographic location, customer type, and category of the respective items represented by provider objects 402-1 and 402-1. Indeed, as described above, categorizing provider objects 402-1, 402-1 according to context characteristics may include categorizing the provider object in a way that simulates (and similarly) a set of rules/or context logic implemented by provider system 104. As also described above, this categorization may otherwise be referred to as segmentation because a provider system 104 may provide provider objects from one segmented and/or contextual way.

Additionally, while provider objects 402-1 and 402-2 are categorized based on their characteristics of both reusability and context, in other examples provider objects 402-1 and 402-2 may be categorized according to one or more reusability and context characteristics.

As shown, cache server 121 stores (e.g., at block 306 of method 300), in memory 126, provider object names 402-1, 402-2 as categorized. As shown, the Supplier Object 402-1 item is stored in association with the indicators of an "A" category of reusability and an "A" category of context characteristics. Similarly, the 402-2 provider object is stored in association with indicators of a category "B" of reusability and a category "B" of context characteristics.

While only two provider objects 402-1, 402-2 are shown as being stored and categorized in memory 126, any suitable number of provider objects 402 may be stored in memory 126, as categorized by the machine learning 235-1, 235-2.

Attention now turns to FIG. 6, which is substantially similar to FIG. 5, with like components having like numbers. In particular, FIG. 6 illustrates the cache server receiving (e.g., at block 308 of method 300), from intermediation server 120, a request 601 for one or more items provided by one or more provider systems 104, such as a theft, and the like. For example, as shown, the request was generated by client device 112 and forwarded to intermediation server 120 which provides request 601 to cache server 121. Request 601 may include criteria (e.g., for the flight, such as origin, destination, date, and the like) that can be used to search for supplier objects 402 stored in memory 126. These criteria may correspond, at least in part, to one or several categories of reusability and context characteristics according to which provider objects 402 are stored in memory 126.

In particular, rather than requesting a provider object that represents provider system item 104, intermediation server 120 may first use request 601 to request the item from cache server 121 which determines whether one or more provider objects 402, stored in memory 126, satisfy the criteria associated with request 601, for example one or more of the respective reusability and context characteristics of provider object 402.

As illustrated, cache server 121 determines (e.g., at block 310 of method 300) that provider object 402-1 satisfies the criteria associated with request 601.

For example, cache server 121 may determine that the reusability of provider object 402-1 meets the criteria associated with query 601 by determining that provider object 402-1 represents one or more of the same characteristics and same combination of one or more elements requested by request 601. However, as illustrated, cache server 121 may determine that the reusability of provider object 402-2 does not meet the criteria associated with query 601 by determining that provider object 402-2 does not represent one or more of the same characteristics and combination of one or more items requested by query 601. Although the present examples are described with relates to the reusability of a provider object meeting the criteria associated with query 601, in other examples, the reusability of more than one provider object may meet the criteria associated with query 601.

Likewise, cache server 121 may determine that the respective context of provider object 402-1 meets the criteria associated with query 601 by determining that provider object 402-1 represents one or more of a same (and/or similar) respective context of request 601, including but not limited to same (and/or similar) personalization, same (and/or similar) geographic location, same customer type (and/or similar) and the same category (and/or similar) associated with request 601 and/or said or several elements requested by request 601.

Cache server 121 estimates (e.g., at block 312 of method 300) the validity of provider object 402-1 using machine learning model 235-3 (e.g., and classifiers of machine learning 435-3). As shown, the 402-1 Provider Object is determined to be valid (e.g. "YES" the 402-1 Provider Object is valid)

In response to determining that provider object 402-1 meets the criteria associated with request 601 and that provider object 402-1 is valid, cache server 121 provides (e.g., at block 314 of the method 300) the provider object 402-1 to the intermediation server 120 which provides the provider object 402-1 to the client device 112, for example by transmitting the provider object 402-1 as message 401. Provider object 402-1 (e.g. message 401 which includes provider object 402-1) may also be received at the event hub device 127 and provided to the machine learning 129 for use in training machine learning models 235, as described above.

Although as shown, a single valid provider object 402-1 that meets the criteria of request 601 is provided to the client device 112, multiple valid provider objects 402 that meet the criteria of request 601 may be provided to the device. client 112, including but not limited to tens to hundreds of vendor 402 objects.

In instances where no valid provider object 402 that satisfies the criteria of query 601 is stored in memory 126, brokerage server 120 may request (e.g., at block 316 of method 300) the system to provider 104 provider objects 402 that meet the criteria of query 601.

In yet other examples, when a provider object 402 stored in memory 126 meets the criteria of request 601 but is determined to be invalid, intermediation server 120 may request provider system 104 for provider objects 402 that satisfy the criteria of query 601, for example to retrieve a newer version of provider object 402 stored in memory 126 that satisfies the criteria of query 601. In these examples, cache server 121 may provide a indicator of an invalid 402 object provider that satisfies the criteria of request 601 which may include an identifier of a provider system 104 that originally generated the now invalid 402 provider object so that the intermediation server 120 can retrieve a newer version of the invalid 402 vendor object based on the 104 vendor system identifier.

In yet other examples, brokerage server 120 may first request provider objects 402 that meet the criteria of request 601 from provider system 104. When provider system 104 does not respond within a given threshold time, the intermediation server 120 can request the provider objects 402 from the cache server 121.

Additionally, cache server 121 may update vendor objects 402 stored in memory 126. For example, vendor objects 402 stored in memory 126 may relate to specific items, such as a specific flight, and other similar. When another vendor object 402 is received (e.g., at block 302 of method 300) that represents a newer version of a vendor object 402 already stored and categorized in memory 126, the new version of a provider object 402 may be categorized and may replace provider object 402 already stored and categorized in memory 126, as described above (e.g., such that reusability, context, and/or validity characteristics are also updated).

The examples illustrated in FIG. 5 and FIG. 6 with respect to the categorization of Provider Objects 402-1, 402-2 into categories "A" and "B" are relatively simplistic. Therefore, attention turns to FIG. 7 which shows examples of provider objects 702 as categorized by machine learning models 235-1, 235-2 and which may be stored in memory 126.

While provider objects 702 are represented in tabular form, provider objects 702 can be saved in any suitable format. In the table shown, each row corresponds to a particular provider object 702, as categorized, with columns corresponding to various attributes and/or characteristics of the provider objects 702, including, but not limited to, characteristics associated with reusability and context characteristics. As shown, supplier object 702 corresponds to a flight offer, with columns defining, for the offers, a carrier ("CXR") of a flight, an origin ("ORI") of a flight , a destination ("DES") of a flight, a passenger type code ("PTC") of the offer (e.g. "ADT" or adult), if an offer is public ("PUB") ( for example or private), a "TTL" for the offer, an identifier ("ID") of the offer, a flight number ("AF#") of the flight, a cost ("COST") of the offer, a number of bags ("BAGS") of the offer and a characteristic of the context ("Context") of the offer.

In particular, the carrier, origin, destination, TTL, identifier, flight number, cost, passenger type code, whether an offer is public, and the number of bags can be determined by using the machine learning model 235-1 determining reusability and may include extracting such information from provider objects 702 prior to categorization.

The context characteristics may be determined using the machine learning context determining model 235-2. As illustrated, for example, each of the vendor objects 702 is categorized based on whether a vendor object 702 caters to customers in different countries. So, for example, the first line provider object 702 can be provided in response to requests from customers located in France, assuming that the first line provider object 702 otherwise meets the criteria for such requests. . Similarly, the second tier vendor object 702 may be provided in response to requests from customers located in the United States, assuming that the second tier vendor object 702 otherwise meets the criteria for such requests. . Similarly, the third tier vendor object 702 may be provided in response to requests from customers located in the UK, assuming that the third tier vendor object 702 otherwise meets the criteria for those requests. .

When new provider objects are received that match one of the 702 as-categorized provider objects, the 702 as-categorized provider objects may be replaced. For example, when a most recent supplier object is received for flight number AF456 (for example, supplier object 702 from the second line), for example with a discounted cost, supplier object 702 from the second line can be replaced with the most recent provider object.

In this specification, elements may be described as being "configured to" implement one or more functions or as being "configured for" those functions. In general, an item that is configured to perform or implement a function is capable of performing the function, or is suitable to perform the function, or is suitable to perform the function, or is functional to perform the function. function or is able to implement the function otherwise.

It is understood that for the purpose of this specification the language "at least one of X, Y and Z" and "one or more of X, Y and Z" may be interpreted to mean X only, Y, only, Z only or any combination of two or more X, Y, Z elements (eg XYZ, XY, YZ, XZ, and so on). Similar logic can be applied for two or more items in any occurrence of "at least one..." and "one or more..." languages.

The terms "about", "substantially", "substantially", "approximately", and the like are, for example, defined to mean "close to", as those skilled in the art will understand. In some examples the terms are understood to be "within 10%", in other examples "within 5%", and in yet other examples "within 1%" and yet in other examples "within 0.5%".

Those skilled in the art will appreciate that in some embodiments, the functionality of the devices and/or methods and/or processes described herein may be implemented using pre-programmed hardware or firmware elements (e.g., integrated circuits specific applications (ASICs), electrically programmable and erasable read-only memories (EEPROMs, etc.) or other related components.In other examples, the functionality of the devices and/or the methods and/or the processes described herein may be implemented using a computing device that has access to a code memory (not shown) that stores computer-readable program code for operation in the computing device.The computer-readable program code could be stored on a computer-readable storage medium that is fixed, tangible, and directly readable by those components, (e.g., removable diskette, CD-ROM, RAM, hard disk, USB key drive). Further, it will be understood that the computer readable program may be stored on a computer program product comprising a computer usable medium. Further, a durable storage device may include computer-readable program code. It is further appreciated that the computer readable program code and/or computer usable medium may comprise durable computer readable program code and/or durable computer usable medium. Alternatively, computer-readable program code may be stored remotely, but may be transmitted to such components via a modem or other interface device connected to a network (including without limitation, the Internet) over a transmission medium. The transmission medium may be either an immovable medium (e.g. optical and/or digital and/or analog communication lines or a removable medium (e.g. microwave, infrared, free space optical or other systems transmission) or a combination thereof.

Those skilled in the art will understand that there are still other possible examples and modifications and that the above examples are only illustrative of one or more examples.

Claims (13)

A method for providing provider objects from a cache comprising:
receiving, on one or more servers, provider objects representing items provided by one or more provider systems;
categorizing, on said one or more servers, provider objects by one or more reusability and context characteristics;
the storage, by said one or more servers, in one or more memories, of the supplier objects as categorized;
receiving, at said one or more servers, from a requesting device, a request for one or more items provided by said one or more provider systems;
determining on one or more servers that a provider object, stored on one or more memories, meets the criteria associated with the request, including one or more respective reusability and context characteristics of the provider object; And
in response to determining that the provider object, which satisfies the criteria, is deemed to be currently valid, by providing, by the one or more servers, to the requesting device, a response corresponding to the provider object. The method of claim 1, wherein categorizing the provider objects by reusability comprises: categorizing the provider objects by one or more of respective characteristics and respective combinations of said one or more respective elements represented by the provider objects; And
determining that the respective reusability of the provider object meets the criteria associated with the query includes: determining that the provider object represents one or more of the same characteristics and a same combination of said one or more items requested by the query. The method of claim 1 or claim 2, wherein categorizing provider objects by context characteristics comprises:
categorizing the provider objects by one or more items of a respective context in which a respective provider object was requested, personalization, geographic location, customer type and category of respective items represented by the supplier ; And
determining that the respective context of the provider object satisfies the criteria associated with the request includes: determining that the provider object represents one or more of a same respective context of the request, a same customization, a same location geographical location, the same type of customer and the same category of said or several elements requested in the request. The method of any of claims 1 to 3, wherein it is determined that the provider object, which satisfies the criteria, is deemed to be currently valid, comprises:
determining that a current time does not exceed one or more of an estimated expiration time and an estimated Time-To-Live (TTL) value of the provider object. The method of any of claims 1 to 4, further comprising:using, on said one or more servers, a reusability-determining machine learning model and a context-determining machine learning model to categorize provider objects based on reusability characteristics and context respectively. The method of any of claims 1 to 5, further comprising:using, on said one or more servers, a validity estimation machine learning model to determine that the provider object is be currently valid. A server for providing provider objects from a cache comprising:
one or more memories;
a communication interface; And
a controller configured for:
receive, via the communication interface, provider objects representing items provided by one or more provider systems;
categorize provider objects by one or more reusability and context characteristics;
store, in one or more memories, the provider objects as categorized;
receiving, via the communication interface, from a requesting device, a request for one or more items provided by one or more provider systems;
determining that a provider object, stored in one or more memories, satisfies the criteria associated with the query, including one or more respective reusability and context characteristics of the provider object; And
in response to determining that the provider object, which satisfies the criteria, is deemed to be currently valid, providing, via the communication interface, to the requesting device, a response corresponding to the provider object. The server of claim 7, wherein the controller is further configured to categorize provider objects by reusability by:
categorizing the provider objects based on one or more respective characteristics and respective combinations of one or more respective elements represented by the provider objects; And
determining that the respective reusability of the provider object satisfies the criteria associated with the query includes: determining that the provider object represents one or more of the same characteristics and a same combination of said one or more elements requested by the query. The server of any of claims 7 to 8, wherein the controller is further configured to categorize provider objects by context characteristics by:
categorizing the provider objects by one or more items of a respective context in which a respective provider object was requested, personalization, geographic location, customer type and category of respective items represented by the provider objects ; And
determining that the respective context of the provider object meets the criteria associated with the request includes: determining that the provider object represents one or more of a same respective context of the request, a same personalization, a same geographical location , the same type of customer and the same category of said element or elements requested in the request. The server of any of claims 7 to 9, wherein the controller is further configured to determine that the provider object, which satisfies the criteria, is deemed to be currently valid by:
determining that a current time does not exceed one or more of an estimated expiration time and an estimated Time-To-Live (TTL) value of the provider object. The server of any of claims 7 to 10, wherein the controller is further configured to:
using a reusability-determining machine learning model and a context-determining machine learning model to categorize provider objects based on reusability and context characteristics, respectively. The server of any of claims 7 to 11, wherein the controller is further configured to:
using a validity estimation machine learning model to determine whether the provider object is estimated to be currently valid. A computer program product comprising program code instructions stored on a computer readable medium for carrying out the method steps according to any one of claims 1 to 6 when said program is running on a computer.