Device, system and method for reproducing request step between client device and provider system at intermediary server

Abstract

A device, system and method for reproducing a request step between a client device and a provider system at an intermediary server. The intermediary server reproduces a requesting step for one or more provider data objects representing at least one item provided by the provider system. Reproducing the requesting step includes providing to the provider system a request (s) for the provider data object, the request (s) being generated and / or altered based on an option associated with the provider system for reducing the number of the one or more provider data objects requested via the one or more requests. A mediation server receives provider data object (s) from a provider system. The intermediary server provides one or more provider data objects to the client device; and / or storing one or more provider data objects.

Description

Technical Field

[0001] This specification generally relates to intermediation between devices, and more particularly to devices, systems, and methods for reproducing request steps between a client device and a provider system at an intermediation server. Background Art

[0002] Supplying various products, including, for example, travel-related goods and services (e.g., flights, hotel reservations, etc.), typically requires various discrete entities to exchange data defining aspects of the products. In the context of travel-related products, examples of such entities include airlines, travel agencies, end-users, reservation systems, etc. Although such entities may be configured to exchange data according to a standardized format (e.g., in the context of travel-related products, according to the New Distribution Capability (NDC) standard based on Extensible Markup Language (XML)), they may still employ different mechanisms to initiate the exchange of data. However, some mechanisms may result in increased bandwidth usage and / or increased processing resource usage between components of a system that exchanges data related to various product offerings. Summary of the Invention

[0003] A first aspect of this specification provides a method that includes: reproducing, via an intermediation server, request steps for one or more provider data objects, where the provider data objects represent at least one item provided by a provider system, and reproducing the request steps includes providing, to the provider system, one or more requests for the one or more provider data objects, the one or more requests being one or more generated and modified based on options associated with the provider system stored at one or more memories, the options being for narrowing the number of one or more provider data objects requested via the one or more requests; receiving, at the intermediation server, the provider data objects from the provider system, and one or more of the following: providing, from the intermediation server, the one or more provider data objects to a client device, and storing, at the one or more memories via the intermediation server, the one or more provider data objects.

[0004] In the first aspect, reproducing the request steps may occur without a prior request step having been performed by the client device.

[0005] In a first aspect, the method may further include: receiving, from a client device, a communication including details for generating the one or more requests; in response to receiving the communication, implementing the reproduction of the request steps; in response to receiving the one or more provider data objects from a provider system and based on historical data associated with the client device, requesting, from the provider system, specific details of a given provider data object among the one or more provider data objects, the specific details including a fixed price of the given provider data object, the specific details being requested using a corresponding identifier of the given provider data object; and implementing providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device by: providing the specific details of the given provider data object to the client device. In these examples, the communication may be received without a prior request step being performed by the client device, and the communication does not have any provider data object identifiers.

[0006] In a first aspect, the method may further include: determining that one or more previously received provider data objects stored at the one or more memories are to be updated; in response to determining that the one or more previously received provider data objects are to be updated, implementing the reproduction of the request steps; and implementing storing the one or more provider data objects at the one or more memories by: replacing, at the one or more memories, the one or more previously received provider data objects with the one or more provider data objects.

[0007] In a first aspect, the method may further include: receiving, from a client device, a communication including details for generating the one or more requests; using the details to select one or more general provider data object descriptions from the one or more memories; in response to implementing the selection of the one or more general provider data object descriptions, implementing the reproduction of the request steps, the one or more general provider data object descriptions also being used to narrow the number of one or more provider data objects requested via the one or more requests; and implementing providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device. In these examples, the communication may be received without a prior request step being performed by the client device, and the communication does not have any provider data object identifiers.

[0008] In a first aspect, the method may further include: in response to receiving the one or more provider data objects from a provider system and based on historical data associated with the client device, further narrowing the number of the one or more provider data objects provided to the client device and stored at the one or more memories.

[0009] In a first aspect, the options may be based on pre-populated information that is one or more received from and associated with the provider system, and the options include types of provider data objects that are one or more available and unavailable from the provider system.

[0010] In a first aspect, the method may further include: based on historical data associated with the provider system, determining corresponding quantities of the one or more requests to be provided. In these examples, the historical data may indicate the speed of the provider system when previously responding to historical provider data object requests.

[0011] A second aspect of the present specification provides an intermediary server, including: a communication interface; and a controller configured to: reproduce a request step for one or more provider data objects, where the provider data objects represent at least one item provided by a provider system, and reproducing the request step includes providing to the provider system one or more requests for the one or more provider data objects, the one or more requests being generated and changed based on options associated with the provider system stored at one or more memories, the options being for narrowing the number of the one or more provider data objects requested via the one or more requests; receiving, via the communication interface, provider data objects from the provider system, and one or more of the following: providing the one or more provider data objects to a client device via the communication interface, and storing the one or more provider data objects at the one or more memories.

[0012] In a second aspect, reproducing the request step may occur in the case where the client device has not performed a previous request step.

[0013] In a second aspect, the controller may further be configured to: receive, from a client device, a communication including details for generating the one or more requests; in response to receiving the communication, implement a replay of the request steps; in response to receiving the one or more provider data objects from a provider system and based on historical data associated with the client device, request, from the provider system, specific details of a given provider data object among the one or more provider data objects, the specific details including a fixed price of the given provider data object, the specific details being requested using a corresponding identifier of the given provider data object; and implement providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device by: providing the specific details of the given provider data object to the client device. In some of these examples, the communication may be received without a prior request step being performed by the client device and without any provider data object identifier.

[0014] In a second aspect, the controller may further be configured to: determine that one or more previously received provider data objects stored at the one or more memories are to be updated; in response to determining that the one or more previously received provider data objects are to be updated, implement a replay of the request steps; and implement storing the one or more provider data objects at the one or more memories by: replacing, at the one or more memories, the one or more previously received provider data objects with the one or more provider data objects.

[0015] In a second aspect, the controller may further be configured to: receive, from a client device, a communication including details for generating the one or more requests; select, using the details, one or more general provider data object descriptions from the one or more memories; in response to implementing the selection of the one or more general provider data object descriptions, implement a replay of the request steps, the one or more general provider data object descriptions also being used to narrow the number of one or more provider data objects requested via the one or more requests; and implement providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device. In some of these examples, a communication may be received without a prior request step being performed by the client device and without any provider data object identifier.

[0016] In a second aspect, the controller may also be configured to: in response to receiving the one or more provider data objects from the provider system and based on historical data associated with the client device, further narrow down the number of the one or more provider data objects provided to the client device and stored at the one or more memories as the one or more.

[0017] In a second aspect, the options may be based on pre-populated information which is one or more received from and associated with the provider system, and the options include provider data object types as one or more available and unavailable from the provider system.

[0018] In a second aspect, the controller may also be configured to: based on historical data associated with the provider system, determine the respective number of the one or more requests to be provided. In some of these examples, the historical data may indicate the speed of the provider system when previously responding to historical provider data object requests.

[0019] A third aspect of this specification provides a non-transitory computer-readable medium storing a computer program, where executing the computer program will implement a method, and the method includes: reproducing, via an intermediary server, a request step for one or more provider data objects, where the provider data objects represent at least one item provided by a provider system, and reproducing the request step includes providing to the provider system one or more requests for the one or more provider data objects, the one or more requests being one or more generated and changed based on options associated with the provider system stored at one or more memories, and the options being used to narrow down the number of the one or more provider data objects requested via the one or more requests; receiving, at the intermediary server, one or more provider data objects from the provider system, and one or more of the following: providing the one or more provider data objects from the intermediary server to the client device, and storing the one or more provider data objects at the one or more memories via the intermediary server.

[0020] In a third aspect, reproducing the request step may occur when there has been no previous request step by the client device.

[0021] In a third aspect, the method may further include: receiving, from a client device, a communication including details for generating the one or more requests; in response to receiving the communication, implementing the reproduction of the request steps; in response to receiving the one or more provider data objects from a provider system and based on historical data associated with the client device, requesting, from the provider system, specific details of a given provider data object among the one or more provider data objects, the specific details including a fixed price of the given provider data object, the specific details being requested using a corresponding identifier of the given provider data object; and implementing providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device by: providing the specific details of the given provider data object to the client device. In these examples, the communication may be received without a prior request step being performed by the client device, and the communication does not have any provider data object identifier.

