System, apparatus and method for memory management

Abstract

A device for memory management may receive a configuration dataset defining a plurality of attributes representing a plurality of discrete units. The device can associate a first field with each of the attributes and define an aggregate field for each of the units, where the aggregate field is based on at least one of the first fields for each of the attributes respective to each of the units.

Description

SYSTEM, APPARATUS AND METHOD FOR MEMORY MANAGEMENTFIELD

[0001] The present specification relates generally to computer and network storage and retrieval, and more specifically memory management of searchable data.BACKGROUND

[0002] With the majority of travel inventory searches and bookings occurring over the Internet, various technical challenges have emerged. Popular platforms often face high traffic volumes, particularly during peak travel times, leading to potential server slowdowns or crashes. This shift has also imposed substantial demands on data storage, as the online ecosystem generates significant amounts of data related to bookings, user profiles, and ticket details. Furthermore, real-time data processing has become imperative to ensure timely availability checks, but such instantaneous processing can heavily tax system resources, especially when multiple concurrent requests are made. Additionally, the complexity of travel searches has grown, with users now demanding intricate queries, necessitating significant computational power and memory.SUMMARY

[0003] An aspect of the specification provides a computer-implemented method for managing memory in an inventory system, the method including: receiving a configuration dataset defining a plurality of attributes representing a plurality of units; associating a first field with each of the attributes; defining an aggregate field for each of the units; the aggregate field based on at least one of the first fields for each of the attributes respective to each of the units; receiving a first value for each of the first fields; determining aggregate values for each of the aggregate fields; and, generating a unit data set including the values; the unit data set searchable for units that match provided attributes; and, storing the unit data set in a memory cache accessible via a network.

[0004] An aspect of the specification provides a method wherein the aggregate field is based on a summation of the first values or a weighted summation of the first values.

[0005] An aspect of the specification provides a method further including: retrieving a subset of units from the unit data set based on search query of attributes that match attributes within the subset; and, sending the subset across a communication network for display on a remote client device.

[0006] An aspect of the specification provides a method wherein the unit data set is organized in a grid.

[0007] An aspect of the specification provides a method wherein the values of the grid are organized based on weightings assigned to each attribute.

[0008] An aspect of the specification provides a method wherein the values of the grid include derivation rules.

[0009] An aspect of the specification provides a method wherein the derivation rules include per date, day or week, and room types.

[0010] An aspect of the specification provides a method further including: receiving a set of predefined validity rules; comparing the values for each unit against the rules; and rejecting values that do not conform to the validity rules.

[0011] An aspect of the specification provides a method further including receiving updated first values for the rejected values.

[0012] An aspect of the specification provides a method wherein the attributes include at least one of a Bed type, a view, and an area.

[0013] An aspect of the specification provides a method further including: receiving a second value for at least one of the fields that updates the first value for the at least one of the fields; redetermining aggregate values for each of the aggregate fields; and, recaching an unit data set including the values; the unit data set searchable for units that match provided attributes.

[0014] An aspect of the specification provides a search engine having a processor and memory; the processor configured to: receive a configuration dataset defining a pluralityof attributes representing a plurality of units; associate a first field with each of the attributes; define an aggregate field for each of the units; the aggregate field based on at least one of the first fields for each of the attributes respective to each of the units; receive a first value for each of the first fields; determine aggregate values for each of the aggregate fields; and, generate a unit data set including the values; the unit data set searchable for units that match provided attributes; and, cache the unit data set for access via a network.

[0015] An aspect of the specification provides a search engine wherein the memory is volatile memory.

[0016] An aspect of the specification provides a search engine wherein the unit data set has a primary index that is searchable on the first field.

[0017] An aspect of the specification provides a search engine wherein the unit data set has a secondary index that is based on the aggregate field and the primary index points to the secondary index.

[0018] An aspect of the specification provides a search engine wherein the aggregate field is based on a summation of the first values or a weighted summation of the first values.

[0019] An aspect of the specification provides a search engine wherein the processor is further configured to: retrieve a subset of units from the unit data set based on search query of attributes that match attributes within the subset; and, send the subset across a communication network for display on a remote client device.

[0020] An aspect of the specification provides a search engine wherein the processor is further configured to: receive a set of predefined validity rules; compare the values for each unit against the rules; and reject values that do not conform to the validity rules.

[0021] An aspect of the specification provides a search engine wherein the processor is further configured to receive updated first values for the rejected values.

[0022] An aspect of the specification provides a search engine wherein the processor is further configured to: receive a second value for at least one of the fields that updates the first value for the at least one of the fields; redetermine aggregate values for each of the aggregate fields; and, recache a unit data set including the values; the unit data set searchable for units that match provided attributes.

[0023] An aspect of the specification provides a search engine wherein the unit data set is stored in the memory as a NoSQL database.

[0024] An aspect of the specification provides a search engine wherein the unit data set is stored in a memory that is remote from the search engine.

[0025] The present specification also contemplates methods, systems, apparatuses and computer readable media according to the foregoing.BRIEF DESCRIPTION OF THE FIGURES

[0026] The present specification includes the attached Figures, in which:

[0027] Figure 1 shows a system for travel booking search normalization.

[0028] Figure 2 shows a schematic diagram of a non-limiting example of internal components of search engine from Figure 1 .

[0029] Figure 3 shows a flowchart depicting a method for managing memory in an inventory system

[0030] Figure 4 shows a flowchart depicting a method for searching managed memory of an inventory system.

[0031] Figure 5 shows an example pricing grid.DETAILED DESCRIPTION

