Machine learning based occupancy forecast

Abstract

This embodiment determines a final occupancy forecast for multiple hotel room check-in dates. The embodiment receives historical reservation data including multiple booking curves for hotel rooms corresponding to multiple reservation windows, the historical reservation data including multiple features. Based on the historical reservation data, the embodiment uses a first model to generate a first occupancy forecast for the check-in date and uses a second model to generate a second occupancy forecast for the check-in date. The embodiment determines the best-performing model from at least the first and second models, and uses the corresponding occupancy forecast of the best-performing model as the final occupancy forecast for the check-in date.

Description

Technical Field

[0001] One embodiment generally relates to a computer system, and more specifically to a computer system for implementing machine learning-based occupancy prediction. Background Technology

[0002] 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 pioneered 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.

[0003] A very common application of revenue management involves service providers accepting reservations for "date-constrained services." Date-constrained services involve imposing transaction-specific, mandatory requirements 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 estimating demand and thus determining optimal pricing that maximizes revenue / profit for date-constrained services, especially in the hotel industry, particularly difficult. Summary of the Invention

[0004] This embodiment determines the final occupancy forecast for multiple hotel room check-in dates. The embodiment receives historical reservation data including multiple booking curves for hotel rooms corresponding to multiple reservation windows, the historical reservation data comprising multiple features. Based on the historical reservation data, the embodiment uses a first model to generate a first occupancy forecast for the check-in date and uses a second model to generate a second occupancy forecast for the check-in date. The embodiment determines the best-performing model from at least the first and second models, and uses the corresponding occupancy forecast of the best-performing model as the final occupancy forecast for the check-in date. Attached Figure Description

[0005] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate various systems, methods, and other embodiments of this 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. Furthermore, elements may not be drawn to scale.

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

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

[0008] Figure 3 This is based on the implementation example when forecasting / predicting occupancy and then optimizing prices. Figure 2 Functional flowchart / block diagram of the occupancy forecast module.

[0009] Figure 4 An example booking curve according to an embodiment is illustrated.

[0010] Figure 5 An example booking curve according to an embodiment is illustrated.

[0011] Figure 6 An example booking curve according to an embodiment is illustrated.

[0012] Figure 7 The illustration shows an example booking curve using an N-window summary statistical model according to an embodiment.

[0013] Figure 8 The illustration shows an example booking curve using an enhanced similarity model according to an embodiment.

[0014] Figure 9 The diagram illustrates the construction of the estimator tree and the associated decision variables according to an embodiment.

[0015] Figure 10-13 The illustration depicts an example cloud infrastructure that can be combined with a network cloud, which may include, according to embodiments, [the network cloud]. Figure 1 Occupancy forecasting system. Detailed Implementation

[0016] The embodiment generates occupancy forecasts for hotels or other date-bound services by using historical booking patterns, and employs multiple machine learning models for occupancy prediction / forecasting, selecting the best-performing model based on booking curve similarity. Instead of treating occupancy for each business date as a continuous data series, the embodiment examines each business date individually. The embodiment then optimizes pricing and revenue based on the occupancy forecasts.

[0017] As disclosed, revenue management is a key component of hotel management and other date-bound services. For many hotels, room revenue accounts for the majority of revenue. Room revenue can generally be defined as the number of rooms occupied multiplied by the room rate. Revenue per available room (“RevPAR”) is an important metric for evaluating hotel operations.

[0018] Knowing with high certainty in advance how many rooms will be occupied for a given business date greatly helps in optimizing revenue, allowing revenue managers to adjust rates accordingly. However, future hotel bookings can be difficult to predict for several reasons. First, occupancy rates can vary depending on the day of the week. For example, rates and occupancy tend to be higher on Fridays and Saturdays, while they tend to be lower on Sundays and other weekdays. Second, hotel demand is highly seasonal. There are peak and off-peak seasons for tourism, meetings, and special events. During peak seasons, rooms are harder to book and are typically booked at higher prices, and vice versa. Third, depending on the type of hotel, there are very different booking patterns, as types include airport hotels, downtown hotels, conference centers, resorts, etc. For example, conference centers will know in advance the number of meetings booked and the expected number of rooms booked, while airport hotels may have many last-minute bookings due to weather or delays. Finally, large-scale unforeseen events can disrupt long-standing patterns. For example, COVID had a significant impact on the tourism industry before the availability of a vaccine.

[0019] All of the above characteristics make occupancy forecasting difficult using known methods. In particular, occupancy forecasts using known methods (such as moving averages or time series forecasts combined with historical occupancy rates) generally have unacceptably large margins of error.

[0020] A unique characteristic of hotel occupancy rates (and other date-bound services) is that final occupancy is closely linked to reservations. Many reservations are made in advance. As the check-in date approaches, the certainty of occupancy rate predictions increases.

[0021] For each business day, there exists a reservation curve, which is the number of existing (i.e., uncancelled) reservations as a function of the number of days preceding the occupancy night. All occupancy nights start with zero reserved rooms. As reservations are made, the number of reserved rooms increases. If a reservation is cancelled, the number of reserved rooms for that date decreases. By examining historical reservation and cancellation data, each occupancy night in the embodiment is mapped to a net cumulative reservation curve. Based on the intuition that if occupancy nights have similar reservation patterns, then the occupancy rates of those nights should also be similar, the embodiment uses the similarity between different reservation curves to predict future occupancy rates.