[0022] In a third aspect, the method may further include: determining that one or more previously received provider data objects stored at the one or more memories are to be updated; in response to determining that the one or more previously received provider data objects are to be updated, implementing the reproduction of the request steps; and implementing storing the one or more provider data objects at the one or more memories by: replacing, at the one or more memories, the one or more previously received provider data objects with the one or more provider data objects.

[0023] In a third aspect, the method may further include: receiving, from a client device, a communication including details for generating the one or more requests; using the details to select one or more general provider data object descriptions from the one or more memories; in response to implementing the selection of the one or more general provider data object descriptions, implementing the reproduction of the request steps, the one or more general provider data object descriptions also being used to narrow the number of one or more provider data objects requested via the one or more requests; and implementing providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device. In these examples, the communication may be received without a prior request step being performed by the client device, and the communication does not have any provider data object identifier.

[0024] In a third aspect, the method may further include: in response to receiving the one or more provider data objects from the provider system and based on historical data associated with the client device, further reducing the number of the one or more provider data objects provided to the client device and stored at the one or more memories.

[0025] In a third aspect, the options may be based on pre-populated information that is one or more received from and associated with the provider system, the options including types of provider data objects that are available and unavailable from the provider system.

[0026] In a third aspect, the method may further include: based on historical data associated with the provider system, determining a corresponding number of the one or more requests to be provided. In these examples, the historical data may indicate the speed of the provider system when previously responding to historical provider data object requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] To better understand the various examples described herein and to more clearly show how to implement these examples, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0028] Figure 1 A system for reproducing request steps between a client device and a provider system at a mediation server is depicted according to a non-limiting example.

[0029] Figure 2 A mediation server for reproducing request steps between a client device and a provider system at the mediation server is depicted according to a non-limiting example.

[0030] Figure 3 Depicts according to a non-limiting example Figure 1 of the computational processing flow of the system.

[0031] Figure 4 More particularly depicts according to a non-limiting example Figure 1 of the system.

[0032] Figure 5 A flowchart of a method for reproducing request steps between a client device and a provider system at a mediation server is depicted according to a non-limiting example.

[0033] Figure 6 Depicts according to a non-limiting example such as Figure 4 depicted in, a system that implements a method for reproducing request steps between a client device and a provider system at a mediation server.

[0034] Figure 7 depicts a system as depicted in Figure 4 which implements a method for reproducing request steps between a client device and a provider system at an intermediary server.

[0035] Figure 8 depicts a system as depicted in Figure 4 which implements a method for reproducing request steps between a client device and a provider system at an intermediary server. Detailed Description

[0036] Figure 1 depicts system 100 for intermediation between a provider system (e.g., one or more servers or other suitable computing devices) and a client device. In the examples discussed herein, provider data objects can include provider data objects and / or data records corresponding to products and / or items provided by the provider system, such as travel-related goods and services (e.g., flights, hotel reservations, car rentals, etc.). More specifically, the products and / or items discussed in the examples below can be airline tickets and related services (e.g., limousine transfer services, destination excursions, baggage check-in services, in-flight dining, entertainment, pet-related services, etc.). However, as will be appreciated by those skilled in the art, the systems and methods discussed below can also be applied to a variety of other types of data objects and / or items, including but not limited to, data objects corresponding to any suitable products and / or any suitable items available (e.g., for purchase, etc.) from any suitable website, etc.

[0037] Delivery of the above items is typically controlled by a provider entity, such as an airline in the case of the items discussed in the tourism-related examples provided herein. System 100 includes one or more provider systems 102 (e.g., one or more servers or other suitable computing devices), which in this example are operated by one or more provider entities. System 100 can include a plurality of client devices 104, but for illustrative purposes, Figure 1 only one client device 104 is shown in

[0038] System 100 may include multiple provider systems 102, each operated by a respective provider entity (e.g., individual airlines), but for illustrative purposes only one provider system 102 is shown. Provider data objects may be in any suitable format, including but not limited to Edifact recommendations in the context of global distribution system (GDS)-based data exchange, offer records in the context of new distribution capability (NDC)-based data exchange, and / or any other suitable format. In fact, provider data objects may include, for example, data objects and / or data records storing Edifact recommendations or NDC offers, and / or any other suitable data representing at least one item provided by provider system 102.

[0039] Provider data objects are understood to define items or combinations of items that can be offered for purchase (e.g., by end users of the items), including but not limited to one or more of flights, train tickets, hotel accommodations, airport lounge access, seat upgrades, baggage check-in services, in-flight meals, entertainment, transfer services, tour services, pet-related services, etc., and / or associated services. Thus, in the examples discussed below, a provider data object may define a flight operated by a provider entity, and / or services associated with the flight or offered as stand-alone services. Accordingly, each provider data object may contain various fields (e.g., data fields), etc. Certain fields define item attributes such as product object identifiers (e.g., service identifiers, item identifiers, product identifiers, etc.), locations corresponding to the product, dates, and times (e.g., flight times and other itinerary data). The type of fields and / or data of a provider data object may depend on the type of provider data object. For example, a provider data object corresponding to a flight may include a flight identifier, while a provider data object corresponding to other travel-related items (such as offers for access to an airport lounge and / or offers for premium seat upgrades) may include information related to the lounge, premium seats, etc.

[0040] At provider system 102, requests for provider data objects may be received from other components of system 100. For example, requests may be received from client device 104 via network 106 (e.g., any suitable combination of local area networks and wide area networks, including the Internet) and via mediation server 108. As will be described below, mediation server 108 generally acts as a mediator between client device 104 and provider system 102, e.g., such that client device 104 can request products from provider system 102 and / or more than one provider system 102 via mediation server 108.

[0041] In addition, in some examples, the mediation server 108 can transform data between formats associated with the provider system 102 and the client device 104. For example, a first provider system 102 can transmit and / or offer provider data objects and / or quotes for provider data objects according to a first format, and a second provider system 102 can transmit and / or offer provider data objects and / or quotes for provider data objects according to a second format (e.g., the second format can be the same as or different from the first format). Both formats may be incompatible with the format used by the client device 104 for communication. Thus, the mediation server 108 can transform data in different formats received from the provider system 102 into a format compatible with the client device 104, and vice versa.

[0042] In this example, the client device 104 can be operated by a travel agency entity and thus generate and submit, on behalf of an end user (e.g., a traveler), requests for provider data objects (e.g., representing products that can be purchased) and / or requests to purchase products (e.g., represented by provider data objects) to the provider system 102 via the mediation server 108.

[0043] Thus, in one example, the mediation server 108 can include an aggregator server that communicates with multiple provider systems 102 and aggregates provider data objects and / or quotes from the multiple provider systems 102 for providing to the client device 104. When the formats of the data used by the provider system 102 and the client device 104 are compatible, the mediation server 108 may not perform the transformation described herein when performing the aggregation function.

[0044] Alternatively, the client device 104 can be operated by the provider system 102. In yet another alternative, the provider system 102 can operate the mediation server 108. Thus, it should be understood that although in Figure 1 the provider system 102, the client device 104, and the mediation server 108 are all depicted as separate from each other, they can be associated with various combinations of one or more entities, and / or the functions of the provider system 102, the client device 104, and the mediation server 108 can be combined in any suitable manner in one or more computing devices and / or servers and / or cloud computing devices. Thus, when referring to the components of the system 100 herein, communication is not meant to refer to the components communicating by transmitting data therebetween (e.g., such as via the network 106), but rather communication between the components of the system 100 herein refers to the components providing data therebetween, which can include but is not limited to transmitting data via the network 106, transmitting data when the components are local to each other and / or combined, and the like.

[0045] A variety of other mechanisms for initiating the creation of a provider data object are also envisioned. For example, an end user (via client device 104 and / or a client device and / or an additional computing device, Figure 1 not shown) can initiate the creation of a provider data object by directly interacting with a website hosted by the intermediary server 108. A variety of mechanisms for creating a provider data object will be apparent to those skilled in the art, such as the "offer" and "order" mechanisms specified by the NDC standard.

