Machine learning-based oversubscription modeling

Abstract

Embodiments optimize hotel room reservation for a hotel. For a first day of a plurality of days in the future, embodiments automatically determine an excess reservation limit for each category of hotel rooms of a hotel based on an objective function, where the hotel includes a plurality of different room categories. Embodiments receive a first reservation request for a first category of rooms for a first day. The embodiment accepts the first reservation request when the determined excess reservation limit for the first class of rooms is not reached. When an accepted first reservation request is handling a check-in hotel on the first day, embodiments automatically determine to reject the first reservation request, accept the first reservation request, or upgrade the first reservation request to a higher class room based on an objective function.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 585,735, filed on September 27, 2023, the disclosure of which is incorporated herein by reference. Technical Field

[0003] One embodiment generally relates to a computer system, and more specifically to a computer system for implementing machine learning-based overbooking modeling. Background Technology

[0004] Revenue management is the process of dynamically adjusting the price of goods or services in response to changes in market or supply conditions. The revenue management process was first introduced in the passenger aviation industry and has since been adopted by other industries such as cargo airlines, hotels, car rental companies, freight forwarders, and advertising brokers.

[0005] A very common application of revenue management involves service providers accepting reservations for "date-bound services." Date-bound services involve imposing transaction-specific restrictions on the dates on which a buyer can use the service they have purchased. Examples of such restrictions include specified arrival and departure dates for airline reservations and specified check-in and check-out dates for hotel reservations. Time constraints make it particularly difficult to estimate demand and thus determine optimal pricing that maximizes revenue / profit for date-bound services, especially in the hotel industry.

[0006] Hotel revenue management can be seen as an extension of airline revenue management. While methods developed for hotels can often be applied to airlines, the reverse is not always true. The key difference lies in the nature of hotel room bookings, which can span several days, allowing for room reuse. Therefore, room availability changes daily as some rooms are occupied by guests staying longer. In contrast, airline seat inventory remains consistent across every flight, regardless of cabin class (e.g., first class, business class, or economy). Consequently, the strategies and methods used for hotel revenue management are inherently more intricate and demanding than those used for airline revenue management. Summary of the Invention

[0007] This embodiment optimizes hotel room reservations for hotels. For the first day of a series of future days, the embodiment automatically determines the overbooking limit for each category of hotel rooms based on an objective function, where the hotel includes multiple different room categories. The embodiment receives a first reservation request for a room in the first category for the first day. If the determined overbooking limit for the first category of rooms has not been reached, the embodiment accepts the first reservation request. When the accepted first reservation request is being processed at the hotel on the first day, the embodiment automatically determines, based on the objective function, whether to reject the first reservation request, accept the first reservation request, or upgrade the first reservation request to a higher room category. Attached Figure Description

[0008] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be appreciated that the boundaries of elements shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent one embodiment of a boundary. In some embodiments, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some embodiments, an element shown as an inner component of another element may be implemented as an outer component, and vice versa. Additionally, elements may not be drawn to scale.

[0009] Figure 1 This is an overview block diagram of a hotel reservation system according to an embodiment of the present invention.

[0010] Figure 2 This is a block diagram of a computer server / system according to an embodiment of the present invention.

[0011] Figure 3 According to the embodiments, this is used as a hotel revenue management system that provides overbooking modeling, accepts reservations, and facilitates the check-in process. Figure 2 The system's functional flowchart.

[0012] Figure 4 The illustration shows an example booking limit decision spanning a whole week, according to an embodiment.

[0013] Figure 5 The illustration shows an example decision for the service period on day s according to an embodiment.

[0014] Figures 6-9 The illustration shows an example cloud infrastructure that can enable hotel chain operation 104, which may include, according to embodiments... Figure 2 Overbooking modeling module 16. Detailed Implementation

[0015] The embodiment generates and uses a machine learning-based model to determine booking limits for hotel reservation periods, including determining room overbooking limits for each hotel room category. The embodiment further uses the model to determine when to assign guests to reserved rooms or upgrade them to higher-level rooms during check-in periods. The model maximizes an objective function such as revenue or profit when making decisions.

[0016] The embodiment optimizes the booking limits for each category in the hotel property management system. Further, the embodiment jointly optimizes the assignment of guests to hotel room categories while constrained by room category limits, minimizing the likelihood of downgrading guests or refusing them rooms. Because the probability of a guest canceling their reservation is always non-zero, the number of reservations can slightly exceed the number of rooms within the overbooking limit, depending on the probability of cancellation. However, since the cancellation probability is always estimated with limited accuracy, the embodiment implements a "robust" optimization method to account for the limited accuracy of the estimate, guaranteeing an optimal solution for the worst-case scenario.

[0017] This implementation modeles hotel revenue management by focusing on two main decision-making phases. The first phase is during the reservation period, where a reservation limit can be established, typically setting the maximum number of reservations that can be accepted on the same day or any other time period. Once this limit is met, reservations for further bookings are closed. The second phase is during the service period (i.e., when customers arrive and attempt to check in in response to their reservations). During this phase, each customer is assigned an appropriate hotel room based on their reservation. For example, if a customer has already reserved a basic room, several options exist. The customer can be assigned to a basic room, thus securing standard room revenue. The customer can be upgraded to a superior room, with the hotel receiving the basic room rate plus an optional additional upgrade fee. Alternatively, the customer can be refused or downgraded, which could result in significant revenue loss.

[0018] Therefore, modeling the hotel's daily decision-making process is bifurcated. In this embodiment, initially, a booking limit is set, which directly impacts the demand for the day. Once this demand is specified, the embodiment needs to implement optimal room assignment and upgrade strategies.

[0019] Generally, hotel managers may face two key decisions each day, one of which is determining booking limits. A common practice is to slightly overbook hotel room categories, thus allowing booking limits to exceed actual available inventory. This approach is driven by two main factors: (1) a certain number of reservations are typically cancelled or result in no-shows during service hours; and (2) if actual attendance exceeds room inventory in one category, guests can be upgraded to another category where availability exceeds demand.

[0020] However, excessive overbooking can backfire. If a hotel is unable to accommodate guests due to extreme overbooking, the resulting rejection costs can be prohibitively high—far exceeding the revenue from a standard room. This may necessitate relocating guests to other hotels, renegotiating rates, and other consequences.

[0021] Setting optimal booking limits presents multifaceted challenges. First, when customers make reservations, it's impossible to know their actual likelihood of showing up. While machine learning methods offer predictions, they can sometimes come with significant margins of error. Inadequately robust methods can lead to substantial revenue losses. Second, the complexity extends beyond setting single-day booking limits. It requires anticipating and setting limits for the following days, as many customers book well in advance. Finally, the duration of each stay can vary, and determining booking limits for both the current day and subsequent days becomes particularly intricate without knowing the certainty of each guest's arrival.

[0022] Generally, implementation plans attempt to maximize revenue from bookings and upgrades, minimize costs for downgraded and "walking" customers, and protect premium tier benefits. Complicating factors that make these achievements difficult to achieve include random cancellations, parameter uncertainty, consideration of multi-day stays, and non-linear room category tiers.

[0023] Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Wherever possible, the same reference numerals will be used for the same elements.

[0024] Figure 1 This is an overview block diagram of a hotel reservation system 100 according to an embodiment of the present invention. Figure 1 This includes booking channels 102 through which potential hotel customers can interact to reserve hotel rooms. These channels include global distribution systems (“GDS”) 111, including “Amadeus”, “Sabre”, “Travel Port”, etc.; online travel agencies (“OTAs”) 112, including “Booking.com”, “Expedia”, etc.; metasearch websites 113; and any other means by which customers reserve hotel rooms, including websites maintained by hotel chains or individual hotels.

[0025] Each hotel chain operation 104 is accessed via an application programming interface (“API”) 140 as a web service such as “WebLogic Server” from Oracle Corporation. Hotel chain operation 104 includes a hotel property management system (“PMS”) 121, such as “OPERA Cloud Property Management” from Oracle Corporation; a hotel central reservation system (“CRS”) 122; and an overbooking modeling module 150 that interfaces with systems 121 and 122 to provide overbooking modeling and all other functionalities disclosed herein. Overbooking modeling can also interface with the hotel’s computer system to provide upgrade recommendations during check-in of customers holding reservations. In this embodiment, hotel chain operation 104 is implemented using cloud-based infrastructure. In one embodiment, the cloud-based infrastructure includes “Oracle Cloud Infrastructure” (“OCI”) from Oracle Corporation.

[0026] Hotel customers or potential hotel customers who use System 100 to obtain hotel rooms typically participate in a three-stage booking process. The first step is a regional availability search. Multiple hotel chains are displayed, and hotel CRS 122 provides static data. Static data may include minimum / maximum rates, available dates, etc.

[0027] If a booking customer selects a hotel, they proceed to the next step: a property search. This includes individual hotel properties, multiple rooms, and rate plans. For a single hotel property, information may include room category descriptions, rate plan descriptions, and room prices, each presented in a specific order. The property search includes real-time availability data and leads the booking customer to select a room. Once a room is selected, the final step is to finalize the booking and secure the reservation via credit card or other payment method.

[0028] Figure 2 This is a block diagram of a computer server / system 10 according to an embodiment of the present invention. Although shown as a single system, the functionality of system 10 can be implemented as a distributed system. Furthermore, the functionality disclosed herein can be implemented on separate servers or devices coupled together via a network. Additionally, one or more components of system 10 may not be included. For example, when implemented as a web server or cloud-based functionality, system 10 is implemented as one or more servers and does not require a user interface such as a monitor or mouse. In embodiments, system 10 can be used to implement... Figure 1 Any element shown.