[0022] For the target date, the implementation uses reservations made up to an appointment window (e.g., 30 days) and compares this set of reservations with all historical dates up to the same appointment window in the database for the same property. The most similar curve is determined by k minimum mean squared error (“MSE”) or weighted average absolute percentage error (“WMAPE”). The median occupancy rate for these k dates is the prediction for the target date.

[0023] Because each reservation has multiple characteristics, such as the number of adults and children, length of stay, booking channel, room type, and room rate, this implementation uses this information to calculate the similarity of reservation curves, which are essentially multidimensional curves. The basic assumption is that if multiple characteristics of a business date series are similar, then the resulting occupancy rates should also be similar. To predict occupancy rates, each characteristic of the target date's reservation curve is compared to that characteristic at the same point in time on other historical date's reservation curves, and a specific proximity score (such as MSE or WMAPE) is calculated to quantify the difference between any two curves. To account for seasonality, the differences between the target date and historical dates in terms of weekdays and months are also considered. These scores are standardized and composited across all characteristics to measure the similarity between dates. Similar dates are identified, and the median of their occupancy rates is used as a prediction for the target date.

[0024] The embodiments utilize multiple machine learning (“ML”) prediction models tested on historical booking data for each hotel property or a set of properties. The best-performing model determined in the embodiments may vary across different properties. Additionally, this testing and validation process also allows for the selection of the best-performing set of hyperparameters.

[0025] 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 in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure can 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.

[0026] 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.

[0027] Each hotel chain operation 104 is accessed by an application programming interface (“API”) 140, which is 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 System” from Oracle Corporation), a hotel central reservation system (“CRS”) 122, and an occupancy forecast module 150 that interfaces with systems 121 and 122 to provide occupancy forecasts and all other functionality disclosed herein. In an 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.

[0028] Hotel customers or potential hotel customers using 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.

[0029] If a booking customer selects a hotel, they proceed to the next step: a property search. This search 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, allowing booking customers to select a room. After selecting a room, the final step is to finalize the booking and secure the reservation via credit card or other payment method.

[0030] 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 in the document.

[0031] 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 consist of any combination of random access memory (“RAM”), read-only memory (“ROM”), static storage devices (such as magnetic or optical discs), 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 interface directly with system 10, or remotely via a network, or through any other method.

[0032] 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.

[0033] 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.

[0034] In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality to system 10. The modules also include an occupancy forecasting module 16 that forecasts occupancy and determines optimized pricing for date-constrained inventory (such as hotel rooms). System 10 may be part of a larger system. Therefore, system 10 may include one or more additional functional modules 18 to include additional functionality, such as a property management system (“PMS”) (e.g., “Oracle Hospitality OPERA Property” or “Oracle Hospitality OPERA Cloud Service”) 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.

[0035] 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 for 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 digital data streams representing various types of information.

[0036] 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.

[0037] 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. Received code can be executed by processor 22 upon receipt and / or stored in database 17 or other non-volatile storage for later execution.

[0038] 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.

[0039] The example uses historical booking patterns combined with reservation windows to predict occupancy rates for date-constrained inventory such as hotel rooms. The example generates multiple ML models (i.e., trains ML algorithms) to produce predictions. For computational efficiency, regression is performed on the aggregated statistics at the selected forecast window to identify “important” features when making predictions; this is called an n-window aggregated statistical regression model. The example can also use this model to predict occupancy rates. Other examples model historical patterns using functional regression, referred to as a “longitudinal model.”

[0040] In this embodiment, multiple function data points are selected from the booking curve for each business date. A regression model is used for prediction. Using a similarity model, the embodiment quantifies the proximity of each of the two curves with scores such as MSE or WMAPE. When comparing multiple features for each business date, the proximity scores of these features are trained with a regression model to make occupancy predictions. Since the best-performing model may differ between different properties, these results are compared and analyzed across models to optimize the final occupancy prediction.

[0041] Figure 3 In accordance with the embodiment, when forecasting / predicting occupancy and then optimizing the price Figure 2 A functional flowchart / block diagram of the occupancy prediction module 16. In one embodiment, Figure 3 The 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.

[0042] At point 302, historical data is received. In this embodiment, the historical data is received from a property management system (such as...). Figure 1 The PMS121 receives the data. In this embodiment, the historical data includes the following characteristics:

[0043] BUSINESS_DATE: This table is updated daily and contains information on new guest check-ins, current stays of existing guests, and check-outs.

[0044] Unique ID: RESV_NAME_ID, NAME_ID, etc.

[0045] Date-related columns:

[0046] oBUSINESS_DATE_CREATED

[0047] oINSERT_DATE

[0048] oTRUNC_BEGIN_DATE

[0049] oTRUNC_END_DATE

[0050] oCANCELLATION_DATE

[0051] RESV_STATUS: Checked in, Checked out, Cancelled, No appearance, Booked

[0052] GROUP_ID: Each entry represents a room. If a group booking with multiple rooms is made, then those entries will have their unique ID and the same group ID.

[0053] Classification features

[0054] oRATE_CODE

[0055] oRATE_CATEGORY

[0056] oMARKET_MAIN_GROUP

[0057] oSOURCE_CODE