[0032] Figure 1 shows a system for travel booking search normalization indicated generally at 100. System 100 comprises a plurality of accommodation actor engines 104- 1 , 104-2 ... 104-n. (Collectively, engines 104-1 , 104-2 ... 104-n are referred to as engines 104, and generically, as engine 104. This nomenclature is used elsewhere herein.) In system 100, engines 104 connect to a network 108 such as the Internet. Network 108 interconnects accommodation actor engines 104 with a plurality of client devices 1 16, at least one administrator terminal 1 18 and a search engine 120. As will be discussed further below, search engine 120 performs a number of processing functions for system 100.

[0033] Accommodation actor engines 104 can be based on any present or future electronic servers or computing architectures that, amongst other things, manage electronic bookings representing one or more specific lodging locations including their accommodation units and associated attributes such as the following non-limiting examples:1. Amenities: Including Wi-Fi, television, minibar, coffee maker, safe, iron, and ironing board.2. Bed Size: Queen, Double, King and number of beds3. Bathroom Facilities: Bathtub or shower, toiletries (soap, shampoo, conditioner, body lotion), towels, hairdryer, and possibly a bidet.4. Furniture: Desks, chairs, nightstands, lamps, sofas, or armchairs.5. View: Whether the room faces the ocean, city, garden, mountains, or other notable sights.6. Room Size: Qualitative measurements such as suite, apartment, house, or family room, or quantitative measurements such as area.7. Air Conditioning and Heating: Climate control systems.8. Soundproofing: To prevent external noises from disturbing guests.9. Decor and Style: The aesthetic and theme of the room.10. Balcony or Terrace: An outdoor space for guests to enjoy.11. Closet Space: Including hangers and possible extra bedding.12. Accessibility Features: For guests with disabilities, like ramps, wider doorways, or grab bars in the bathroom.13. Flooring: Whether it's carpeted, wooden, tiled, etc.14. Room Service Availability: Whether guests can order food and drinks to their room.15. Smoke-Free vs. Smoking Rooms: Depending on the hotel's policies.16. Location within the Property: Proximity to elevators, ground floor vs. higher floors, near the pool or far from the dining area.17. Kitchenette or Full Kitchen: Especially in extended-stay lodgings or suites, including a microwave, refrigerator, stove, and utensils.18.Technology Features: USB ports, smart TVs, voice-activated assistants, or automated curtains.19. Security: Electronic door locks, peepholes, and chain locks.20.Additional Sleeping Arrangements: Such as pull-out sofas or rollaway beds.

[0034] Search engine 120, can be any type of electronic server or computing architecture that facilitates searching and booking interactions between client devices 116 and accommodation actor engines 104.

[0035] Client devices 116 can be any type of human-machine interface for interacting with search engine 120. For example, client devices 116 can include traditional laptop computers, desktop computers, mobile phones, tablet computers and any other devicethat can be used to receive and send content that complement the input and output hardware devices associated with a given client device 1 16. It is contemplated client devices 1 16 can include virtual or augmented reality gear complementary to virtual reality or augmented reality or “metaverse” environments that can be offered on collaboration engines 104. Client devices 1 16 can be operated by different users 124 that are associated with a respective identifier object 128 that uniquely identifies a given user 124 accessing a given client device 1 16 in system 100.

[0036] Administrator terminal 1 18 can also be any type of human-machine interface of the same types as client devices 1 16. Administrator terminal 118 is operated by an administrator 126. There can be one administrator terminal 1 18 for all accommodation actor engines 104, and / or in variants, a plurality of administrator terminals 1 18 respective to one or more accommodation actor engines 104.

[0037] The present specification contemplates scenarios where users 124 may wish to search for accommodation units offered via one or more accommodation actor engines 104. The present specification further contemplates that such searches may be based on attributes of the accommodation units.

[0038] Administrator 126 operates administrator terminal 1 18 and receives input representing configuration datasets defining attributes representing discrete accommodation units for each accommodation actor engine 104 at search engine 120 for what types of accommodations can be searched and booked by users 124.

[0039] In a present example embodiment, engines 104 can be based on servers hosted by individual accommodation actors such as hotels, resorts and cruise ships. For example, an inventory of hotel rooms may be hosted on engine 104. As will become more apparent with the benefit of reading this specification, each engine 104 can be connected directly to their own application travel interfaces (API)s, or via travel aggregators like a global distribution system (GDS), such as Travelfusion, or Amadeus, or via aggregators such as Amadeus Travel Platform), using certain APIs that can be based on the Electronic Data Interchange For Administration, Commerce and Transport, (“Edifact”) format or another format.

[0040] Thus, individual accommodation actors may, for example, use a Global Distribution System (GDS) such as Amadeus, Sabre, or Travelport, and / or the Amadeus Central Reservation System (CRS) or the like which compute data including accommodations and pricing on behalf of individual travel actors.

[0041] Accordingly, client devices 1 16 are based on any suitable client computing platform operated by users 124 that may have an interest in the content being provided by engines 104. Each device 116 and its user 124 is thus typically associated with a user identifier object 128, particularly if any booking functions are to be utilized.

[0042] A person of skill in the art is to recognize that the form of an identifier object 128 is not particularly limited, and in a simple example embodiment, can be simply an alpha- numerical sequence that is entirely unique in relation to other identifier objects in system 100. Identifier objects can also be more complex as they may be combinations of account credentials (e.g. user name, password, two-factor authentication token, etc.) that uniquely identify a given user 124. Identifier objects themselves may also be indexes that point to other identifier objects, such as one or more accounts. The salient point is that they are uniquely identifiable within system 100 in association with what they represent.

[0043] Having described an overview of system 100, it is useful to comment on the hardware infrastructure of system 100. Figure 2 shows a schematic diagram of a nonlimiting example of internal components of search engine 120.