[0046] The client device 104 is configured to receive data included in the provider data object via the intermediary server 108. The data obtained by the client device 104 via the intermediary server 108 can be presented, for example, to a user served by the client device 104 via a display screen (not depicted) that can be local to the client device 104; the client device 104 can request more information associated with the item represented by the provider data object, which can include but is not limited to the client device 104 ordering the item. In other words, the system 100 enables the client device 104 to request more information associated with the item represented by the provider data object via the intermediary server 108. The client device 104 can be configured to provide a request via the intermediary server 108 to the provider system 102 to request more information and / or initiate such an order.

[0047] The provider data object provided by the provider system 102 typically includes provider data object data representing at least one item provided by the provider system 102. In some examples, the provider data object data can include a provider data object identifier and / or provider data object identifier data that identifies the provider data object to the provider system 102. The provider data object data typically includes information identifying travel-related products and / or services. Whether the provider data object data includes a specific provider data object identifier can depend or can not depend on whether the provider data object is in NDC format or GDS format. For example, when the provider data object includes an NDC offer, the provider data object identifier data can include an identifier specifically generated by the provider system 102 that identifies the NDC offer. However, when the provider data object includes an Edifact recommendation (which typically does not contain a specific identifier), the provider system 102 can identify the Edifact recommendation based on the provider data object identifier data (such as the characteristics of the Edifact recommendation, such as the specific order and / or format of the data in the Edifact recommendation).

[0048] Generally, communication between the client device 104 and the mediation server 108 occurs via a computing processing flow 110 implemented by the client device 104, such as an application programming interface (API). For example, during the ordering of a provider data object (e.g., booking a flight), the client device 104 may implement the computing processing flow 110 in the form of an API, and the communication between the client device 104 and the mediation server 108 may be defined by the API.

[0049] In any case, the steps of quoting and ordering a provider data object may occur according to a series of predefined steps, which will be discussed in more detail in conjunction with Figure 3 However, it should be understood that these steps are not exhaustive, and other steps may occur in the computing processing flow 110. However, when the system 100 is configured such that the provider system 102 responds to each request for a provider data object, the request step (where the client device 104 may request a provider data object from one or more provider systems 102 via the mediation server 108) may result in network traffic cancellation at the provider system 102. In particular, in some examples, the provider system 102 may (e.g., at the server) publish and / or provide information describing various provider data objects (e.g., such as flight schedules, fares, airline rules, flight availability data, etc.) to the mediation server 108, which may enable the mediation server 108 to generate provider data objects. Alternatively, the mediation server 108 may maintain a cache of information describing various provider data objects, etc., which includes but is not limited to the seat availability of various flights (e.g., when the provider data object represents a seat on a flight, etc.). In these examples, at the request step, the mediation server 108 may use such information to respond to the client device 104's request for a provider data object (e.g., the mediation server 108 may generate a provider data object and provide it to the client device 104) without explicitly querying the provider system 102. Such a response from the mediation server 108 may occur in response to a GDS type query and / or request from the client device 104; however, such a response is understood to be general and / or non-customized; in addition, such a response may be in GDS format.

[0050] However, in NDC-based data exchange, an NDC offer (e.g., an offer for a provider data object) can be based on options associated with the provider system 102; the options can specify various factors that the provider system 102 can use to respond to requests for provider data objects and can include, but are not limited to (e.g., using a travel-based example), the destinations and / or airports served by the provider system 102, the connecting airports used by the provider system 102, the baggage-related factors used by the provider system 102, etc., and other possibilities. Thus, in NDC-based data exchange, NDC offers can be customized according to various factors.

[0051] Thus, it is further understood that in some examples, the mediation server 108 and / or one or more provider systems 102 operate according to the NDC standard.

[0052] However, although in NDC-based data exchange, the provider system 102 may receive thousands to millions or even hundreds of millions (sometimes higher) of requests per day, few requests may result in the client device 104 making a reservation and / or purchase of a provider data object, etc. This situation may result in a large waste of bandwidth between the components of the system 100 and / or a large waste of processing resources at the provider system 102.

[0053] It is further understood that to address this issue, the mediation server 108 is typically configured to reproduce (e.g., simulate and / or imitate, etc.) the request steps for one or more provider data objects by, for example, providing the provider system 102 with one or more requests for one or more provider data objects, including, for example, the request identifier and its price estimate, the one or more requests being generated and changed based on one or more options associated with the provider system 102 as stored in one or more memories, the options being used to narrow the number of one or more provider data objects requested via the one or more requests. In particular, this narrowing of the number of one or more provider data objects requested via the one or more requests can reduce the use of processing resources by the provider system 102 in responding to the one or more requests. In particular, although provider data objects can be customized, for different requests (e.g., from the client device 104 and / or different client devices 104), this customization can be similar and / or the same, and thus narrowing and / or restricting the search for provider data objects at the provider system 102 can save bandwidth between the provider system 102 and the mediation server 108, as well as processing resources at the provider system 102.

[0054] The mediation server 108 can receive provider data objects from the provider system 102 and store them such that when a request for a stored provider data object is received from the client device 104, the mediation server 108 can retrieve the provider data object from one or more memories instead of requesting the provider data object from the provider system 102 again. Alternatively, the provider data object from the provider system 102 can be provided to the client device 104, for example, in response to a data exchange with the mediation server 108 that occurs during a selection step described in more detail below.

[0055] Go to Figure 2 , before discussing the functions of the system 100 in more detail, certain components of the mediation server 108 will be discussed in more detail. Although the mediation server 108 is depicted as a single device, it can include one or more computing devices and / or one or more cloud computing devices that can be geographically distributed.

[0056] As Figure 2 shown, the mediation server 108 includes at least one controller 202, such as a central processing unit (CPU). The controller 202 is interconnected with a memory 204 that stores an application 206, and the memory 204 is implemented as a suitable non-transitory computer-readable medium (e.g., a suitable combination of non-volatile and volatile memory subsystems, including any one or more of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic computer storage devices, etc.). The controller 202 and the memory 204 typically consist of one or more integrated circuits (ICs).

[0057] The controller 202 is also interconnected with a communication interface 208, which enables the mediation server 108 to communicate with other computing devices of the system 100 (i.e., the provider system 102 and the client device 104) via the network 106. However, it should be understood that when the components of the system 100 are combined, this communication can occur locally. Thus, the communication interface 208 can include any necessary components (e.g., a network interface controller (NIC), a radio unit, etc.) for communicating via the network 106. The specific components of the communication interface 208 can be selected based on the nature of the network 106 and / or local communication between the components of the system 100, etc. The mediation server 108 can also include input and output devices (not shown) connected to the controller 202, such as a keyboard, a mouse, a display, etc.

[0058] The components of the mediation server 108 described above may be deployed in a single enclosure or in a distributed format. Thus, in some examples, the mediation server 108 includes multiple processors that either share the memory 204 and the communication interface 208 or each have different associated memories and communication interfaces. Accordingly, it should be understood that the memory 204 and / or a portion of the memory 204 may be located inside (e.g., as depicted) or outside the mediation server 108; in any case, the controller 202 should be understood to have access to the memory 204.

[0059] The memory 204 also stores multiple computer-readable programming instructions that may be executed by the controller 202, and these instructions are in the form of various applications, including the application 206. As those skilled in the art will understand, the controller 202 executes the instructions of the application 206 (and any other suitable applications) to perform various actions defined by the instructions contained therein. In the following description, the controller 202, and more generally, the mediation server 108 are referred to as being configured to perform these actions. It should be understood that they are so configured by executing (by the controller 202) the instructions of the applications stored in the memory 204.

[0060] In some examples, as will be discussed below, the execution of the application 206 configures the mediation server 108 to implement the functions for reproducing the request steps to supply provider data objects at the mediation server 108, including but not limited to the blocks of the methods set forth in Figure 5 the boxes.

[0061] As will be described in more detail below, in some examples, the application 206 may include one or more machine learning algorithms that are trained to implement the functions for reproducing the request steps to supply provider data objects at the mediation server 108, including but not limited to the blocks of the methods set forth in Figure 5 the boxes. However, alternatively or additionally, the application 206 may include one or more programming algorithms.