[0058] oSOURCE_MAIN_GROUP

[0059] oMARKET_CODE

[0060] oCHANNEL

[0061] oCOUNTRY

[0062] oROOM_CATEGORY

[0063] oROOM_CLASS

[0064] oVIP STATUS

[0065] ROOM: The room number of the booked room, used to verify a valid room and a unique reservation.

[0066] PHYSICAL QUANTITY

[0067] ROOM_ADULTS

[0068] ROOM_CHILDREN

[0069] RATE_AMOUNT: The total amount paid by the guest, some of which may include breakfast and tax.

[0070] PSUEDO_ROOM_YN

[0071] PRIMARY_YN

[0072] STAY_ROOMS: 1 indicates a checked-in reservation, and 0 or more indicates a cancelled reservation.

[0073] At position 304, the received historical data undergoes preprocessing, including feature extraction, encoding, and other feature engineering. Because the example forecasts occupancy a certain number of days prior to check-in, it indicates the number of current and cancelled reservations and their characteristics. For each reservation, the following features, typically available in the hotel's PMS, are extracted:

[0074] Numerical characteristics (including binary):

[0075] Reservation window (how many days in advance to make a reservation)

[0076] Duration of stay

[0077] House price

[0078] Refundability

[0079] number of adults

[0080] Number of children

[0081] Group booking

[0082] Corporate Discounts

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

[0084] Membership points or other cumulative reward tiers (if applicable)

[0085] Classification characteristics:

[0086] Room categories

[0087] Price plan (list price, best available price (BAR), including breakfast, etc.)

[0088] The following are alternative booking channels:

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

[0090] o Global Distribution System (GDS), such as Apollo

[0091] Hotel website or telephone reservation system

[0092] o other

[0093] The categorical features listed above are encoded as one-hot numerical features. These features are then averaged over all active (i.e., non-cancelled) reservations for the target date.

[0094] Additional categorical features were collected for the stay date, including:

[0095] Months of the year

[0096] Dates of the week

[0097] Holidays or special events

[0098] Finally, the total number of active reservations was used as a numerical feature.

[0099] The target variable for all forecasting models disclosed in the embodiments below is the occupancy level of a particular property as a percentage of available rooms on a particular date. Additionally, in the embodiments, all forecasting models explore booking curves, which are the number of currently active bookings as a function of the number of days prior to the stay date. Figure 4 An example booking curve according to an embodiment is illustrated. Figure 4 In the example, there are 14 booking curves for a two-week period in July 2021. These curves are used in embodiments using the forecasting model to infer the value of the target variable based on booking history.

[0100] At point 306, subsequent functionality is performed for each reservation window N, where N is the number of days prior to the target check-in date (e.g., 20 days, 30 days, etc.). Therefore, the input data consists of N repeated samples of reservations that constitute the multidimensional booking curve.

[0101] At 308, the N-window summary statistical model, detailed below, provides a prediction of occupancy levels for future dates, along with a subset of features determined based on a level of "importance." Then, at 312, a subset of features is used in conjunction with the longitudinal model, and at 314, a subset of features is used in conjunction with the similarity model to generate additional occupancy level predictions for future dates, as disclosed below. At 316, the three models are evaluated to determine the best-performing model by comparing their weighted average absolute percentage error ("WMAPE"), which is calculated as follows: ,in It is the actual value and These are forecast values. Their difference divided by the actual value. The occupancy rate for each forecast in the observed data is summed with respect to the absolute value of this ratio and divided by the number of observations, n. The forecast from the best-performing model is then used for the occupancy rate forecast at point 318. This occupancy rate forecast is then used at point 320 to optimize hotel room pricing.

[0102] In one embodiment, a similarity model is implemented at position 314. Machine learning similarity models, often referred to as similarity models or similarity measures, are a type of model used in machine learning and data analysis to measure the similarity or dissimilarity between two or more data points. These data points can take various forms, such as text documents, images, numerical vectors, or any other type of data. The goal is to quantify how similar or different these data points are based on their properties or features.

[0103] The similarity model in the embodiments assumes that if certain business dates share similar booking patterns, then the final occupancy rates for those business dates should also be similar. Figure 5 An example booking curve according to an embodiment is illustrated. Figure 5 As shown, the booking curves approximately follow the same pattern. Each line in the graph represents a cumulative booking curve for a past business date. These curves reflect the overall booking pattern, including the number of existing bookings for each day up to the check-in date and the final occupancy rate for the stay date. They are labeled with the corresponding stay dates. Line 502 corresponds to the target date / curve, as the check-in date is in the future, and only partial data up to the current observation date is observed. The occupancy rate for the date marked as day 0 in the graph is marked by points 503, 504, 505, etc. Figure 5For illustrative purposes, the booking window is truncated to 60 days, and the forecast window 510 is 30 days. However, since line 502 is most similar to line 504, it can be expected that the booking curve represented by line 502 will produce an occupancy rate very close to that represented by line 504, which has been observed in the past. Therefore, the occupancy rate forecast for the booking curve of line 502 is set to the occupancy rate already observed for line 504.