[0044] In this example, search engine 120 includes at least one input device 204. Input from device 204 is received at a processor 208 which in turn controls an output device 212. Input device 204 can be a traditional keyboard and / or mouse to provide physical input. Likewise output device 212 can be a display. In variants, additional and / or other input devices 204 or output devices 212 are contemplated or may be omitted altogether as the context requires.

[0045] Processor 208 may be implemented as a plurality of processors or one or more multi-core processors. The processor 208 may be configured to execute different programming instructions responsive to the input received via the one or more inputdevices 204 and to control one or more output devices 212 to generate output on those devices.

[0046] To fulfill its programming functions, the processor 208 is configured to communicate with one or more memory units, including non-volatile memory 216 and volatile memory 220. Non-volatile memory 216 can be based on any persistent memory technology, such as an Erasable Electronic Programmable Read Only Memory (“EEPROM”), flash memory, solid-state hard disk (SSD), other type of hard-disk, or combinations of them. Non-volatile memory 216 may also be described as a non- transitory computer readable media. Also, more than one type of non-volatile memory 216 may be provided.

[0047] Volatile memory 220 is based on any random-access memory (RAM) technology. For example, volatile memory 220 can be based on a Double Data Rate (DDR) Synchronous Dynamic Random-Access Memory (SDRAM). Other types of volatile memory 220 are contemplated.

[0048] Processor 208 also connects to network 108 via a network interface 232. Network interface 232 can also be used to connect another computing device that has an input and output device, thereby obviating the need for input device 204 and / or output device 212 altogether.

[0049] Programming instructions in the form of applications 224 are typically maintained, persistently, in non-volatile memory 216 and used by the processor 208 which reads from and writes to volatile memory 220 during the execution of applications 224. Various methods discussed herein can be coded as one or more applications 224. One or more tables or databases 228 are maintained in non-volatile memory 216 for use by applications 224.

[0050] The infrastructure of search engine 120, or a variant thereon, can be used to implement any of the computing nodes in system 100, including accommodation actor engines 104. Furthermore, search engine 120 and accommodation actor engines 104 may also be implemented as virtual machines and / or with mirror images to provide loadbalancing. Functions of search engine 120 may also be distributed amongst different accommodation actor engines 104, thereby obviating the need for a central search engine 120. By the same token, a plurality of search engines 120 may be provided. Overall, the engines 104 and / or engine 120 and other nodes in system 100 may be implemented using cloud computing platforms such as Microsoft Azure or Amazon Web Services (AWS).

[0051] Furthermore, a person of skill in the art will recognize that the core elements of processor 208, input device 204, output device 212, non-volatile memory 216, volatile memory 220 and network interface 232, as described in relation to the server environment of search engine 120, have analogues in the different form factors of client machines such as those that can be used to implement client devices 1 16 and administrator terminal 118. Again, client devices 1 16 can be based on computer workstations, laptop computers, tablet computers, mobile telephony devices or the like.

[0052] Figure 3 shows a flowchart depicting a method for managing memory in an inventory system indicated generally at 300. Method 300 can be implemented on system 100. Persons skilled in the art may choose to implement method 300 on system 100 or variants thereon, or with certain blocks omitted, performed in parallel or in a different order than shown. Method 300 can thus also be varied. However, for purposes of explanation, method 300 will be described in relation to its performance on system 100 with a specific focus on treating method 300 as, for example, application 224-1 maintained within search engine 120 and its interactions with the other nodes in system 100.