[0062] Although the structures of the provider system 102 and the client device 104 are not described in detail, it should be understood that the provider system 102 and the client device 104 have structures similar to those of the mediation server 108 but adapted to the functions of the provider system 102 and the client device 104.

[0063] Next note Figure 3, which depicts a block diagram of an example of a computing processing flow 110. Although the example computing processing flow 110 is depicted in the form of a flowchart, it should be understood that the example computing processing flow 110 (e.g., hereinafter referred to as the computing processing flow 110) may show steps of an API, including steps 302-1, 302-2, 302-3, 302-4, which may hereinafter be collectively referred to interchangeably as steps 302 and generally referred to as steps 302. This convention will be used throughout this specification.

[0064] For example, at request step 302-1, a user of the client device 104 may enter criteria and / or details in a data field of a GUI for searching for provider data objects representing flights, such as the date (e.g., and time) of the flight, the departure airport, the arrival airport, and other possibilities; the criteria may be provided to the intermediary server 108, and the intermediary server 108 may provide the criteria and / or details to the provider system 102. The provider system 102 may return corresponding quotes for provider data objects representing flights that meet the criteria and / or details. Generally, such quotes for provider data objects may be customized according to options associated with the provider system 102. The intermediary server 108 may aggregate quotes for provider data objects from multiple provider systems 102 and return the quotes for the provider data objects to the client device 104. In an NDC-based data exchange, it should be understood that quotes may be identified by corresponding quote identifiers (e.g., which may be referred to as OfferId and / or OfferID).

[0065] At selection step 302-2, a list of quotes for provider data objects representing flights returned by the provider system 102 via the intermediary server 108 may be provided in a GUI at a display screen associated with the client device 104, and the user of the client device 104 may select, for example, a flight to book; in some examples, the user of the client device 104 may select an electronic button or the like to add a service (such as a transfer service) to the quote and / or the provider data object. At selection step 302-2, the client device 104 may request a "firm" quote for the selected provider data object, such as a "firm" and / or final price, which may be different from the "published" price. Any suitable data exchange between the client device 104, the intermediary server 108, and the provider system 102 via the network 106 is understood to occur for selecting, requesting, and receiving a firm quote for the provider data object, however, when such data exchange includes an NDC-based data exchange (e.g., using the quote identifier of the selected quote), such data exchange is understood to be based on the aforementioned quote identifier.

[0066] Similarly, at booking step 302-3, information about the selected provider data object (such as the aforementioned flight) can be provided in the GUI at the display screen, and the user of client device 104 can select an electronic button therefrom to make a payment for the flight and / or add services to the booking, such as pick-up and drop-off services, etc. Any suitable data exchange between client device 104, intermediary server 108, and provider system 102 via network 106 is understood to constitute a firm offer for booking the provider data object. However, when such data exchange includes NDC-based data exchange, such data exchange is understood to be based on the aforementioned offer identifier.

[0067] Similarly, at payment step 302-4, a field for entering payment information (such as credit card information) can be provided in the GUI at the display screen to pay for the selected booked flight. Any suitable data exchange between client device 104, intermediary server 108, and provider system 102 via network 106 is understood to constitute a firm offer for paying the provider data object.

[0068] Although step 302 can be entirely implemented as purchasing a provider data object (e.g., a flight represented by a provided object), for instances of the remaining steps 302, request step 302-1 can be implemented dozens to hundreds to thousands of times (or more). For example, the user of client device 104 may request and view many provider data objects before selecting and / or booking and / or paying for a provider data object; in fact, the user of client device 104 may request and view many provider data objects but never select and / or book and / or pay for a provider data object. Additionally, users of different client devices 104 can request provider data objects using similar and / or identical criteria at corresponding request step 302-1, which may cause provider system 102 to provide similar and / or identical provider data objects to client devices 104 (e.g., assuming that client device 104 and / or the requests received at request step 302-2 satisfy the same or similar options and / or factors associated with provider system 102 that provides the provider data object).

[0069] Now note Figure 4 , which illustrates an example of system 100 that includes a provider system 102, a client device 104, and an intermediary server 108 that intermediates therebetween. Although network 106 is not depicted, it should be understood to exist. For example, the communication links between the components of system 100 are depicted as two-way arrows between the corresponding components in Figure 4 and throughout this specification; the communication links can include any suitable combination of wireless and / or wired links, and / or wireless and / or wired communication networks, including but not limited to network 106.

[0070] Figure 4 Also depicted is a memory 400 accessible by the mediation server 108. Although the memory 400 is depicted in the form of a database, the memory 400 may include one or more suitable memories 400 in which provider data objects (e.g., in the form of offers of provider data objects, and / or in any other suitable format) may be stored. The memory 400 (which may hereinafter be referred to interchangeably as one or more memories 400) may be separate from the mediation server 108 and / or may be at least partially integrated with the mediation server 108, e.g., at the memory 204.

[0071] As depicted, the memory 400 stores options 402 associated with the provider system 102. Although only one provider system 102 and one set of associated options 402 are depicted, the memory 400 may store a set of options 402 for each of a plurality of provider systems 102 with which the mediation server 108 communicates. The options 402 are generally understood to be based on pre-populated information received from and / or associated with the provider system 102; e.g., the options 402 may include one or more types of provider data objects that are available or unavailable from the provider system 102. For example, the options 402 may specify various rules that the provider system 102 may use to respond to a request for a provider data object at the request step. In an example where the application 206 includes one or more machine learning algorithms, the options 402 may include a machine learning classifier that may be used to generate a request for a provider data object from the provider system 102 based on various factors used as input to one or more machine learning algorithms, such as details of one or more items and / or flights received from the client device 104, details of previous provider data objects stored at one or more memories 400 (e.g., the previous provider data object 406 described below), etc.

[0072] In a particular non - limiting example, option 402 can indicate that the provider system 102 provides flights only between certain destinations and / or does not provide flights between other destinations. In another particular non - limiting example, option 402 can indicate that the provider system 102 provides flights only between certain airports and / or does not provide flights between other airports; for example, while the provider system 102 can provide flights to and / or from a given city that may have multiple airports, option 402 can indicate that the provider system 102 provides flights only to one of the airports and not to the other airports (e.g., to or from Charles de Gaulle Airport in Paris, but not to or from Orly Airport in Paris). In another particular non - limiting example, option 402 can indicate that the provider system 102 provides only stop - over and / or connecting flights via certain airports and / or does not provide stop - over and / or connecting flights via other airports (e.g., via John F. Kennedy Airport in New York City, but not via Pierre Elliott Trudeau Airport in Montreal). In yet another particular non - limiting example, option 402 can indicate that the provider system 102 provides flights that include one checked bag, but does not provide flights that exclude checked bags (e.g., at a cheaper fare). In other words, option 402 can include a set of rules and / or machine - learning classifiers that correspond to the rules internal to the provider system 102 that are applied when searching for flights upon receiving a request at request step 302 - 1.

[0073] In other words, option 402 can specify one or more types of provider data objects that are available or unavailable from the provider system 102. Continuing the above travel - related example, option 402 can indicate that certain types of provider data objects corresponding to flights between particular destinations are available from the provider system 102, and / or option 402 can indicate that other types of provider data objects corresponding to flights between other particular destinations are unavailable from the provider system 102.677.

[0074] Similarly, option 402 can indicate that certain types of provider data objects corresponding to flights that include a stop - over and / or connecting flight at a particular airport are available from the provider system 102, and / or option 402 can indicate that other types of provider data objects corresponding to flights that include a stop - over and / or connecting flight at other particular airports are unavailable from the provider system 102.

[0075] Similarly, option 402 can indicate that certain types of provider data objects corresponding to flights that include a checked bag are available from the provider system 102, and / or option 402 can indicate that other types of provider data objects corresponding to flights that do not include a checked bag are unavailable from the provider system 102.

[0076] However, option 402 can include any suitable type of rules and / or machine learning classifiers and / or any suitable type of provider data objects and / or any suitable indication of any suitable type of provider data objects, etc.