[0104] To predict occupancy rates 30 days in advance, the implementation compares the curves for the 60 days prior to check-in with those for the 30 days prior. A similarity model 314 finds the k most similar curves, and the median and average occupancy rates of these k similar dates are used as the predicted occupancy rate for the target date. The distance between the target curve 502 and each historical curve is calculated using the root mean square error (“RMSE”). The smaller the RMSE score, the more similar the two curves are. The RMSE is calculated between the target date and each historical date, where t = 365, 355, ..., forecast window = 30. The curve with the smallest RMSE is used to predict the occupancy rate for the target date.

[0105] In this embodiment, the similarity-based prediction model 314 is a type of k-nearest neighbor (“k-NN”) nonparametric regression model. Since there are no estimated parameters, there is no need to train or fit the model. The model makes predictions by calculating the average of the observed outputs of the k nearest neighbors, weighted by the inverse of the distances between the curves, where the distances are calculated using RMSE as defined above. The parameter k is a configured hyperparameter, which is set to 7 in one embodiment. Thus, the prediction for curve 502 will be based on curve 504 and its three neighboring curves, 505 and its neighboring curves, and 503 and its neighboring curves, with most of the weights assigned to the four nearest curves (504 and its three neighboring curves).

[0106] At 312, the embodiment implements the longitudinal model in a manner similar to similarity model 314. Instead of using RMSE to determine the k most similar booking patterns, longitudinal model 312 extracts net cumulative data points every few days and fits this data to a regression model. Machine learning longitudinal models are a type of model designed to handle data with a temporal or longitudinal structure. Longitudinal data refers to data collected over a series of time points or observations concerning the same individual, subject, or entity. These models are used to analyze and make predictions based on patterns and relationships within this time series data. Due to strong seasonality and weekday / weekend differences, month and weekday attributes are also added to the training data. The embodiment uses a random forest regression model trained on the observations described above. The trained model is used to predict occupancy rates using newly observed data.

[0107] Figure 6 An example booking curve according to an embodiment is illustrated. Figure 6 The diagram shows an illustrative example of the observation set. The set of explanatory independent variables consists of the number of bookings at different locations on days prior to the stay date and seasonal variables, which are weekdays and months of the year treated as categorical variables. The dependent or target variable is the occupancy rate for the stay date.

[0108] At 308, the embodiment implements an N-window summary statistical model. Instead of viewing historical booking patterns consisting only of the number of bookings for each day in the booking curve, model 308 is designed to allow for the consideration of more features. Such features include total number of adults, total room rate, average length of stay, number of bookings for each channel, etc. Therefore, for each day selected for the booking curve, the set of independent variables now consists of multiple features. In other words, the booking curve becomes multidimensional. One advantage of this model is that it considers multiple features, thus providing high visibility into feature importance. However, when the number of features becomes very large, the model may begin to overfit. The approach used in the embodiment mitigates this effect by using regularization, which in this case is achieved by reducing the number of features to approximately one-tenth of the number of observations. Since the model is implemented as a random forest or extreme tree ensemble model, its features are selected based on their importance scores determined after training the model on historical data. Therefore, the model at 308 serves both as a regression-based predictive model and as a selection of features to be used in other models disclosed below.

[0109] Figure 7 The illustration shows an example booking curve using an N-window summary statistical model according to an embodiment.

[0110] In this embodiment, at 314, an enhanced similarity model is implemented, which is an extension of the "standard" similarity model disclosed above. In the disclosed standard similarity model, predictions are based solely on a single value for each sampling day, resulting in a one-dimensional curve—the historical booking pattern. In the enhanced similarity model, multiple features selected at 308 are included to prevent overfitting of the model. The assumption remains the same: if several dates share similar patterns across multiple features (e.g., room rates, booking trends, channel distribution, etc.), then these dates should share similar multidimensional booking curves. Evaluating the model across all features can be computationally expensive; therefore, this embodiment uses results from the N-window summary statistical model 308 to identify the top ten (or other predefined number) key features.

[0111] In the standard similarity model, only the net cumulative room count for the target date is compared across all historical dates. In contrast, at point 314, for the enhanced similarity model, this calculation is extended to all important features, such that each feature for the target date is compared against the same feature across all historical dates. The RMSE is calculated for each given feature and between each historical date and the target date. This multidimensional booking curve summarizes the standard similarity model, which can be viewed as a special case of the enhanced similarity model.

[0112] Figure 8 The illustration shows an example booking curve using an enhanced similarity model according to an embodiment. Figure 8 As illustrated in the diagram, taking the "important" feature of net cumulative bookings at 804 as an example, the difference between the two booking curves is simplified to an RMSE score. For a feature, the difference between the target date curve and all other curves generates a column of RMSE scores. Each column in the RMSE table corresponds to a feature. Because different features have different units (e.g., the RMSE for room rate amount will be much larger than the RMSE for net room count), but one feature is not more important than another, the MSE is standardized using a standard scaler and then normalized to a value between 0 and 1 using a minimum-maximum scaler. An example of the MSE table for the target date is shown at 802. As shown, the MSE for the target date row will be a list of zeros because it calculates the MSE between itself.

[0113] Similar to standard similarity models, the embodiment determines the row mean for each date, and the dates with the k least-weighted mean values ​​(MSEs) become the dates used for prediction. Alternatively, because a table of data is generated and the target variable is the final occupancy rate, the prediction can be treated as a regression problem and can be trained with any regression model. The embodiment uses Random Forest (“RF”) and Extreme Trees (“ET”) (i.e., tree ensembles) as regression models to be trained using the data described above. These tree ensemble models are then used to issue price recommendations.