[0029] System 10 includes a bus 12 or other communication mechanism for transmitting information, and a processor 22 coupled to the bus 12 for processing information. Processor 22 can be any type of general-purpose or special-purpose processor. System 10 also includes memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can include any combination of random access memory (“RAM”), read-only memory (“ROM”), static storage devices (such as magnetic disks or optical disks), or any other type of computer-readable medium. System 10 also includes communication devices 20 (such as a network interface card) to provide access to a network. Therefore, a user can directly interface with system 10, remotely via a network, or through any other method.

[0030] Computer-readable media can be any available medium accessible to processor 22, and includes volatile and non-volatile media, removable and non-removable media, and communication media. Communication media can include computer-readable instructions, data structures, program modules, or other data in modulated data signals (such as carrier waves or other transport mechanisms), and includes any information delivery medium.

[0031] The processor 22 is further coupled to the display 24, such as a liquid crystal display (“LCD”), via bus 12. The keyboard 26 and the cursor control device 28 (such as a computer mouse) are further coupled to bus 12 to enable the user to interface with the system 10.

[0032] In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. These modules include an operating system 15 that provides operating system functionality to system 10. These modules also include an overbooking model module 16 that models overbooking to provide overbooking limits during the hotel room reservation process and upgrade recommendations during check-in, as well as additional functionality disclosed herein. System 10 may be part of a larger system. Therefore, system 10 may include one or more additional functionality modules 18 to include additional functionality such as a property management system (“PMS”) (e.g., “Oracle Hospitality OPERA Property” or “Oracle Hospitality OPERA Cloud Services”) or enterprise resource planning (“ERP”) system functionality. Database 17 is coupled to bus 12 to provide centralized storage for modules 16 and 18 and to store guest data, hotel data, transaction data, etc. In one embodiment, database 17 is a relational database management system (“RDBMS”) that can use Structured Query Language (“SQL”) to manage the stored data.

[0033] In this embodiment, communication interface 20 provides bidirectional data communication coupling to a network link 35 connected to a local network 34. For example, communication interface 20 may be an Integrated Services Digital Network (“ISDN”) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line or Ethernet. As another example, communication interface 20 may be a Local Area Network (“LAN”) card to provide data communication connectivity to a compatible LAN. A wireless link may also be implemented. In any such implementation, communication interface 20 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0034] Network link 35 typically provides data communication to other data devices via one or more networks. For example, network link 35 may provide a connection to host computer 32 or data equipment operated by Internet service provider (“ISP”) 38 via local network 34. ISP 38 then provides data communication services via Internet 36. Both local network 34 and Internet 36 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks, as well as signals on network link 35 and through communication interface 20 (which carry digital data to and from computer system 800), are example forms of transmission media.

[0035] System 10 can send messages and receive data, including program code, via one or more networks, network links 35, and communication interfaces 20. In the Internet example, server 40 may transmit application-requested code via the Internet 36, ISP 38, local network 34, and communication interface 20. The received code can be executed by processor 22 upon receipt and / or stored in database 17 or other non-volatile storage for later execution.

[0036] In one embodiment, system 10 is a computing / data processing system that includes an aggregation of applications or distributed applications for an enterprise organization and may also provide logistics, manufacturing, and inventory management functionality. The application and computing system 10 may be configured to operate locally or implemented as a cloud-based, networked system, such as in Infrastructure as a Service (“IAAS”), Platform as a Service (“PAAS”), Software as a Service (“SAAS”) architectures, or other types of computing solutions.

[0037] Figure 3 According to the embodiments, this is used as a hotel revenue management system that provides overbooking modeling, accepts reservations, and facilitates the check-in process. Figure 2 A functional flowchart of system 10. In one embodiment, Figure 3The functionality of the flowchart is implemented by software stored in memory or other computer-readable or tangible media and executed by a processor. In other embodiments, the functionality may be implemented by hardware (e.g., by using an application-specific integrated circuit (“ASIC”), a programmable gate array (“PGA”), a field-programmable gate array (“FPGA”), etc.) or any combination of hardware and software. Figure 3 The functionality is disclosed for hotel reservation systems, but in other embodiments it can be applied to any date-constrained environment.

[0038] The implementation of the embodiments supports the assumptions regarding the benefits of overbooking, including that some reservations may not be shown and that reservations can be upgraded to other room categories, as well as the problems of overbooking, including high “delivery” costs and protection of revenue from other categories.

[0039] Figure 3 The functional illustration illustrates a hotel's business process implemented by an embodiment. For any hotel, the customer's journey typically begins with a reservation: the customer selects a specific date, chooses the desired room type, and specifies the duration of their stay. Subsequently, on the selected arrival date, the customer can check in at the front desk or choose to cancel the reservation in advance. In some cases, the customer may not show up without prior notice. For the purposes of this disclosure, it is assumed that each hotel has three room types: "Basic," "Superior," and "Suite," where Basic rooms are generally the cheapest, and Suites are generally the most expensive.

[0040] Given this framework, the daily decision-making process can be divided into two distinct parts, such as Figure 3 As shown in the image.

[0041] At 302, the optimization according to the embodiment applies to specific days s for each day from day 1 to day T. This is implemented on a daily basis because appointments are generally specified with significantly different, unpredictable probabilities of no-shows and varying lengths of stay. In other embodiments, the optimized frequency can be more or less frequent than daily.

[0042] At point 304, during the reservation period (i.e., as each reservation arrives at the hotel reservation system), the implementation makes a first-stage decision at point 308 based on the reservation limit determined for each room type. If the number of reservations is less than the reservation limit, then the reservation is accepted at point 310. If the number of reservations equals the reservation limit, then the reservation window for that room type for that day or time period is closed, unless there are future cancellations during that time period.

[0043] At point 306, during the service period (i.e., when a customer with a reservation arrives to check in), the arrival of each requested room for category i and duration D is evaluated. If the customer fails to show up, then at point 328, revenue (or lack of revenue) is determined. If the customer arrives, then the embodiment makes a second-stage decision at point 316 regarding the allocation of the reserved room. The customer will be offered the room category reserved at points 320 and 324, or an upgraded room at points 322 and 326, each of which, if accepted, affects revenue (or other objective function). This is implemented according to the embodiment. Figure 3 The functional model is disclosed below.

[0044] In response to selecting / assigning a specific optimized room at or after location 316, the embodiment includes transmitting dedicated data (i.e., data specific to the selected room) to other dedicated devices that use the data, such as automatically encoding hotel room cards or automatically programming hotel room door locks.

[0045] Model