[0077] Generally speaking, as will be described in more detail below, when the mediation server 108 reproduces the request steps 302-1 for one or more provider data objects, option 402 can be used to narrow the request conditions for the provider data objects provided to the provider system 102. In other words, when the mediation server 108 reproduces the request steps 302-1 for one or more provider data objects, the mediation server 108 can include a request generated according to option 402. For example, to include conditions corresponding to the types of provider data objects supplied by the provider system 102 in the request, and / or to exclude conditions corresponding to the types of provider data objects not supplied by the provider system 102 in the request.

[0078] In some examples, option 402 can be explicitly based on information received from the provider system 102 (e.g., a set of rules and / or provider data object types). However, in other examples, the mediation server 108 can derive option 402 based on previous requests received from the client device 104 and the corresponding provider data objects returned from the provider system 102 (which can be stored as historical data 404 at the memory 400); for example, the mediation server 108 can process the historical data 404 received from the provider system 102 and the requests for the corresponding provider data objects in response to the request to determine option 402.

[0079] In particular, the historical data 404 can be used to train the machine learning algorithm of the application 206. For example, the requests received from the client device 104 can be used as training inputs, and the corresponding provider data objects returned from the provider system 102 can be used as training outputs to generate option 402, especially its machine learning classifier.

[0080] Similarly, as depicted, the memory 400 can also store previous provider data objects 406 received from the provider system 102, which can be stored together with the historical data 404 and / or separately from the historical data 404. For example, the previous provider data objects 406 can contain the above-mentioned training outputs used to generate option 402. However, the training outputs used to generate the previous provider data objects 406 can alternatively be stored as a cache of provider data objects, and the mediation server 108 can search this cache in response to requests from the client device 104.

[0081] However, the historical data 404 can store historical data 404 associated with the client device 104, such as regarding the selection step 302-2 (or a similar step), the reservation step 302-3 (or a similar step), and / or the payment step 302-4 (or a similar step). For example, the historical data 404 associated with the client device 104 can be used, for example, in combination with implementing the method described below regarding Figure 5 to reduce the number of provider data objects provided to the client device 104 and stored at one or more memories 400. For example, the historical data 404 can indicate that the client device 104 typically selects and / or reserves the cheapest flights, and / or flights without layovers, or more expensive flights with associated premium services (such as lounge passes, etc.). Thus, it should be understood that some provider data objects can correspond to flights with such premium services associated therewith.

[0082] In particular, as depicted, the historical data 404 can be used to generate a client device rule 407, which can include rules and / or machine learning classifiers, etc., for reducing the number of provider data objects provided to the client device 104 and stored at one or more memories 400. In an example, the client device rule 407 can indicate that only a given number of provider data objects (e.g., such as 10 provider data objects) representing the cheapest items represented by the provider data objects will be the one or more provider data objects provided to the client device 104 and stored at one or more memories 400. In another example, the client device rule 407 can indicate that only a given number of provider data objects (e.g., such as 10 provider data objects) representing expensive flights with associated premium services (such as lounge passes) will be the one or more provider data objects provided to the client device 104 and stored at one or more memories 400. However, the client device rule 407 can indicate any "preferences" associated with the client device 104 as indicated by the historical data 404 (and / or any other suitable data).

[0083] In particular, the historical data 404 can be used to train the machine learning algorithm of the application 206. For example, selection requests and / or reservation requests and / or payment requests received from the client device 104 can be used as training inputs, and the corresponding provider data objects selected and / or reserved and / or paid for can be used as training outputs to generate the client device rule 407, particularly its machine learning classifier.

[0084] As depicted, the memory 400 also stores a general provider data object description 408. Such general provider data object descriptions 408 can include examples and / or general travel itineraries, which can exclude flight details but can include, for example, an estimate of the price of a flight. The use of the general provider data object descriptions 408 will be described in more detail below, but it should be understood that the general provider data object descriptions 408 can indicate "popular" itineraries that can be based on the historical data 404. For example, the general provider data object description 408 can indicate that flights with a morning departure time (e.g., between 06:00 and 12:00) between two destinations and / or airports are the most popular, while afternoon and / or night flights are not. This determination of popularity can be based on a threshold of flight bookings; for example, when morning flights between two destinations are booked in the top 90% of the time compared to afternoon and / or night flights, the morning flights can be determined to be the most popular, and the general provider data object description 408 can store the "itinerary" of the morning flights between the two destinations but not the "itinerary" of the afternoon or night flights. In some examples, the general provider data object description 408 can be more specific and, for example, can indicate the itinerary of a flight with a departure time between 07:30 and 08:30 between two destinations.

[0085] In a specific example, the general provider data object description 408 can contain flight information and / or an "itinerary" for a flight from Toronto to Paris with a departure time between 06:00 and 12:00. In a simple example, such a general provider data object description 408 can include: "Departure City: Toronto; Destination City: Paris; Departure Time Range: 06:00 to 12:00". The general provider data object description 408 can omit other itineraries between the two destinations to indicate that the stored itinerary is the most popular. However, any suitable format for any suitable itinerary applicable to the general provider data object description 408 is within the scope of this specification.

[0086] Thus, it should be understood that the general provider data object descriptions 408 are referred to herein as "general" because they generally and / or generally describe a set of conditions that some provider data objects may meet, but do not describe a specific provider data object.

[0087] As depicted, client device 104 communicates with a memory 410 (e.g., depicted in the form of a database), which stores provider data object (e.g., "PO") information 412. The provider data object information 412 can include provider data object information about provider data objects available from provider system 102 and available from the provider system 102, and can include published flight schedules. The provider data object information 412 can enable, for example, a local search for provider data objects at the client device 104 in a request step that mimics and / or emulates the request step 302-2 without communicating with the mediation server 108 and / or the provider system 102.

[0088] Now note Figure 5 , which depicts a flowchart representing a method 500 for reproducing, at a mediation server, request steps between a client device and a provider system in accordance with indications of possible steps associated with a corresponding provider system. Figure 5 The operations of the method 500 correspond to machine-readable instructions executed by the mediation server 108 (specifically, the controller 202 of the mediation server 108). In the example shown, Figure 5 the instructions represented by the boxes in Figure 5 are stored, for example, as an application 206 at the memory 204. Figure 5 The method 500 of Figure 5 is one way that the controller 202 and / or the mediation server 108 and / or the system 100 can be configured. Additionally, the following discussion of Figure 5 the method 500 of

[0089] Figure 5 will help in further understanding the system 100 and its various components.

[0089] Figure 5 The method 500 of Figure 5 need not be executed in the exact order shown, and likewise, the various boxes can be executed in parallel rather than sequentially. Accordingly, the elements of the method 500 are referred to herein as "boxes" rather than "steps". Figure 5 The method 500 of Figure 1 and Figure 4 can also be implemented on variants of the system 100 of

[0090] It should be understood that the method 500 can generally enable fewer requests for provider data objects to be provided to the provider system 102, thereby reducing the bandwidth usage of the system 100.

[0091] At block 502, the controller 202 and / or the mediation server 108 reproduce the request steps for one or more provider data objects, e.g., including requesting their identifiers and price estimates, where the provider data objects represent at least one item provided by the provider system 102. Reproducing the request steps includes providing to the provider system 102 one or more requests for one or more provider data objects, the one or more requests being generated and modified based on one or more options 402 associated with the provider system 102 as stored in one or more memories 400, and the options 402 being used to narrow the number of one or more provider data objects requested via the one or more requests.

[0092] In some examples, at block 502, reproducing the request steps can occur without the client device 104 having performed the previous request step 302-1. However, in other examples, the previous request step 302-1 may have occurred according to the same and / or similar conditions and / or details as the request steps reproduced at block 502.

[0093] Generally speaking, as described above, the options 402 of block 502 can be based on pre-populated information received from the provider system 102. Additionally, as described above, the options 402 can include provider data object types that are available or unavailable from the provider system 102 as one or more. Additionally, as described above, the options 402 can include a machine learning classifier.