[0114] Feature selection

[0115] As disclosed, at position 310, a subset of "important" features is selected, which is used by the longitudinal model at position 312 and by the similarity model at position 314. To select the subset of features, let... Let j be the j-th feature of the i-th reservation and let To stay at time t and exactly ahead of time The set of reservations that are currently active. That is, the size of this set. Is the date t occupied in the reservation window? The value of the booking curve at that location. Then Let represent the average eigenvalue for all N features. These N features are used in an N-window model at position 308 by applying random forest regression. Since random forest regression provides the importance of these features based on its predictive ability for occupancy forecasts, ... A subset of features is selected, where It is a configurable hyperparameter.

[0116] The enhanced similarity model at position 314 and the longitudinal model at position 312 were used in the reservation window. subset of features sampled Therefore, the total number of predictive variables becomes This keeps it at approximately 10% of the observation count (which is the number of hotel occupancy days in the historical dataset). For example, if booking history for the past three years (i.e., approximately one thousand days) is stored, then the total number of predictive features is set to one hundred, or, for example, the ten most important booking features sampled over ten booking windows (e.g., ten weeks). The enhanced similarity model will then use them at 314 to find the k nearest curves as follows: Let The importance of feature j is taken into account. Therefore, the distance between any two pre-booked curves will be calculated as...

[0117]

[0118] in Is it related to the check-in date and The feature difference between the two corresponding curves. In other words, for occupied dates with similar booking curves, the distance between the booking curves will be smaller. Therefore, occupancy prediction is essentially a KNN (k nearest neighbors) method, where the distance is calculated according to the expression above.

[0119] In the longitudinal model at position 312, this These features are used as predictive variables in random forest regression.

[0120] Price / Revenue Optimization

[0121] At 320, the embodiment optimizes hotel revenue by finding the optimal set of room rates and other control characteristics, which will maximize the product of the average room rate and the occupancy rate predicted at 318. Specifically, the embodiment uses individual estimators (i.e., decision trees) of ensemble regressors (such as random forests (“RF”) or extreme trees (“ET”) as disclosed above and finds the optimal values ​​of the control variables that lead to the leaves of the decision tree with the optimal average.

[0122] The example represents the set of predictor feature variables as follows: , where x is a vector of controlled feature values ​​(such as house prices, booking limits, etc.), which is essentially the optimization or processing variable, and w is an environmental variable (such as the date of the week) that is constant for each given optimization problem scenario. Each individual estimator is a decision tree, where each node is split based on some pre-selected feature.

[0123] make It is the estimator index and It is the set of all estimators. For an estimator t, the set of nodes where it is split across x variables is represented as: And its set of leaf nodes is represented as For each node , and These are its left and right child nodes, respectively, and for , It is the parent node of this node. Furthermore, for each node... The value of the profit is expressed as For each node , It is a feature on which splitting occurs, and and These are the corresponding decision variables and splitting thresholds, respectively. Finally, in the example, an auxiliary binary decision variable is defined for each edge in tree t and represented as... .

[0124] Figure 9 The diagram illustrates the construction of an estimator tree according to an embodiment and the associated decision variables. In this tree, the set of leaf nodes... and feature segmentation node set Since node 2 splits the environment features (which is constant in the scene), this node is skipped by directly connecting node 1 to node 5. Figure 9 The use of decision variables q and x is further illustrated. The auxiliary variable q determines the path from root node 1 to leaf node 6 based on the specific x variable values ​​corresponding to the right branch at the root and the left branch at node 3, thereby leading to the objective function value at leaf node 6. This construction is expressed as the following mixed-integer linear programming ("MILP") formula.

[0125]

[0126] Subject to the following conditions:

[0127]

[0128]

[0129] In the MILP formula above, constraints (1-2) enforce variable splitting only if the split node is on an active path from the root to a leaf. They use "Big M notation," where M is a large constant. In this formula, it can be set as a prior known upper bound on x, i.e., Constraint (3) ensures the continuity of the path from the root to the leaf. Constraint (4) is to ensure that only one leaf is selected. Finally, constraint (5) requires that the auxiliary q variable be binary. The solution to the optimization problem is the values ​​of the decision x variables, which provide the path to the leaf with the largest average value across all estimator trees.

[0130] Price / revenue optimization at 320 is applied to solve a one- or multi-day revenue optimization problem for the planning scope by finding the optimal house price used in the occupancy forecast.

[0131] In response to the optimized room pricing at 320, the system offers customers a selection of rooms with optimized pricing, and, in response to the optimized pricing selection, reserves one of the rooms, promoting hotel stay based on the reservation. Promoting hotel stay in embodiments includes transmitting dedicated data to other dedicated devices that use the data, such as automatically encoding hotel keys using the data, automatically programming hotel room door locks using the data, etc.

[0132] In this embodiment, after the optimized price has been determined above, the display order and product classification can be further optimized using the discrete selection model disclosed in U.S. Patent Application No. 17 / 643,638, the disclosure of which is hereby incorporated by reference.

[0133] In this embodiment, the price optimization disclosed above is performed on a daily basis based on remaining inventory. In this case, the present invention enhances the MILP optimization problem described above by adding a set of inventory constraints for each room category c from the category set C:

[0134]

[0135] In the constraint (6) above, for each node , This indicates the number of rooms that have been occupied in room category c. This indicates the booking limit for this category. Booking limits are updated based on the current booking level.

[0136] Example cloud infrastructure

[0137] Figures 10-13 The illustration depicts an example cloud infrastructure that can enable hotel chain operations 104, which may include, according to embodiments... Figure 2Occupancy forecasting system 10.

[0138] 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.

[0139] In some cases, IaaS customers can access resources and services over 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 that 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.

[0140] 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.

[0141] 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 server preparation (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 disposition (OS), middleware, and / or application deployment (e.g., on self-service virtual machines, etc., which can be started on demand).

[0142] 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.

[0143] In some cases, IaaS provisioning presents two distinct challenges. First, there are initial challenges in provisioning the initial infrastructure set before any operations begin. Second, there are challenges in evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.) after all operations have been provisioned. In some cases, these challenges can be addressed by enabling configurations that declaratively define the infrastructure. In other words, the infrastructure (e.g., which components it depends on 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, after the topology is defined, workflows for creating and / or managing the different components described in the profiles can be generated.

[0144] 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.

[0145] In some cases, continuous deployment techniques can be used to enable the deployment of infrastructure code across various virtual computing environments. Additionally, 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 across the 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 code can be deployed using deployment tools after the infrastructure has been provisioned.

[0146] Figure 10This is a block diagram 1100 illustrating an example pattern of an IaaS architecture according to at least one embodiment. Service operator 1102 may be communicatively coupled to a secure host lease 1104, which may include a virtual cloud network (“VCN”) 1106 and a secure host subnet 1108. In some examples, service operator 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., Google Glass® 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. The client computing device can be a workstation computer running a variety of commercially available UNIX® or UNIX-like operating systems, including but not limited to any of the various GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, the client computing device can be any other electronic device, such as a thin client computer, an internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without Kinect® gesture input), and / or a personal messaging device capable of communicating over a network that can access VCN 1106 and / or the internet.

[0147] VCN 1106 may include a local peering gateway (“LPG”) 1110, which may be communicatively coupled to Secure Shell (SSH) VCN 1112 via LPG 1110 contained in 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.

[0148] 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 a corporate intranet and an external network). DMZ-based servers can have limited liability and help contain security vulnerabilities. Additionally, the DMZ layer 1120 may include one or more load balancer (“LB”) subnets 1122, a control plane App layer 1124 that may include one or more 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 App subnets 1126 contained in the control plane App layer 1124 and an Internet gateway 1134 that may be contained in the control plane VCN 1116. One or more App 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.