[0053] Block 304 comprises receiving a configuration dataset defining attributes representing discrete accommodation units. (Note that, in variants, common or substantially identical accommodation units having similar or the same attributes can be grouped into inventory types, thereby permitting the bulk definition of these groups. The definition of “common” or “substantially identical” can be configured by administrator 126. Furthermore, it can also be desired to establish group attributes, such as for example, defining a “kitchen” attribute to include a “refrigerator” and “microwave oven”. The attributes can be predefined for all engines 104 or they can be individually defined foreach accommodation actor engine 104 and / or for different lodgings within a particular accommodation actor engine 104. It is thus contemplated that the administrator 126 can define the fields of the dataset, including attribute name and dataset, for a particular lodging as hosted by a particular accommodation actor engine 104. The attributes can be based on any of the examples discussed earlier, or they can be based on additional attributes that will occur to those skilled in the art.

[0054] Block 308 comprises associating at least one additional field with each of the attributes defined at block 304. The at least one of the fields includes a numerical value representing a financial amount that reflects the perceived value to a user 124 for that particular attribute in a currency that is, typically, familiar to the user 124. Additional fields at block 308 can include a dependency value for the attributes defined at block 304, such as the presence or absence of the attribute.

[0055] Block 312 comprises defining an aggregate value field based on the at the least one additional fields from block 308. The aggregate value field can be a summation of each of the at least one additional fields from block 308. The aggregate value field can also be a weighted summation of each of the at least one additional fields from block 308, wherein each additional field from block 308 is given a different weighting. (The aggregate value field can be determined through other computations, such as including a multiplier when two or more attributes are selected. For example, “ocean view” and “king size bed” when selected together may have a multiplier of, for example, 1 .2 to add a twenty percent premium for the combination of those two. Other example multipliers and computation will now occur to those skilled in the art.)

[0056] Table 228-1 shows an example of resulting performance of block 304, block 308, block 312, block 316 and block 320.TABLE 228-1 Example Configuration Dataset - Populated (including references to blocks in method 300)

[0057] Explaining the example in Table 228-1 in greater detail, block 304 comprised identifying four attributes: an area of the accommodation unit; a first bed; a second bed; a view and an outdoor space. It is to be emphasized that these are non-limiting examples and that the choice of types and numbers of attributes can be predefined or discretionary to administrator 126. Block 308 comprised defining a descriptor and a value for each attribute. Again, the descriptor itself is optional and can be used to further refine the attribute, such as a room type, bed type, view type or outdoor space type. Descriptor and attribute fields can thus be merged as desired. Block 308 also comprised the inclusion of a numerical value field expressed in a currency familiar to each user 124. Block 316 comprised identifying three separate units, and, respective to each unit, providing an individual value for the descriptor and value fields, such as indicating a type of bed as being “King” or that a particular Outdoor Space as having a “Balcony” or “Terrace”. Furthermore, block 316 included adding a numerical value such as “50” for a King Bed.Block 320 comprised summing (without any weighting) each of the numerical values to arrive at a total value ascribed to a given unit. Full details of the example Table 228-1 can be found by examining the Table itself.

[0058] For convenience, Table 228-1 is illustrated again but without including reference to the blocks in method 300 that were respective to the creation of Table 228-1 .TABLE 228-1 Example Configuration Dataset - Populated (omitting references to blocks in method 300)

[0059] Block 324 comprises generating a unit data set searchable by the attributes from Table 228-1 . The unit data set can be searchable for units matching a query primarily on attribute searches, with the ability to retrieve the full data for the unit to present to a user 124 during a search. Table 228-2 shows an example of a unit data set according to block 328 including a tree structure with attributes as the primary index.TABLE 228-2Example Unit Dataset

[0060] Other ways of generating the unit data set are contemplated, including combining Table 228-1 with Table 228-2 so that each unit is quickly searchable by attribute in Table 228-2, but the full set of attributes can be retrieved from Table 228-1 so that a query from a device 1 16 can be based on the attributes, while the full set of possible units that satisfy the query are retrievable from Table 228-1 . Alternatively, Table 228-2 can be a secondary index that simply points to the relevant unit in Table 228-1 .

[0061] Example: Primary Table (Unit-Based):

[0063] Other data structures that facilitate rapid searching by one or more attributes while allowing retrieval of full unit details include B+ trees, will now occur to those skilled in the art. Indices may also be used.

[0064] Block 328 comprises caching the data set from block 324 into storage that is readily searchable by users 124. More particularly, the data set from block 324 can be retrievable from non-volatile memory 216 and / or a copy can be placed into volatile memory 220 to facilitate even more rapid retrieval from a device 1 16 accessing engine 120. Partial copies may also be placed in memory 216 that facilitate rapid search and retrieval from memory 200. Notably, however, in certain embodiments the individual values and aggregate values are also available for retrieval and generation on device 1 16 as a result of a query. As will be discussed further below, behavioural responses to thesearch results on devices 1 16, such as conversions, (where an accommodation unit retrieved during a search is actually booked) or bounces (where an accommodation unit is not booked), or other behaviours, can be further used to refine Table 228-1 , including individual values from block 316 and aggregate values from block 320, to reduce overall churn in system 100 so as to increase conversions. Further, the reason for conversions or bounces or other behaviours may be discernable both from the presented individual values and / or the aggregate values, to facilitate criteria for dynamically updating Table 228-1 .

[0065] Note that in various embodiments, the caching mechanism at block 328 can be implemented by blobs in the Key / Value database, and is generally readily readable by client device 1 16 and rather is ready by search engine 120 itself in order to reduce its processing time. When data is updated, (such as when a data are updated via administrator terminal 1 18 the data are pre-processed, re-organized, indexed and stored in a non-human readable format into the cache. As will be elaborated later, when search engine 120 processes a search request, search engine 120 can fetch its data directly from the cache so it benefits from the optimized data structure to get access rapidly to the pre-processed data.

[0066] Note that the caching mechanism at block 328 can include pre-processing such as, but not limited to, validity checks, flattening of the data and / or re-organization of the data before storage.

[0067] It should also be noted that that the example in Table 228-1 is intentionally highly- simplified and that a person of skill in the art will appreciate how the number of attributes, the number of units, the number of lodgings (including hotels, motels, bed and breakfasts, hostels, resorts, inns, campsites, cabins, serviced apartments, guest houses, capsule hotels, farm stays, ice hotels, cruise ship berths, rail car berths, airplane berths on luxury aircraft), as maintained by different engines 104, can massively scale, and the aforementioned search efficiencies can reduce or ameliorate processing, memory and bandwidth burdens on various nodes and links within system 100.

[0068] Figure 4 shows a flowchart depicting a method for searching managed memory of an inventory system indicated generally at 400. Method 400 can be implemented on system 100. Persons skilled in the art may choose to implement method 400 on system 100 or variants thereon, or with certain blocks omitted, performed in parallel or in a different order than shown. Method 400 can thus also be varied. However, for purposes of explanation, method 400 will be described in relation to its performance on system 100 with a specific focus on treating method 400 as, for example, application 224-2 maintained within search engine 120 and its interactions with the other nodes in system 100. Method 400 also typically contemplates that method 300, or a variant thereon, has already been performed and that a cached unit data set is already available either from non-volatile memory 216 or volatile memory 220 or a combination of both.

[0069] Block 404 comprises receiving a search query. In the example of system 100, where Table 228-1 and / or Table 228-2 are cached on engine 120, our example can assume that device 1 16-1 is being accessed by user 124-1 via an account associated with user identifier object 128-1 . Furthermore, our example can assume that user 124-1 is accessing engine 120 and conducting a search for lodging.

[0070] Block 408 comprises parsing and identifying primary fields used in the query. It is thus notable that block 404 and block 408 can be effected in different ways depending on the search interface of engine 120. In certain embodiments, the search interface of engine 120 can be highly structured, such that only the specific attributes or other fields from Table 228-1 (or whatever configuration for Table 228-1 may be effected at method 300) are searchable. In other embodiments, traditional accommodation search fields may be offered which may or may not align with the attributes from the configuration from method 300. In still further embodiments, a natural language processing (NLP) interface may be offered, including the possibility of a large language model (LLM) interface, where an unstructured query may be made at block 404 such as “Please find me hotel rooms with King size beds.” Other examples of search interfaces will be apparent to those skilled in the art. Thus, it can be seen that the search interface is not particularly limited.

[0071] At block 420, it is determined whether there is an attribute field match. To elaborate according to our specific example, block 420 determines whether the search query is based on an attribute that exists in Table 228-1 . A “no” determination leads to block 424 for exception handling, while a “yes” determination leads to block 428 for a structured query search of the cached unit data set from block 328.

[0072] At one extreme, it is possible that the search interface at block 404 can be configured so that it does not even permit the searching by an attribute that does not exist within Table 228-1 , and accordingly, this “No” branch of block 420 is moot, thereby eliminating block 420 and block 424 altogether from method 400. (Here is a salient example of how a person of skill in the art can appreciate that method 400 can be varied and remain within the scope of this specification.)

[0073] However, on the other hand, if the search interface at block 404 can accommodate receiving search queries based on attribute fields that do not exist within Table 228-1 , then a “no” branch is possible at block 420. For example, if the search interface at block 404 is based on a natural language processing (NLP) query, then the received search can include requests for fields that are not included. For example, if the query from block 404 is for units with WiFi, (e.g. an NLP query of the form “Please show me a list of rooms that include WiFi”) then that attribute can be stored at block 408 and then at block 420, a “no” determination will be reached, thereby leading method 400 to block 424 for exception handling. To elaborate, since WiFi is not one of the attributes from “Attribute Name” column in Table 228-1 , then block 420 will arrive at the “no” determination. However, the fact of the “WiFi” attribute being stored at block 408 can be used for later refinement of Table 228-1 , as will be discussed further below.

[0074] Block 424 thus includes exception handling. Exception handling can include a simple error message (e.g. in an NLP interface “I am sorry I cannot search on that attribute. Please choose from the following attributes, ccinclude list of attributes from Table 228-1 »”) that sends method 400 back to block 404 to begin method 400 anew (This branch is not shown in Figure 4). A structured interface can also be provided whereby at block 424, a graphical interface that indicates an error can be generated.Alternatively, block 424 can implement exception handling by reverting to an unstructured search through Table 228-1 and / or any other broader dataset, such as electronic brochures or any other collateral or data set or accounting records generated prior to method 300 previously used to search and book accommodation units. Again, an LLM can be used to assist with such an unstructured search.

[0075] Note however, that using an unstructured search at block 424 results in a greater drain on computing resources of engine 120 than block 428, which will be discussed further below. However, including exception handling block 424 thus accommodates the possibility for understanding which attributes are relevant to the greatest numbers of users 124, thereby allowing the capture of those attributes at block 408 for later use in reconfiguring Table 228-1 so that it is optimized for those attributes that are most sought after. In this manner, Table 228-1 and the resulting cached unit data set at block 328 can, over time, be relatively small and only include the most relevant subset of attributes, thereby reducing memory usage in engine 120. This also has the effect of reducing the frequency of “no” determinations at block 420. As will be discussed further below, the opportunity exists to iteratively reconfigure Table 228-1 and the cached unit data set to be as small as possible, while at the same time satisfying the most common attribute searches from users 124. Threshold numbers of attribute requests at block 408 can be established that will flag a given attribute for inclusion in Table 228-1 to allow a desired balancing of flexibility for users 124 while limiting the amount of memory and other computational resources at engine 120 and the other nodes and links in system 100.

[0076] Thus a “yes” determination at block 420 where the attribute being searched is based on, for example, a search for rooms with a “King Size Bed”. Such a “yes” determination leads to block 428.

[0077] Accordingly, block 428 thus comprises performing a structured search through Table 228-1 , or Table 228-2, and / or any structured searching technique that complements the caching of the unit dataset from block 328 of method 300. (Note that it possible that no accommodation units matching the criteria are available, leading to a null result.) According to our example, Table 228-3 shows an example of search results thatcan be returned that match the search query 404 and which are a subset of data of the data from Table 228-1 - again recognizing that this is an illustrative simplified example and that system 100 is configured for massive scaling.Table 228-3 Search Results for Units with King-Sized Beds

[0078] Thus, Table 228-3 generated at block 428 includes the two units from the Table 228-1 that have at least one king-sized bed. Note that the detailed breakdown of values for each attribute are excluded in these results but could be included if desired.

[0079] Block 432 comprises returning results. To elaborate, block 432 comprises returning the results of the search from block 428, or the results from the exception handling at block 424. The results are thus responsive to engine 120 processing the search query at block 404.

[0080] According to our specific example involving a query for king size beds, at block 432 the contents of Table 228-3 can be generated in a graphical interface for device 1 16- 1 including a booking option for selecting one of the units.

[0081] (At this point it should be clear that other relevant information such as dates, location, check in times, check out times, taxes, etc. that would accompany a search for an accommodation unit booking are assumed as inherent in these discussions and all relevant blocks in method 300 and method 400, and that this discussion is primarily focusing on the attribute aspect of such bookings. Those other fields are omitted for illustrative simplicity, but are salient to help illustrate additional exacerbating processing and memory burdens on system 100 and how the present specification helps ameliorate those burdens.)

[0082] Block 436 comprises identifying inputs or other behavior that is responsive to the results returned at block 432. To elaborate, block 436 monitors for whether a booking actually occurred, (aka a “conversion”), or another non-conversion event (such as a “bounce”) whereby, notwithstanding the generation of the search results at block 432 that were responsive to the query at block 424, no booking actually resulted. In general terms, a “conversion” would represent that the configuration of Table 228-1 is achieving the desired balance of improving throughput of searches in system 100 and reducing consumption of computing resources, while at the same time leading to meaningful search results that fulfill the objectives of user 124-1 to locate an appropriate accommodation unit and the objectives of a given accommodation actor engine 104-1 to allocating otherwise-empty accommodation units within the inventory of accommodation units.

[0083] It can thus be noted that block 436 executes adjacent to an accommodation unit booking method also executing on engine 120 or elsewhere in system 100, and that method 400 overall relates to searching for accommodation units in a manner that manages the efficient use of memory 216 and memory 220 and other computing resources of system 100.

[0084] Block 440 thus comprises a determination whether to update the configuration. To elaborate, the determination at block 440 is based on one or more performances of method 400, examining a combination of the attributes stored at block 408, the decisions at block 420 and / or the behaviors at block 436. A “yes” determination at block 440 leads to block 444 whereby method 300 is performed again with the information from block 408, block 420 and block 432. Or, a variant of method 300 is performed to establish a new a configuration of structured data fields. Block 444, in general, can be configured to increase the number of “yes” determinations at block 420, to otherwise have a version of Table 228-1 that is memory-efficient and / or results in performance of structured search queries at block 428. Furthermore, block 444 can be configured to increase the overall number of conversions at block 436.

[0085] Accordingly, the determination at block 440 can be based on thresholds whereby if the resource utilization in system 100 (e.g. memory 216 and / or memory 220 and / or equivalents on engines 104) is reduced while achieving an increased number of conversion behaviors at block 436. If the thresholds are within a certain tolerance, then a “no” determination can be made from block 440 and cycles method 400 back to block 404. A “yes” determination can be made if those thresholds are outside that tolerance, where the amount of memory being consumed can be reduced in Table 228-1 by reducing the number of attributes, while still achieving a desired level of conversion behaviors at block 436.

[0086] Thus, a person of skill in the art will appreciate that when method 300 is performed iteratively, in conjunction with the feedback loop of method 400, Table 228-1 can be constantly adjusted to include or exclude attributes based on the attribute fields stored at block 408 that lead to the most conversions at block 432. The other blocks in method 300 can be used to generate and cache a lean version of Table 228-1 that reduces usage of memory 216 and / or memory 220, which is searchable at block 428 in a fashion that uses a lean amount of computing resources, and which leads to the most conversions at block 436.

[0087] In view of the above it will now be apparent that variants, combinations, and subsets of the foregoing embodiments are contemplated. For example, the teachings herein can be expanded to other types of travel actors or e-commerce environments such as airlines, railways, buses, car rentals, car purchases, restaurants, spas, concert venues, exhibition centers, summits, sporting event venues, fairs, conference venues, sporting arenas, museums, art galleries, tours and resort activity centers and the like. The teachings herein may be expanded to cover vacation packages that include combinations of transportation, accommodation, meals and / or destination activities.

[0088] As another example, in terms of exception handling at block 424, it is also contributed that even if no fields match, or a query cannot be specifically aligned with the contents of available inventory, then engine 120 can be configured to still return results based on a best guess, and / or results that only partially fulfill the query. Other forms of exception handling at block 424 will now occur to those skilled in the art.

[0089] As another example variant, the aggregate field of block 312 can based on a summation of the values from block 308 or a weighted summation of the values from block 308.

[0090] As another example variant, the results returned at block 432 can be organized on a graphical user interface on devices 1 16 in a grid. The aggregate values from block 320 of the grid can be organized based on weightings assigned to each attribute from block 308. The values of the grid can include derivation rules that includes a formula or guideline that helps determine the aggregate value at block 320 for an accommodation unit given certain circumstances. Derivation rules can be based on, for example, Dynamic Pricing: Hotels, especially those using advanced revenue management systems, can adjust room rates dynamically based on current demand, historical data, and future predictions. The derivation rules can help determine the value at which a room should be sold at any given time. Reference Rate: Often, a derivation rule will use a "reference rate" or "base rate" as a starting point. This rate might be the standard aggregate value for a room during off-peak times, for example. The derivation rule can adjust this aggregate value up or down based on various factors. Factors InfluencingDerivation: These rules might consider factors like: Occupancy Levels: If nearly all of the accommodation units are booked, the aggregate value may increase. The opposite is also true. Time to Booking: A last-minute booking might have an increased aggregate value than one made months in advance. Day of the Week: Weekdays might have different aggregate values compared to weekends, especially for hotels that cater to business travelers or event goers. Special Events: If there's a major event in town, aggregate values might be increased. Competitor Pricing: Rates of nearby or similar hotels might influence the derivation rule. Length of Stay: Longer stays might receive a per-night discount. Derived Rates: Using these rules, "derived rates" can be created as part of the aggregate value from block 320. For instance, a derived rate might be a discounted aggregate value for members, a special package aggregate value, or an aggregate value for extended stays. Automation and Flexibility: Modern accommodationactor engines 104 can allow administrator 126 to set up such derivation rules once and then engine 120 can adjust aggregate values automatically. The derivation rules can be set per date, day or week, room types, etc.

[0091] Referring now to Figure 5, an example price grid illustrative of the foregoing is indicated generally at 500. Note the various numbers represent a financial amount. No currency is specified as the currency or the fact that the number is financial is secondary to processing efficiencies that are the subject of the present specification. Price grid 500 includes a definition section 504 defining different rate plans, (“RP1 ”, “RP2” and “RP3” respectively corresponding to “Flexible Policy”, “IncludeWE”, and “BusinessPolicy”), and an associated price grid. Price grid 500 also includes a raw data and derivation rule section 508 that shows the base rates for various room types (e.g., Standard, Junior Suite, King, Ocean View, Ocean + King) and guest types (e.g., ADT for adults, TEEN for teenagers) along with the derivation rules to be applied to adjust these rates. Standard (SR) refers to a standard or base room and Junior Suite, King, Ocean View, Ocean + King are attributes (ATT) that can be added on top of a standard room, defining a specific inventory type. In the example two levels of derivations are shown (PG1 and PG2), but one can imagine complex systems with ten levels of derivation or more, and wherein a rate for an attribute may be depend on and be derived of another attribute. Price grid 500 also includes an aggregated section 512 that applies the rules from section 508 toproduce final adjusted rates. A pricing with attributes section 516 shows how specific attributes such as "Ocean," "King," and "King + Ocean" are finally priced under different rate plans, the result of applying section 508 to section 512, illustrating the impact of these attributes on the final room rates.

[0092] To expand further on Figure 5, the example price grid 500 includes a definition section 504 defining different rate plans, namely RP1 (Rate Plan 1 ), RP2 (Rate Plan 2), and RP3 (Rate Plan 3). Each rate plan includes specific pricing groups, namely PG1 (Flexible Policy, Public), PG2 (IncludeWE, Public), and PG3 (BusinessPolicy, Corporate). The Flexible Policy refers to a public rate plan providing flexibility in booking and cancellation terms. The IncludeWE is a public rate plan that includes weekend stays, encouraging longer stays. The BusinessPolicy is a corporate rate plan targeting business travelers with specific amenities suited for corporate clients.

[0093] Price grid 500 also includes a raw data and derivation rule section 508 that shows the base rates for various room types (e.g., Standard, Junior Suite, King, Ocean View, Ocean + King) and guest types (e.g., ADT for adults, TEEN for teenagers) along with the derivation rules applied to adjust these rates. Within Raw Data and Derivation Rule Section 508:

[0094] PG1 : Displays base rates that apply to a standard room and to attributes that can be added to the standard room for particular guest types and occupancy conditions.

[0095] PG2: Shows rates adjusted from PG1 with specific discounts or percentage decreases, demonstrating the application of derivation rules.

[0096] PG3: Further adjusts rates from PG2 with additional discounts, illustrating the cascading effect of policy adjustments.

[0097] Price grid 500 also includes the aggregated section 512 that applies the rules from section 508 to produce final adjusted rates. Aggregated Section 512 compiles the final adjusted rates from all policy groups, showing how rates evolve through each adjustment stage. For example, the Standard room for adults (SR ADT) starts at a base rate of 150in PG1 , is adjusted to 145 in PG2 with a -5 fixed discount, and further reduced to 125 in PG3 with an additional -20 fixed discount.

[0098] The pricing with attributes section 516 shows how specific attributes such as "Ocean," "King," and "King + Ocean" are priced under different rate plans, illustrating the impact of these attributes on the final room rates. The Pricing with Attributes Section 516 demonstrates derived pricing for specific attributes such as Ocean view and King bed. For example, under the Flexible Policy (RP1 ), the rate for a room with an ocean view (Ocean ADT) starts at 170, and for a room with a king bed and ocean view (King + Ocean ADT), it starts at 340. Under IncludeWE (RP2), these rates are adjusted to 163 and 316, respectively. Under BusinessPolicy (RP3), the rates are further reduced to 140 and 270, respectively, illustrating dynamic pricing adjustments based on different rate plans.

[0099] Given the rate plans 516, the base price grid (PG1 in section 508), and the derived price grids (PG2 and PG3 in section 508), during an offline process, the prices for a standard room and the various attributes for a given guest type and an occupancy condition can be precomputed and checked for consistency based on predefined validity rules, as will be explained in more detail in the paragraph below. Upon validation, the accommodation unit data set (e.g. pricing with attributes section 516) from block 328 can be computed and stored in a NoSQL database. This process includes validation of the computation providing an important technological advantage: data requests specifying an attribute and a rate plan can be retrieved without the need to go through a longer and more complex computation process for a rate plan that is deeply nested, (i.e. has many derivation levels). A person of skill the art will recognize that such nested computations can result in exponentially more processing cycles, and thus, in price grids that have even greater complexity than price grid 500, the response times may also take too long to be technically practical. Hence, with the present teachings, lower response times can be provided, and the retrieval process can be made more efficient. Simulations have shown that, with this offline precomputation process, a data request of the type shown in Figure 5 can be answered in about 40 milliseconds using the teachings herein, whereas it can take an additional 100 milliseconds if the computation (retrieval of the price grid,application of the derivation rules, and aggregation to obtain result for requested unit) is performed in real-time.

[0100] Method 300 can further include receiving a set of predefined validity rules and comparing the values for each unit against the rules, and rejecting values that do not conform to the validity rules. Method 300 can further include receiving updated first values for the rejected values. The validity rules can, for example, include comparing the aggregate values determined at block 320 against certain minimum or maximum values. That range of values can be based on historical values for the units based on values established prior to implementation of method 300 and method 400. The range of values can be hard coded. Such validation rules can be applied in conjunction with or in lieu of derivation rules. In general, the validation rules can help protect against an outlier aggregation value where, perhaps inadvertently, the individual field values from block 308 are set so that the aggregation value at block 320 is clearly excessively high (beyond a maximum) or excessively low (below a minimum).

[0101] Method 300 can further comprise receiving a second value for at least one of the rate fields that updates the first value at block 308 for the at least one of the attribute fields; redetermining aggregate values at block 320 for each of the aggregate fields for each unit; and, recaching at block 328 an unit data set including the redetermined values at block 320.

[0102] Method 300 and method 400 can also include machine learning or other automation techniques, whereby the individual values from block 308 for each attribute are dynamically adjusted upwards when there are too many conversion behaviours at block 432 and / or dynamically adjusted downwards when there are too few conversion behaviours at block 432. As a reduced set of attribute fields are established after several iterations of method 300 and method 400, so too can the values from block 308 also be adjusted to achieve a desired level of conversion behaviours at block 432 and / or reduce the number of bounce behaviours at block 432.

[0103] Method 300 and method 400 can also be part of a broader revenue management system which can be used to establish various attribute prices and aggregation computations.

[0104] It is to be understood that method 300 and method 400 can interact with and / or intersect with and / or be integrated with existing Property Management Systems (PMS) and Central Reservations Systems (CRS). Both Property Management System and Central Reservation System serve as integral backbones for efficient operations for accommodation actors. A PMS can be used by individual hotels, motels, resorts, or rental establishments, to manage on-site operations, managing tasks like room bookings, guest check-ins and check-outs, billing, and housekeeping. Furthermore, it often integrates with Point-of-Sale systems to cater to additional guest services, such as dining or spa treatments. A CRS can manage guest reservations from a centralized platform, ensuring inventory distribution across numerous sales channels, and as noted can interact with Global Distribution Systems, Travel Platforms and Online Travel Agencies allowing accommodation units to be accessible across a global implementation of system 100. A person of skill in the art will now appreciate possible relationships between method 300 and / or method 400 with various PMS and CRS.

[0105] A person skilled in the art will now appreciate that the teachings herein can improve the technological efficiency and computational and communication resource utilization across system 100 by providing a cached unit data set that mitigates the need for users 124 to run multiple searches, thereby reducing the overall burden on traffic resources of network 108 and computational resources on engine 120, devices 116 and engines 104. The present teachings can mitigate the need for users 124 to conduct repeated and seemingly endless searches so they can compare all of the attributes of a given accommodation unit, especially those attributes having the highest priority, thereby reducing wastage of Internet bandwidth as well as local and remote processing and memory resources. Engine 120 seeks to optimize for persistence of data from accommodation actors 104, while offering an optimized response time for devices 1 16. This and other technical advantages of this specification will now occur to those of skill in the art.

[0106] It should be recognized that features and aspects of the various examples provided above can be combined into further examples that also fall within the scope of the present disclosure. In addition, the figures are not to scale and may have size and shape exaggerated for illustrative purposes.

Claims

CLAIMS1 . A computer-implemented method for managing memory in an inventory system, the method comprising: receiving a configuration dataset defining a plurality of attributes representing a plurality of units; associating a first field with each of the attributes; defining an aggregate field for each of the units; the aggregate field based on at least one of the first fields for each of the attributes respective to each of the units; receiving a first value for each of the first fields; determining aggregate values for each of the aggregate fields; and, generating a unit data set including the values; the unit data set searchable for units that match provided attributes; and, storing the unit data set in a memory cache accessible via a network.

2. The method of claim 1 wherein the aggregate field is based on a summation of the first values or a weighted summation of the first values.

3. The method of claim 1 or claim 2 further comprising: retrieving a subset of units from the unit data set based on search query of attributes that match attributes within the subset; and, sending the subset across a communication network for display on a remote client device.

4. The method of any one of claims 1 to 3 wherein the unit data set is organized in a grid.

5. The method of claim 4 wherein the values of the grid are organized based on weightings assigned to each attribute.

6. The method of claim 4 or claim 5 wherein the values of the grid include derivation rules.

7. The method of claim 6 wherein the derivation rules include per date, day or week, and room types.

8. The method of any one of claims 1 to 7 further comprising: receiving a set of predefined validity rules; comparing the values for each unit against the rules; and rejecting values that do not conform to the validity rules.

9. The method of claim 8 further comprising receiving updated first values for the rejected values.

10. The method of any one of claims 1 to 9 wherein the attributes include at least one of a Bed type, a view, and an area.1 1 . The method of any one of claims 1 to 10 further comprising: receiving a second value for at least one of the fields that updates the first value for the at least one of the fields; redetermining aggregate values for each of the aggregate fields; and, recaching a unit data set including the values; the unit data set searchable for units that match provided attributes.

12. A search engine having a processor and memory; the processor configured to: receive a configuration dataset defining a plurality of attributes representing a plurality of units; associate a first field with each of the attributes; define an aggregate field for each of the units; the aggregate field based on at least one of the first fields for each of the attributes respective to each of the units; receive a first value for each of the first fields;determine aggregate values for each of the aggregate fields; and, generate a unit data set including the values; the unit data set searchable for units that match provided attributes; and, cache the unit data set for access via a network.

13. The search engine of claim 12 wherein the memory is volatile memory.

14. The search engine of claim 12 or claim 13 wherein the unit data set has a primary index that is searchable on the first field.

15. The search engine of claim 14 wherein the unit data set has a secondary index that is based on the aggregate field and the primary index points to the secondary index.

16. The search engine of any one of claims 12 to 15 wherein the aggregate field is based on a summation of the first values or a weighted summation of the first values.

17. The search engine of any one of claims 12 to 16 wherein the processor is further configured to: retrieve a subset of units from the unit data set based on search query of attributes that match attributes within the subset; and, send the subset across a communication network for display on a remote client device.

18. The search engine of any one of claims 12 to 17 wherein the processor is further configured to: receive a set of predefined validity rules; compare the values for each unit against the rules; and reject values that do not conform to the validity rules.

19. The search engine of claim 18 wherein the processor is further configured to receive updated first values for the rejected values.

20. The search engine of any one of claims 12 to 19 wherein the processor is further configured to: receive a second value for at least one of the fields that updates the first value for the at least one of the fields; redetermine aggregate values for each of the aggregate fields; and, recache a unit data set including the values; the unit data set searchable for units that match provided attributes.21 .The search engine of any one of claims 12 to 20 wherein the unit data set is stored in the memory as a NoSQL database.

22. The search engine of any one of claims 12 to 20 wherein the unit data set is stored in a memory that is remote from the search engine.

Images