[0094] In some examples, at block 502, the controller 202 and / or the mediation server 108 can determine the respective number of one or more requests to provide based on historical data 404 associated with the provider system 102. Such historical data 404 can indicate the speed of the provider system 102 in previously responding to historical provider data object requests. For example, the historical data 404 can indicate that the provider system 102 previously responded faster to two separate requests specifying different specific search conditions for flights between two airports (e.g., one request included a layover while the other did not) than to a request specifying a more general search condition for flights between two cities (e.g., not indicating whether a layover was requested). Generally speaking, the historical data 404 can be used to optimize the number of requests provided to the provider system 102 at block 502. In fact, in these examples, the application 206 can include one or more machine learning algorithms that are trained to determine the number of requests that can result in the fastest response from the provider system 102, and such one or more machine learning algorithms are trained using the number and / or type of requests provided to the provider system 102 and the time to receive the corresponding responses from the provider system 102.

[0095] It is further understood that block 502 can be described below with respect toFigure 6 , Figure 7 and Figure 8 initiated under different circumstances described in more detail.

[0096] At block 504, the controller 202 and / or the mediation server 108 (e.g., via the communication interface 208) receives, in response to one or more requests provided at block 504, one or more provider data objects from the provider system 102, e.g., including their identifiers and price estimates.

[0097] At block 506, the controller 202 and / or the mediation server 108 provides one or more provider data objects from the mediation server to the client device 104 (e.g., via the communication interface 208).

[0098] At block 508, the controller 202 and / or the mediation server 108 stores one or more provider data objects at one or more memories 400.

[0099] It should be understood that one or more of blocks 506 and 508 can be implemented. In particular, only block 506 can be implemented, only block 508 can be implemented, or both block 506 and block 508 can be implemented. Whether block 506 is implemented and / or whether block 508 is implemented can depend on many factors described in more detail below regarding Figure 6 , Figure 7 and Figure 8 but these factors can include, but are not limited to, the circumstances at the time of initiating the method 500.

[0100] In some examples, the method 500 can further include: the controller 202 and / or the mediation server 108: in response to receiving one or more provider data objects from the provider system 102 at block 504, and based on the historical data 404 associated with the client device 104, further narrowing the number of one or more provider data objects to be provided to the client device 104 (e.g., at block 506) and stored at one or more memories 400 (e.g., at block 508). For example, as described above, the historical data 404 associated with the client device 104 can indicate that the client device 104 typically requests the cheapest flights, so the narrowing based on the historical data 404 associated with the client device 104 can include providing and / or storing only the ten cheapest provider data objects, or any other suitable number of provider data objects.

[0101] Next note Figure 6 , Figure 7 and Figure 8 , which depict aspects of different examples of the method 500 implemented at the system 100. Figure 6 ,Figure 7 and Figure 8 with Figure 4 are substantially similar, where the same components have the same numbers.

[0102] Next, note that Figure 6 , where the client device 104 implements the request and / or shopping step 602 based on the provider data object information 412 stored at the memory 410. In other words, the request and / or shopping step 602 implemented by the client device 104 is similar to the request step 302-1 of the computing processing flow 110, but occurs when the client device 104 interacts with and / or searches the provider data object information 412, rather than when communicating with the provider system 102 via the intermediary server 108. Thus, in this example, the request step 302-1 of the computing processing flow 110 does not occur; instead, the request step 602 occurs within the boundaries of the client device system (e.g., which includes the client device 104 and the memory 410) and without communicating with the provider system 102 via the intermediary server 108. For example, detailed information and / or conditions such as the departure city, destination city, and date can be used to search the provider data object information 412 to generate a list of provider data objects represented by the provider data object information 412.

[0103] Although it is possible to select one or more provider data objects from the list of provider data objects represented by the provider data object information 412 at the client device 104, such selection does not include any offer identifiers associated with the selected provider data objects.

[0104] Nonetheless, the client device 104 attempts to implement the selection step by providing a communication 604 to the intermediary server 108, the communication 604 including details for generating one or more requests 606 (e.g., at block 502 of method 500). The details can include, but are not limited to, details of the provider data objects selected at the request step 602. For example, based on the provider data object information 412 (which may or may not be accurate), the communication 604 can identify a flight between two cities on a particular date offered by the provider system 102. In some examples, the communication 604 can include a request for a "fixed" price for such a provider data object.

[0105] However, the communication 604 is understood to not have offer identifiers used in NDC-based data exchanges; rather, compared to the selection step 302-2, the selection step represented by the communication 604 is performed without offer identifiers and the like to identify a particular provider data object.

[0106] As depicted, communication 604 is received at mediation server 108, and mediation server 108 implements block 502 of method 500.

[0107] Specifically, mediation server 108 reproduces request steps 302-2 for one or more provider data objects for details that may satisfy communication 604. For example, as depicted, mediation server 108 requests an identifier (e.g., a quote identifier) and its price estimate by providing one or more requests 606 for one or more provider data objects to provider system 102. One or more requests 606 are understood to be one or more generated and changed based on option 402 associated with provider system 102. For example, option 402 typically narrows the number of one or more provider data objects requested via one or more requests 606.

[0108] For example, details of communication 604 can be used as input to a machine learning algorithm that uses a machine learning classifier of option 402 to generate one or more requests 606. Additionally, a machine learning algorithm trained to reduce the response time of provider system 102, etc., can be used to further determine and / or optimize the number of one or more requests 606, as described above.

[0109] Continuing the above example, although details of communication 604 can identify a flight between two cities on a specific date provided by provider system 102, since there is no identifier for such a flight, mediation server 108 generates one or more requests 606 for such a flight based on option 402. For example, as previously described, option 402 can instruct provider system 102 to provide flights between given airports in the cities specified in communication 604; thus, one or more requests 606 can include conditions for searching for flights between two airports (e.g., rather than between two cities).

[0110] Similarly, option 402 can instruct provider system 102 to provide flights between given airports in the cities specified in communication 604, but only for one checked bag (e.g., no additional checked bag fee). Thus, one or more requests 606 can include conditions for searching for flights that include one checked bag between two airports, e.g., rather than flights that charge a checked bag fee.

[0111] In this way, the conditions of one or more requests 606 for performing a search at provider system 102 can be refined and / or changed relative to the details of communication 604.

[0112] Accordingly, one or more requests 606 should be understood to be generated relative to a situation of searching for provider data objects at the provider system 102 using details of the communication 604, to narrow the search for provider data objects at the provider system 102.

[0113] As depicted, it should be understood that the provider system 102 receives one or more requests 606, performs a search for provider data objects based on the one or more requests 606, and returns one or more provider data objects 608 to the mediation server 108, which are received at the mediation server 108 (e.g., at block 504 of method 500). The one or more provider data objects 608 are understood to contain identifiers, such as offer identifiers, etc.

[0114] As depicted, the mediation server 108 can apply the client device rules 407 to select a given provider data object (e.g., so as to reproduce the selection step 302-2), and the mediation server 108 can request specific details of the given provider data object in the one or more provider data objects 608 from the provider system 102, where the specific details include the fixed price of the given provider data object, and the specific details are requested using the corresponding identifier of the given provider data object (e.g., offer identifier). For example, as depicted, the mediation server 108 provides a request 610 that contains the identifier of the given provider data object. Although this example is described with respect to one given provider data object, the mediation server 108 can request specific details of multiple given provider data objects, such that the request 610 includes more than one identifier.

[0115] As depicted, the provider system 102 receives the identifier of the request 610 and returns the provider data object 612 (and / or corresponding offer) identified by the identifier of the request 610; the provider data object 612 (and / or corresponding offer) is understood to include the fixed price of the provider data object 612 and final details, such as the date and time of the flight represented by the provider data object 612. When the request 610 contains more than one identifier, the provider system 102 can return multiple provider data objects that have final prices and details corresponding to that number of identifiers.

[0116] As depicted, the provider system 102 can provide (e.g., at block 506 of method 500) the provider data object 612 to the client device 104, for example, as a response to the communication 604. The client device 104 can then implement the booking step 302-3 and the payment step 302-4, assuming the user of the client device 104 proceeds to book and pay for the flight represented by the provider data object 612.

[0117] As depicted, the provider system 102 can alternatively store (e.g., at block 508 of method 500) the provider data object 612 in the memory 400, e.g., as a previous provider data object 406. Other information, such as the communication 604 and one or more requests 606 and / or requests 610, can be stored at the historical data 404, as well as whether the flight associated with the provider data object 612 has been booked and / or paid for, e.g., to better train the various machine learning algorithms described herein in one or more machine learning feedback loops.