[0149] The control plane VCN 1116 may include a data plane mirror application layer 1140, which may include one or more App subnets 1126. The one or more App subnets 1126 contained 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 App subnets 1126 of the data plane mirror application layer 1140 to the one or more App subnets 1126 that may be contained in the data plane App layer 1146.

[0150] Data plane VCN 1118 may include data plane App 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 App subnets 1126 of data plane App layer 1146 and Internet gateway 1134 of data plane VCN 1118. One or more App 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 App subnets 1126 of data plane App layer 1146.

[0151] 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.

[0152] 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.

[0153] 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.

[0154] 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.

[0155] 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, the LB subnets 1122 can transmit the request to one or more App subnets 1126 contained in the control plane App 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 the storage to be stored in one or more DB subnets 1130.

[0156] 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.

[0157] 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 isolation of networks that could prevent users or customers from interacting with resources of other users or customers. Furthermore, this embodiment can allow the system's users or customers to privately store databases without relying on the public Internet 1154, which may not have the desired level of security for storage.

[0158] 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 can be isolated from the public internet 1154.

[0159] Figure 11This 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 a secure shell (SSH) VCN 1212 (e.g., SSH VCN 1112 10) via LPG 1110 included in an SSH VCN 1212. 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 (e.g., control plane VCN 1116) via LPG 1210 included in control plane VCN 1216. Control plane VCN 1216 may be included in service lease 1219 (e.g., service lease 1119), and data plane VCN 1218 (e.g., data plane VCN 1118) may be included in customer lease 1221 that may be owned or operated by a user or customer of the system.

[0160] 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 App layer 1224 (e.g., control plane App layer 1124) that may include one or more App subnets 1226 (e.g., one or more App 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 App subnets 1226 contained in the control plane App 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 App 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.

[0161] 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 App subnets 1226. The one or more App subnets 1226 contained 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 App subnets 1226 of the data plane mirror application layer 1240 and the one or more App subnets 1226 that may be contained in the data plane App layer 1246 (e.g., data plane App layer 1146) via the VNIC 1242 contained in the data plane mirror application layer 1240 and the VNIC 1242 contained in the data plane App layer 1246.

[0162] 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).

[0163] 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.

[0164] 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 App subnets 1226. Data plane mirror application layer 1240 may reside in data plane VCN 1218, but may not reside in data plane VCN 1218. That is, data plane mirror application layer 1240 may access 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.

[0165] 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 by the customer 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.

[0166] 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 deployment 8 is invoked by service gateway 1236 contained in control plane VCN 1216 located in region 1, then the invocation can be transmitted to deployment 8 in region 1. In this example, control plane VCN 1216 or deployment 8 in region 1 may be uncoupled from or otherwise communicate with deployment 8 in region 2.