[0046] According to the implementation example, the model calculates the booking limit for all room categories for each day (or other time period) (i.e., Figure 3 Phase 1 (308) will be used to make acceptance / rejection decisions for new appointments that will arrive during the same day (i.e., Figure 3 The second phase (316). The example assumes there are a total of n room categories, and the room categories... Total There are [number] rooms. The daily revenue generated by room category i is [percentage]. Without loss of generality, assume .

[0047] The expected benefit of upgrading from room category i to a higher or equivalent category j is... Given the following: Assume the hotel manager has the discretion to determine the upgrade strategy whenever any incoming request reaches the front desk. Furthermore, upgrades do not necessarily occur only when inventory reaches capacity. For illustration, even if basic inventory remains available, a single-night upgrade request may still be optimal, especially based on forecasts (where the likelihood of receiving five subsequent basic requests is higher), potentially yielding greater benefits. Regarding the anticipated upgrade price, Always non-negative. A value of 0 indicates an involuntary upgrade, while a positive value indicates that an additional upgrade fee will be charged to the customer.

[0048] At the start of day s, the embodiment can access two sets of information: existing appointments (i.e., Figure 3 Service hours 306) and new appointments predicted to arrive during day s (i.e., Figure 3(Reservation time slot 304).

[0049] 1. Existing Reservations: For each couple ,in ,make This represents the number of reservations made on day t and remaining until day t' (this only considers those reservations that have not been cancelled at the start of day s). Set The detailed information of the kth customer is given by the following formula:

[0050]

[0051] in The expected length of stay (in days) under the specified reservation. It is a vector of binary variables, where This means that the customer requested a room of category i (assuming each customer requests exactly one room), and This is a vector for temporary room assignments. For each request for room category i on day t, at the time of booking, the embodiment makes the following room assignment decision: assign the customer to a room of category i, or assign the customer to a room of category i. The room (free upgrade) or refuse to provide any room to the customer and impose a penalty. Use binary variables. To capture this decision. Specifically:

[0052] a. And for all , This means assigning the initially requested room category to the customer;

[0053] b. For a certain , And for all , This means the customer has been upgraded to a category j room (in this case, the customer will only be notified of this free upgrade at check-in).

[0054] c. For all j, This means that customers will be refused any rooms, in which case the hotel will incur a penalty. .

[0055] At the start of day s, aggregated data from existing appointments is captured by the following sigma domain:

[0056]

[0057] make Represents a set The probability that the k-th customer does not appear on day t'. In this example, a true probability is assumed. The uncertainty is estimated with a small error of + / - 5 percentage points. Therefore, when the cancellation probability is estimated to be, for example, 20%, the uncertainty is set in the range of 15%–25%. Examples include known sets of convex uncertainties. , making ,in It is made by all of The vector composed of these elements. Since the implementation uses a fixed 5% error, the set of uncertainties becomes... Hypercube in 3D space.

[0058] In one embodiment, the probability of each individual appointment is predicted using the following ML-based method:

[0059] Features (or independent variables):

[0060] Numerical characteristics (including binary):

[0061] • Reservation window (how many days in advance to make an appointment)

[0062] • Length of stay (number of days)

[0063] • Number of days before arrival

[0064] • Rate Amount

[0065] • Refundability based on the number of days prior to check-in

[0066] • Number of adults and children

[0067] • Corporate Discounts

[0068] • Guest's VIP status (Yes / No)

[0069] • Membership points or other tiers of accumulated rewards (if applicable)

[0070] Classification features (encoded as one-hot numerical features):

[0071] • Room Categories

[0072] • Rate plans (list price, best available (BAR), include breakfast, etc.)

[0073] • Booking channels, with the following options:

[0074] • Online travel agencies (OTAs), such as Expedia

[0075] • Global Distribution System (GDS), such as Apollo

[0076] • Hotel website or telephone reservation system

[0077] •other

[0078] • Additional categorical features are collected based on the stay date and include:

[0079] • Months of the year

[0080] • What day of the week

[0081] • Holidays or special events

[0082] In this embodiment, the dependent variable (output) is 0 / 1, indicating whether the appointment has been cancelled. In this embodiment, a random forest is used in classifier mode, where each leaf of each decision tree in the ensemble has a 0 / 1 value to be selected as the prediction.

[0083] In this embodiment, for model training, training samples are constructed by replicating each existing reservation for each number of days prior to check-in within the prediction horizon. For example, if a reservation is booked 7 days in advance and cancelled 3 days in advance, it will appear 4 times in the training samples: 7, 6, 5, and 4 days in advance, with an output of 1 (i.e., cancelled).

[0084] In this embodiment, the cancel probability prediction / estimation is obtained via the standard "predict_proba()" method available in most known classifiers. Generally, the probability is obtained as the proportion of each decision tree that predicts an output of 1.

[0085] 2. Predicted New Reservations: In addition to the information disclosed above regarding existing reservations, at the beginning of day s, the embodiment also employs a prediction algorithm to predict possible new reservations on any day s. Additional reservations for the initial stay. In one embodiment, a machine learning (“ML”) algorithm is used to generate a prediction. This represents the predicted number of additional bookings made on day s for a stay starting on day t. Similarly, for each... ,

[0086] ,

[0087] in and Both are outputs of the prediction algorithm. On each day s, for each future arrival day t, the example uses the following ML-based method to predict future bookings. and its duration :

[0088] Training phase: For all historically observed pairs of days s and t, collect the following numerical statistics on existing bookings for day s: number of bookings, average booking window (how many days in advance to book), and number of days before arrival. The data includes average refundability for the number of days prior to check-in, average number of adults and children in the reservation, average corporate discount, average VIP and loyalty status of guests, and a unique categorization value averaging all reservations: room type; rate plan (list price, best available (“BAR”), breakfast included, etc.); booking channel with options such as online travel agencies (“OTAs”), e.g., Expedia, global distribution systems (“GDS”), e.g., Apollo, hotel websites, or telephone booking systems; and other categorization features collected for the arrival date, including month of the year, day of the week, holidays, or special events.

[0089] This model is designed for a specific prediction window. Each room category is trained separately, resulting in a pool of predictive models applied to a specific prediction window to predict the number of future bookings (dependent variable) for a particular room category. The implementation uses a Random Forest (“RF”) algorithm in regressor mode. The most important variable is the number of existing bookings, indicating demand for the hotel. The remaining variables act as moderating factors, essentially predicting the proportion of short-window bookings by sensing the prevalence of business bookings versus vacation bookings, which tend to have different booking windows. During the prediction phase, the trained RF model outputs the predicted number of future bookings.

[0090] Similarly, another set of predictive models was used to estimate the average length of stay for future bookings. These models used the same statistics and were also built separately for each prediction window and room category. Once the average length of stay was predicted, the example used a Poisson distribution to derive the percentage of stay for each day as follows: ,in It is the predicted average length of stay and Based on the parameter The probability mass function (“PMF”) of the Poisson distribution yields the proportion of stays of length l, shifting the zero quantity to the length of stay per day. Finally, the percentage... Multiply by the total number of predicted appointments The data is rounded to match the total number of reservations. Since very limited information is available about the nature of new reservations, the implementation estimates the cancellation probability of new reservations by running a simple linear regression on the stay duration of the new reservation as the sole predictive feature and using the predicted cancellation probabilities of existing reservations as training samples.

[0091] For all the trained predictive ML models disclosed above, in response to the passage of time, when it is known how accurate the predictions are (such as the number of new reservations received, the number of reservations canceled in advance, etc.), one or more models will be retrained.

[0092] The aggregated data for the predicted appointments at the beginning of day s is given by the following formula:

[0093] .

[0094] gather The probability that the k-th customer cancels / does not show up on day t is unknown. As mentioned above, assume it belongs to a known set of convex uncertainties. .

[0095] In summary, at the start of day s, the embodiment can access the following set of information:

[0096] .

[0097] In the above text, the ^ (hat) symbol was used to represent the output of the ML algorithm. For ease of notation, from now on, the hat will be removed from all notation. The meaning of each variable (whether corresponding to information from existing appointments or, alternatively, to the output of the prediction algorithm) can be clearly seen from the time index in which the superscript appears (because starting on day s, any variable with a superscript...). (some of them) The variables in the algorithm correspond to the output of the ML algorithm.

[0098] The key decision made at the beginning of day s in the example is to determine the booking limit. Suppose a room of type j is booked on day s, and the user intends to stay for L days starting on day t (the condition is...). The reservation was temporarily assigned to room of category i (by...). (Instructions). Only when for from t to For each day s' within the time period (inclusive), the total number of checked-in reservations assigned to room category i on day s' is less than the maximum capacity assigned to category i. This assignment is only feasible if, at that time, the room category is available. In other words, an assignment to a room category is feasible if and only if there are available rooms of that category for each day during the expected period of stay (subject to the prescribed booking limit).

[0099] As disclosed, the embodiments not only determine the booking limit for day "s", but also establish booking limits for each subsequent day. This stems from the understanding that, for any given day s, reservations can be made not only for that day, but also for day s+1, day s+2, and so on. Without forward-looking booking limits for future days, there is a risk of unintentionally overbooking on certain upcoming dates. For example, if the optimal booking limit for a superior room on day s+7 is fixed at 6 and there are already 6 uncancelled reservations, then the hotel should stop making further reservations, indicating that this category is fully booked for day s+7. Figure 4 The illustration shows an example booking limit decision spanning a whole week, according to an embodiment.

[0100] For service periods (i.e., Figure 3 In the second phase (316), as disclosed above, the embodiment generates one of three potential decisions for the k-th arriving customer:

[0101] (1) Assign arriving customers to the room category they initially requested and earn [money / rewards]. The benefits, that is, And for all , .

[0102] (2) Upgrade to a higher room category j to receive additional non-negative fees. That is, for a certain , And for all , .

[0103] (3) Rejecting customers incurs significant rejection costs. That is, for all j, .

[0104] The complexity of this decision-making stems from the variable duration of each customer's stay. This variability means that linear programming alone cannot solve the problem concisely; different stay durations significantly impact the future availability of a given room.

[0105] Figure 5The illustration depicts an example decision for a service period on day s, according to an embodiment. Assume the hotel initially has 5 basic rooms (502), 3 superior rooms (504), and 1 suite (506). Since rooms 2, 4, and 5 are already occupied (likely due to previous multi-night bookings), only 2 basic rooms, 2 superior rooms, and 1 suite are available. On the left, the diagram shows different customers: customer 520 represents a customer requesting a basic room, customer 521 represents a customer seeking a superior room, and customer 522 represents a suite request. Not all customers with reservations will show up; some may cancel early. The main challenge during the service period is to efficiently match each arriving customer with the appropriate available room. The optimized assignment determined by the embodiment... Figure 5 The instructions included that one of the customers seeking a premium room was refused.

[0106] Optimization formula

[0107] The example uses a given day This is achieved through a customized optimization model for hotel revenue management, considering both various room types and multi-day bookings. The model is underpinned by a two-stage optimization structure. In the initial stage (reservation stage), the core decision variable involves the booking limit set for each room category. The subsequent stage (service stage) introduces assignment decision variables that describe the room upgrade strategy. Essentially adaptive, these variables depend on actual demand and cancellation patterns, thus providing a dynamic response mechanism to real-world customer behavior. Specifically, the implementation considers worst-case scenarios of no-shows and cancellations, addressing these issues through robust optimization techniques.

[0108] The implementation example optimizes the decision-making process a hotel manager needs to address at the start of each day using a rolling view approach. Specifically, at the start of day s, the hotel manager needs to calculate the following steps by considering existing reservations, anticipated new requests, ad-hoc assignment decisions, and the likelihood of cancellations / no-shows. Heaven (that is, Reservation limit The goal is to maximize the worst-case expected gains / profits over the next T' days.

[0109] for and ,make The success probability is An independent Bernoulli random variable (this is used as an indicator to indicate no cancellation / absence). For and ,make This represents the number of rooms of category i that are occupied on day t due to reservations made before day s. This can be represented using an information set. To calculate. Finally, define. , , , as follows:

[0110]

[0111] The robust optimization formula is given below:

[0112] Target

[0113] (1)

[0114] constraint

[0115]

[0116] fixed (1) The terms in the objective can be split into two parts. Summation

[0117]

[0118] This represents the total revenue from all non-cancelled reservations made in the past for a stay starting on day t. The second summation...

[0119]

[0120] This represents the total cost of the penalty. To see this, note... Let $\frac{1}{t}$ represent the number of rooms of category $i$ that were occupied on day $t due to reservations made before day $s$, and summate the results.

[0121]

[0122] This represents the number of rooms of category i occupied on day t by customers who made reservations since day s (these include customers who initially requested a room of category i and were assigned a room of category i, as well as customers who initially requested a room of a lower category but were upgraded to category i; customers who initially requested a room of category i but were upgraded to a higher category are not included).

[0123] Next, reference items This is the principle of robust optimization. Given the significant costs associated with rejection, hotel managers tend to make more conservative decisions to ensure that customer rejections at check-in are minimized, even in the most challenging scenarios. To achieve this, a set of uncertainties representing the probability of cancellation is defined. This set (denoted as...) (cross) The implementation then focuses on maximizing gains in the worst-case adversarial scenario.

[0124] All constraints in the optimization formula are self-evident:

[0125] • The first constraint ensures the upgrade from room i to room i. It is binary: either 1 (indicates upgrade) or 0 (do not upgrade).

[0126] • The second constraint ensures that the number of requests during the reservation period does not exceed the predetermined reservation limit.

[0127] • The third constraint mandates that upgrades can only be made to one room category at most.

[0128] In general, the robust mixed-integer optimization problem described above is not suitable for traditional optimization solvers. These solvers are insufficient to solve the problem when uncertainty is established on the parameters of random variables. The constraints in the model include: (1) the number of accepted reservations is less than the reservation limit; (2) requests are only accepted upon appearance; (3) for each request, the number of upgrades is non-negative; (4) the number of upgrades is less than the number of requested rooms; and (5) for each day within the planning horizon, the number of occupied rooms in each class does not exceed the inventory. Among these constraints, numbers 2-5 involve uncertainty. Therefore, the embodiment addresses this technical problem by transforming the robust mixed-integer optimization problem (Equation (1) above) into a linear optimization problem.

[0129] To transform equation (1) above into a linear optimization problem, the embodiment begins by establishing a polyhedral set of uncertainties for the total number of customers arriving, thereby eliminating the random variables present in equation (1). Subsequently, the embodiment develops robust counterparts for each constraint containing uncertainty.

[0130] Polyhedral Uncertainty Set

[0131] The examples begin with the following set of inequalities:

[0132] make It is an independent Bernoulli random variable. If ,and So, for any :

[0133]

[0134] in .

[0135] Notice .because According to Bernstein's inequality,

[0136] .

[0137] For each day, parameters This indicates the expected confidence level. For example, if decision-makers seek a highly conservative decision with a 99% confidence level, then they can choose... Make:

[0138] .

[0139] After this is established, for any Uncertainty set It can be defined as:

[0140] (2)

[0141] in Let represent the expected number of customers arriving during the service period on day t. Equation (2) implies that the total number of customers arriving on day t should be close to its expected value. Therefore, the choice of the adversary can be redirected from determining the cancellation probability to choosing the arrival count. Thus, the term in optimization problem (1) It can be replaced by :

[0142] Robust mixed integer programming

[0143] (3)

[0144] Limited by:

[0145]

[0146] robust counterpart

[0147] Example of relaxation To satisfy any i, j, k, s, t, Therefore, the only factor preventing optimization problem (3) from being classified as linear programming lies in the uncertainty variables present in the first and sixth constraints, which lie within the specified polyhedral uncertainty region. To address this issue, the embodiment derives a linear formula for each of these constraints.

[0148] Fenchel conjugate function

[0149] The example begins by providing the definition of the Fenchel conjugate: the Fenchel conjugate of a function f is defined as follows:

[0150]

[0151] The conjugate function can be understood from an economic perspective. Let x be the quantity of the product, f(x) be the cost of producing x units, and y be the market price per unit. This represents the revenue from selling x units. Therefore, the conjugate function... This represents the optimal profit at a given price y.

[0152] Next, consider the conjugate of the following indicator functions:

[0153]

[0154] Therefore, its Fenchel conjugate function is:

[0155] .

[0156] Therefore, item The conjugate function of the indicator function Instead. Furthermore, considering the set of uncertainties... It can be expressed as the intersection of two clearly different sets: The following theorem can be used to simplify the conjugate function:

[0157] Theorem 1: Let , For a closed convex set, ,So

[0158] .

[0159] Based on Theorem 1 above, the set of uncertainties can be described as two polyhedra (i.e., and The intersection of the polyhedra. The conjugate function of each polyhedron can be substantially computed. A lemma describing the conjugate function within the set of uncertainties of polyhedra can also be proposed:

[0160] Lemma 1: Let It is in the form of If a polyhedron is a closed polyhedron, then:

[0161]

[0162] The proof of Lemma 1 is as follows:

[0163] By defining the conjugate function:

[0164]

[0165] Next, through Lagrange duality:

[0166]

[0167] Using Theorem 1 and Lemma 1, the conjugate function of the polyhedral uncertainty set (2) can be solved as follows:

[0168] (4)

[0169] Derive robust counterparts for each constraint that includes uncertainty.

[0170] We can now determine the robust counterpart for each constraint involving uncertain variables. Let's delve deeper into the details of constraints 1 and 6:

[0171] Constraint 1:

[0172] ,

[0173] First, multiply both sides by -1:

[0174] , .

[0175] For each The implementation example defines a diagonal matrix. The non-zero element in the k-th row is Therefore, constraint 1 is equivalent to:

[0176]

[0177] According to equation (4) above, the robust counterpart is:

[0178]

[0179] Constraint 6:

[0180]

[0181] Deriving robust counterparts for constraint 6 presents challenges. For each We must consider targeting All uncertainties set Furthermore, equation (4) is not applicable in this context. Therefore, the robust counterpart is as follows:

[0182] First, to simplify the notation, let Then, constraint 6 is equivalent to: for any , ,

[0183] ,

[0184] this means:

[0185] .

[0186] Next, we derive the robust counterpart for the left-hand side. According to the definition of the uncertainty set (2), the left-hand problem can be written as:

[0187] (5)

[0188] Limited by:

[0189]

[0190] The Lagrange duality derivation of (5) is as follows:

[0191]

[0192] For simplicity, the Lagrange duality of (5) is equivalent to:

[0193]

[0194] Limited by:

[0195]

[0196] Therefore, the robust counterpart of constraint 6 is:

[0197]

[0198] Linear optimization counterpart

[0199] Using the above results, a linear optimization approximately equivalent to (1) can be written as:

[0200] (6)

[0201] Limited by

[0202]

[0203] Pseudocode for overbooking optimization

[0204] Embodiments of the present invention can be implemented using the following pseudocode / algorithm / heuristic method designed to determine the booking limit for each day within a time horizon [1,T]:

[0206] Input: Time period Confidence level .

[0207] Output: Booking limit for day s: .

[0208] for :

[0209] for :

[0210] Find it in the following equation :

[0211] (7)

[0212] For all , :

[0213] use Solve the optimization problem (6).

[0214] Return to optimal booking limit

[0215] Finish

[0217] The above pseudocode requires defining a time period. The input is s. For each day, denoted as s, the pseudocode recommends a series of days ( (Reservation limit). A higher value provides better protection against extreme situations; however, this also increases computational costs exponentially. In practical applications, implementation examples can be set... This means the implementation is determining the booking limit for the entire week. The pseudocode also requires a confidence level. The input. This value represents the level of conservatism the manager expects in decision-making. In this embodiment, the confidence level is specified as... =95%.

[0218] On day s, the embodiment first predicts information for future requests. Information related to all existing requests. In combination, the hotel manager can access the following collection of information. As disclosed above, the embodiments construct a set of uncertainties for the total number of arrivals. The size of this set is based on the confidence level. And this varies. Higher confidence levels lead to a larger set of uncertainties. To ensure with high certainty that the total number of arrivals falls within the set, this set must be large enough to cover most possible scenarios. Using this framework, the implementation determines for... of The value of is shown in equation (7). Once equipped and The implementation example then proceeds to solve the linear optimization problem (6).

[0219] The optimal solution for the booking limit is expressed as: , where i spans by This represents all room categories, and t covers a range of... These booking limits are updated daily. If the number of reservations for room category i on day t matches the booking limit, then the booking window for that day is closed. Furthermore, if the optimal booking limit for room category i on day t is equal to or less than the current limit, then the booking window remains closed. Otherwise, it will be reopened.

[0220] Example cloud infrastructure

[0221] Figures 6-9 The illustration shows an example cloud infrastructure that can enable hotel chain operation 104, which may include, according to embodiments... Figure 2 Overbooking modeling module 16.

[0222] As disclosed above, Infrastructure as a Service (“IaaS”) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, cloud providers can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, IaaS providers can also provision various services to complement these infrastructure components (e.g., billing, monitoring, logging, security, load balancing, and clustering, etc.). Therefore, because these services can be policy-driven, IaaS users can implement policies to drive load balancing to maintain application availability and performance.

[0223] In some cases, IaaS customers can access resources and services via a wide area network (WAN) such as the Internet and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create virtual machines (“VMs”), install an operating system (“OS”) on each VM, deploy middleware such as databases, create buckets for workloads and backups, and even install enterprise software into the VM. The customer can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0224] In most cases, cloud computing models will require the involvement of cloud providers. Cloud providers can, but are not necessarily, third-party providers specializing in (e.g., provisioning, renting, selling) IaaS services. Entities may also choose to deploy private clouds, thus becoming their own infrastructure service providers.

[0225] In some examples, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It may also include the processing of the preparation server (e.g., installation libraries, daemons, etc.). This is typically managed by the cloud provider, below the hypervisor layer (e.g., servers, storage devices, network hardware, and virtualization). Therefore, the customer can be responsible for processing (OS), middleware, and / or application deployment (e.g., on self-service virtual machines, etc., which can be started on demand).

[0226] In some examples, IaaS provisioning can refer to acquiring computers or virtual hosts for use, or even installing necessary libraries or services on them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0227] In some cases, IaaS provisioning presents two distinct challenges. First, there are initial challenges in provisioning the initial infrastructure set before anything is operational. Second, once everything is provisioned, there are challenges in evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both challenges can be addressed by enabling configuration that declaratively defines the infrastructure. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more profiles. Therefore, the overall topology of the infrastructure (e.g., which resources depend on which resources and how they work together) can be described declaratively. In some cases, once the topology is defined, workflows for creating and / or managing the different components described in the profiles can be generated.

[0228] In some examples, the infrastructure can have many interconnected components. For example, there may be one or more Virtual Private Clouds (“VPCs”) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as the core network. In some examples, one or more security group rules may also be provided to define how the network's security will be configured, as well as one or more virtual machines. Other infrastructure elements, such as load balancers, databases, etc., may also be provided. The infrastructure can evolve incrementally as more and / or more infrastructure elements are expected and added.

[0229] In some cases, continuous deployment techniques can be used to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the described techniques enable infrastructure management within these environments. In some examples, service teams may write code that they expect to deploy to one or more, but often many, different production environments (e.g., across various geographical locations, sometimes spanning the entire world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or once the infrastructure is provisioned, deployment tools can be used to deploy the code.

[0230] Figure 6 This is a block diagram 1100 illustrating an example pattern of an IaaS architecture according to at least one embodiment. Service operator 1102 may communicatively couple to secure host lease 1104, which may include a virtual cloud network (“VCN”) 1106 and a secure host subnet 1108. In some examples, service provider 1102 may use one or more client computing devices (which may be portable handheld devices (e.g., iPhone®, cellular phone, iPad®, computing tablet, personal digital assistant (“PDA”)) or wearable devices (e.g., Meta Quest® head-mounted display) running software (such as Microsoft Windows Mobile®) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.) and supporting the Internet, email, short message service (“SMS”), Blackberry®, or other communication protocols). Alternatively, client computing devices may be general-purpose personal computers, including, for example, personal computers and / or laptops running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. Client computing devices may run various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems such as, for example, Google Chrome). Workstation computers operating systems (OS) may be any type of operating system. Alternatively or additionally, client computing devices may be any other electronic devices, such as thin client computers, internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices capable of communicating over a network that can access VCN 1106 and / or the internet.

[0231] VCN 1106 may include a local peering gateway (“LPG”) 1110, which may be communicatively coupled to SSH VCN 1112 via LPG 1110 contained in a secure shell (“SSH”) VCN 1112. SSH VCN 1112 may include an SSH subnet 1114, and SSH VCN 1112 may be communicatively coupled to control plane VCN 1116 via LPG 1110 contained in control plane VCN 1116. Furthermore, SSH VCN 1112 may be communicatively coupled to data plane VCN 1118 via LPG 1110. Control plane VCN 1116 and data plane VCN 1118 may be contained in a service lease 1119 that may be owned and / or operated by an IaaS provider.

[0232] The control plane VCN 1116 may include a control plane demilitarized zone (“DMZ”) layer 1120 that acts as a peripheral network (e.g., a portion of a corporate network between an internal and external network). DMZ-based servers can assume limited liability and help control security breaches. Furthermore, the DMZ layer 1120 may include one or more load balancer (“LB”) subnets 1122, a control plane application layer 1124 that may include one or more application (app) subnets 1126, and a control plane data layer 1128 that may include one or more database (DB) subnets 1130 (e.g., one or more front-end DB subnets and / or one or more back-end DB subnets). One or more LB subnets 1122 contained in the control plane DMZ layer 1120 may be communicatively coupled to one or more application subnets 1126 contained in the control plane application layer 1124 and an Internet gateway 1134 that may be contained in the control plane VCN 1116. The application subnets 1126 may be communicatively coupled to one or more DB subnets 1130 contained in the control plane data layer 1128, as well as a service gateway 1136 and a Network Address Translation (NAT) gateway 1138. The control plane VCN 1116 may include the service gateway 1136 and the NAT gateway 1138.

[0233] The control plane VCN 1116 may include a data plane mirror application layer 1140, which may include one or more application subnets 1126. The one or more application subnets 1126 included in the data plane mirror application layer 1140 may include a virtual network interface controller (VNIC) 1142 capable of executing a compute instance 1144. The compute instance 1144 may communicatively couple the one or more application subnets 1126 of the data plane mirror application layer 1140 to the one or more application subnets 1126 that may be included in the data plane application layer 1146.

[0234] Data plane VCN 1118 may include data plane application layer 1146, data plane DMZ layer 1148, and data plane data layer 1150. Data plane DMZ layer 1148 may include one or more LB subnets 1122 communicatively coupled to one or more application subnets 1126 of data plane application layer 1146 and Internet gateway 1134 of data plane VCN 1118. One or more application subnets 1126 communicatively coupled to service gateway 1136 and NAT gateway 1138 of data plane VCN 1118. Data plane data layer 1150 may also include one or more DB subnets 1130 communicatively coupled to one or more application subnets 1126 of data plane application layer 1146.

[0235] The Internet gateway 1134 of control plane VCN 1116 and data plane VCN 1118 can be communicatively coupled to metadata management service 1152, which can be communicatively coupled to public Internet 1154. Public Internet 1154 can be communicatively coupled to NAT gateway 1138 of control plane VCN 1116 and data plane VCN 1118. Service gateway 1136 of control plane VCN 1116 and data plane VCN 1118 can be communicatively coupled to cloud service 1156.

[0236] In some examples, service gateway 1136 of control plane VCN 1116 or data plane VCN 1118 can make application programming interface (“API”) calls to cloud service 1156 without traversing the public internet 1154. API calls from service gateway 1136 to cloud service 1156 can be unidirectional: service gateway 1136 can make API calls to cloud service 1156, and cloud service 1156 can send requested data to service gateway 1136. However, cloud service 1156 may not initiate API calls to service gateway 1136.

[0237] In some examples, secure host lease 1104 can be directly connected to service lease 1119, which would otherwise be isolated. Secure host subnet 1108 can communicate with SSH subnet 1114 via LPG 1110, which enables bidirectional communication between otherwise isolated systems. Connecting secure host subnet 1108 to SSH subnet 1114 allows secure host subnet 1108 to access other entities within service lease 1119.

[0238] Control plane VCN 1116 may allow users of service lease 1119 to configure or otherwise provision desired resources. Desired resources provisioned in control plane VCN 1116 may be deployed or otherwise used in data plane VCN 1118. In some examples, control plane VCN 1116 may be isolated from data plane VCN 1118, and the data plane mirror application layer 1140 of control plane VCN 1116 may communicate with the data plane application layer 1146 of data plane VCN 1118 via VNIC 1142, which may be included in both the data plane mirror application layer 1140 and the data plane application layer 1146.

[0239] In some examples, users or clients of the system can make requests, such as create, read, update, or delete (“CRUD”) operations, via the public internet 1154, which can transmit requests to the metadata management service 1152. The metadata management service 1152 can transmit requests to the control plane VCN 1116 via internet gateway 1134. Requests can be received by one or more LB subnets 1122 contained in the control plane DMZ layer 1120. The LB subnets 1122 can determine that the request is valid, and in response to this determination, they can transmit the request to one or more application subnets 1126 contained in the control plane application layer 1124. If the request is validated and requires a call to the public internet 1154, the call to the public internet 1154 can be transmitted to a NAT gateway 1138 that can make calls to the public internet 1154. The request may expect storage to be located in one or more DB subnets 1130.

[0240] In some examples, the data plane mirroring application layer 1140 can facilitate direct communication between the control plane VCN 1116 and the data plane VCN 1118. For example, it may be desirable to apply configuration changes, updates, or other appropriate modifications to resources contained in the data plane VCN 1118. Through VNIC 1142, the control plane VCN 1116 can communicate directly with the resources contained in the data plane VCN 1118, and thus can perform configuration changes, updates, or other appropriate modifications to these resources.

[0241] In some embodiments, the control plane VCN 1116 and data plane VCN 1118 may be included in service lease 1119. In this case, the system's users or customers may not own or operate the control plane VCN 1116 or data plane VCN 1118. Alternatively, the IaaS provider may own or operate both the control plane VCN 1116 and data plane VCN 1118, and both planes may be included in service lease 1119. This embodiment can enable the isolation of networks that might prevent users or customers from interacting with the resources of other users or customers. Furthermore, this embodiment can allow users or customers of the system to privately store databases without relying on the public Internet 1154, which may not have the desired level of security for storage.

[0242] In other embodiments, one or more LB subnets 1122 included in the control plane VCN 1116 may be configured to receive signals from the service gateway 1136. In this embodiment, the control plane VCN 1116 and the data plane VCN 1118 may be configured to be invoked by the IaaS provider's customers without invoking the public internet 1154. The IaaS provider's customers may expect this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on a service lease 1119, which may be isolated from the public internet 1154.

[0243] Figure 7This is a block diagram 1200 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service provider 1202 (e.g., service provider 1102) may be communicatively coupled to a secure hosting lease 1204 (e.g., secure hosting lease 1104), which may include a virtual cloud network (VCN) 1206 (e.g., VCN 1106) and a secure hosting subnet 1208 (e.g., secure hosting subnet 1108). VCN 1206 may include a local peering gateway (LPG) 1210 (e.g., LPG 1110), which may be communicatively coupled to SSH VCN 1212 via LPG 1110 contained in a secure shell (SSH) VCN 1212 (e.g., SSH VCN 111210). SSH VCN 1212 may include SSH subnet 1214 (e.g., SSH subnet 1114), and SSH VCN 1212 may be communicatively coupled to control plane VCN 1216 via LPG 1210 contained in control plane VCN 1216 (e.g., control plane VCN 1116). Control plane VCN 1216 may be contained in service lease 1219 (e.g., service lease 1119), and data plane VCN 1218 (e.g., data plane VCN 1118) may be contained in customer lease 1221, which may be owned or operated by a user or customer of the system.

[0244] The control plane VCN 1216 may include a control plane DMZ layer 1220 (e.g., control plane DMZ layer 1120), which may include one or more LB subnets 1222 (e.g., one or more LB subnets 1122), a control plane application layer 1224 (e.g., control plane application layer 1124) that may include one or more application subnets 1226 (e.g., one or more application subnets 1126), and a control plane data layer 1228 (e.g., control plane data layer 1128) that may include one or more database (DB) subnets 1230 (e.g., similar to one or more DB subnets 1130). One or more LB subnets 1222 contained in the control plane DMZ layer 1220 may be communicatively coupled to one or more application subnets 1226 contained in the control plane application layer 1224 and an Internet gateway 1234 (e.g., Internet gateway 1134) that may be contained in the control plane VCN 1216, and one or more application subnets 1226 may be communicatively coupled to one or more DB subnets 1230 contained in the control plane data layer 1228, as well as a service gateway 1236 and a Network Address Translation (NAT) gateway 1238 (e.g., NAT gateway 1138). The control plane VCN 1216 may include the service gateway 1236 and the NAT gateway 1238.

[0245] Control plane VCN 1216 may include a data plane mirror application layer 1240 (e.g., data plane mirror application layer 1140) that may include one or more application subnets 1226. The one or more application subnets 1226 included in the data plane mirror application layer 1240 may include a virtual network interface controller (VNIC) 1242 (e.g., the VNIC of 1142) capable of performing compute instance 1244 (e.g., similar to compute instance 1144). Compute instance 1244 may facilitate communication between the one or more application subnets 1226 of the data plane mirror application layer 1240 and the one or more application subnets 1226 that may be included in the data plane application layer 1246 (e.g., data plane application layer 1146) via the VNIC 1242 included in the data plane mirror application layer 1240 and the VNIC 1242 included in the data plane application layer 1246.

[0246] Internet gateway 1234, included in control plane VCN 1216, may be communicatively coupled to metadata management service 1252 (e.g., metadata management service 1152), which may be communicatively coupled to public internet 1254 (e.g., public internet 1154). Public internet 1254 may be communicatively coupled to NAT gateway 1238, included in control plane VCN 1216. Service gateway 1236, included in control plane VCN 1216, may be communicatively coupled to cloud service 1256 (e.g., cloud service 1156).

[0247] In some examples, data plane VCN 1218 may be included in customer lease 1221. In this case, the IaaS provider may provide control plane VCN 1216 for each customer, and the IaaS provider may set up a unique compute instance 1244 for each customer, included in service lease 1219. Each compute instance 1244 may allow communication between control plane VCN 1216 included in service lease 1219 and data plane VCN 1218 included in customer lease 1221. Compute instance 1244 may allow resources provisioned in control plane VCN 1216 included in service lease 1219 to be deployed or otherwise used in data plane VCN 1218 included in customer lease 1221.

[0248] In other examples, an IaaS provider's customer may have a database residing in customer lease 1221. In this example, control plane VCN 1216 may include data plane mirror application layer 1240, which may include one or more application subnets 1226. Data plane mirror application layer 1240 may reside in data plane VCN 1218, but may not reside in data plane VCN 1218. In other words, data plane mirror application layer 1240 may have access to customer lease 1221, but may not reside in data plane VCN 1218 or be owned or operated by an IaaS provider's customer. Data plane mirror application layer 1240 may be configured to invoke data plane VCN 1218, but may not be configured to invoke any entity contained in control plane VCN 1216. Customers may expect to deploy or otherwise use resources provided in the control plane VCN 1216 in the data plane VCN 1218, and the data plane mirroring application layer 1240 can facilitate the customer's expected deployment or other use of resources.

[0249] In some embodiments, an IaaS provider's customer may apply filters to data plane VCN 1218. In this embodiment, the customer may determine what data plane VCN 1218 can access, and the customer may restrict access from data plane VCN 1218 to the public Internet 1254. The IaaS provider may not be able to apply filters or otherwise control data plane VCN 1218's access to any external networks or databases. Applying filters and controls to data plane VCN 1218 contained in customer lease 1221 can help isolate data plane VCN 1218 from other customers and the public Internet 1254.

[0250] In some embodiments, cloud service 1256 may be invoked by service gateway 1236 to access services that may not exist on public internet 1254, control plane VCN 1216, or data plane VCN 1218. The connection between cloud service 1256 and control plane VCN 1216 or data plane VCN 1218 may not be real-time or continuous. Cloud service 1256 may reside on different networks owned or operated by an IaaS provider. Cloud service 1256 may be configured to receive calls from service gateway 1236 and may be configured not to receive calls from public internet 1254. Some cloud services 1256 may be isolated from other cloud services 1256, and control plane VCN 1216 may be isolated from cloud services 1256 that may not be in the same region as control plane VCN 1216. For example, control plane VCN 1216 may be located in "Region 1," and cloud service "Deployment 8" may be located in both "Region 1" and "Region 2." If the service gateway 1236, contained in the control plane VCN 1216 located in region 1, makes a call to deployment 8, then that call can be transmitted to deployment 8 in region 1. In this example, the control plane VCN 1216 or deployment 8 in region 1 may not be communicatively coupled to or otherwise communicate with deployment 8 in region 2.

[0251] Figure 8This is a block diagram 1300 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service provider 1302 (e.g., service provider 1102) may be communicatively coupled to a secure hosting lease 1304 (e.g., secure hosting lease 1104), which may include a virtual cloud network (VCN) 1306 (e.g., VCN 1106) and a secure hosting subnet 1308 (e.g., secure hosting subnet 1108). VCN 1306 may include an LPG 1310 (e.g., LPG 1110), which may be communicatively coupled to an SSH VCN 1312 via the LPG 1310 included in an SSH VCN 1312 (e.g., SSH VCN 1112). SSH VCN 1312 may include SSH subnet 1314 (e.g., SSH subnet 1114), and SSH VCN 1312 may be communicatively coupled to control plane VCN 1316 via LPG 1310 included in control plane VCN 1316 (e.g., control plane VCN 1116) and communicatively coupled to data plane VCN 1318 via LPG 1310 included in data plane VCN 1318 (e.g., data plane 1118). Control plane VCN 1316 and data plane VCN 1318 may be contained in service lease 1319 (e.g., service lease 1119).

[0252] The control plane VCN 1316 may include a control plane DMZ layer 1320 (e.g., control plane DMZ layer 1120) that may include one or more load balancer (“LB”) subnets 1322 (e.g., one or more LB subnets 1122), a control plane application layer 1324 (e.g., control plane application layer 1124) that may include one or more application subnets 1326 (e.g., similar to one or more application subnets 1126), and a control plane data layer 1328 (e.g., control plane data layer 1128) that may include one or more DB subnets 1330. One or more LB subnets 1322 contained in the control plane DMZ layer 1320 may be communicatively coupled to one or more application subnets 1326 contained in the control plane application layer 1324 and an Internet gateway 1334 (e.g., Internet gateway 1134) that may be contained in the control plane VCN 1316. One or more application subnets 1326 may be communicatively coupled to one or more DB subnets 1330 contained in the control plane data layer 1328, as well as a service gateway 1336 (e.g., a service gateway) and a Network Address Translation (NAT) gateway 1338 (e.g., a NAT gateway 1138). The control plane VCN 1316 may include the service gateway 1336 and the NAT gateway 1338.

[0253] Data plane VCN 1318 may include data plane application layer 1346 (e.g., data plane application layer 1146), data plane DMZ layer 1348 (e.g., data plane DMZ layer 1148), and data plane data layer 1350 (e.g., data plane data layer 1150 of FIG. 10). Data plane DMZ layer 1348 may include one or more trusted application subnets 1360 and one or more untrusted application subnets 1362 communicatively coupled to data plane application layer 1346, and one or more LB subnets 1322 of Internet gateway 1334 contained in data plane VCN 1318. One or more trusted application subnets 1360 may be communicatively coupled to service gateway 1336, NAT gateway 1338 contained in data plane VCN 1318, and one or more DB subnets 1330 contained in data plane data layer 1350. One or more untrusted application subnets 1362 may be communicatively coupled to a service gateway 1336 contained in a data plane VCN 1318 and one or more database subnets 1330 contained in a data plane data layer 1350. The data plane data layer 1350 may include one or more database subnets 1330 that may be communicatively coupled to a service gateway 1336 contained in a data plane VCN 1318.

[0254] One or more untrusted application subnets 1362 may include one or more primary VNICs 1364(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 1366(1)-(N). Each tenant VM 1366(1)-(N) may be communicatively coupled to a corresponding application subnet 1367(1)-(N) that may be contained in a corresponding container egress VCN 1368(1)-(N) that may be contained in a corresponding customer lease 1370(1)-(N). A corresponding secondary VNIC 1372(1)-(N) may facilitate communication between one or more untrusted application subnets 1362 contained in a data plane VCN 1318 and application subnets contained in container egress VCN 1368(1)-(N). Each container exit VCN 1368(1)-(N) may include a NAT gateway 1338 that can be communicatively coupled to the public Internet 1354 (e.g., the public Internet 1154).

[0255] Internet gateway 1334, contained in control plane VCN 1316 and data plane VCN 1318, can be communicatively coupled to metadata management service 1352 (e.g., metadata management system 1152), which can be communicatively coupled to public internet 1354. Public internet 1354 can be communicatively coupled to NAT gateway 1338, contained in control plane VCN 1316 and data plane VCN 1318. Service gateway 1336, contained in control plane VCN 1316 and data plane VCN 1318, can be communicatively coupled to cloud service 1356.

[0256] In some embodiments, the data plane VCN 1318 may be integrated with the customer lease 1370. Such integration may be useful or desired by the IaaS provider's customer in certain situations, such as when support may be expected during code execution. The customer may provide code that could be destructive, might communicate with other customer resources, or might otherwise cause undesirable effects. In response, the IaaS provider may determine whether to run the code provided by the customer.

[0257] In some examples, an IaaS provider's customer may grant the IaaS provider temporary network access and request functionality to be attached to data plane layer application 1346. The code running this functionality may execute in VMs 1366(1)-(N) and may not be configured to run anywhere else on data plane VCN 1318. Each VM 1366(1)-(N) may be connected to a customer lease 1370. The corresponding container 1371(1)-(N) contained in VMs 1366(1)-(N) may be configured to run the code. In this case, dual isolation may exist (e.g., container 1371(1)-(N) runs the code, where container 1371(1)-(N) may be contained in at least one or more untrusted application subnets 1362 containing VMs 1366(1)-(N)), which can help prevent incorrect or otherwise unintended code from corrupting the IaaS provider's network or the networks of different customers. Containers 1371(1)-(N) may be communicatively coupled to customer lease 1370 and may be configured to transmit or receive data from customer lease 1370. Containers 1371(1)-(N) may not be configured to transmit or receive data from any other entity in the data plane VCN 1318. After the code execution is complete, the IaaS provider may terminate or otherwise dispose of containers 1371(1)-(N).

[0258] In some embodiments, one or more trusted application subnets 1360 may run code that can be owned or operated by an IaaS provider. In this embodiment, one or more trusted application subnets 1360 may be communicatively coupled to one or more database subnets 1330 and configured to perform CRUD operations in one or more database subnets 1330. One or more untrusted application subnets 1362 may be communicatively coupled to one or more database subnets 1330, but in this embodiment, one or more untrusted application subnets may be configured to perform read operations in one or more database subnets 1330. Containers 1371(1)-(N) that may be contained in each customer's VM 1366(1)-(N) and may run code from the customer may not be communicatively coupled to one or more database subnets 1330.

[0259] In other embodiments, the control plane VCN 1316 and the data plane VCN 1318 may be coupled without direct communication. In this embodiment, there may not be direct communication between the control plane VCN 1316 and the data plane VCN 1318. However, communication may occur indirectly through at least one method. The LPG 1310 may be established by the IaaS provider, which can facilitate communication between the control plane VCN 1316 and the data plane VCN 1318. In another example, the control plane VCN 1316 or the data plane VCN 1318 may invoke the cloud service 1356 via the service gateway 1336. For example, an invocation of the cloud service 1356 from the control plane VCN 1316 may include a request for a service that can communicate with the data plane VCN 1318.

[0260] Figure 9This is a block diagram 1400 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service operator 1402 (e.g., service operator 1102) may be communicatively coupled to a secure hosting lease 1404 (e.g., secure hosting lease 1104), which may include a virtual cloud network (“VCN”) 1406 (e.g., VCN 1106) and a secure hosting subnet 1408 (e.g., secure hosting subnet 1108). VCN 1406 may include an LPG 1410 (e.g., LPG 1110), which may be communicatively coupled to an SSH VCN 1412 via the LPG 1410 included in an SSH VCN 1412 (e.g., SSH VCN 1112). SSH VCN 1412 may include SSH subnet 1414 (e.g., SSH subnet 1114), and SSH VCN 1412 may be communicatively coupled to control plane VCN 1416 via LPG 1410 included in control plane VCN 1416 (e.g., control plane VCN 1116) and communicatively coupled to data plane VCN 1418 via LPG 1410 included in data plane VCN 1418 (e.g., data plane 1118). Control plane VCN 1416 and data plane VCN 1418 may be contained in service lease 1419 (e.g., service lease 1119).

[0261] The control plane VCN 1416 may include a control plane DMZ layer 1420 (e.g., control plane DMZ layer 1120) that may include one or more LB subnets 1422 (e.g., one or more LB subnets 1122), a control plane application layer 1424 (e.g., control plane application layer 1124) that may include one or more application subnets 1426 (e.g., one or more application subnets 1126), and a control plane data layer 1428 (e.g., control plane data layer 1128) that may include one or more DB subnets 1430 (e.g., one or more DB subnets 1330). One or more LB subnets 1422 contained in the control plane DMZ layer 1420 may be communicatively coupled to one or more application subnets 1426 contained in the control plane application layer 1424 and an Internet gateway 1434 (e.g., Internet gateway 1134) that may be contained in the control plane VCN 1416. One or more application subnets 1426 may be communicatively coupled to one or more DB subnets 1430 contained in the control plane data layer 1428, as well as a service gateway 1436 (e.g., the service gateway of Figure 10) and a Network Address Translation (NAT) gateway 1438 (e.g., the NAT gateway 1138 of Figure 10). The control plane VCN 1416 may include the service gateway 1436 and the NAT gateway 1438.

[0262] Data plane VCN 1418 may include data plane application layer 1446 (e.g., data plane application layer 1146), data plane DMZ layer 1448 (e.g., data plane DMZ layer 1148), and data plane data layer 1450 (e.g., data plane data layer 1150). Data plane DMZ layer 1448 may include one or more trusted application subnets 1460 (e.g., one or more trusted application subnets 1360) and one or more untrusted application subnets 1462 (e.g., one or more untrusted application subnets 1362) communicatively coupled to data plane application layer 1446, and one or more LB subnets 1422 of Internet gateway 1434 contained in data plane VCN 1418. One or more trusted application subnets 1460 may be communicatively coupled to a service gateway 1436 contained in a data plane VCN 1418, a NAT gateway 1438 contained in a data plane VCN 1418, and one or more DB subnets 1430 contained in a data plane data layer 1450. One or more untrusted application subnets 1462 may be communicatively coupled to a service gateway 1436 contained in a data plane VCN 1418 and one or more DB subnets 1430 contained in a data plane data layer 1450. The data plane data layer 1450 may include one or more DB subnets 1430 that may be communicatively coupled to a service gateway 1436 contained in a data plane VCN 1418.

[0263] One or more untrusted application subnets 1462 may include a primary VNIC 1464(1)-(N) communicatively coupled to tenant virtual machines (VMs) 1466(1)-(N) residing within one or more untrusted application subnets 1462. Each tenant VM 1466(1)-(N) may run code in a corresponding container 1467(1)-(N) and is communicatively coupled to an application subnet 1426 that may be contained in a data plane application layer 1446, which may be contained in a container egress VCN 1468. A corresponding secondary VNIC 1472(1)-(N) may facilitate communication between one or more untrusted application subnets 1462 contained in a data plane VCN 1418 and the application subnets contained in a container egress VCN 1468. The container egress VCN may include a NAT gateway 1438 communicatively coupled to a public internet 1454 (e.g., public internet 1154).

[0264] Internet gateway 1434, contained in control plane VCN 1416 and data plane VCN 1418, can be communicatively coupled to metadata management service 1452 (e.g., metadata management system 1152), which can be communicatively coupled to public internet 1454. Public internet 1454 can be communicatively coupled to NAT gateway 1438, contained in control plane VCN 1416 and data plane VCN 1418. Service gateway 1436, contained in control plane VCN 1416 and data plane VCN 1418, can be communicatively coupled to cloud service 1456.

[0265] In some examples, Figure 9 The architecture shown in block diagram 1400 can be considered as... Figure 8 This is an exception to the pattern shown in the architecture of block diagram 1300, and is likely what the IaaS provider's customers would expect in situations where the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). Customers can access each customer's corresponding container 1467(1)-(N) contained in VMs 1466(1)-(N) in real time. Containers 1467(1)-(N) can be configured to invoke corresponding secondary VNICs 1472(1)-(N) contained in one or more application subnets 1426 of the data plane application layer 1446, which may be contained in a container egress VCN 1468. The secondary VNICs 1472(1)-(N) can transmit the calls to a NAT gateway 1438, which can then transmit the calls to the public internet 1454. In this example, containers 1467(1)-(N), which can be accessed by clients in real time, can be isolated from the control plane VCN 1416 and from other entities contained in the data plane VCN 1418. Containers 1467(1)-(N) can also be isolated from resources from other clients.

[0266] In other examples, a client can use containers 1467(1)-(N) to invoke cloud service 1456. In this example, the client can run code within containers 1467(1)-(N) requesting a service from cloud service 1456. Container 1467(1)-(N) can then forward the request to a secondary VNIC 1472(1)-(N), which can then forward the request to a NAT gateway, which can then forward the request to the public internet 1454. The public internet 1454 can then forward the request via internet gateway 1434 to one or more LB subnets 1422 contained in control plane VCN 1416. In response to determining that the request is valid, one or more LB subnets can then forward the request to one or more application subnets 1426, which can then forward the request to cloud service 1456 via service gateway 1436.

[0267] It should be recognized that the IaaS architectures 1100, 1200, 1300, and 1400 depicted in the figures may have components other than those depicted. Furthermore, the embodiments shown in the figures are merely examples of cloud infrastructure systems that can be combined with certain embodiments. In some other embodiments, the IaaS system may have more or fewer components than shown in the figures, may combine two or more components, or may have different component arrangements or configurations.

[0268] As disclosed, the embodiments address the overbooking problem in hotel operations with multiple room categories. Each pair of room categories can be compared in a sense that one is better than the other (e.g., larger room, larger bed, better view, etc.), or they may not be comparable if one room category has a better view but a smaller room size. If one room category is better than the other, then guests can be upgraded from the basic category to the premium category when the basic category is overbooked or the guest agrees to pay an upgrade fee. If the premium category is underbooked, this mechanism allows the hotel to overbook the basic category.

[0269] However, over-booking the Basic category too aggressively can lead to lost revenue when late bookings in the Premium category are blocked by early upgrades from the Basic category. Therefore, even if there is currently available space in the Premium category, some revenue protection mechanism should be imposed to limit the number of bookings in the Basic category. Because of a significant number of hotel booking cancellations, the overall hotel booking limit can exceed the total number of rooms by accepting the small risk of refusing to provide rooms to guests.

[0270] In this embodiment, the stochastic nature of the problem is addressed by formulating the problem as a robust optimization to guarantee optimal performance in the worst-case scenario and account for errors in estimating cancellation probabilities. The decision variables are the daily booking limit for each hotel room category and the assignment variable representing the upgrade strategy for each day's operations. The optimization objective is total profit, defined as the difference between revenue collected from bookings and the cost of downgrading hotel guests. The primary constraint is the limit on room inventory for each category.

[0271] The embodiment includes a model for hotel revenue management that adapts to multiple room types and multi-day bookings. The model utilizes a two-stage optimization framework. On each day, in the first stage (referred to as the booking stage), the decision variable is an overbooking limit assigned to each room type. Subsequently, in the second stage (also referred to as the service stage), the embodiment includes assignment decision variables representing escalation strategies. These variables are adaptive and depend on realized demand and cancellations. Therefore, they provide flexibility to dynamically respond to the actual outcomes of customer behavior. Furthermore, the model considers worst-case scenarios of no-shows and cancellations, which are addressed through robust optimization.

[0272] Specifically, the implementation adopts a linear decision rule to transition from a two-stage optimization problem to a more manageable single-stage problem. To address the probabilistic nature of customer cancellations and absences, the implementation fully utilizes specific probability set inequalities to construct a polyhedron encapsulating the uncertainties associated with these random variables. Thus, the implementation introduces a theoretical adversary whose task is to minimize the total payoff by choosing values ​​of random variables within a specified region of uncertainty. This leads to the derivation of a “robust counterpart” for each constraint. Specifically, a robust counterpart is a version of the original constraint without random variables. Furthermore, it maintains its integrity by incorporating the influence of both the adversary and the region of uncertainty polyhedron. These robust counterparts are equivalently expressed as linear equations, resulting in a linear optimization problem. Finally, the linear optimization problem is solved by one of the industry-wide standard linear programming solvers.

[0273] Compared to known solutions, this implementation uniquely integrates four key components: (1) optimization of booking limits; (2) addressing the inherent variability of customer attendance; (3) a dynamic escalation strategy tailored to observed demand; and (4) consideration of multi-day stays. While some known solutions address these factors in isolation, their interdependencies (such as how specific escalation strategies alter optimal booking limits) mean that these known solutions cannot address this comprehensive challenge.

[0274] The comprehensive adaptive robust optimization framework in this embodiment seamlessly integrates all variables while considering the intricate interactions between the components of the problem. This approach to developing optimization methods concurrently solves several problems that typically present significant analytical challenges. The embodiment transforms the original robust optimization problem into a nearly equivalent linear programming formula.

[0275] The features, structures, or characteristics of this disclosure described throughout this specification can be combined in any suitable manner in one or more embodiments. For example, the use of terms such as "one embodiment," "some embodiments," "specific embodiments," "certain embodiments," or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with that embodiment can be included in at least one embodiment of this disclosure. Therefore, the appearance of the phrases "one embodiment," "some embodiments," "specific embodiments," "certain embodiments," or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0276] It will be readily understood by those skilled in the art that the embodiments discussed above can be practiced with steps in a different order and / or with elements in a configuration different from the disclosed configuration. Therefore, while this disclosure contemplates the outlined embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions can be made while remaining within the spirit and scope of this disclosure. Therefore, reference should be made to the appended claims to determine the scope and limits of this disclosure.

Claims

1. A method for optimizing hotel room reservations, the method comprising: For the first day of a multi-day period, the overbooking limit for hotel rooms in each category is automatically determined based on an objective function, where the hotel includes multiple different room categories; Receive the first reservation request for a Class 1 room on the first day; If the overbooking limit for Category 1 rooms has not been reached, accept the first reservation request; When the first reservation request has been accepted and the hotel is being checked in on the first day, the check-in decision is automatically determined based on the objective function, which can be used to reject the first reservation request, accept the first reservation request, or upgrade the first reservation request to a higher category of room.

2. The method of claim 1, further comprising determining an overbooking limit for the sequence of future multi-day periods.

3. The method of claim 1, further comprising using a first machine learning model to generate predictions of new appointments for the next few days.

4. The method of claim 1, further comprising using a second machine learning model to generate predictions of cancellations of existing appointments.

5. The method of claim 1, further comprising: Generate a mixed-integer optimization problem (MILP) that models both overbooking limits and check-in decisions. as well as The MILP problem is transformed into a linear optimization problem using a polyhedral uncertainty set for the total number of customers arriving at the hotel.

6. The method of claim 5, wherein the MILP comprises a plurality of random variables, and the polyhedral uncertainty set eliminates the random variables.

7. The method of claim 6, wherein the linear optimization problem includes a plurality of constraints containing uncertainty, and further includes developing a robust counterpart without random variables for each of the plurality of constraints.

8. The method of claim 1, further comprising: In response to the check-in decision, the corresponding hotel room card is automatically coded.

9. A computer-readable medium having instructions stored thereon, the instructions, when executed by one or more processors, causing the processors to optimize hotel room reservations for a hotel, the optimization comprising: For the first day of a multi-day period, the overbooking limit for hotel rooms in each category is automatically determined based on an objective function, where the hotel includes multiple different room categories; Receive the first reservation request for a Class 1 room on the first day; If the overbooking limit for Category 1 rooms has not been reached, accept the first reservation request; When the first reservation request has been accepted and the hotel is being checked in on the first day, the check-in decision is automatically determined based on the objective function, which can be used to reject the first reservation request, accept the first reservation request, or upgrade the first reservation request to a higher category of room.

10. The computer-readable medium of claim 9, wherein the optimization further includes determining an overbooking limit for the sequence of future multi-day periods.

11. The computer-readable medium of claim 9, wherein the optimization further comprises using a first machine learning model to generate predictions for new appointments for the next multiple days.

12. The computer-readable medium of claim 9, wherein the optimization further includes using a second machine learning model to generate predictions of cancellations of existing appointments.

13. The computer-readable medium of claim 9, wherein the optimization further comprises: Generate a mixed-integer optimization problem (MILP) that models both overbooking limits and check-in decisions. as well as The MILP problem is transformed into a linear optimization problem using a polyhedral uncertainty set for the total number of customers arriving at the hotel.

14. The computer-readable medium of claim 13, wherein the MILP comprises a plurality of random variables, and the polyhedral uncertainty set eliminates the random variables.

15. The computer-readable medium of claim 14, wherein the linear optimization problem includes a plurality of constraints containing uncertainty, and further includes developing a robust counterpart without random variables for each of the plurality of constraints.

16. The computer-readable medium of claim 9, wherein the optimization further comprises: In response to the check-in decision, the corresponding hotel room card is automatically coded.

17. A cloud-based hotel reservation system that optimizes hotel room reservations, the system comprising: One or more processors, adapted to: For the first day of a multi-day period, the overbooking limit for hotel rooms in each category is automatically determined based on an objective function, where the hotel includes multiple different room categories; Receive the first reservation request for a Class 1 room on the first day; If the overbooking limit for Category 1 rooms has not been reached, accept the first reservation request; When the first reservation request has been accepted and the hotel is being checked in on the first day, the check-in decision is automatically determined based on the objective function, which can be used to reject the first reservation request, accept the first reservation request, or upgrade the first reservation request to a higher category of room.

18. The system of claim 17, wherein the processor further determines an overbooking limit for the future multi-day sequence.

19. The system of claim 17, further comprising a first trained machine learning model, and using the first trained machine learning model to generate predictions for new appointments for the next multiple days.

20. The system of claim 17, further comprising a second trained machine learning model, and using the second trained machine learning model to generate predictions of cancellations of existing appointments.

Images