[0118] In Figure 6 the example of, it should be understood that method 500 can further include the controller 202 and / or the mediation server 108: receiving the communication 604 from the client device 104, the communication 604 including details for generating one or more requests 606 (e.g., of block 502); in response to receiving the communication 604, implementing the reproduction (e.g., of block 502); in response to receiving one or more provider data objects 608 from the provider system 102 (e.g., at block 504), and based on the historical data 404 associated with the client device 104 (e.g., represented by the client device rules 407), requesting from the provider system 102 specific details of a given provider data object of the one or more provider data objects 608, the specific details including a fixed price of the given provider data object, the specific details being requested using the corresponding identifier of the given provider data object; and implementing providing (e.g., at block 506) one or more provider data objects and identifiers of the one or more provider data objects to the client device 104 by: providing the specific details of the given provider data object (e.g., in the form of the provider data object 612) to the client device 104. In some examples, the communication 604 is received without any provider data object identifier (e.g., such as a quote identifier) in the case where the client device 104 has not performed a previous request step (such a previous request step including communication with the mediation server 108).

[0119] In other words, method 500 can further include the controller 202 and / or the mediation server 108: in response to receiving one or more provider data objects 608 from the provider system 102, and based on the historical data 404 associated with the client device 104 (e.g., represented by the client device rules 407), further narrowing the number of the one or more provider data objects 608 that are provided to the client device 104 and stored at the one or more memories 400.

[0120] Next note Figure 7, where the client device 104 does not implement the request and / or shopping steps internally or in combination with the mediation server 108. Instead, the mediation server 108 can process previous provider data objects 406 (which can represent a cache of provider data objects and from which responses to requests for provider data objects from the client device 104 can be populated) to determine which of the previous provider data objects 406 can be "refreshed" and / or updated. For example, the mediation server 108 can maintain the previous provider data objects 406 as a cache of provider data objects, and there can be a condition that none of the previous provider data objects 406 should be older than a given time period (e.g., such as 1 day, 1 week, and / or any other suitable time period). Thus, the mediation server 108 can periodically process the previous provider data objects 406 to determine which of the previous provider data objects 406 are older than the given time period and initiate a method 500 to update the previous provider data objects 406, as described next. However, the determination of when to update the previous provider data objects 406 and / or which of the previous provider data objects 406 to update can occur in any suitable manner.

[0121] For example, the mediation server 108 can determine that one or more of the previously received provider data objects 406 will be updated (e.g., based on age or any other suitable factor) and implement a replay (e.g., of block 502) in response to determining that one or more of the previously received provider data objects 406 will be updated.

[0122] In particular, as depicted, the mediation server 108 can provide one or more requests 706 to the provider system 102, the one or more requests 706 including details of the provider data objects of the previously received provider data objects 406 that have been determined to be updated. However, the one or more requests 706 omit quote identifiers and the like specific to the previously received provider data objects 406, but these identifiers do not identify new provider data objects 406 and / or their quotes. The number of the one or more requests 706 can be optimized as described herein.

[0123] Similar to that described with respect to Figure 6 the provider system 102 receives the one or more requests 706, searches for provider data objects based on the one or more requests 706, and returns to the mediation server 108 one or more provider data objects 708 that the mediation server 108 (e.g., at block 504 of method 500) receives. The one or more provider data objects 608 are understood to include identifiers, such as quote identifiers and the like.

[0124] The mediation server 108 may store one or more provider data objects 608 (e.g., at block 508 of method 500) at the memory 400, e.g., at a previously received provider data object 406; in particular, the provider data object 608 stored at the previously received provider data object 406 may replace a previously received provider data object determined to need updating.

[0125] Accordingly, method 500 may further include, by the controller 202 and / or the mediation server 108: determining that one or more previously received provider data objects 406 stored at one or more memories 400 are to be updated; implementing a replay (e.g., of block 502) in response to determining that one or more previously received provider data objects 406 are to be updated; and implementing a storage (e.g., of block 508) of one or more provider data objects 708 at one or more memories 400 by: at one or more memories 400, replacing (e.g., those determined to be updated) one or more previously received provider data objects 406 with one or more provider data objects 708.

[0126] In some of these examples, method 500 may further include narrowing one or more provider data objects 708 to replace one or more previously received provider data objects 406 (e.g., those determined to be updated) by determining which of the one or more provider data objects 708 received from the provider system 102 best correspond to the previously received provider data objects 406. For example, one of the previously received provider data objects 406 may represent a flight from Toronto to Paris at a given departure time (e.g., 08:00), and multiple provider data objects 708 received from the provider system 102 may correspond to that flight, but none have exactly the same departure time as the previous flight. In these examples, the provider data object 708 received from the provider system 102 with a departure time closest to the given departure time (e.g., 08:00) may be used to replace the previously received provider data object 406. For example, multiple provider data objects 708 received from the provider system 102 may represent flights from Toronto to Paris, with respective departure times of 07:30, 07:59, and 09:00, and the provider data object 708 representing the 07:59 flight may replace the 08:00 flight of the previously received provider data object 406.

[0127] Next note Figure 8 that depicts another example of method 500, which is similar to the example of Figure 6 but uses a general provider data object description 408.

[0128] In particular, the client device 104 may implement a request (e.g., shopping) step 802 similar to the request step 602 and provide a communication 804 similar to the communication 604 to the mediation server 108. The communication 804 is understood to contain details for generating a request to the provider system 102 and may include, but is not limited to, details of the provider data object selected at the request step 802.

[0129] However, compared to the example of Figure 6 , at the example of Figure 8 , the mediation server 108 may compare the details of the communication 804 with the general provider data object description 408, e.g., to use the details of the communication 804 to select one or more general provider data object descriptions 408. For example, the details of the communication 804 may indicate a request for the price of a flight from Toronto to Paris (e.g., on a specific date), and the general provider data object description 408 may indicate the most popular itineraries for such flights (e.g., flights departing between 07:30 and 08:30). Thus, the mediation server 108 may generate one or more requests 806 that are similar to the one or more requests 606 but based on one or more general provider data object descriptions 408 selected using the details of the communication 804. In particular, the option 402 is also used to generate the one or more requests 806 as described above. For example, one or more general provider data object descriptions 408 may be selected based on the details of the communication 804, and the option 402 may be used to generate the one or more requests 806. For example, as described above, the option 402 may indicate that the provider system 102 provides flights between given airports in the cities specified in the communication 804; thus, the one or more requests 806 may contain conditions for searching for flights between two airports (e.g., rather than between two cities) and only search for flights departing between the times in the selected general provider data object description 408.

[0130] As depicted, similar to the example of Figure 6 , the provider system 102 returns a provider data object 808 (e.g., similar to the provider data object 808) in response to the request 806, and the mediation server 108 may provide the provider data object 808 to the client device 104 as a response to the communication 804 and / or store the provider data object 808 at the memory 400. Although not depicted, the mediation server 108 may apply the client device rules 407 to the provider data object 808 before providing the provider data object 808 to the client device 104, similar to that described with respect to Figure 6 .

[0131] Accordingly, method 500 may further include, for controller 202 and / or mediation server 108: receiving, from client device 104, a communication 804 that includes details for generating one or more requests 606; using the details to select, from one or more memories 400, one or more general provider data object descriptions 408; in response to implementing (e.g., the) selection of one or more general provider data object descriptions 408, implementing a reproduction (e.g., at block 502) of the one or more general provider data object descriptions 408, which are also used to narrow the number of one or more provider data objects 808 requested via one or more requests 806; and implementing providing (e.g., at block 506) to client device 104 the one or more provider data objects 808 and an identifier (e.g., an offer identifier) of the one or more provider data objects 808. In some examples, communication 804 is received without any prior request step by client device 104 (such prior request step including communication with mediation server 108), and the communication 804 does not have any provider data object identifier (e.g., such as an offer identifier).

[0132] It should now be apparent that the operations and functions of the devices described herein are so complex that they need to be implemented on a computer system and are not actually executable in the human mind. In particular, computing devices such as those set forth herein are understood to require and provide a speed, accuracy, and complexity management that is not achievable by human mental steps, as well as the digital nature inherent in such operations (e.g., the human mind cannot directly interact with RAM or other digital storage, cannot transmit or receive electronic messages, and other features and functions set forth herein).