[0167] Figure 12This 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 (e.g., SSH VCN 1112) via an LPG 1310 included in an SSH VCN 1312. 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 (e.g., control plane VCN 1116) via LPG 1310 included in control plane VCN 1316 and to data plane VCN 1318 (e.g., data plane 1118) via LPG 1310 included in data plane VCN 1318. Control plane VCN 1316 and data plane VCN 1318 may be contained in service lease 1319 (e.g., service lease 1119).

[0168] 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 App layer 1324 (e.g., control plane App layer 1124) that may include one or more App subnets 1326 (e.g., similar to one or more App 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 App subnets 1326 contained in the control plane App 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 App 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.

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

[0170] One or more untrusted App 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 App subnet 1367(1)-(N) that may be contained in a corresponding container egress VCN 1368(1)-(N), which 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 App subnets 1362 contained in a data plane VCN 1318 and the App subnets contained in a container egress VCN 1368(1)-(N). Each container exit VCN 1368(1)-(N) may include a NAT gateway 1338 that can communicatively couple to the public Internet 1354 (e.g., public Internet 1154).

[0171] 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 the 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.

[0172] 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 customers in certain situations, such as when support may be expected during code execution. Customers 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 to the IaaS provider.

[0173] 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 App 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).

[0174] In some embodiments, one or more trusted App subnets 1360 may run code that can be owned or operated by an IaaS provider. In this embodiment, one or more trusted App subnets 1360 may be communicatively coupled to one or more DB subnets 1330 and configured to perform CRUD operations in one or more DB subnets 1330. One or more untrusted App subnets 1362 may be communicatively coupled to one or more DB subnets 1330, but in this embodiment, one or more untrusted App subnets may be configured to perform read operations in one or more DB 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 DB subnets 1330.

[0175] 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 be no 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 an IaaS provider, which can facilitate communication between the control plane VCN 1316 and the data plane VCN 1318. In another example, either the control plane VCN 1316 or the data plane VCN 1318 may make invocations to 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.