[0133] In this specification, an element may be described as "configured to" perform one or more functions or "configured for" such functions. Generally, an element configured to perform or configured for performing a function is enabled to perform the function, or is suitable for performing the function, or is adapted to perform the function, or is operable to perform the function, or is otherwise capable of performing the function.

[0134] It should be understood that, for the purposes of this specification, the phrases "at least one of X, Y, and Z" and "one or more of X, Y, and Z" may be construed to mean only X, only Y, only Z, or any combination of two or more of X, Y, and Z (e.g., XYZ, XY, YZ, XZ, etc.). Similar logic may apply to any two or more items in any expression of "at least one..." and "one or more...".

[0135] The terms "about", "substantially", "essentially", "approximately", etc. are defined as "close to", e.g., as understood by those skilled in the art. In some examples, these terms are understood to be "within 10%", in other examples "within 5%", in still other examples "within 1%", and in yet other examples "within 0.5%".

[0136] Those skilled in the art will recognize that in some examples, the functionality of the devices and / or methods and / or processes described herein can be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read only memories (EEPROMs), etc.) or other related components. In other examples, the functionality of the devices and / or methods and / or processes described herein can be implemented using a computing device capable of accessing a code memory (not shown) that stores computer readable program code for operation of the computing device. The computer readable program code can be stored on a computer readable storage medium that is fixed, tangible and directly readable by these components (e.g., removable disk, CD-ROM, ROM, fixed disk, USB drive). Additionally, it should be recognized that the computer readable program can be stored as a computer program product including a computer usable medium. Additionally, a permanent storage device can include computer readable program code. It should also be recognized that the computer readable program code and / or computer usable medium can include non-transitory computer readable program code and / or non-transitory computer usable medium. Alternatively, the computer readable program code can be stored remotely, but can be transmitted to these components via a modem or other interface device connected to a network (including but not limited to the Internet) through a transmission medium. The transmission medium can be a non-mobile medium (e.g., optical and / or digital and / or analog communication lines) or a mobile medium (e.g., microwave, infrared, free space optics or other transmission schemes) or a combination thereof.

[0137] Those skilled in the art will recognize that there are many more possible alternative examples and modifications, and the above examples are merely illustrative of one or more examples. Therefore, the scope is limited only by the appended claims.

Claims

1. A method, comprising: reproducing, via an intermediary server, a request step for one or more provider data objects, the provider data objects representing at least one item provided by a provider system, the reproducing of the request step including providing to the provider system one or more requests for the one or more provider data objects, the one or more requests being one or more generated and modified based on options associated with the provider system stored at one or more memories, the options being for narrowing the number of one or more provider data objects requested via the one or more requests; receiving, at the intermediary server, the one or more provider data objects from the provider system, and one or more of the following: providing the one or more provider data objects from the intermediary server to a client device, and storing the one or more provider data objects at the one or more memories via the intermediary server.

2. The method of claim 1, wherein the reproducing of the request step occurs in the case where no previous request step has been performed by the client device.

3. The method of claim 1 or claim 2, further comprising: receiving, from the client device, a communication including details for generating the one or more requests; in response to receiving the communication, implementing the reproducing of the request step; in response to receiving the one or more provider data objects from the provider system and based on historical data associated with the client device, requesting specific details of a given provider data object among the one or more provider data objects from the provider system, the specific details including a fixed price of the given provider data object, the specific details being requested using a corresponding identifier of the given provider data object; and implementing providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device by: providing the specific details of the given provider data object to the client device.

4. The method of claim 3, wherein the communication is received in the case where no previous request step has been performed by the client device, and the communication does not have any provider data object identifier.

5. The method of any one of claims 1 to 4, further comprising: determining that one or more previously received provider data objects stored at the one or more memories are to be updated; in response to determining that the one or more previously received provider data objects are to be updated, implementing the reproducing of the request step; and implementing storing the one or more provider data objects at the one or more memories by: replacing the one or more previously received provider data objects with the one or more provider data objects at the one or more memories.

6. The method of any one of claims 1 to 5, further comprising: receiving, from the client device, a communication including details for generating the one or more requests; Select one or more general provider data object descriptions from the one or more memories using the details; In response to implementing the selection of the one or more general provider data object descriptions, implement reproducing the request steps, the one or more general provider data object descriptions also being used to narrow the number of one or more provider data objects requested via the one or more requests; and, Implement providing the one or more provider data objects and the identifiers of the one or more provider data objects to a client device.

7. The method according to claim 6, wherein the communication is received without a prior request step by the client device and the communication does not have any provider data object identifiers.

8. The method according to any one of claims 1 to 7, further comprising: In response to receiving the one or more provider data objects from the provider system and based on historical data associated with the client device, further narrow the number of the one or more provider data objects that are provided to the client device and stored at the one or more memories as the one or more.

9. The method according to any one of claims 1 to 8, wherein the options are based on pre-populated information that is received from and associated with the provider system, the options including provider data object types that are available and unavailable from the provider system.

10. The method according to any one of claims 1 to 9, further comprising determining corresponding numbers of the one or more requests to be provided based on historical data associated with the provider system.

11. The method according to claim 10, wherein the historical data indicates the speed of the provider system when previously responding to historical provider data object requests.

12. A mediation server, comprising: A communication interface; And A controller configured to: Reproduce request steps for one or more provider data objects, the provider data objects representing at least one item provided by a provider system, reproducing the request steps including providing to the provider system one or more requests for the one or more provider data objects, the one or more requests being generated and changed based on options associated with the provider system stored at one or more memories, the options being used to narrow the number of one or more provider data objects requested via the one or more requests; Receive the one or more provider data objects from the provider system via the communication interface, and one or more of the following: Provide the one or more provider data objects to a client device via the communication interface, and Store the one or more provider data objects at the one or more memories.

13. The mediation server according to claim 12, wherein reproducing the request steps occurs without a prior request step by the client device.

14. The mediation server according to claim 12 or claim 13, wherein the controller is further configured to: Receive a communication from a client device that includes details for generating the one or more requests; In response to receiving the communication, implement the request steps; In response to receiving the one or more provider data objects from a provider system and based on historical data associated with the client device, request specific details of a given provider data object among the one or more provider data objects from the provider system, the specific details including a fixed price of the given provider data object, and the specific details are requested using a corresponding identifier of the given provider data object; and Implement providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device by: providing the specific details of the given provider data object to the client device.

15. The mediation server according to claim 14, wherein the communication is received when the client device has not performed a previous request step, and the communication does not have any provider data object identifiers.

16. The mediation server according to any one of claims 12 to 15, wherein the controller is further configured to: Determine that one or more previously received provider data objects stored at the one or more memories are to be updated; In response to determining that the one or more previously received provider data objects are to be updated, implement the request steps; And Implement storing the one or more provider data objects at the one or more memories by: replacing the one or more previously received provider data objects with the one or more provider data objects at the one or more memories.

17. The mediation server according to any one of claims 12 to 16, wherein the controller is further configured to: Receive a communication from a client device that includes details for generating the one or more requests; Use the details to select one or more general provider data object descriptions from the one or more memories; In response to implementing the selection of the one or more general provider data object descriptions, implement the request steps, and the one or more general provider data object descriptions are also used to narrow the number of the one or more provider data objects requested via the one or more requests; and, Implement providing the one or more provider data objects and identifiers of the one or more provider data objects to the client device.

18. The mediation server according to any one of claims 12 to 17, wherein the controller is further configured to: in response to receiving the one or more provider data objects from a provider system and based on historical data associated with the client device, further narrow the number of the one or more provider data objects provided to the client device and stored at the one or more memories.

19. The mediation server according to any one of claims 12 to 18, wherein the options are based on pre-populated information, the pre-populated information being one or more received from and associated with a provider system, the options including provider data object types that are one or more available and unavailable from the provider system.

20. The mediation server according to any one of claims 12 to 19, wherein the controller is further configured to: determine a corresponding quantity of the one or more requests to be provided based on historical data associated with the provider system.

Images