[0176] Figure 13This is a block diagram 1400 illustrating another example pattern of an IaaS architecture according to at least one embodiment. A service provider 1402 (e.g., service provider 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 SSHVCN 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 (e.g., control plane VCN 1116) via LPG 1410 included in control plane VCN 1416 and to data plane VCN 1418 (e.g., data plane 1118) via LPG 1410 included in data plane VCN 1418. Control plane VCN 1416 and data plane VCN 1418 may be contained in service lease 1419 (e.g., service lease 1119).

[0177] 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 App layer 1424 (e.g., control plane App layer 1124) that may include one or more App subnets 1426 (e.g., one or more App 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 App subnets 1426 contained in the control plane App layer 1424 and an Internet gateway 1434 (e.g., Internet gateway 1134) that may be contained in the control plane VCN 1416, and one or more App subnets 1426 may be communicatively coupled to one or more DB subnets 1430 contained in the control plane data layer 1428 and a service gateway 1436 (e.g., Figure 10 The service gateway) and Network Address Translation (NAT) gateway 1438 (e.g., Figure 10(NAT gateway 1138). The control plane VCN 1416 may include the service gateway 1436 and the NAT gateway 1438.

[0178] Data plane VCN 1418 may include data plane App layer 1446 (e.g., data plane App 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 App subnets 1460 (e.g., one or more trusted App subnets 1360) and one or more untrusted App subnets 1462 (e.g., one or more untrusted App subnets 1362) communicatively coupled to data plane App layer 1446, and one or more LB subnets 1422 of Internet gateway 1434 contained in data plane VCN 1418. One or more trusted App 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 App 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.

[0179] One or more untrusted App 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 App subnets 1462. Each tenant VM 1466(1)-(N) may run code in a corresponding container 1467(1)-(N) and may be communicatively coupled to an App subnet 1426 that may be contained in a data plane App layer 1446 contained in a container egress VCN 1468. A corresponding secondary VNIC 1472(1)-(N) may facilitate communication between one or more untrusted App subnets 1462 contained in a data plane VCN 1418 and the App 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).

[0180] 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.

[0181] In some examples, by Figure 13 The architecture pattern illustrated in block diagram 1400 can be considered as being composed of Figure 12 This is an exception to the pattern illustrated in the architecture diagram 1300, and this pattern may be what the IaaS provider's customers would expect if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer can access in real time the corresponding container 1467(1)-(N) contained in each customer's VM 1466(1)-(N). Container 1467(1)-(N) can be configured to invoke a corresponding secondary VNIC 1472(1)-(N) contained in one or more App subnets 1426 of the data plane App layer 1446, which may be contained in the container egress VCN 1468. The secondary VNIC 1472(1)-(N) can transmit the call to a NAT gateway 1438, which can then transmit the call 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.

[0182] 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 transmit the request to a secondary VNIC 1472(1)-(N), which can then transmit the request to a NAT gateway, which can then transmit the request to the public internet 1454. The public internet 1454 can then transmit 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 transmit the request to one or more App subnets 1426, which can then transmit the request to cloud service 1456 via service gateway 1436.

[0183] It should be recognized that the IaaS architectures 1100, 1200, 1300, and 1400 depicted in the figures may have other components besides 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 configurations or component arrangements.

[0184] As disclosed, the embodiments generate occupancy forecasts by independently processing forecasts for each business day. The embodiments do not use any time-series data and do not require any statistical calculations on the time-series data. Declines and spikes in occupancy due to weekdays or seasonality are part of the nature of hotel bookings. The embodiments do not attempt to deseasonalize or smooth occupancy rates, but instead accept these abrupt changes by making forecasts based on similar characteristics.

[0185] The implementation provides high visibility. From the similarity model, it is easy to identify which dates were used for prediction. By looking at the coefficients and feature importance, it is also easy to discern how each feature contributes to the prediction's occupancy.

[0186] 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 means 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.

[0187] 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 will be readily apparent 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 determining the final occupancy rate forecast for check-in dates of multiple hotel rooms, the method comprising: Receive historical reservation data including multiple reservation curves for hotel rooms corresponding to multiple reservation windows, the historical reservation data including multiple features; Based on historical reservation data, a first occupancy rate prediction for the check-in date is generated using a first model, and a second occupancy rate prediction for the check-in date is generated using a second model. Determine the best-performing model from at least the first and second models; as well as Use the occupancy forecast corresponding to the best-performing model as the final occupancy forecast for the check-in date.

2. The method of claim 1, wherein the first model comprises a similarity model and the second model comprises a longitudinal model.

3. The method of claim 2, wherein the similarity model comprises a k-nearest neighbor nonparametric regression model.

4. The method of claim 2, wherein the similarity model includes a random forest regression model.

5. The method of claim 1, further comprising: Based on historical reservation data, a third occupancy rate prediction for the check-in date is generated using a third model, which includes a summary statistical model comprising several features from the aforementioned multiple features; and The best-performing model is determined from at least the first, second, and third models.

6. The method of claim 5, further comprising: A subset of the multiple features is generated using a third model; The subset is provided to the first model and the second model for generating predictions.

7. The method of claim 1, wherein determining the best-performing model comprises comparing the weighted average absolute percentage error for each of the models.

8. The method of claim 1, further comprising: Optimized pricing for hotel rooms is determined based on final occupancy forecasts, which includes an ensemble tree expressed as a mixed-integer linear programming problem.

9. The method of claim 8, further comprising: Based on optimized pricing, an optimized order for displaying available rooms on the hotel reservation system is determined; Receive a reservation for one of the available rooms; as well as In response to the reservation, the corresponding hotel room key is automatically coded.

10. A computer-readable medium storing instructions thereon, said instructions, when executed by one or more processors, causing the processors to determine a final occupancy forecast for check-in dates of a plurality of hotel rooms, the determination of the final occupancy forecast comprising: Receive historical reservation data including multiple reservation curves for hotel rooms corresponding to multiple reservation windows, the historical reservation data including multiple features; Based on historical reservation data, a first occupancy rate prediction for the check-in date is generated using a first model, and a second occupancy rate prediction for the check-in date is generated using a second model. Determine the best-performing model from at least the first and second models; as well as Use the occupancy forecast corresponding to the best-performing model as the final occupancy forecast for the check-in date.

11. The computer-readable medium of claim 10, wherein the first model comprises a similarity model and the second model comprises a longitudinal model.

12. The computer-readable medium of claim 11, wherein the similarity model comprises a k-nearest neighbor nonparametric regression model.

13. The computer-readable medium of claim 11, wherein the similarity model comprises a random forest regression model.

14. The computer-readable medium of claim 10, further comprising determining the final occupancy forecast: Based on historical reservation data, a third occupancy rate prediction for the check-in date is generated using a third model, which includes a summary statistical model comprising several features from the aforementioned multiple features; and The best-performing model is determined from at least the first, second, and third models.

15. The computer-readable medium of claim 14, further comprising determining the final occupancy forecast: A subset of the multiple features is generated using a third model; The subset is provided to the first model and the second model for generating predictions.

16. The computer-readable medium of claim 10, wherein determining the best-performing model comprises comparing the weighted average absolute percentage error for each of the models.

17. The computer-readable medium of claim 10, further comprising determining the final occupancy forecast. Optimized pricing for hotel rooms is determined based on final occupancy forecasts, which includes an ensemble tree expressed as a mixed-integer linear programming problem.

18. The computer-readable medium of claim 17, further comprising determining the final occupancy forecast: Based on optimized pricing, an optimized order for displaying available rooms on the hotel reservation system is determined; Receive a reservation for one of the available rooms; as well as In response to the reservation, the corresponding hotel room key is automatically coded.

19. A cloud-based hotel reservation system for determining the final occupancy forecast for check-in dates of multiple hotel rooms, the system comprising: First model; Second model; One or more processors, suitable for: Receive historical reservation data including multiple reservation curves for hotel rooms corresponding to multiple reservation windows, the historical reservation data including multiple features; Based on historical reservation data, a first occupancy rate prediction for the check-in date is generated using a first model, and a second occupancy rate prediction for the check-in date is generated using a second model. Determine the best-performing model from at least the first and second models; as well as Use the occupancy forecast corresponding to the best-performing model as the final occupancy forecast for the check-in date.

20. The system of claim 19, wherein the processor is further adapted to: Optimized pricing for hotel rooms is determined based on final occupancy forecasts, which includes an ensemble tree expressed as a mixed-integer linear programming problem.

Images