US20230078464A1 - Computer-implemented interface for bookings for transportation services - Google Patents
Computer-implemented interface for bookings for transportation services Download PDFInfo
- Publication number
- US20230078464A1 US20230078464A1 US18/046,681 US202218046681A US2023078464A1 US 20230078464 A1 US20230078464 A1 US 20230078464A1 US 202218046681 A US202218046681 A US 202218046681A US 2023078464 A1 US2023078464 A1 US 2023078464A1
- Authority
- US
- United States
- Prior art keywords
- channel
- distribution channels
- channels
- respective distribution
- rooms
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 108091006146 Channels Proteins 0.000 claims abstract description 432
- 238000000034 method Methods 0.000 claims abstract description 122
- 230000007175 bidirectional communication Effects 0.000 claims abstract description 5
- 238000004364 calculation method Methods 0.000 claims description 35
- 230000006870 function Effects 0.000 claims description 34
- 238000012545 processing Methods 0.000 claims description 18
- 238000004458 analytical method Methods 0.000 claims description 9
- 230000006854 communication Effects 0.000 claims description 6
- 238000004891 communication Methods 0.000 claims description 6
- 238000013500 data storage Methods 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims 1
- 230000008569 process Effects 0.000 description 63
- 238000004422 calculation algorithm Methods 0.000 description 27
- 230000008859 change Effects 0.000 description 15
- 230000004308 accommodation Effects 0.000 description 13
- 238000012546 transfer Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 10
- 230000000694 effects Effects 0.000 description 9
- 230000007423 decrease Effects 0.000 description 7
- 238000007619 statistical method Methods 0.000 description 7
- 230000003247 decreasing effect Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 230000004044 response Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 239000000047 product Substances 0.000 description 3
- 238000007792 addition Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 1
- 238000005352 clarification Methods 0.000 description 1
- 230000000052 comparative effect Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000006735 deficit Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000010006 flight Effects 0.000 description 1
- 239000012530 fluid Substances 0.000 description 1
- 230000002068 genetic effect Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 102220013433 rs35141404 Human genes 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/273—Asynchronous replication or reconciliation
Definitions
- This disclosure generally relates to the field of computing systems.
- a computer-implemented method of managing online bookings for transportation services inventory establishes a channel interface that provides bidirectional communication between at least one server computing device and a vendor computing device. Furthermore, the computer-implemented method stores, via a channel data structure, a channel record for each of a plurality of distribution channels. Additionally, the computer-implemented method receives, from the vendor computing device through the channel interface, a selection, from the plurality of distribution channels, of one or more participant channels for a transportation service. The computer-implemented method also establishes, via the channel data structure, one or more active channel records based upon the one or more participant channels for the transportation service.
- the computer-implemented method establishes, via the channel data structure, one or more inactive channel records based upon one or more non-participant channels for the transportation service.
- the computer-implemented method links the one or more active channel records to the channel interface.
- the computer-implemented method receives, in real time for the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, sale data corresponding to at least one or more additional vendor computing devices.
- the computer-implemented method determines a performance indicator in real time, for each of the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, based at least on the sale data corresponding to said at least one or more additional vendor computing devices.
- the computer-implemented method adjusts, via the channel interface, a price of the transportation service by an adjustment factor if the performance indicator indicates a performance that fails to meet a performance threshold.
- a computer-implemented method of managing online bookings for transportation services inventory establishes a channel interface that provides bidirectional communication between at least one server computing device and a vendor computing device. Furthermore, the computer-implemented method stores, via a channel data structure, a channel record for each of a plurality of distribution channels. Additionally, the computer-implemented method receives, from the vendor computing device through the channel interface, a selection, from the plurality of distribution channels, of one or more participant channels for a transportation service. The computer-implemented method also establishes, via the channel data structure, one or more active channel records based upon the one or more participant channels for the transportation service.
- the computer-implemented method establishes, via the channel data structure, one or more inactive channel records based upon one or more non-participant channels for the transportation service.
- the computer-implemented method links the one or more active channel records to the channel interface.
- the computer-implemented method receives, in real time for the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, sale data corresponding to at least one or more additional vendor computing devices.
- the computer-implemented method determines a performance indicator in real time, for each of the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, based at least on the sale data corresponding to said at least one or more additional vendor computing devices.
- the computer-implemented method adjusts, via the channel interface, a price of the transportation service by an adjustment factor if the performance indicator indicates a performance that meets a performance threshold.
- FIG. 1 shows a schematic view of an exemplary embodiment of a system for managing the allocation of inventory.
- FIG. 2 shows a flowchart indicating an exemplary embodiment of a method for managing the allocation of inventory.
- FIG. 3 shows a flowchart indicating an exemplary embodiment of a method for managing the allocation of inventory when supply of that inventory exceeds demand for that inventory.
- FIG. 4 shows a flowchart indicating an exemplary embodiment of a method for collecting data relating to different re-sellers.
- FIG. 5 shows a schematic flowchart of an exemplary embodiment of a method for managing inventory allocations.
- FIG. 6 shows a schematic drawing of a central server and a central database that are in communication with an affiliated distributed database that is distributed over a plurality of distributed servers.
- FIG. 7 shows a functional flow diagram of a method in accordance with an embodiment.
- FIG. 8 shows a functional flow diagram of part of the diagram in FIG. 7 , in more detail.
- FIG. 9 shows a functional flow diagram of part of the diagram in FIG. 7 , in more detail.
- FIG. 10 shows a schematic diagram of a central database and a distributed database of the embodiment shown in FIG. 6 .
- FIG. 11 shows a functional flow diagram of part of the diagram in FIG. 7 , in more detail.
- FIG. 12 shows a functional flow diagram of part of the diagram in FIG. 7 , in more detail.
- While this invention is intended to cover a wide variety of inventory-types, the travel and accommodation industries, in particular, would benefit greatly from efficient allocations of inventory to various Channels.
- a primary reason for this is that the traveling public is now able to book and pay online for practically all of its travel and accommodation needs via various online travel/accommodation reseller portals and agencies, which can be regarded as Channels.
- the online reseller market is particularly large in this field and the various Channels have the potential to be extremely successful.
- reference numeral 10 broadly illustrates an exemplary embodiment of a system for managing inventory allocated to respective re-sellers.
- accommodation allotments are allotments of property for the purposes of short term rental, such as holiday apartments, hotel rooms, etc.
- the system 10 includes a data processing apparatus in the form of a computer 12 that is connectable to a network.
- the network can be the Internet indicated at 14 or a private network indicated at 16 .
- the private network 16 can be a virtual private network (VPN) which could form part of the World Wide Web indicated at 14 .
- VPN virtual private network
- the computer 12 is programmed or configured with to receive data relating to accommodation allotments allocated to respective re-sellers stored on servers that are referred to as distribution channels or channels, indicated schematically at 18 , via the World Wide Web 14 .
- the computer 12 is configured to process the data to obtain data relating to sales performance in each channel 18 and referred to as performance data that provides an indicator of the performance in the sales channel.
- the computer On receipt of the performance data, the computer is configured to adjust characteristics or parameters relating to inventory allocated to respective channels 18 depending on the performance data, and/or re-allocate inventory in respective channels 18 to other channels 18 .
- the computer 12 is configured to store data representing inventory that is required to be sold on line by third party on line resellers using the channels 18 .
- the system 10 allows a vendor of the inventory, in the form of a member or subscriber, indicated at 20 , to place all or part of their inventory required to be sold online in a database 22 of the computer 12 .
- the computer 12 is configured so that it generates a database 22 and uses a subroutine 24 that can be stored in a non-transitory, computer-readable medium, to manipulate the data representing the inventory, as described below.
- the computer 12 is configured to associate the channels 18 with inventory data in the database 22 .
- the computer 12 receives data relating to the transfer of inventory in the form of data relating to one or more of the following: sale price of each item of inventory, rate of commission and number of items sold over a pre-determined length of time.
- the subroutine 24 is configured to calculate a rate index, in the form of an indicator, for each channel 18 in the form of a ratio of the number of items of inventory transferred in a pre-determined time (“S”) to the number of inventory items available (“A”) in that distribution channel 18 . That gives (S/A) or (S:A) that can be used as an indicator for whether or not the computer 12 is required to make certain decisions.
- the computer 12 is configured to calculate a performance rating, which is also an indicator, for each channel 18 .
- the performance rating can reflect a determination of whether or not supply of inventory to each channel 18 exceeds demand or vice versa per channel 18 .
- the subroutine 24 can calculate the number of inventory items, in the form of a distribution value, to allocate or distribute to one or more particular channels 18 , and the price at which those items can be sold to maximize a profit for the items.
- the subroutine 24 is configured so that, when executed by the computer 12 , the computer can set a minimum price of items and can adjust the price up from or back to that minimum based on the performance rating of the channel 18 in which the relevant inventory is placed.
- the subroutine 24 is configured also so that, when executed by the computer 12 , the computer increases the price in channels with a relatively high outward transfer rate and high costs, such as commissions, when compared with other channels, so that their performance rating can be equal to or higher than other channels 18 with lower outward transfer rates and costs. It follows that the system 10 can be used to maximize prof it on a range of competing channels. It follows also that a rate at which a particular channel is selling compared to its performance rating is directly proportional to a surplus of supply and the outward transfer rate in that channel.
- the vendors or an administrator of the system of the invention can set a rate of change that could be used to increase or decrease a price at which an inventory item is sold.
- An example of a suitable rate is 10%.
- performance of the channels 18 will be calculated per hour, i.e. recurrently, and related to previous statistical analysis of a particular targeted date range. That analysis can provide a tool for adjusting the rate upwardly or downwardly. In other words, the performance of the channels is calculated recurrently.
- reference numeral 30 generally indicates a broad overview of the operation of the system 10 .
- Reference numeral 32 indicates any channel 18 associated with a user-selected third party re-seller that stocks real-time inventory availabilities or allocations that are represented by values in database fields of computers associated with the channels 18 .
- the subroutine 24 is configured dynamically to allocate or reallocate or update or query inventory allocations associated with the channel 32 . This can be done, for example, using an XML standard.
- the operation 30 is initiated with inventory being transferred out from the channel 32 at a predetermined price.
- the subroutine 24 calculates the rate index, as explained above.
- the subroutine 24 is configured to calculate the rate index by calculating an amount sold in a predetermined period of time divided by the amount allocated to the channel 32 (NS).
- the value returned is then multiplied by 100 to get a percentage.
- the percentage is used as a parameter or indicator by the subroutine 24 to calculate whether or not particular channels are to be allocated inventory.
- the parameter is used in a function to make that calculation. It will also be appreciated that channels could be performing equally well, even though the value (A/S) is higher for one than the other. This would occur where one of the channels has been allocated more inventory than the other.
- imaginary inventory allocations are generated in order to provide the necessary equalization in the form of initial distribution conditions.
- a suitable statistical equation (described in more detail below) can be applied using a comparison to average values for NS over the channels being compared.
- the statistical equation can use a Standard Deviation parameter to adjust for the different starting amounts or initial distribution conditions.
- the subroutine 24 queries whether or not demand has exceeded supply in the channel 32 . If a negative answer is returned, the subroutine decreases the price by a percentage, such as about 10%, at 38 and updates data representing the channel 32 . In other words, the steps taken by the computer executing the subroutine are contingent on the query carried out by the subroutine.
- the subroutine 24 allocates inventory, at 46 , to another channel by distributing a fresh distribution value to said another channel. Subsequently, the subroutine 24 queries whether or not the inventory allocated to the other channel exceeds a previous demand at 48 . If that query returns a positive, then the subroutine 24 carries out the step of decreasing the price, at 38 . If the query returns a negative, then the channel 32 is updated, as at 44 .
- the subroutine 24 includes a calculation at 38 that involves what is known as “Minimum Rack Rate”, a “Current Rate” and a “Surplus Percentage”.
- rack rate is used to refer to a fixed rate for a room. It follows that a Minimum Rack Rate would be a minimum price for a particular accommodation or room allocation. In this case “room” is interchangeable with “item” for the sake of understanding.
- the current rate, or price of a room per night, for example, would be a rate at a particular snap shot in time.
- the Surplus Percentage would indicate a percentage of surplus room allocations in a particular distribution channel.
- the computer 12 compares the performance rating, or control indicator, of the channel 32 with control indicators or performance ratings of other channels to provide a group control indicator relating to the group of channels.
- the performance rating can be in the form of a number of parameters. For example, it could be related to a surplus or deficit percentage related to supply and demand of particular inventory items.
- the subroutine 24 queries whether or not the performance rating of the channel 32 is greater than the other channels. This can be done using the “imaginary rooms” or the statistical analysis mentioned above.
- the computer 12 removes inventory items at 54 from the lower performing channels and adds them to the channel 32 by refreshing distribution values.
- the computer 12 serves to increase the inventory item price at 56 by a particular percentage. In this example, the percentage is 10%.
- the channel 32 is updated or refreshed.
- all calculations are done hourly per item or allocation and each calculation per item is started apart from the others' calculations.
- the times at which calculations are made for respective items are temporally independent. It follows that item A calculations would, for example, start at 12:00 and item B calculations would, for example, start at 12:01 and so on.
- the computer 12 is configured such that the interval is decided by the amount of items and channels 18 on which the items reside and where the channels 18 communicate with the computer 12 via the World Wide Web 14 .
- Channels that report values in real-time back to the computer 12 store their data in the database 22 until it is called or polled by the subroutine 24 .
- request-based channels are polled by the subroutine 24 before the calculations are made to determine fresh values.
- FIG. 4 An example of the manner in which the data is collected from the channels is shown in FIG. 4 .
- the computer 12 executing the subroutine 24 , carries out hourly calculations at 60 for each item in the various distribution channels.
- the computer 12 cycles through a list of channels where the items are stored in the database
- the subroutine 24 then queries or determines, at 64 , for each channel, whether or not the list of channels has been cycled through. In the event that a negative response is returned, the subroutine 24 queries whether or not the respective channel is “real-time”. In the event that the response is negative, the subroutine 24 requests a report at 68 from the relevant server.
- the subroutine 24 continues to cycle through the list of channels at 62 .
- the subroutine 24 carries out various calculations to obtain the indicators in the form of sale rate indices and performance rating, at 70 , as described earlier.
- a number of allotments or items to be allocated are calculated.
- the subroutine 24 calculates the prices for those allotments.
- the subroutine 24 allocates the allotments to various channels, in accordance with the tests and parameters described with reference to FIGS. 2 and 3 .
- the subroutine 24 queries whether or not the respective channel is a real-time channel. In the event that this query returns a negative result, the subroutine 24 polls the relevant server of the channel at 80 . The server for the channel then transmits the report to the database 22 .
- the subroutine 24 stores the report values in the database 22 at 82 .
- the channel 84 provides, on a regular basis, real-time reports and requests of sales to the database 22 at 82 .
- the subroutine 24 serves to re-set allocations to various Channels 18 and the respective prices at 86 .
- tables are represented within computer systems as relational databases.
- the word “table” is used to facilitate an understanding of the embodiments described herein.
- the Rooms are those associated with a particular property (Property).
- the Property is to be understood as a characteristic of the Rooms that makes comparison between the Rooms meaningful.
- the Rooms could be sourced from a common hotel franchise or from a particular geographical area or from a particular star rating etc. This could be given a value for use in a function to be applied to values in database fields of the various channels.
- Notation Definition A Number of Rooms Allotted S Number of Rooms Sold I An indicator variable to depict whether a Channel has a negotiated blocked allocation T Total Number of Rooms Sold P Proportion of Rooms Sold NS_CR Number of Rooms that are Not sold and CAN be redistributed NS_CNR Number Rooms that are Not sold and CANNOT be redistributed TNS Total Number of Rooms Not Sold NAA New Allocation Amount Aadj Allocation Adjustment Amount FAA Final Allocation Amount RA Redistribution Adjustment from Unblocked Rooms FAA_UB Final Allocation Amount After Unblocking Sum_S Total Rooms Sold Overall (per stated time period) Sum_NSR Total Rooms Not Sold (per time period) that CAN be redistributed
- Day 4 is therefore analogous to the start of a final 7-day period when rooms are released to the general domain as mentioned above.
- the number of Rooms sold is recorded and a total is calculated in the final column.
- a ratio between the Rooms sold per Channel and the total number of Rooms sold at each time point is calculated to provide a suitable indicator. This provides a measure of how well a channel is selling the Rooms for a predetermined time period. This is then used to ascertain any price adjustments that should be made for the associated channel.
- Rooms are artificially allocated to each channel depending on each P calculated above. This allocation is considered to be artificial since the main consideration is not whether a channel is selling a large proportion of its Rooms, only that it is selling a larger proportion of Rooms relative to its competitors in that Property.
- Channel 1 has 20 Rooms and Channel 2 has 10 Rooms and they each sell 5 Rooms. Comparatively, they are performing equally well, but if the price changes are based on a contingent value, in this example, the ratio of sold Rooms to allocated Rooms, then Channel 1 appears to be doing worse and its prices, which are non-contingent values, would be required to drop compared to Channel 2 that appears to be doing better and its prices would invariably go up.
- Tables 1 to 4 are named “Base Case” and represent the situation on each day respectively when a given channel that has no blocked Rooms is depleted of all of its inventory at the end of Day 1. Thus, a number of Rooms in the respective channels needs to be adjusted.
- Tables 5 to 8 are named “Inventory Depleted before Unblock” and represent the situation on each day respectively when a channel is depleted of its Rooms on Day 2, prior to when its unsold Rooms in blocked channels are released for general distribution.
- Tables 9 to 12 are named “Inventory Depleted after Unblock” and represent the situation when a channel is depleted of its Rooms after any Rooms that have not been sold during the blocked period are released (on Day 4).
- Steps 2 and 3 ensure that those Rooms not sold are recorded correctly as to whether they can be redistributed at a later stage or not.
- Per channel calculate P as T/Sum_S. Compare each of the amounts obtained at part 6 to the average proportion sold per channel.
- Steps 12 and 13 only need to be carried out if one of the channels has been depleted of Rooms. Furthermore, note that if a Room is transferred to another channel and if a channel has a Room block, it cannot have any Rooms taken away from it, but it is can be allocated more Rooms. However, this step is unavoidable since a transfer of Rooms is based on a ratio of Rooms sold per channel to all Rooms sold and this total will include those blocked channels and therefore cannot be ignored. However, any extra Rooms that are allocated to a blocked channel can be redistributed if another channel becomes depleted.
- This next step ensures that if all of the Rooms from the block are sold (where it is assumed that if an accommodation provider has a blocked deal, then it will sell Rooms from that block first and then any other Rooms sold at a given time period will come out of its Rooms that CAN be redistributed, as mentioned above), and NS_CNR becomes negative in the step above, then this will not affect the calculation of the total Rooms not sold.
- the algorithm is capable of dealing with this. However, it means that the calculation for NSCR must be altered so that the negative value does not affect totals that are otherwise correct.
- step 3 If (NS_CNR>O, A ⁇ S-NS_CNR, A ⁇ S). Therefore, if NS_CNR is negative, the count of Rooms that have not yet been sold and that can be redistributed is simply (A ⁇ S) because all Rooms now are available to be redistributed. If NS_CNR is not negative, then the count of rooms that can be redistributed must be (A ⁇ S-NS_CNR) as there are still some available from the original blocked amount that cannot be classed as being able to be redistributed.
- NS_CNR is unlikely to be negative because not many Rooms will be transferred and, therefore, each channel will keep selling Rooms from its initial allotted amount of Rooms.
- a new row is created that will convert any negative values of NS_CNR to zero. Recall that negative values in NS_CNR indicate that a Room sold has come from a count that CAN be redistributed rather than the blocked count. Next, calculate the total for this new row.
- step 12 the remaining Rooms that have not been sold by the blocked channels can now be redistributed to all of the channels depending on how well they are performing, measured through P. Therefore, multiply P by the total calculated in part 11 for each channel. This is defined as RA.
- the Final Allocation Adjustment after Unblocking (FAA_UB) is determined. This is equal to RA+NS_CR for each channel.
- this new variable, FAA_UB will flow through into Day 4 to represent the new Room totals per channel. Note that after these blocked Rooms have been released, then the only total of Rooms not sold required is the absolute total per channel and not the breakdown into those that can be redistributed and those that cannot. Therefore, there are two less rows after Day 4 in the tables in Excel.
- the algorithm is configured so that only a channel that has no blocked Rooms can have its Rooms to sell depleted. This is a case where the only complication arises when the total number of Rooms to be reallocated changes from those that can be redistributed to a different term in the spreadsheet after any unblocked Rooms are released into the general domain.
- step 12 compute the FAA at the next time period for all other channels by multiplying TNS by each P.
- the algorithm is configured for the case when a previously blocked Channel is depleted after the blocked Channels have redistributed their allocations (if they had not sold all of their allocations). Therefore, after Day 4, when checking for whether any Room transfers are necessary, steps 11 and 12 are changed slightly as follows.
- step 12 compute the FAA at the next time period for all other channels by multiplying TNS by each P.
- the algorithm is configured for when a blocked channel is depleted of its Rooms before the blocked channels are required to redistribute their Rooms. Therefore, prior to Day 4, when checking for whether any Room transfers are necessary in steps 11 to 13, these are carried out in the same way as described in the initial step
- the algorithm is preferably configured to make adjustments once a day. That serves to inhibit frequent fluctuations in price, which could occur in potentially large jumps upwards and/or downwards if the algorithm is used to update the prices more than once a day.
- the time of day can be selected to take advantage of yield management theories indicating when a buyer is more likely to make a purchase of a Room over the Internet.
- the algorithm is also configured to accommodate a situation where another channel enters at any stage of a particular time-period.
- the algorithm incorporates a step that will allow for this to happen and each step in the algorithm can be generalized so that resulting calculations reflecting any new information entered as inputs are correct.
- the invention is intended to cover an embodiment in which rather than using the number of Rooms sold to evaluate how a particular re-seller compares to its competitors, the total revenue generated out of the total amount of revenue for that time period is considered.
- comparisons are made over a predetermined time period. Seven days would be an example.
- the embodiment provides a valuable opportunity to process data for the purposes of developing an evaluation tool. That could be done by recording historical data, analyzing the data statistically and monitoring the progress of the algorithm and of the market in general. This would inevitably lead to changes in the process described above and likely deliver a more efficient tool.
- the first calculation below determines the percentage of rooms booked, via the channel, out of rooms allocated to the channel for the property. This value is calculated for each day in a 30 day period assessed.
- A the total number of allotments given to the channel for the property per day
- Z 1 to Z 30 the percentage sold from a channel per day
- Z ⁇ 1 ( A ⁇ I ⁇ S ) ⁇ 100
- Z ⁇ 2 ( A ⁇ I ⁇ S ) ⁇ 100
- Z ⁇ 29 ( A ⁇ I ⁇ S ) ⁇ 100
- Z ⁇ 30 ( A ⁇ I ⁇ S ) ⁇ 100
- the second calculation below determines the average percentage of rooms sold over the entire 30 day period for that property via that channel.
- M Average percentage of rooms booked via that channel for the property over 30 days
- the next calculation determines how each day's percentage of rooms sold compare against an average percentage of rooms sold over the whole month. This will return a positive or negative number.
- R 1 to R 30 a positive or negative number showing how a day's trade compares against the monthly average of percentage of rooms sold.
- R ⁇ 1 ( Z ⁇ 1 - M )
- R ⁇ 2 ( Z ⁇ 2 - M )
- R ⁇ 3 ( Z ⁇ 3 - M )
- R ⁇ 4 ( Z ⁇ 4 - M ) ⁇
- R ⁇ 5 ( Z ⁇ 4 - M )
- R ⁇ 6 ( Z ⁇ 4 - M )
- the next calculation is designed to get the average number of rooms sold across all channels using an embodiment of the invention for each day in the 30 day period assessed.
- C ⁇ 1 ( Channel ⁇ 1 - Z ⁇ 1 + Channel ⁇ 2 - Z ⁇ 1 + Channel ⁇ 3 - Z ⁇ 1 ) / 3
- C ⁇ 2 ( Channel ⁇ 1 - Z ⁇ 2 + Channel ⁇ 2 - Z ⁇ 2 + Channel ⁇ 3 - Z ⁇ 2 ) / 3
- C ⁇ 29 ( Channel ⁇ 1 - Z ⁇ 29 + Channel ⁇ 2 - Z ⁇ 29 + Channel ⁇ 3 - Z ⁇ 29 ) / 3
- C ⁇ 30 ( Channel ⁇ 1 - Z ⁇ 30 + Channel ⁇ 2 - Z ⁇ 30 + Channel ⁇ 3 - Z ⁇ 30 ) / 3
- the final calculation is done to determine the number (average percentage sold with controlling factors) between ⁇ 100 and 100. This calculation is done for each day in the 30 day period assessed. This value is used to increase or decrease the rate according to a ledger of thresholds that can readily be determined by the Property.
- the schematic flowchart 100 represents an embodiment of a software product in the form of instructions stored on a non-transitory computer-readable medium executable by a computer and a method for managing inventory allocated to respective re-sellers.
- the product provides flexibility in the application of the generated performance indicator referred to with the variable Z in the previous embodiment to current and future “Yield Management” techniques (i.e. techniques relating to maximizing the financial yield from inventory allocations).
- the performance indicator can also be referred to as a control indicator, since it is used to control non-contingent values. These can include values of “price” referred to above.
- variable symbols used correspond with those defined in the description of the previous embodiments, unless otherwise indicated.
- the software product 100 comprising computer-readable instructions, is also configured to separate various processes and calculations into stages to limit the amount of processing needed when applying the indicator (Z) to “Yield Management” techniques and to cache the data for appropriate re-use (e.g. statistical analysis). This allows operations to be performed on the indicator without the need to calculate it every time.
- Z the indicator
- Yield Management e.g. statistical analysis
- the allocation of inventory will be referred to as a Room, with the understanding that this embodiment can be applied to any allocation of inventory.
- the Rooms can be associated with a particular Property to envisage the situation of, for example, a resort attempting to obtain the best yield from the Rooms it has available.
- “Property” could also be understood to be more than particular geographical location. For example, it could be a certain category of properties, or a chain of resorts.
- the Rooms are grouped into Properties to provide a meaningful comparison between performances achieved by different Channels.
- the embodiment can be applied to relational databases that could carry any form of data, not necessarily relation to sale of inventory.
- the software product 100 defines a remote booking engine 102 that uses a suitable communications protocol to receive booking data at 104 for a property and room type when made via a channel.
- the software product 100 calls a data storage function 108 for storing the booking data in a Data Processing Table 110 .
- the function 108 writes an appropriate date range (arrival date and departure date less one day) and associated room identification data (Room ID) to the table 110 .
- the software product 100 calls the function 108 for storing a record in the table 110 .
- the function 108 stores the date and Room ID in the table 110 .
- Allocation allotment changes are processed at 112 in a suitable allotment interface.
- the function 108 is called and the appropriate date range (Date Range) and associated Room ID is passed to the function 108 which stores the Date Range and Room ID in the table 110 . If more than one Room is chosen for allocation changes then more than one record of the change is created in the table 110 .
- Steps 1 and 2 below are repeated as long as there is data to select from the table 110 .
- the records are selected by a function 116 consecutively from the table 110 in the order of entry.
- An algorithm defined by the function 116 is then processed for each day and associated Room ID in the date range stored in the table 110 .
- a difference between this embodiment and the previous embodiment for a predetermined timeline is that a concept of a “re-distribution timeline” (the five days in the Tables) is not introduced at this stage.
- a value of “Sum_A” only includes the allotments from channels participating in the re-distribution process for a Room Type (i.e. a Room in a particular Property) and date of a particular record.
- a channel In order to participate in this embodiment, a channel must not be holding blocked inventory. Also, the channel must at least have an “allotment value” for the Room via the channel on the given date in the record.
- An “allotment value” is an entry in a database table used by the product 100 to associate channels with Rooms, Room types, available dates and other characteristics usually associated with a booking. “Sum_NSR” therefore only includes rooms that are sold from a re-distributable pool. Per channel, the function 116 computes the following:
- NS_R A ⁇ S (The C is dropped since C & CN are indicators of whether or not a particular Room can be sold and as that differentiator is not applicable in this embodiment);
- the results of these calculations are then recorded or updated for each date processed and for each Channel that has a Room allocated on the respective date, for the Room Type being processed, into a cache table 118 .
- an Allotment Re-Distribution Date Storage function 120 is called to store the Room ID and date where re-allocation is required into an Allotment Re-Distribution Table 122 that carries or stores distribution values.
- an Allotment Re-Distribution Date Storage function 124 is called to store the Room ID and date where re-allocation is required in the table 122 .
- Each record is selected from the table 122 and processed by the function 122 one by one in order of entry into the table 122 .
- the channels that participate in a re-distribution process described above for a particular Room Type and date are selected from a channels table 126 . To satisfy “participation” criteria they must not be holding inventory that is “locked” in the channel. They must also at least have an allotment value, as described above for the Room via the channel on the given date. In other words there must be an entry in the table 126 that associates the channel and the Room.
- An active ClientChannels table record is a record in a ClientChannels table that links to an interface used by a vendor to select a particular Channel.
- the table record contains a list of channels available for selection by the vendor. In order for the particular record to be active, that channel should have been selected by a vendor to participate in the reselling of the vendor's inventory (Rooms for this particular example).
- vendor is used broadly and can be interchanged with “Property” as that word has been defined earlier.
- the function 120 uses the performance indicator (Z) for the channel to order a list in the channels table 126 from highest performing Channel first to lowest performing channel last. If there are channels in the list that have the same performance rating then the function 120 uses a randomizing algorithm to order those channels.
- the function 120 counts the number of Rooms in the re-distributable pool for the day in question and loops through the list of channels assigning one Room to each channel in the list in turn until the number of re-distributable Rooms is exhausted. If the list of channels is exhausted and there are still Rooms to be distributed, the looping process is repeated until there are no more Rooms to distribute.
- the function 120 Once a count of Rooms to be allotted has been determined, the function 120 generates the necessary script to facilitate allotment with OTA XML and communicates it to the channels via the protocol used by OTA.
- OTA stands for the Open Travel Alliance. That organization has developed an XML standard (OTA XML) that facilitates online bookings and allocations.
- a price or rate calculation function 128 is called and executed every 24 hours by a time-based scheduling device or cron.
- the function 128 adjusts non-contingent values in the form of prices for 30 days into the future from the date on which it is executed for all channels that have rooms with allotments on the days in question.
- the function 128 initiates by uploading a list of the dates to process. Next it selects all the Room and channel combinations from the table 122 that actually have an allotment value for the respective dates.
- the allotment value must be greater than 0 as there is no reason to increase the price of a room if there is nothing to sell.
- the function 128 selects a current price for the room via that channel on the date it is executed as well as a minimum rate (the rate it cannot go below) for that date/Room I Channel combination.
- a Rates table 130 is then adjusted accordingly and the OTA XML created for transfer of the respective rate to the Channel.
- the software product 100 provides an interface to permit the Property to lock inventory (Rooms) out of the algorithms of the software product in the event that a Property has negotiated a block of the Rooms with a particular vendor. In the event that Rooms are to be released back for participation in the software product 100 , the interface 100 allows the Rooms to be “unlocked”.
- a particular advantage of exemplary embodiments is that they provide the cache 118 that is accessible with a statistical analysis engine 132 .
- the engine 132 is configured to perform statistical analyses on the data collected in the cache 118 to assess the performance of the algorithms used by the software product of the invention.
- the statistical assessment can be carried out manually. However, it is preferable that the assessment be carried out with a suitable application such as that known as a genetic or self-learning algorithm.
- a statistics table 134 is provided to receive data from the statistical analysis engine 132 .
- the subroutine 24 is executed to readjust distribution values (number of rooms) at “refreshing times”.
- Relational database fields are previously described and shown as entries or records in spreadsheets, for example, Excel spreadsheets. It is to be appreciated that such spreadsheets are effectively relational databases with a collection of database fields that are capable of being updated by the computer 12 when executing the computer readable instructions of the software product. As described above, execution of the software product allows the computer 12 to make efficient use of a processor when handling the databases.
- FIGS. 6 to 12 have been added further to clarify the steps described above that lead to efficient collection of data. Furthermore, the following description makes use of the word “values” to describe, generically, the parameters set out in the above tables. This is for clarity in describing the method of using the computer 12 to manage or control a distributed database.
- a relational database is a collection of data items organized as a set of formally-described tables in which data is structured to recognize relations between stored data entries and that can be accessed or reassembled in many different ways without having to reorganize the database tables.
- the tables are relational databases.
- reference is made to tables with changing cell values. It follows that the use of the term “relational database” is for convenience and for a proper understanding of the role of the various components shown in FIG. 1 , for example.
- the tables are updated if and when certain conditions apply. See, for example, the description of the manner in which the tables are established. It follows that values in the tables are contingent upon certain conditions. These are referred to as contingent values. These conditions arise out of sporadic interactions between the subscribers 20 , clearly making use of terminal computer systems indicated in FIG. 1 and the servers 18 , which are distributed computer systems.
- the term “sporadic” has been introduced to reflect, in the examples provided above, the necessarily sporadic nature of bookings or consumption by the public.
- the values can therefore also include non-contingent values, such as the price of an allotment or allocation, which are related to the contingent values.
- control indicators in the following description since they can be used to control the manner in which fresh initial values are determined for sending to the contingent and non-contingent distributed database fields. Those control indicators are also used, in some instances, to control priorities for refreshing of distributed databases field.
- the computer 12 can be considered to be a central computer system in the form of a server 200 (shown in FIG. 6 as a further example).
- the server 200 has a central relational database 202 .
- the server 200 is in data communion with a data communication network 204 , such as the Internet.
- a plurality of distributed computer systems (servers) 206 . 1 to 206 . 3 (also represented as the channels 18 in FIG. 1 ) are connected to the network 204 and include a distributed database 208 that has database fields 212 . 1 to 212 . 3 .
- these would be necessary for receiving and sending information such as the sale price, rate of commission, and number of items sold, as described in paragraph [0057] of the Parent Application.
- Terminal computer systems such as PCs, tablets, phones, and the like (also represented as members or subscribers 20 in FIG. 1 ) interact with the distributed servers 208 sporadically in ways that alter some of the values of the database fields 212 in the distributed database 208 .
- the terminal computer systems can incorporate, wholly or in part, the distributed servers.
- the distributed servers are shown separately for clarity only.
- the distributed servers can be cloud-based so as not necessarily to be represented by separate physical servers.
- the servers can be virtual servers distributed across networks.
- Each distributed database 208 is affiliated with the central relational database 202 in the sense that the central sever 200 and central relational database 202 determine values for the distributed database fields 212 according to predefined relationships or conditions that have to be met. Those values are then used to populate the associated distributed database fields 212 of the distributed database 208 .
- a difficulty occurs when the values of the distributed database fields 212 are contingent on sporadic interaction between terminal computer systems and the distributed servers 210 , which varies the values of the database fields 212 sporadically and unpredictably out of their relationship. This would clearly be the case where the values depended on, for example, booking rates, as envisaged above.
- the central server 200 and central database 202 from time-to-time, have to update or refresh the values in the distributed database fields 212 to restore their appropriate relationships as per the allowable relationships or conditions reflected in the central database 202 .
- Some of these allowable relationships or conditions are reflected in the above description with reference to various types of tables.
- various techniques are provided for refreshing the distributed database 208 as required by the central server 200 and central database 202 to maintain a sufficient degree of data reliability over and above the unpredictable interactions of the terminal computer systems 210 with the distribution servers 206 , so as still to enable many useful applications.
- reference numeral 216 indicates generally a method of using a central server 200 having the central database 202 systematically to refresh the distributed database 208 that is distributed over the plurality of distributed servers 206 .
- the distributed database 208 includes a least some database fields 212 . 1 A to 212 . 3 A that store contingent values. In other words, they store values that vary subject to sporadic interactions between the terminal computer systems 110 and the distributed servers 208 .
- the method 216 includes executing computer instructions, at 218 , which cause two separate parallel processes, 220 , 222 , to execute on the central server.
- a receiving process 216 broadly includes recurrently, at receiving times, noting, at 224 , the receiving time for receiving contingent values of the distributed database fields 212 . 1 A to C from the distributed servers 208 , and storing, at 226 , the received values in the central relational database 202 in succession with previously received and stored contingent values of the distributed database fields, so as to build, for each distributed server an associated series of successive contingent values 214 . 1 A to C.
- This process can result in the generation of one or more of the tables described herein.
- a refreshing process 220 broadly includes recurrently, at refreshing times, noting the refreshing time, at 230 , determining, at 232 , fresh initial distribution values for the distributed database fields based on the successive contingent values 214 . 1 A to C of the distributed servers 206 and based on required initial distribution conditions, and distributing, at 234 , the fresh initial distribution values to the distributed database fields of the distributed servers 206 .
- the two processes can run in parallel and are temporally independent in a way that the receiving process 220 controls receiving of data, say values, from the distributed database 208 in its own time, and the refreshing process 222 controls refreshing of the distributed database 208 in its own time, without the one process interfering with the other process.
- FIG. 4 An example of this process is shown in FIG. 4 , where a real-time and a polled distribution channel are shown operating independently.
- process 236 is used for the case in which a distributed server 206 needs to be prompted (polled) at times, to send the contingent values of its database fields 212 to the central server 200 for storing in the central database 202 .
- Processes 238 and 240 are for cases in which the central server is configured to wait for automatic responses from the distributed servers 206 that send the contingent values at times.
- the three processes described here are reflected somewhat in FIG. 4 , with FIG. 5 providing further clarification.
- the central server selects a distributed server.
- a check is performed to determine if that distributed server 208 needs to be prompted for receiving the contingent values or if the distributed server 208 is configured automatically to send the contingent values to the central server 200 . If the distributed server needs to be prompted, then, at 246 , the central server determines if it is time (a receiving time) to receive the contingent values from that distributed server, and if it is, then prompt the distributed server 208 , at 248 .
- the contingent values are received from the distributed server 208 , and the central database is updated at 252 . The process then returns to 242 to select another distributed server and to repeat the process 236 . If, at 244 , the central server determines that the distributed server need not be prompted, then the process returns to 242 to select another distributed server 208 and to repeat the process 236 . The same applies at 246 .
- Process 238 is for controlling the case when a distributed server is configured to send the contingent values to the central server periodically and automatically.
- the central server receives, at 254 , contingent values from a distributed server.
- the central server determines which server sent the contingent values, and, at 258 , the central server updates the central database 202 .
- Process 240 is similar to process 238 , except that process 240 is for controlling the case when a distributed server is configured to send the contingent values only once a change in the contingent values occurs.
- the central server receives, at 260 , contingent values from a distributed server.
- the central server determines which server sent the contingent values, and, at 264 , the central server updates the central database 202 .
- process 220 is also further split into temporally independent processes.
- process 266 is for determining, at refreshing times, fresh initial values for the distributed database
- process 268 is for distributing, at distributing times, those fresh initial values to the distributed database 208 .
- process 266 when process 266 is executed, then, at 270 , the central server 200 times the refreshing process, and at 272 checks if it is time to determine fresh initial values for the distributed database fields, and if so, then determines, at 274 , the fresh initial values for the distributed database based on successive contingent values of the distributed servers and based on required initial conditions and relationships. Otherwise the process returns to 270 .
- the fresh initial values are stored in the central database 202 ready for distribution to the distributed database 208 .
- Process 268 when executed, broadly involves timing, at 276 , when it is time to distribute the fresh initial values to the distributed servers 206 , and to check if it is time, at 278 , to refresh or update the distributed database 208 . If so, at 280 , a relevant distributed server is selected, and the fresh values are sent to the distributed server at 282 . At 284 , the computer 12 checks if there are other servers that still need updating, and if so, proceeds to 280 to select and update the relevant distributed server. Otherwise, the process proceeds to 276 .
- FIG. 10 shows a simplified version of a central database and an affiliated distributed database to assist with the explanation.
- the central database 202 includes a set of database fields 214 that make provision for storing series of values. As can be seen, this can readily be shown in table format and is, effectively, a generic form of either of the tables described above.
- the series of central database fields 214 . 1 , 214 . 2 , 214 . 3 are respectively affiliated with distributed database fields 212 . 1 . 212 . 2 , and 212 . 3 .
- These include fields 212 . 1 A, 212 . 2 A and 212 . 3 A for storing contingent values and 212 . 1 B to 212 . 3 B for storing non-contingent values that do not vary directly by interaction of the terminal computer systems with the distributed servers.
- the recently received contingent values are added to their affiliated series of contingent values that represent a history of the database fields. See, for example, successively received contingent values 214 . 1 B, 214 . 1 D, 214 . 1 F, 214 . 1 H, 214 . 11 , which are affiliated with distributed database field 212 . 1 . Also, when, at times, the fresh initial values are determined and the affiliated distributed database field is successfully updated, then the initial values are also stored within the series of values at their appropriate times. See for example, 214 . 1 C, 214 . 1 E, 214 . 1 G.
- a fresh non-contingent value is determined then it is also stored in the database set in relation to its related contingent value. See for example, 214 . 1 V, 214 . 1 W, 214 . 1 X, 214 . 1 Yand 214 . 1 Z that are stored in relation to 214 . 1 A, 214 . 1 C, 214 . 1 E, 214 . 1 G, 214 . 1 H.
- the central database also includes conditional or relational fields 214 . 4 that are used, at least in part, to define relationships between the fresh initial values when being determined for the contingent database fields.
- the central database also includes conditional or relational fields 214 . 5 that are used, at least in part, to determine a non-contingent value in relation to an associated fresh initial value for the contingent database field.
- Process 268 executes, and monitors, at 276 , refreshing times for the initial values of the database fields 212 of the distributed servers 206 . These refreshing times can be predefined, or dependent on variables.
- it is time, decided at 288 , to determine fresh initial values for the distributed database then, at 290 , one of the distributed servers is selected, and an individual control indicator is determined, at 292 , for that distributed server based on selected past initial- and contingent values for that distributed server.
- the central server 200 determines a relationship between the individual control indicator and some predefined conditions, and if those conditions are not met then a fresh non-contingent value is determined, at 298 . However, if those conditions are met, then a group control indicator is determined, at 296 . At 300 , the central server 200 determines a relationship between the individual control indicator and some predefined conditions, and if those conditions are not met then a fresh non-contingent value is determined at 302 .
- the central database is updated with the fresh initial distributed values, and the distributing process can now update the distributed database in its own time.
- process 310 is shown that is used to supplement or expand process 268 .
- process 310 is used to expand process 268 in the case that it is determined, at 294 , by the central server 200 that the relationship between the individual control indicator and predefined conditions, are not met.
- the central server selects a distributed server and determines, at 314 , an individual control indicator (and/or) a group control indicator.
- a check is performed to determine if there are more servers that need considering and, if so, the process returns to 312 in which the next server is selected, and an individual control indicator and/or a group control indicator is determined also for that server, until an individual control indicator and/or group control indicator is determined for each distributed server.
- the central server determines if a fresh initial value has to be determined for any of the distributed database fields that are for storing contingent values and, if so, then, at 320 , fresh initial values are determined as needed for the distributed database.
- updating or refreshing of the distributed database there are a few techniques that this embodiment provides, that enable updating or refreshing of the distributed database fields at the distributed servers.
- the central server is configured to detect only those fields in the central database within a set of database fields that have been updated with fresh initial values or fresh non-contingent values, and then systematically only to update those fields in the affiliated distributed database field over time as opposed to rolling out entire set of values of the set of database fields.
- the central server is configured to make use of the individual, and/or group control indicators to determine priorities for updating the various distributed database fields, and update those distributed database fields with higher priorities first.
- “Inventory” is any item, whether tangible or intangible, that is capable of being transferred or distributed from one party, entity, apparatus, or consumption source to another and in respect of which it may be required to control and monitor quantity, rate of consumption and other parameters.
- the definition is not limited to items that are sold.
- it can encompass items or measures of fluid that are fed from one apparatus to another and where is may be desired to monitor, measure or otherwise determine characteristics of the inventory and the manner in which is it transferred, such as a rate of transfer.
- Computer is any apparatus capable of carrying out data processing functions and includes a computer system, or a collection of one or more apparatus, including mobile apparatus, such as smart phones, tablets and other hand-held devices.
- Allocations are representations of items of inventory that are allocated to portals, channels, and other distribution agents for allocation or re-allocation to other portals, channels and distribution channels. These are also referred to as “allotments” in this specification.
- Distribution Channels are portals, outlets, channels and other distribution agents that are configured for the distribution of inventory to consumers or sources consumption.
- Server is a computer or other data processing apparatus that is capable of carrying out server-side operations.
- the various embodiments described above can provide a means whereby an efficient distribution of inventory can be made between various distribution channels for that inventory. This is particularly important where significant data is generated that could place undue load on data processors. In such cases, administrators, for example, servers, can find it difficult to investigate the performance of connected distribution channels and, in response, make changes to parameters of inventory.
- the method of using a central computer system can provide a means whereby the administrators can maintain control of inventory parameters such as supply rates with a processor load that would not be possible without the steps of the embodiments of the method.
- the database management techniques described above such as independent processing, in particular for processes that involve interaction between the central server and the distributed servers, and also processes that execute only central server side, provide embodiments that are diverse and suitable, for controlling overall efficiency, reliability, and redundancy, as uniquely required by different applications.
- Words indicating direction or orientation are used for convenience.
- the inventor(s) envisages that various embodiments can be used in a non-operative configuration, such as when presented for sale.
- Such words are to be regarded as illustrative in nature, and not as restrictive.
Abstract
Description
- The present application is a continuation of U.S. patent application Ser. No. 17/749,091, filed on May 19, 2022, which is a continuation of U.S. patent application Ser. No. 16/924,395, filed on Jul. 9, 2020, which is a continuation of U.S. patent application Ser. No. 16/150,799, filed on Oct. 3, 2018, which is a continuation of U.S. patent application Ser. No. 14/877,669, filed on Oct. 7, 2015, which is Continuation-In-Part patent application of U.S. patent application Ser. No. 12/227,451, filed on Dec. 18, 2009, which is a national stage of international patent application no. PCT/AU2007/000684, filed on May 18, 2007, which claims the benefit of priority to Australian provisional patent application 2006902685, filed on May 18, 2006, the contents of all of which are hereby incorporated by reference in their entireties.
- This disclosure generally relates to the field of computing systems.
- A particular problem exists when selling inventory, such as travel services including accommodation allotments, flights and other transport services. The problem is a result of the manner in which such inventory is allocated to various re-sellers, referred to as distribution channels (“Channels”), which can be ad hoc and thus inefficient.
- The particular problem is that the market has forced vendors to commit physical inventory to particular Channels in a relatively ad hoc manner. Furthermore, where the inventory is accommodation which needs to be sold between particular dates, any attempt to achieve efficiency by selecting the most efficient Channels can become extremely difficult. In particular, most independent hotels and accommodation properties lack the resources to have members of staff dedicated to managing allocations to Channels. It is practically impossible for them to manage this inventory in multiple Channels while still maintaining their businesses.
- In one aspect of the disclosure, a computer-implemented method of managing online bookings for transportation services inventory is provided. The computer-implemented method establishes a channel interface that provides bidirectional communication between at least one server computing device and a vendor computing device. Furthermore, the computer-implemented method stores, via a channel data structure, a channel record for each of a plurality of distribution channels. Additionally, the computer-implemented method receives, from the vendor computing device through the channel interface, a selection, from the plurality of distribution channels, of one or more participant channels for a transportation service. The computer-implemented method also establishes, via the channel data structure, one or more active channel records based upon the one or more participant channels for the transportation service. Furthermore, the computer-implemented method establishes, via the channel data structure, one or more inactive channel records based upon one or more non-participant channels for the transportation service. The computer-implemented method links the one or more active channel records to the channel interface. Also, the computer-implemented method receives, in real time for the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, sale data corresponding to at least one or more additional vendor computing devices. The computer-implemented method determines a performance indicator in real time, for each of the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, based at least on the sale data corresponding to said at least one or more additional vendor computing devices. Finally, for each of the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, the computer-implemented method adjusts, via the channel interface, a price of the transportation service by an adjustment factor if the performance indicator indicates a performance that fails to meet a performance threshold.
- In another aspect of the disclosure, a computer-implemented method of managing online bookings for transportation services inventory is provided. The computer-implemented method establishes a channel interface that provides bidirectional communication between at least one server computing device and a vendor computing device. Furthermore, the computer-implemented method stores, via a channel data structure, a channel record for each of a plurality of distribution channels. Additionally, the computer-implemented method receives, from the vendor computing device through the channel interface, a selection, from the plurality of distribution channels, of one or more participant channels for a transportation service. The computer-implemented method also establishes, via the channel data structure, one or more active channel records based upon the one or more participant channels for the transportation service. Furthermore, the computer-implemented method establishes, via the channel data structure, one or more inactive channel records based upon one or more non-participant channels for the transportation service. The computer-implemented method links the one or more active channel records to the channel interface. Also, the computer-implemented method receives, in real time for the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, sale data corresponding to at least one or more additional vendor computing devices. The computer-implemented method determines a performance indicator in real time, for each of the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, based at least on the sale data corresponding to said at least one or more additional vendor computing devices. Finally, for each of the one or more participant channels corresponding to the one or more active channel records linked to the channel interface, the computer-implemented method adjusts, via the channel interface, a price of the transportation service by an adjustment factor if the performance indicator indicates a performance that meets a performance threshold.
- The above-mentioned features of the present disclosure will become more apparent with reference to the following description taken in conjunction with the accompanying drawings wherein like reference numerals denote like elements and in which:
-
FIG. 1 shows a schematic view of an exemplary embodiment of a system for managing the allocation of inventory. -
FIG. 2 shows a flowchart indicating an exemplary embodiment of a method for managing the allocation of inventory. -
FIG. 3 shows a flowchart indicating an exemplary embodiment of a method for managing the allocation of inventory when supply of that inventory exceeds demand for that inventory. -
FIG. 4 shows a flowchart indicating an exemplary embodiment of a method for collecting data relating to different re-sellers. -
FIG. 5 shows a schematic flowchart of an exemplary embodiment of a method for managing inventory allocations. -
FIG. 6 shows a schematic drawing of a central server and a central database that are in communication with an affiliated distributed database that is distributed over a plurality of distributed servers. -
FIG. 7 shows a functional flow diagram of a method in accordance with an embodiment. -
FIG. 8 shows a functional flow diagram of part of the diagram inFIG. 7 , in more detail. -
FIG. 9 shows a functional flow diagram of part of the diagram inFIG. 7 , in more detail. -
FIG. 10 shows a schematic diagram of a central database and a distributed database of the embodiment shown inFIG. 6 . -
FIG. 11 shows a functional flow diagram of part of the diagram inFIG. 7 , in more detail. -
FIG. 12 shows a functional flow diagram of part of the diagram inFIG. 7 , in more detail. - It will be appreciated that efficient selection of Channels for such inventory can allow vendors to achieve a selling price that corresponds with demand for the inventory in the Channels. In this way, an optimum price for, and supply of the inventory in each Channel could be achieved with such correct selection.
- While this invention is intended to cover a wide variety of inventory-types, the travel and accommodation industries, in particular, would benefit greatly from efficient allocations of inventory to various Channels. A primary reason for this is that the traveling public is now able to book and pay online for practically all of its travel and accommodation needs via various online travel/accommodation reseller portals and agencies, which can be regarded as Channels. The online reseller market is particularly large in this field and the various Channels have the potential to be extremely successful.
- In
FIG. 1 , reference numeral 10 broadly illustrates an exemplary embodiment of a system for managing inventory allocated to respective re-sellers. - In the following description, reference is made to the inventory items in the form of accommodation allotments and in further descriptions as Rooms. It is to be understood that such accommodation allotments or Rooms are allotments of property for the purposes of short term rental, such as holiday apartments, hotel rooms, etc.
- The system 10 includes a data processing apparatus in the form of a
computer 12 that is connectable to a network. In this case, the network can be the Internet indicated at 14 or a private network indicated at 16. It will readily be appreciated that theprivate network 16 can be a virtual private network (VPN) which could form part of the World Wide Web indicated at 14. - The
computer 12 is programmed or configured with to receive data relating to accommodation allotments allocated to respective re-sellers stored on servers that are referred to as distribution channels or channels, indicated schematically at 18, via theWorld Wide Web 14. - The
computer 12 is configured to process the data to obtain data relating to sales performance in eachchannel 18 and referred to as performance data that provides an indicator of the performance in the sales channel. On receipt of the performance data, the computer is configured to adjust characteristics or parameters relating to inventory allocated torespective channels 18 depending on the performance data, and/or re-allocate inventory inrespective channels 18 toother channels 18. - The
computer 12 is configured to store data representing inventory that is required to be sold on line by third party on line resellers using thechannels 18. The system 10 allows a vendor of the inventory, in the form of a member or subscriber, indicated at 20, to place all or part of their inventory required to be sold online in adatabase 22 of thecomputer 12. Thus, thecomputer 12 is configured so that it generates adatabase 22 and uses asubroutine 24 that can be stored in a non-transitory, computer-readable medium, to manipulate the data representing the inventory, as described below. - In particular, the
computer 12 is configured to associate thechannels 18 with inventory data in thedatabase 22. Thecomputer 12 receives data relating to the transfer of inventory in the form of data relating to one or more of the following: sale price of each item of inventory, rate of commission and number of items sold over a pre-determined length of time. Thesubroutine 24 is configured to calculate a rate index, in the form of an indicator, for eachchannel 18 in the form of a ratio of the number of items of inventory transferred in a pre-determined time (“S”) to the number of inventory items available (“A”) in thatdistribution channel 18. That gives (S/A) or (S:A) that can be used as an indicator for whether or not thecomputer 12 is required to make certain decisions. - The
computer 12 is configured to calculate a performance rating, which is also an indicator, for eachchannel 18. The performance rating can reflect a determination of whether or not supply of inventory to eachchannel 18 exceeds demand or vice versa perchannel 18. - By using the performance rating and the calculated index, S/A, the
subroutine 24 can calculate the number of inventory items, in the form of a distribution value, to allocate or distribute to one or moreparticular channels 18, and the price at which those items can be sold to maximize a profit for the items. - The
subroutine 24 is configured so that, when executed by thecomputer 12, the computer can set a minimum price of items and can adjust the price up from or back to that minimum based on the performance rating of thechannel 18 in which the relevant inventory is placed. - Furthermore, the
subroutine 24 is configured also so that, when executed by thecomputer 12, the computer increases the price in channels with a relatively high outward transfer rate and high costs, such as commissions, when compared with other channels, so that their performance rating can be equal to or higher thanother channels 18 with lower outward transfer rates and costs. It follows that the system 10 can be used to maximize prof it on a range of competing channels. It follows also that a rate at which a particular channel is selling compared to its performance rating is directly proportional to a surplus of supply and the outward transfer rate in that channel. - It is to be understood that supply of inventory items and extent of commission can control the rate at which inventory is sold in each
channel 18, at a basic level. It follows that if a shortage of supply should occur, a price of inventory in all thechannels 18 will increase. However, in the event that there is over-supply, the price will decrease relative to the performance rating. - It follows that the vendors or an administrator of the system of the invention can set a rate of change that could be used to increase or decrease a price at which an inventory item is sold. An example of a suitable rate is 10%. In a particular example, performance of the
channels 18 will be calculated per hour, i.e. recurrently, and related to previous statistical analysis of a particular targeted date range. That analysis can provide a tool for adjusting the rate upwardly or downwardly. In other words, the performance of the channels is calculated recurrently. - In
FIG. 2 ,reference numeral 30 generally indicates a broad overview of the operation of the system 10. -
Reference numeral 32 indicates anychannel 18 associated with a user-selected third party re-seller that stocks real-time inventory availabilities or allocations that are represented by values in database fields of computers associated with thechannels 18. Thesubroutine 24 is configured dynamically to allocate or reallocate or update or query inventory allocations associated with thechannel 32. This can be done, for example, using an XML standard. - The
operation 30 is initiated with inventory being transferred out from thechannel 32 at a predetermined price. At 34, thesubroutine 24 calculates the rate index, as explained above. In particular, thesubroutine 24 is configured to calculate the rate index by calculating an amount sold in a predetermined period of time divided by the amount allocated to the channel 32 (NS). The value returned is then multiplied by 100 to get a percentage. The percentage is used as a parameter or indicator by thesubroutine 24 to calculate whether or not particular channels are to be allocated inventory. The parameter is used in a function to make that calculation. It will also be appreciated that channels could be performing equally well, even though the value (A/S) is higher for one than the other. This would occur where one of the channels has been allocated more inventory than the other. - In that case, imaginary inventory allocations are generated in order to provide the necessary equalization in the form of initial distribution conditions. Alternatively, a suitable statistical equation (described in more detail below) can be applied using a comparison to average values for NS over the channels being compared. The statistical equation can use a Standard Deviation parameter to adjust for the different starting amounts or initial distribution conditions.
- At 36, the
subroutine 24 queries whether or not demand has exceeded supply in thechannel 32. If a negative answer is returned, the subroutine decreases the price by a percentage, such as about 10%, at 38 and updates data representing thechannel 32. In other words, the steps taken by the computer executing the subroutine are contingent on the query carried out by the subroutine. - This step is more clearly shown in
FIG. 3 . If that supply exceeds demand at 40, then thesubroutine 24 queries at 42 whether any other channel requires inventory. If a negative answer is returned, then the price, in the form of a non-contingent value, can be decreased as at 38. Once the price has been decreased, thesubroutine 24 updates the data relating to thechannel 32, at 44. - If the query at 42 is positive, then the
subroutine 24 allocates inventory, at 46, to another channel by distributing a fresh distribution value to said another channel. Subsequently, thesubroutine 24 queries whether or not the inventory allocated to the other channel exceeds a previous demand at 48. If that query returns a positive, then thesubroutine 24 carries out the step of decreasing the price, at 38. If the query returns a negative, then thechannel 32 is updated, as at 44. - The
subroutine 24 includes a calculation at 38 that involves what is known as “Minimum Rack Rate”, a “Current Rate” and a “Surplus Percentage”. As is known in the accommodation industry, for example, the term “rack rate” is used to refer to a fixed rate for a room. It follows that a Minimum Rack Rate would be a minimum price for a particular accommodation or room allocation. In this case “room” is interchangeable with “item” for the sake of understanding. The current rate, or price of a room per night, for example, would be a rate at a particular snap shot in time. The Surplus Percentage would indicate a percentage of surplus room allocations in a particular distribution channel. - The step of decreasing a price by the calculation at 38 is effectively a step of decreasing the performance rating of that particular channel. Accordingly, in this example, the
subroutine 24 adjusts the performance rating down by 10%. Thus, if thechannel 32 had a performance rating of X rooms selling at $Y each with a commission of $Z and the performance rating is to be reduced by 10%, then the following calculation is carried out by thesubroutine 24 to obtain the rate (R): 0.9Y+Z=R. - If the Minimum Rack Rate was below the R, then $R would be the new sale price per room. Otherwise, the minimum rack rate would be the price. It is thus to be appreciated that the
subroutine 24 would not continually lower the prices of rooms below a predetermined minimum, which could be represented as minimum non-contingent value. - Reverting back now to
FIG. 2 , if the query at 36 returns a positive, then thecomputer 12 compares the performance rating, or control indicator, of thechannel 32 with control indicators or performance ratings of other channels to provide a group control indicator relating to the group of channels. As set out earlier, the performance rating can be in the form of a number of parameters. For example, it could be related to a surplus or deficit percentage related to supply and demand of particular inventory items. At 52, thesubroutine 24 queries whether or not the performance rating of thechannel 32 is greater than the other channels. This can be done using the “imaginary rooms” or the statistical analysis mentioned above. - If the query returns a positive, then the
computer 12 removes inventory items at 54 from the lower performing channels and adds them to thechannel 32 by refreshing distribution values. Alternatively, if the query at 52 returns a negative result, then thecomputer 12 serves to increase the inventory item price at 56 by a particular percentage. In this example, the percentage is 10%. - Using a calculation similar to the one used for decreasing the price, if a channel with a performance rate of X allotments selling at $Y with a commission of $Z is increased by 10% the following calculation would be used to obtain the rate (R): 1.1Y+Z=R.
- As can be seen in
FIG. 2 , once the steps at 54 and 56 are completed, thechannel 32 is updated or refreshed. - Two methods have been conceived for receiving the data from
respective channels 18. These are referred to as the “real-time” and “request-based” methods. - In this example, all calculations are done hourly per item or allocation and each calculation per item is started apart from the others' calculations. In other words, the times at which calculations are made for respective items are temporally independent. It follows that item A calculations would, for example, start at 12:00 and item B calculations would, for example, start at 12:01 and so on. The
computer 12 is configured such that the interval is decided by the amount of items andchannels 18 on which the items reside and where thechannels 18 communicate with thecomputer 12 via theWorld Wide Web 14. - Channels that report values in real-time back to the
computer 12 store their data in thedatabase 22 until it is called or polled by thesubroutine 24. On the other hand, request-based channels are polled by thesubroutine 24 before the calculations are made to determine fresh values. - An example of the manner in which the data is collected from the channels is shown in
FIG. 4 . InFIG. 4 , thecomputer 12, executing thesubroutine 24, carries out hourly calculations at 60 for each item in the various distribution channels. At 62, thecomputer 12 cycles through a list of channels where the items are stored in the database - The
subroutine 24 then queries or determines, at 64, for each channel, whether or not the list of channels has been cycled through. In the event that a negative response is returned, thesubroutine 24 queries whether or not the respective channel is “real-time”. In the event that the response is negative, thesubroutine 24 requests a report at 68 from the relevant server. - On the other hand, if the query at 66 is positive, the
subroutine 24 continues to cycle through the list of channels at 62. - If the query or determination at 64 is positive, the
subroutine 24 carries out various calculations to obtain the indicators in the form of sale rate indices and performance rating, at 70, as described earlier. At 72, a number of allotments or items to be allocated are calculated. At 74, thesubroutine 24 calculates the prices for those allotments. At 76, thesubroutine 24 allocates the allotments to various channels, in accordance with the tests and parameters described with reference toFIGS. 2 and 3 . At 78, thesubroutine 24 queries whether or not the respective channel is a real-time channel. In the event that this query returns a negative result, thesubroutine 24 polls the relevant server of the channel at 80. The server for the channel then transmits the report to thedatabase 22. Thesubroutine 24 stores the report values in thedatabase 22 at 82. - At 84 there is schematically indicated a real-time channel. The
channel 84 provides, on a regular basis, real-time reports and requests of sales to thedatabase 22 at 82. - In the event that the query at 78 returns a positive, the
subroutine 24 serves to re-set allocations tovarious Channels 18 and the respective prices at 86. - Embodiment for Application Over a Predetermined Period
- A further embodiment is now described with reference to an algorithm defined by the
subroutine 24. The algorithm can be applied in the framework of the system 10, described above. However, this algorithm is an alternative to the algorithmic process described above, while still falling within the broader scope of the preceding material. - The description is with reference to the operation of the algorithm over a 5 day period. Reference is made to Tables 1 to 5 which appear at the end of the description of this embodiment. It is to be appreciated that the embodiment can readily be applied to longer or shorter periods without technical difficulty.
- As is generally known, tables are represented within computer systems as relational databases. In this specification, the word “table” is used to facilitate an understanding of the embodiments described herein.
- In this example, it is assumed that there are five channels operating servers. This example takes into account that two of the channels have negotiated blocks of 50 allotments, something which is conventional in the field. The negotiated blocks are indicated by the row entitled “blocked allocation” in the tables. It is to be understood that since those allotment allocations have been negotiated, it is not possible for the system 10 to act freely on those allocations.
- For ease of reference only, the allotments are referred to as “Rooms”.
- It should be noted that the Rooms are those associated with a particular property (Property). The Property is to be understood as a characteristic of the Rooms that makes comparison between the Rooms meaningful. For example, the Rooms could be sourced from a common hotel franchise or from a particular geographical area or from a particular star rating etc. This could be given a value for use in a function to be applied to values in database fields of the various channels.
- Set out below is a list of Notations used with their meanings in the Tables and in the following description:
-
Notation Definition A Number of Rooms Allotted S Number of Rooms Sold I An indicator variable to depict whether a Channel has a negotiated blocked allocation T Total Number of Rooms Sold P Proportion of Rooms Sold NS_CR Number of Rooms that are Not sold and CAN be redistributed NS_CNR Number Rooms that are Not sold and CANNOT be redistributed TNS Total Number of Rooms Not Sold NAA New Allocation Amount Aadj Allocation Adjustment Amount FAA Final Allocation Amount RA Redistribution Adjustment from Unblocked Rooms FAA_UB Final Allocation Amount After Unblocking Sum_S Total Rooms Sold Overall (per stated time period) Sum_NSR Total Rooms Not Sold (per time period) that CAN be redistributed - If a blocked allocation of Rooms has been negotiated (i.e. it is not possible to transfer those Rooms from one channel to another), wholesalers generally release unsold Rooms back to the associated Property, usually 7 days from the end of a negotiated time-period.
- It is thus necessary to monitor each of the Rooms within each step of the algorithm to ensure that any adjustments are made using only those Rooms that are free to be sold through channels and transferred from one channel to another. The reason is that the blocked Rooms can be considered as sold.
- This five day example assumes that on day four any Rooms obtained in a previously negotiated blocked sale that are not sold are then released into a general domain for selling in any of the other channels to sell, and re-allocated accordingly. This reallocation will be a function of a channel's relative performance in the market.
- Day 4 is therefore analogous to the start of a final 7-day period when rooms are released to the general domain as mentioned above.
- Furthermore, it is assumed that adjustments are made only once a day.
- For each channel, the number of Rooms sold is recorded and a total is calculated in the final column. In order to obtain a measure of how well a re-seller is performing in the market, a ratio between the Rooms sold per Channel and the total number of Rooms sold at each time point is calculated to provide a suitable indicator. This provides a measure of how well a channel is selling the Rooms for a predetermined time period. This is then used to ascertain any price adjustments that should be made for the associated channel.
- For j=1, . . . n, where j represents the Channel Number, the ratio is defined by Pj=Sj/Σj=1 nSi, Sj being the number sold per Channel. In this case, n=5.
- In order to evaluate any redistribution of room allocations (when necessary), it is also necessary to record the number of rooms that are not sold. In general, if there are some channels that have negotiated room blocks for a given room type in a given property (as is the case in this example), then this amount needs to be further broken down into a count of rooms that can be redistributed to other channels and a count of rooms that cannot be redistributed to other channels.
- However, it is assumed that if a Room is sold from a channel with a negotiated allocation, this will be deducted from their initial block of Rooms rather than any redistributed allocation that may occur at a stage when a channel is depleted of all Rooms. This will be discussed in more detail below.
- In order to set up the algorithm in the
subroutine 24, Rooms are artificially allocated to each channel depending on each P calculated above. This allocation is considered to be artificial since the main consideration is not whether a channel is selling a large proportion of its Rooms, only that it is selling a larger proportion of Rooms relative to its competitors in that Property. - However, it is necessary for the number of Rooms to be factored into the algorithm used by the
subroutine 24. The reason is that an accommodation provider can choose to allocate, at the outset, a block of Rooms (through negotiation based on a business decision) to a Channel or even select Channels through which to sell Rooms. In the associated relational database, these could be set up as initial distribution conditions. - In any event, the following example illustrates why the number of Rooms should not play a role in price adjustments.
- Assume there are only two Channels for Rooms in a particular Property. Assume that Channel 1 has 20 Rooms and Channel 2 has 10 Rooms and they each sell 5 Rooms. Comparatively, they are performing equally well, but if the price changes are based on a contingent value, in this example, the ratio of sold Rooms to allocated Rooms, then Channel 1 appears to be doing worse and its prices, which are non-contingent values, would be required to drop compared to Channel 2 that appears to be doing better and its prices would invariably go up.
- Consequently, in order to calculate any adjustment of non-contingent values, in this example price adjustments, the proportion of total Rooms sold by a channel is compared to the average proportion over all channels. This is done through a percentage change (PC) calculation relative to the average proportion of Rooms sold. Furthermore, a scale is derived to project these percentage changes onto a comparative measure, which is done in the following way: Zj=PCj−Mean(PC)/(St.Dev(PC/√n)).
- Again, the value for n should be replaced with 5 since five channels are being considered. Using this, it is possible to apply the following adjustments:
-
Z score Adjustment to price Greater than 3 Increase by 5% Between 2 and 3 Increase by 2% Between 1 and 2 Increase by 1% Between −1 and 1 No change Between −2 and −1 Decrease by 1% Between −3 and −2 Decrease by 2% Greater than −3 Decrease by 5% - The description given in the above paragraphs covers the general issues and calculations required to adjust the price of a Room for a respective Property.
- The following paragraphs go into more detail regarding each step to be carried out and the order in which each of the steps must proceed.
- Referring to the Tables mentioned earlier, Tables 1 to 4 are named “Base Case” and represent the situation on each day respectively when a given channel that has no blocked Rooms is depleted of all of its inventory at the end of Day 1. Thus, a number of Rooms in the respective channels needs to be adjusted.
- Tables 5 to 8 are named “Inventory Depleted before Unblock” and represent the situation on each day respectively when a channel is depleted of its Rooms on Day 2, prior to when its unsold Rooms in blocked channels are released for general distribution.
- Tables 9 to 12 are named “Inventory Depleted after Unblock” and represent the situation when a channel is depleted of its Rooms after any Rooms that have not been sold during the blocked period are released (on Day 4).
- Three steps are to be noted when the
subroutine 24 is executed. There are an initial set of steps for a first time period or recurrence. These are described first. In a second and in subsequent time periods, a number of minor changes are applied depending on if and when Room numbers in respective channels need to be readjusted. These are described in turn. Thirdly, prior to the blocked Rooms being released to the general domain, a number of steps are required to adjust the number of Rooms in respective channels at the beginning of the next time period (i.e. at the beginning of Day 4 in this worked example). - Note that the notation used for logical statements in an Excel (such as If) are written below exactly as they would appear in an Excel spreadsheet, except that rather than using cell Identifiers (for example, A1), a description of what the cell contains, defined by the notation provided above, is given. It will be appreciated by those of ordinary skill in the field that an Excel spreadsheet is effectively a relational database. It is therefore to be appreciated that the following steps described with reference to an Excel spreadsheet can just as well be carried out with any number of relational database applications.
- Initial steps to be carried out: Per channel, compute the following:
- Per channel, compute the following:
- 1. Record Rooms Allotted (A) and Rooms Sold (S).
- 2. If (I=1, NS_CNR=A−S, 0).
- 3. If (I=0, NS_CR=A−S, 0).
- 4. T=A−S.
- Steps 2 and 3 ensure that those Rooms not sold are recorded correctly as to whether they can be redistributed at a later stage or not.
- Next, 5. Calculate Sum_S and Sum_NSR using the values from the previous 4 steps.
- Per channel, calculate P as T/Sum_S. Compare each of the amounts obtained at part 6 to the average proportion sold per channel.
- 7. Compute the average of the P's.
- Again, per channel, 8. Work out the percentage change (%C) of each P relative to the average P. Now, compute the average percentage change and the standard deviation of this percentage change (see equations above).
- Using these values, per channel, 9. subtract the mean Percentage Change from each %C.
- And, 10. Divide through by (Standard Deviation of the Percentage Change/Square Root (Number of channels)). This returns a Standardized Score for measuring each of the scores to each other and therefore adjusted according to the scales for Z provided above. Per channel, the
subroutine 24 checks whether any Rooms need to be transferred to other channels. This will only be the case if the channel has sold all of its Rooms. - Therefore, 11. check to see if A>S. If so, then NAA=0 and there are still rooms left to sell for this channel. If A=S, then multiply the proportion of rooms sold for this channel (P) by Sum_NSR to get a value for NAA (this should only give a value for where A=S).
- 12. Compute any relevant adjustment of Room numbers for all other channels (Aadj) by multiplying NS_CR by each P.
- 13. Compute the FAA at the next time period by adding AAdj to NS_CNR.
- Note that Steps 12 and 13 only need to be carried out if one of the channels has been depleted of Rooms. Furthermore, note that if a Room is transferred to another channel and if a channel has a Room block, it cannot have any Rooms taken away from it, but it is can be allocated more Rooms. However, this step is unavoidable since a transfer of Rooms is based on a ratio of Rooms sold per channel to all Rooms sold and this total will include those blocked channels and therefore cannot be ignored. However, any extra Rooms that are allocated to a blocked channel can be redistributed if another channel becomes depleted.
- Subsequent Steps to be Carried Out
- For further time periods, the following adjustments at steps 2 and 3 must be made per channel.
- At step 2: If (1=1, NS_CNR=NS_CNR (Day 1) S (Day 2), 0). After the calculations for Day 1 have taken place initially, this becomes a count over each time period of how many Rooms from the original blocked count are available. In other words, this is carried out recurringly. Therefore, if (1=0), NS_CNR=0.
- This next step ensures that if all of the Rooms from the block are sold (where it is assumed that if an accommodation provider has a blocked deal, then it will sell Rooms from that block first and then any other Rooms sold at a given time period will come out of its Rooms that CAN be redistributed, as mentioned above), and NS_CNR becomes negative in the step above, then this will not affect the calculation of the total Rooms not sold. The algorithm is capable of dealing with this. However, it means that the calculation for NSCR must be altered so that the negative value does not affect totals that are otherwise correct.
- Consequently, per channel, at step 3: If (NS_CNR>O, A−S-NS_CNR, A−S). Therefore, if NS_CNR is negative, the count of Rooms that have not yet been sold and that can be redistributed is simply (A−S) because all Rooms now are available to be redistributed. If NS_CNR is not negative, then the count of rooms that can be redistributed must be (A−S-NS_CNR) as there are still some available from the original blocked amount that cannot be classed as being able to be redistributed.
- Note that in the initial loops (times when the algorithm is executed) performed by the subroutine using the algorithm, NS_CNR is unlikely to be negative because not many Rooms will be transferred and, therefore, each channel will keep selling Rooms from its initial allotted amount of Rooms.
- However, it will be appreciated that a negative value for NS_CNR is possible since a blocked channel can be allocated more Rooms when a transfer occurs and therefore sell its original blocked amount of Rooms while still having some Rooms left over to sell. As such, this step needs to be included so as to ensure that all totals are correct for sold and not sold Rooms and consequently prices are adjusted correctly.
- The Release of Unsold Blocked Rooms
- Assume that at Day 4 in this artificial example, any Rooms not sold from a block can be redistributed for ALL channels to sell. Therefore, prior to Day 4, at Step 11 a redistribution of the newly available Rooms must be made to all channels, depending on how well they are currently performing in the market. Therefore, the following steps are carried out per channel.
- At step 11 a new row is created that will convert any negative values of NS_CNR to zero. Recall that negative values in NS_CNR indicate that a Room sold has come from a count that CAN be redistributed rather than the blocked count. Next, calculate the total for this new row.
- At
step 12 the remaining Rooms that have not been sold by the blocked channels can now be redistributed to all of the channels depending on how well they are performing, measured through P. Therefore, multiply P by the total calculated in part 11 for each channel. This is defined as RA. - At step 13, the Final Allocation Adjustment after Unblocking (FAA_UB) is determined. This is equal to RA+NS_CR for each channel.
- At
step 14, in defining the new Room totals per channel, this new variable, FAA_UB will flow through into Day 4 to represent the new Room totals per channel. Note that after these blocked Rooms have been released, then the only total of Rooms not sold required is the absolute total per channel and not the breakdown into those that can be redistributed and those that cannot. Therefore, there are two less rows after Day 4 in the tables in Excel. - Three cases will now be described in more detail.
- Three separate scenarios are described to consider a number of eventualities that are represented by the attached Tables.
- Tables 1 to 4: Base Case
- In this situation, the algorithm is configured so that only a channel that has no blocked Rooms can have its Rooms to sell depleted. This is a case where the only complication arises when the total number of Rooms to be reallocated changes from those that can be redistributed to a different term in the spreadsheet after any unblocked Rooms are released into the general domain.
- Therefore, prior to Day 4, steps 11 to 13 remain as described above. However, after Day 4, when checking for whether any Room transfers are necessary steps 11 to 13 are altered as follows.
- At step 11, check to see if A>S. If so, then NAA=0 and there are still Rooms left to sell for this Channel. If A=S, then multiply the proportion of Rooms sold per Channel (P) by TNS to get a value for NAA (only for where A=S).
- At
step 12, compute the FAA at the next time period for all other channels by multiplying TNS by each P. - Tables 9 to 12: Inventory Depleted After Unblock
- In this situation, the algorithm is configured for the case when a previously blocked Channel is depleted after the blocked Channels have redistributed their allocations (if they had not sold all of their allocations). Therefore, after Day 4, when checking for whether any Room transfers are necessary, steps 11 and 12 are changed slightly as follows.
- At step 11, check to see if A>S. If so, then NAA=0 and there are still Rooms left to sell for this channel. If A=S, then multiply the proportion of Rooms sold per channel (P) by TNS to get a value for NAA (only for where A=S).
- At
step 12, compute the FAA at the next time period for all other channels by multiplying TNS by each P. - Tables 5 to 9: Inventory Depleted Before Unblock
- In this situation, the algorithm is configured for when a blocked channel is depleted of its Rooms before the blocked channels are required to redistribute their Rooms. Therefore, prior to Day 4, when checking for whether any Room transfers are necessary in steps 11 to 13, these are carried out in the same way as described in the initial step
- The algorithm is preferably configured to make adjustments once a day. That serves to inhibit frequent fluctuations in price, which could occur in potentially large jumps upwards and/or downwards if the algorithm is used to update the prices more than once a day.
- The time of day can be selected to take advantage of yield management theories indicating when a buyer is more likely to make a purchase of a Room over the Internet.
- However, the situation arising as a result of a channel selling all of its Rooms before re-adjustment would mean that the channel could not sell any more Rooms until any re-adjustment takes place at the specified time.
- For this eventuality, a loop is fed in to the algorithm to allow immediate updating and reallocation when a channel sells all of its Rooms. Therefore, if S=A, then the algorithm updates immediately to reallocate some Rooms to that channel to maintain the efficacy of the algorithm.
- The algorithm is also configured to accommodate a situation where another channel enters at any stage of a particular time-period. The algorithm incorporates a step that will allow for this to happen and each step in the algorithm can be generalized so that resulting calculations reflecting any new information entered as inputs are correct.
- The invention is intended to cover an embodiment in which rather than using the number of Rooms sold to evaluate how a particular re-seller compares to its competitors, the total revenue generated out of the total amount of revenue for that time period is considered.
- This can readily be implemented in the framework described in the above paragraphs, in the event that information was made available.
- Furthermore, there is provided an embodiment in which instead of making comparisons of channels at time points, comparisons are made over a predetermined time period. Seven days would be an example.
- Still further, the embodiment provides a valuable opportunity to process data for the purposes of developing an evaluation tool. That could be done by recording historical data, analyzing the data statistically and monitoring the progress of the algorithm and of the market in general. This would inevitably lead to changes in the process described above and likely deliver a more efficient tool.
- A Further Example of a Calculation for Changing a Rate
- The first calculation below determines the percentage of rooms booked, via the channel, out of rooms allocated to the channel for the property. This value is calculated for each day in a 30 day period assessed.
- A=the total number of allotments given to the channel for the property per day
- S=the number of total sold allotments via the channel for the property per day
- Z1 to Z30=the percentage sold from a channel per day
-
- The second calculation below determines the average percentage of rooms sold over the entire 30 day period for that property via that channel.
- M=Average percentage of rooms booked via that channel for the property over 30 days
- M=(Z1+Z2 . . . +Z29+Z30)/30
- The next calculation determines how each day's percentage of rooms sold compare against an average percentage of rooms sold over the whole month. This will return a positive or negative number.
- R1 to R30=a positive or negative number showing how a day's trade compares against the monthly average of percentage of rooms sold.
-
- The next calculation is designed to get the average number of rooms sold across all channels using an embodiment of the invention for each day in the 30 day period assessed.
- In the case of a property distributing to three Channels (i.e Channel 1, Channel 2 and Channel 3) the formula is:
-
- The final calculation is done to determine the number (average percentage sold with controlling factors) between −100 and 100. This calculation is done for each day in the 30 day period assessed. This value is used to increase or decrease the rate according to a ledger of thresholds that can readily be determined by the Property.
-
-
TABLE 1 BASE CASE Day 1 Channel Notation Cl C2 C3 C4 CS Total Av Dev Blocked Allocation I 1 1 0 0 0 Rooms Allotted A 50 50 50 50 50 250 Room Sold S 8 20 50 10 5 93 Rooms Not Sold NS_CNR 42 30 0 0 0 72 (that cannot be redistributed) Rooms Not Sold NS_CR 0 0 0 40 45 85 (that can be redistributed) Total Rooms Not TNS 42 30 0 40 45 157 Sold Rooms Sold per p 0.086 0.2151 0.5376 0.1075 0.0538 1 0.2 Channel/Total Rooms Sold (P)** Percentage Z −57 7.55 168.8 −46.25 −73.1 −2.8422E−15 99.0986 Difference in (P)(relative to average) Scaled Value −1.29 0.17 3.81 −1.04 −1.65 New Allocation NAA 0 0 46 0 0 46 Amount New Allocation Aadj 7 18 46 9 5 85 Adjustment Final Allocation FAA 49 48 46 9 5 157 Amount -
TABLE 2 BASE CASE Day 2 Channel Cl C2 C3 C4 C5 Total Rooms Allotted A 49 48 46 9 5 157 Room Sold S 5 20 4 4 2 35 Rooms Not Sold NS_CNR 37 10 0 0 0 47 (that cannot be redistributed) Rooms Not Sold NS_CR 7 18 42 5 3 75 (that can be redistributed) Total Rooms Not TNS 44 28 42 5 3 122 Sold Rooms Sold per p 0.1429 0.5714 0.1143 0.1143 0.0571 1 0.2 Channel/Total Rooms Sold (P)** Percentage % C −28.55 185.7 −42.85 −42.85 −71.45 −5.6843E−15 104.973 Difference in (P) (relative to average) Scaled Value Z −0.64 4.19 −0.97 −0.97 −1.61 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount -
TABLE 3 BASE CASE Day 3 Channel Cl C2 C3 C4 C5 Total Rooms Allotted A 44 28 42 5 3 122 Room Sold S 10 4 2 2 2 20 Rooms Not Sold NS_CNR 27 6 0 0 0 33 (that cannot be redistributed) Indicator Variable 27 6 0 0 0 33 for a negative number of rooms Rooms Not Sold NS_CR 7 18 40 3 1 69 (that can be redistributed) Total Rooms Not TNS 34 24 40 3 1 102 Sold Rooms Sold per p 0.5 0.2 0.1 0.1 0.1 1 0.2 Channel/Total Rooms Sold (P)** Percentage 150 1.388E−14 −50 −50 −50 1.42109E−14 86.6025 Difference in (P) (relative to average) Scaled Value Z 3.38 0.00 −1.13 −1.13 −1.13 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount Redistribution RA 17 7 3 3 3 33 adjustmentfrom unblocked rooms Final Allocation FAA_UB 24 25 43 6 4 102 Amount_After Unblocking In this worked example, after this time point, blocked rooms have been redistributed -
TABLE 4 BASE CASE Channel Cl C2 C3 C4 C5 Total Day 4 Rooms Allotted A 24 25 43 6 4 102 Room Sold S 4 6 3 6 1 20 Total Rooms Not TNS 20 19 40 0 3 82 Sold Rooms Sold per p 0.2 0.3 0.15 0.3 0.05 1 0.2 Channel/Total Rooms Sold(P)** Percentage 0 50 −25 50 −75 −8.5265E−15 53.033 Difference in (P)(relative to average) Scaled Value Z 0.00 1.13 −0.56 1.13 −1.69 New Allocation NAA 0 0 0 25 0 25 Amount Final Allocation FAA 16 25 12 25 4 82 Amount Day 5 Rooms Allotted A 16 25 12 25 4 82 Room Sold S 10 0 2 2 1 15 Total Rooms Not TNS 6 25 10 23 3 67 Sold Rooms Sold per p 0.6667 0 0.1333 0.1333 0.0667 1 0.2 Channel/Total Rooms Sold(P)** Percentage 233.35 −100 −33.35 −33.35 −66.65 8.52651E−15 133.341 Difference in (P)(relative to average) Scaled Value Z 5.27 −2.26 −0.75 −0.75 −1.50 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Would stop here in this example -
TABLE 5 INVENTORY DEPLETED BEFORE UNBLOCK Day 1 Channel Notation Cl C2 C3 C4 C5 Total Av. Dev Blocked Allocation I 1 1 0 0 0 Rooms Allotted A 50 50 50 50 50 250 Room Sold S 8 20 8 10 5 51 Rooms Not NS_CNR 42 30 0 0 0 72 Sold(that cannot be redistributed) Rooms Not NS_CR 0 0 42 40 45 127 Sold(that can be redistributed) Total Rooms TNS 42 30 42 40 45 199 NotSold Rooms Sold per p 0.1569 0.3922 0.1569 0.1961 0.098 1.0001 0.20002 Channel/Total Rooms Sold (P)** Percentage −21.557844 96.080392 −21.557844 −1.959804 −51.0049 −1.3E−14 56.4939457 Difference in (P) (relative to average) Scaled Value Z −0.85 3.80 −0.85 −0.08 −2.02 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount -
TABLE 6 INVENTORY DEPLETED BEFORE UNBLOCK Day 2 Channel Cl C2 C3 C4 C5 Total Rooms Allotted A 42 30 42 40 45 199 Room Sold S 5 20 4 4 2 35 Rooms Not NS_CNR 37 10 0 0 0 47 Sold(that cannot be redistributed) Rooms Not NS_CR 0 0 38 36 43 117 Sold(that can be redistributed) Total Rooms Not TNS 37 10 38 36 43 164 Sold Rooms Sold per p 0.1429 0.5714 0.1143 0.1143 0.0571 1 0.2 Channel/Total Rooms Sold (P)** Percentage % C −28.55 185.7 −42.85 −42.85 −71.45 −5.7E−15 104.972544 Difference in (P) (relative to average) Scaled Value Z −1.13 7.35 −1.70 −1.70 −2.83 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount -
TABLE 7 INVENTORY DEPLETED BEFORE UNBLOCK Day 3 Channel Cl C2 C3 C4 C5 Total Rooms Allotted A 37 10 38 36 43 164 Room Sold S 10 4 2 2 2 20 Rooms Not Sold NS_CNR 27 6 0 0 0 33 (that cannot be redistributed) Indicator Variable 27 6 0 0 0 33 for a negative number of rooms Rooms Not Sold NS_CR 0 0 36 34 41 111 (that can be redistributed) Total Rooms Not TNS 27 6 36 34 41 144 Sold Rooms Sold per p 0.5 0.2 0.1 0.1 0.1 1 0.2 Channel/Total Rooms Sold (P)** Percentage 150 1.388E−14 −50 −50 −50 1.42E−14 86.6025404 Difference in (P) (relative to average) Scaled Value Z 5.94 0.00 −1.98 −1.98 −1.98 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount In this worked example, after this time point, blocked rooms have been redistributed Redistribution RA 17 7 3 3 3 33 adjustment from unblocked rooms Final Allocation FAA_UB 17 7 39 37 44 144 Amount After Unblocking -
TABLE 8 INVENTORY DEPLETED BEFORE UNBLOCK Channel Cl C2 C3 C4 C5 Total Day 4 Rooms Allotted A 17 7 39 37 44 144 Room Sold S 17 6 3 2 1 29 Total Rooms TNS 0 1 36 35 43 115 NotSold Rooms Sold per p 0.5862 0.2069 0.1034 0.069 0.0345 1 0.2 Channel/Total Rooms Sold (P)** Percentage 193.1 3.45 −48.3 −65.5 −82.75 0 112.661234 Difference in (P) (relative to average) Scaled Value Z 7.64 0.14 −1.91 −2.59 −3.28 New Allocation NAA 67 0 0 0 0 67 Amount Final Allocation FAA 67 24 12 8 4 115 Amount Day S Rooms Allotted A 67 24 12 8 4 115 Room Sold S 10 18 2 2 1 33 Total Rooms Not TNS 57 6 10 6 3 82 Sold Rooms Sold per p 0.303 0.5455 0.0606 0.0606 0.0303 1 0.2 Channel/Total Rooms Sold (P)** Percentage 51.5 172.75 −69.7 −69.7 −84.85 −1.1E−14 111.142381 Difference in (P) (relative to average) Scaled Value Z 2.04 6.84 −2.76 −2.76 −3.36 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment -
TABLE 9 INVENTORY DEPLETED AFTER UNBLOCK Day 1 Channel Notation Cl C2 C3 C4 C5 Total Av. Dev Blocked Allocation I 1 1 0 0 0 Rooms Allotted A 50 50 50 50 50 250 Room Sold S 8 20 8 10 5 51 Rooms Not NS_CNR 42 30 0 0 0 72 Sold(that cannot be redistributed) Rooms Not Sold NS_CR 0 0 42 40 45 127 (that can be redistributed) Total Rooms TNS 42 30 42 40 45 199 Not Sold Rooms Sold per p 0.1569 0.3922 0.1569 0.1961 0.098 1.0001 0.20002 Channel/Total Rooms Sold (P)** Percentage −21.557844 96.080392 −21.557844 −1.959804 −51.0049 −1.3E−14 56.4939457 Difference in (P) (relative to average) Scaled Value Z −0.85 3.80 −0.85 −0.08 −2.02 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount -
TABLE 10 INVENTORY DEPLETED AFTER UNBLOCK Day 2 Channel Cl C2 C3 C4 C5 Total Rooms Allotted A 42 30 42 40 45 199 Room Sold S 5 20 4 4 2 35 Rooms Not NS_CNR 37 10 0 0 0 47 Sold(that cannot be redistributed) Rooms Not NS_CR 0 0 38 36 43 117 Sold(that can be redistributed) Total Rooms TNS 37 10 38 36 43 164 NotSold Rooms Sold per p 0.1429 0.5714 0.1143 0.1143 0.0571 1 0.2 Channel/Total Rooms Sold (P)** Percentage % C −28.55 185.7 −42.85 −42.85 −71.45 −5.7E−15 104.972544 Difference in (P)(relative to average) Scaled Value Z −1.13 7.35 −1.70 −1.70 −2.83 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount -
TABLE 11 INVENTORY DEPLETED AFTER UNBLOCK Day 3 Channel Cl C2 C3 C4 C5 Total Rooms Allotted A 37 10 38 36 43 164 Room Sold S 10 4 2 2 2 20 Rooms Not Sold NS_CNR 27 6 0 0 0 33 (that cannot be redistributed) Indicator Variable 27 6 0 0 0 33 for a negative number of rooms Rooms Not Sold NS_CR 0 0 36 34 41 111 (that can be redistributed) Total Rooms Not TNS 27 6 36 34 41 144 Sold Rooms Sold per p 0.5 0.2 0.1 0.1 0.1 1 0.2 Channel/Total Rooms Sold (P)** Percentage 150 1.388E−14 −50 −50 −50 1.42E−14 86.6025404 Difference in (P) (relative to average) Scaled Value Z 5.94 0.00 −1.98 −1.98 −1.98 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment Final Allocation FAA 0 0 0 0 0 0 Amount In this worked example, after this time point, blocked rooms have been redistributed Redistribution RA 17 7 3 3 3 33 adjustment from unblocked rooms Final Allocation FAA_UB 17 7 39 37 44 144 Amount_After Unblocking -
TABLE 12 INVENTORY DEPLETED AFTER UNBLOCK Channel Cl C2 C3 C4 C5 Total Day 4 Rooms Allotted A 17 7 39 37 44 144 Room Sold S 17 6 3 2 1 29 Total Rooms TNS 0 1 36 35 43 115 NotSold Rooms Sold per p 0.5862 0.2069 0.1034 0.069 0.0345 1 0.2 Channel/Total Rooms Sold (P)** Percentage 193.1 3.45 −48.3 −65.5 −82.75 0 112.661234 Difference in (P) (relative to average) Scaled Value Z 7.64 0.14 −1.91 −2.59 −3.28 New Allocation NAA 67 0 0 0 0 67 Amount Final Allocation FAA 67 24 12 8 4 115 Amount Day S Rooms Allotted A 67 24 12 8 4 115 Room Sold S 10 18 2 2 1 33 Total Rooms Not TNS 57 6 10 6 3 82 Sold Rooms Sold per p 0.303 0.5455 0.0606 0.0606 0.0303 1 0.2 Channel/Total Rooms Sold (P)** Percentage 51.5 172.75 −69.7 −69.7 −84.85 −1.1E−14 111.142381 Difference in (P) (relative to average) Scaled Value Z 2.04 6.84 −2.76 −2.76 −3.36 New Allocation NAA 0 0 0 0 0 0 Amount New Allocation Aadj 0 0 0 0 0 0 Adjustment - Embodiment for Application Without a Predetermined Period
- The following paragraphs relate to the schematic flowchart set out in
FIG. 5 and referred to generally withreference numeral 100. Theschematic flowchart 100 represents an embodiment of a software product in the form of instructions stored on a non-transitory computer-readable medium executable by a computer and a method for managing inventory allocated to respective re-sellers. In particular, the product provides flexibility in the application of the generated performance indicator referred to with the variable Z in the previous embodiment to current and future “Yield Management” techniques (i.e. techniques relating to maximizing the financial yield from inventory allocations). It is to be appreciated that the performance indicator can also be referred to as a control indicator, since it is used to control non-contingent values. These can include values of “price” referred to above. - In the following description, the variable symbols used correspond with those defined in the description of the previous embodiments, unless otherwise indicated.
- The
software product 100, comprising computer-readable instructions, is also configured to separate various processes and calculations into stages to limit the amount of processing needed when applying the indicator (Z) to “Yield Management” techniques and to cache the data for appropriate re-use (e.g. statistical analysis). This allows operations to be performed on the indicator without the need to calculate it every time. A person of ordinary skill in the field would appreciate that such a product, when executed, can reduce data processing load on thecomputer 12, when compared with load that would result in calculations having to be carried out across all databases for each operation. - For convenience, the allocation of inventory will be referred to as a Room, with the understanding that this embodiment can be applied to any allocation of inventory. Furthermore, the Rooms can be associated with a particular Property to envisage the situation of, for example, a resort attempting to obtain the best yield from the Rooms it has available. “Property” could also be understood to be more than particular geographical location. For example, it could be a certain category of properties, or a chain of resorts. In other words, the Rooms are grouped into Properties to provide a meaningful comparison between performances achieved by different Channels. In addition, the embodiment can be applied to relational databases that could carry any form of data, not necessarily relation to sale of inventory.
- Each logical progression is numbered and explained below and refers to the program flow depicted by
FIG. 5 . - Processes Initiated by a Channel/Booking Engine
- The
software product 100 defines aremote booking engine 102 that uses a suitable communications protocol to receive booking data at 104 for a property and room type when made via a channel. - Processes that Feed Data into a Data Storage Function
- When a booking is processed and the booking data is entered into the system, the
software product 100 calls adata storage function 108 for storing the booking data in a Data Processing Table 110. Thefunction 108 writes an appropriate date range (arrival date and departure date less one day) and associated room identification data (Room ID) to the table 110. - When a cancellation is processed at 106, the
software product 100 calls thefunction 108 for storing a record in the table 110. Thefunction 108 stores the date and Room ID in the table 110. - Allocation allotment changes are processed at 112 in a suitable allotment interface. The
function 108 is called and the appropriate date range (Date Range) and associated Room ID is passed to thefunction 108 which stores the Date Range and Room ID in the table 110. If more than one Room is chosen for allocation changes then more than one record of the change is created in the table 110. - It will be understood that certain Rooms in a particular property could be locked or unlocked from processing by the
software product 100 due to a previous negotiation with a specific channel, as envisaged in the previous embodiment. When Rooms for a channel are locked or unlocked at 114 via an interface referred to as a Channel Connection Interface, a section of the Rooms available on a given date for the associated channel is removed from or added to a re-distribution pool of Rooms by thefunction 108. - When this occurs, all cached records for Rooms from an associated property are re-calculated based on a resultant re-distributable pool. The appropriate date ranges (from a day the Rooms are locked until a last allotment date for that Property), as well as all the Room ID's for that Property, are passed to the
function 108 which stores the records in the table 110. - Calculating a Performance Indicator From the Data Processing Table
- This is a process that runs constantly. Steps 1 and 2 below are repeated as long as there is data to select from the table 110.
- 1. The records are selected by a
function 116 consecutively from the table 110 in the order of entry. - 2. An algorithm defined by the
function 116 is then processed for each day and associated Room ID in the date range stored in the table 110. - A difference between this embodiment and the previous embodiment for a predetermined timeline is that a concept of a “re-distribution timeline” (the five days in the Tables) is not introduced at this stage. This means that a value of “Sum_A” only includes the allotments from channels participating in the re-distribution process for a Room Type (i.e. a Room in a particular Property) and date of a particular record.
- In order to participate in this embodiment, a channel must not be holding blocked inventory. Also, the channel must at least have an “allotment value” for the Room via the channel on the given date in the record. An “allotment value” is an entry in a database table used by the
product 100 to associate channels with Rooms, Room types, available dates and other characteristics usually associated with a booking. “Sum_NSR” therefore only includes rooms that are sold from a re-distributable pool. Per channel, thefunction 116 computes the following: - 1. Record Rooms Allotted (A) and Rooms Sold (S);
- 2. NS_R=A−S (The C is dropped since C & CN are indicators of whether or not a particular Room can be sold and as that differentiator is not applicable in this embodiment);
- 3. T=A−S;
- Next,
- 4. Calculate Sum_S and Sum_NSR using the values from the previous 3 steps; Per Channel,
- 5. Calculate P as S/Sum_S. Now, the
function 116 compares each of the amounts obtained at step 5 to the average proportion sold per channel; - 6. Compute the average of the P's; Again, per channel,
- 7. Compute a percentage change (%C) of each P relative to the average P;
- 8. Compute the average percentage change and the standard deviation of this percentage change;
- Using these values, per channel,
- 9. Subtract the mean Percentage Change from each %C; and
- 10. Divide the result returned by the previous step through by (Standard Deviation of the Percentage Change)(Square Root (Number of Channels)).
- The results of these calculations are then recorded or updated for each date processed and for each Channel that has a Room allocated on the respective date, for the Room Type being processed, into a cache table 118.
- Re-distributing Rooms Triggered by Booking and Cancellation Processes
- When the booking processing is complete and it has been calculated that a Channel has run out of Rooms for a Room Type then an Allotment Re-Distribution
Date Storage function 120 is called to store the Room ID and date where re-allocation is required into an Allotment Re-Distribution Table 122 that carries or stores distribution values. - If it is determined that there are no more Rooms to re-distribute for a particular Room
- ID and date then the data is not entered into the table 122 as no re-distribution is required.
- When the cancellation processing is complete and a new Room exists for the Room Type then an Allotment Re-Distribution
Date Storage function 124 is called to store the Room ID and date where re-allocation is required in the table 122. - Each record is selected from the table 122 and processed by the
function 122 one by one in order of entry into the table 122. - The channels that participate in a re-distribution process described above for a particular Room Type and date are selected from a channels table 126. To satisfy “participation” criteria they must not be holding inventory that is “locked” in the channel. They must also at least have an allotment value, as described above for the Room via the channel on the given date. In other words there must be an entry in the table 126 that associates the channel and the Room.
- They must also be currently linked to the Property via an active ClientChannels table record. An active ClientChannels table record is a record in a ClientChannels table that links to an interface used by a vendor to select a particular Channel. Thus, the table record contains a list of channels available for selection by the vendor. In order for the particular record to be active, that channel should have been selected by a vendor to participate in the reselling of the vendor's inventory (Rooms for this particular example). It will be appreciated that “vendor” is used broadly and can be interchanged with “Property” as that word has been defined earlier.
- Once the participant channels have been determined, the
function 120 uses the performance indicator (Z) for the channel to order a list in the channels table 126 from highest performing Channel first to lowest performing channel last. If there are channels in the list that have the same performance rating then thefunction 120 uses a randomizing algorithm to order those channels. - After the order has been determined, the
function 120 counts the number of Rooms in the re-distributable pool for the day in question and loops through the list of channels assigning one Room to each channel in the list in turn until the number of re-distributable Rooms is exhausted. If the list of channels is exhausted and there are still Rooms to be distributed, the looping process is repeated until there are no more Rooms to distribute. - Once a count of Rooms to be allotted has been determined, the
function 120 generates the necessary script to facilitate allotment with OTA XML and communicates it to the channels via the protocol used by OTA. OTA stands for the Open Travel Alliance. That organization has developed an XML standard (OTA XML) that facilitates online bookings and allocations. - Price Modification
- A price or
rate calculation function 128 is called and executed every 24 hours by a time-based scheduling device or cron. Thefunction 128 adjusts non-contingent values in the form of prices for 30 days into the future from the date on which it is executed for all channels that have rooms with allotments on the days in question. - The
function 128 initiates by uploading a list of the dates to process. Next it selects all the Room and channel combinations from the table 122 that actually have an allotment value for the respective dates. The allotment value must be greater than 0 as there is no reason to increase the price of a room if there is nothing to sell. - Then it selects a performance or control indicator Z for a Room and channel combination from the
cache 118. - The
function 128 then selects a current price for the room via that channel on the date it is executed as well as a minimum rate (the rate it cannot go below) for that date/Room I Channel combination. - It then carries out an adjustment on the rate according to Z and the corresponding adjustment value from an adjustment table referred to in the previous embodiment making sure it does not drop below the minimum rate.
- A Rates table 130 is then adjusted accordingly and the OTA XML created for transfer of the respective rate to the Channel.
- Linking and Unlinking Rooms
- At 136, the
software product 100 provides an interface to permit the Property to lock inventory (Rooms) out of the algorithms of the software product in the event that a Property has negotiated a block of the Rooms with a particular vendor. In the event that Rooms are to be released back for participation in thesoftware product 100, theinterface 100 allows the Rooms to be “unlocked”. - Statistical Analysis
- A particular advantage of exemplary embodiments is that they provide the
cache 118 that is accessible with astatistical analysis engine 132. Theengine 132 is configured to perform statistical analyses on the data collected in thecache 118 to assess the performance of the algorithms used by the software product of the invention. - The statistical assessment can be carried out manually. However, it is preferable that the assessment be carried out with a suitable application such as that known as a genetic or self-learning algorithm.
- In order to achieve that, a statistics table 134 is provided to receive data from the
statistical analysis engine 132. - Database Management
- As envisaged in paragraphs [0074], [0079], [0170], [0181], [0228] and elsewhere in the published parent application of U.S. patent application Ser. No. 16/924,395, the embodiments described above lead to increased efficiencies in the operation of the data processing apparatus. The following description is intended further to clarify the manner in which the increased efficiencies are achieved without the addition of new material to the description as set out in the Parent Application. As set out in paragraph [0080] two methods in which data can be received from respective Channels have been conceived. These are “real time” and “request-based” (also known as polling) methods. Use is made of the word “temporal” in the following description to characterize the time-based nature of operation of the
computer 12. Furthermore, the “real-time” and “request-based” data are described as being received at “receiving times” for convenience. - At an independent time, for example as described in paragraph [0115] of the Parent Application, the
subroutine 24 is executed to readjust distribution values (number of rooms) at “refreshing times”. - Reference is made to “relational database fields”. These are previously described and shown as entries or records in spreadsheets, for example, Excel spreadsheets. It is to be appreciated that such spreadsheets are effectively relational databases with a collection of database fields that are capable of being updated by the
computer 12 when executing the computer readable instructions of the software product. As described above, execution of the software product allows thecomputer 12 to make efficient use of a processor when handling the databases. - For the purposes of this description,
FIGS. 6 to 12 have been added further to clarify the steps described above that lead to efficient collection of data. Furthermore, the following description makes use of the word “values” to describe, generically, the parameters set out in the above tables. This is for clarity in describing the method of using thecomputer 12 to manage or control a distributed database. - Reference is also made to a “relational database”. As is commonly known in the art, a relational database is a collection of data items organized as a set of formally-described tables in which data is structured to recognize relations between stored data entries and that can be accessed or reassembled in many different ways without having to reorganize the database tables. In the above embodiments, and as set out above, it can be said that the tables are relational databases. Furthermore, throughout the above description, reference is made to tables with changing cell values. It follows that the use of the term “relational database” is for convenience and for a proper understanding of the role of the various components shown in
FIG. 1 , for example. - As set out above, the tables are updated if and when certain conditions apply. See, for example, the description of the manner in which the tables are established. It follows that values in the tables are contingent upon certain conditions. These are referred to as contingent values. These conditions arise out of sporadic interactions between the
subscribers 20, clearly making use of terminal computer systems indicated inFIG. 1 and theservers 18, which are distributed computer systems. The term “sporadic” has been introduced to reflect, in the examples provided above, the necessarily sporadic nature of bookings or consumption by the public. The values can therefore also include non-contingent values, such as the price of an allotment or allocation, which are related to the contingent values. - In the above description, reference is made to various ratings and indices to reflect the performance of Channels. See, for example, paragraph [0067] of the published parent application of U.S. patent application Ser. No. 16/924,395. Those are referred to as control indicators in the following description since they can be used to control the manner in which fresh initial values are determined for sending to the contingent and non-contingent distributed database fields. Those control indicators are also used, in some instances, to control priorities for refreshing of distributed databases field.
- The
computer 12 can be considered to be a central computer system in the form of a server 200 (shown inFIG. 6 as a further example). Theserver 200 has a centralrelational database 202. Theserver 200 is in data communion with a data communication network 204, such as the Internet. A plurality of distributed computer systems (servers) 206.1 to 206.3 (also represented as thechannels 18 inFIG. 1 ) are connected to the network 204 and include a distributed database 208 that has database fields 212.1 to 212.3. In the above example, these would be necessary for receiving and sending information such as the sale price, rate of commission, and number of items sold, as described in paragraph [0057] of the Parent Application. - Terminal computer systems, such as PCs, tablets, phones, and the like (also represented as members or
subscribers 20 inFIG. 1 ) interact with the distributed servers 208 sporadically in ways that alter some of the values of the database fields 212 in the distributed database 208. It is envisaged that the terminal computer systems can incorporate, wholly or in part, the distributed servers. In the drawings, the distributed servers are shown separately for clarity only. In other embodiments, the distributed servers can be cloud-based so as not necessarily to be represented by separate physical servers. For example, the servers can be virtual servers distributed across networks. - Each distributed database 208 is affiliated with the central
relational database 202 in the sense that the central sever 200 and centralrelational database 202 determine values for the distributed database fields 212 according to predefined relationships or conditions that have to be met. Those values are then used to populate the associated distributed database fields 212 of the distributed database 208. A difficulty occurs when the values of the distributed database fields 212 are contingent on sporadic interaction between terminal computer systems and the distributedservers 210, which varies the values of the database fields 212 sporadically and unpredictably out of their relationship. This would clearly be the case where the values depended on, for example, booking rates, as envisaged above. - Consequently, the
central server 200 andcentral database 202, from time-to-time, have to update or refresh the values in the distributed database fields 212 to restore their appropriate relationships as per the allowable relationships or conditions reflected in thecentral database 202. Some of these allowable relationships or conditions are reflected in the above description with reference to various types of tables. - Monitoring those sporadic changes and refreshing the values accordingly in the distributed database with the central server and database, poses practical difficulties to ensure a sufficient degree of the reliability of the data which, in turn, requires efficient updates, redundancy, and the like.
- In accordance with an embodiment, as further described below, various techniques are provided for refreshing the distributed database 208 as required by the
central server 200 andcentral database 202 to maintain a sufficient degree of data reliability over and above the unpredictable interactions of theterminal computer systems 210 with the distribution servers 206, so as still to enable many useful applications. - In
FIG. 7 ,reference numeral 216 indicates generally a method of using acentral server 200 having thecentral database 202 systematically to refresh the distributed database 208 that is distributed over the plurality of distributed servers 206. The distributed database 208 includes a least some database fields 212.1 A to 212.3A that store contingent values. In other words, they store values that vary subject to sporadic interactions between theterminal computer systems 110 and the distributed servers 208. - Broadly, the
method 216 includes executing computer instructions, at 218, which cause two separate parallel processes, 220, 222, to execute on the central server. - One process, a
receiving process 216, broadly includes recurrently, at receiving times, noting, at 224, the receiving time for receiving contingent values of the distributed database fields 212.1 A to C from the distributed servers 208, and storing, at 226, the received values in the centralrelational database 202 in succession with previously received and stored contingent values of the distributed database fields, so as to build, for each distributed server an associated series of successive contingent values 214.1 A to C. This process can result in the generation of one or more of the tables described herein. - The other process, a
refreshing process 220, broadly includes recurrently, at refreshing times, noting the refreshing time, at 230, determining, at 232, fresh initial distribution values for the distributed database fields based on the successive contingent values 214.1 A to C of the distributed servers 206 and based on required initial distribution conditions, and distributing, at 234, the fresh initial distribution values to the distributed database fields of the distributed servers 206. - The two processes can run in parallel and are temporally independent in a way that the receiving
process 220 controls receiving of data, say values, from the distributed database 208 in its own time, and the refreshing process 222 controls refreshing of the distributed database 208 in its own time, without the one process interfering with the other process. - An example of this process is shown in
FIG. 4 , where a real-time and a polled distribution channel are shown operating independently. - Regarding the
receiving process 216, in this embodiment, three techniques are provided further to reduce temporal dependency and therefore to increase the applied diversity of the system. - Referring to
FIG. 8 , threeprocesses process 236 is used for the case in which a distributed server 206 needs to be prompted (polled) at times, to send the contingent values of its database fields 212 to thecentral server 200 for storing in thecentral database 202.Processes FIG. 4 , withFIG. 5 providing further clarification. - When
process 236 executes, then, at 242, the central server selects a distributed server. At 244, a check is performed to determine if that distributed server 208 needs to be prompted for receiving the contingent values or if the distributed server 208 is configured automatically to send the contingent values to thecentral server 200. If the distributed server needs to be prompted, then, at 246, the central server determines if it is time (a receiving time) to receive the contingent values from that distributed server, and if it is, then prompt the distributed server 208, at 248. At 250, the contingent values are received from the distributed server 208, and the central database is updated at 252. The process then returns to 242 to select another distributed server and to repeat theprocess 236. If, at 244, the central server determines that the distributed server need not be prompted, then the process returns to 242 to select another distributed server 208 and to repeat theprocess 236. The same applies at 246. -
Process 238 is for controlling the case when a distributed server is configured to send the contingent values to the central server periodically and automatically. When theprocess 238 executes, the central server receives, at 254, contingent values from a distributed server. At 256 the central server determines which server sent the contingent values, and, at 258, the central server updates thecentral database 202. -
Process 240 is similar toprocess 238, except thatprocess 240 is for controlling the case when a distributed server is configured to send the contingent values only once a change in the contingent values occurs. When theprocess 240 executes, the central server receives, at 260, contingent values from a distributed server. At 262 the central server determines which server sent the contingent values, and, at 264, the central server updates thecentral database 202. - In this embodiment,
process 220 is also further split into temporally independent processes. Referring toFIG. 9 ,process 266 is for determining, at refreshing times, fresh initial values for the distributed database, andprocess 268 is for distributing, at distributing times, those fresh initial values to the distributed database 208. - Broadly, when
process 266 is executed, then, at 270, thecentral server 200 times the refreshing process, and at 272 checks if it is time to determine fresh initial values for the distributed database fields, and if so, then determines, at 274, the fresh initial values for the distributed database based on successive contingent values of the distributed servers and based on required initial conditions and relationships. Otherwise the process returns to 270. At 274, the fresh initial values are stored in thecentral database 202 ready for distribution to the distributed database 208. -
Process 268, when executed, broadly involves timing, at 276, when it is time to distribute the fresh initial values to the distributed servers 206, and to check if it is time, at 278, to refresh or update the distributed database 208. If so, at 280, a relevant distributed server is selected, and the fresh values are sent to the distributed server at 282. At 284, thecomputer 12 checks if there are other servers that still need updating, and if so, proceeds to 280 to select and update the relevant distributed server. Otherwise, the process proceeds to 276. - In order to explain more specifically how the central database is updated at 252, 258, 264, in the above processes, and how the fresh initial values are determined, at 274, for the distributed database, reference is first made to
FIG. 10 that shows a simplified version of a central database and an affiliated distributed database to assist with the explanation. - The
central database 202 includes a set ofdatabase fields 214 that make provision for storing series of values. As can be seen, this can readily be shown in table format and is, effectively, a generic form of either of the tables described above. In particular, the series of central database fields 214.1, 214.2, 214.3 are respectively affiliated with distributed database fields 212.1. 212.2, and 212.3. These include fields 212.1A, 212.2A and 212.3A for storing contingent values and 212.1 B to 212.3B for storing non-contingent values that do not vary directly by interaction of the terminal computer systems with the distributed servers. - When any one of the
processes - In some cases, at refreshing times, it might be necessary for the central database also to determine fresh values for refreshing the non-contingent database fields at the same time as their related contingent fields are refreshed. For that reason, if a fresh non-contingent value is determined then it is also stored in the database set in relation to its related contingent value. See for example, 214.1V, 214.1W, 214.1X, 214.1Yand 214.1Z that are stored in relation to 214.1 A, 214.1 C, 214.1 E, 214.1 G, 214.1 H.
- The central database also includes conditional or relational fields 214.4 that are used, at least in part, to define relationships between the fresh initial values when being determined for the contingent database fields. Similarly, the central database also includes conditional or relational fields 214.5 that are used, at least in part, to determine a non-contingent value in relation to an associated fresh initial value for the contingent database field.
- Referring to
FIG. 11 , one embodiment of theprocess 268 is shown in more detail.Process 268 executes, and monitors, at 276, refreshing times for the initial values of the database fields 212 of the distributed servers 206. These refreshing times can be predefined, or dependent on variables. When it is time, decided at 288, to determine fresh initial values for the distributed database, then, at 290, one of the distributed servers is selected, and an individual control indicator is determined, at 292, for that distributed server based on selected past initial- and contingent values for that distributed server. - At 294, the
central server 200 determines a relationship between the individual control indicator and some predefined conditions, and if those conditions are not met then a fresh non-contingent value is determined, at 298. However, if those conditions are met, then a group control indicator is determined, at 296. At 300, thecentral server 200 determines a relationship between the individual control indicator and some predefined conditions, and if those conditions are not met then a fresh non-contingent value is determined at 302. - Otherwise, if those conditions are met, then fresh initial distributed values are determined, at 304.
- At 305, the central database is updated with the fresh initial distributed values, and the distributing process can now update the distributed database in its own time.
- Referring to
FIG. 12 , anotherprocess 310 is shown that is used to supplement or expandprocess 268. In particular,process 310 is used to expandprocess 268 in the case that it is determined, at 294, by thecentral server 200 that the relationship between the individual control indicator and predefined conditions, are not met. In that case, at 312, the central server selects a distributed server and determines, at 314, an individual control indicator (and/or) a group control indicator. At 316, a check is performed to determine if there are more servers that need considering and, if so, the process returns to 312 in which the next server is selected, and an individual control indicator and/or a group control indicator is determined also for that server, until an individual control indicator and/or group control indicator is determined for each distributed server. - At 318, the central server determines if a fresh initial value has to be determined for any of the distributed database fields that are for storing contingent values and, if so, then, at 320, fresh initial values are determined as needed for the distributed database.
- Thereafter, a further check is performed, at 322, to determine if any one of the fresh initial values meets some predefined conditions, and if so, then the
central server 200 proceeds to 324, to determine a fresh non-contingent value that is related to the contingent value, and the central database is updated at 326. Otherwise, at 322, the process proceeds directly to updating the central database - The fresh initial values for the contingent database fields and the related non-contingent values, once determined and stored in the central database, need to be sent to the distributed database. Regarding updating or refreshing of the distributed database, there are a few techniques that this embodiment provides, that enable updating or refreshing of the distributed database fields at the distributed servers.
- In one embodiment, the central server is configured to detect only those fields in the central database within a set of database fields that have been updated with fresh initial values or fresh non-contingent values, and then systematically only to update those fields in the affiliated distributed database field over time as opposed to rolling out entire set of values of the set of database fields.
- In another embodiment, or in addition to the above, the central server is configured to make use of the individual, and/or group control indicators to determine priorities for updating the various distributed database fields, and update those distributed database fields with higher priorities first.
- In this Specification, the following definitions provided below are applied.
- “Inventory” is any item, whether tangible or intangible, that is capable of being transferred or distributed from one party, entity, apparatus, or consumption source to another and in respect of which it may be required to control and monitor quantity, rate of consumption and other parameters. The definition is not limited to items that are sold. For example, it can encompass items or measures of fluid that are fed from one apparatus to another and where is may be desired to monitor, measure or otherwise determine characteristics of the inventory and the manner in which is it transferred, such as a rate of transfer.
- “Computer” is any apparatus capable of carrying out data processing functions and includes a computer system, or a collection of one or more apparatus, including mobile apparatus, such as smart phones, tablets and other hand-held devices.
- “Allocations” are representations of items of inventory that are allocated to portals, channels, and other distribution agents for allocation or re-allocation to other portals, channels and distribution channels. These are also referred to as “allotments” in this specification.
- “Distribution Channels” are portals, outlets, channels and other distribution agents that are configured for the distribution of inventory to consumers or sources consumption.
- “Server” is a computer or other data processing apparatus that is capable of carrying out server-side operations.
- It is submitted that the various embodiments described above can provide a means whereby an efficient distribution of inventory can be made between various distribution channels for that inventory. This is particularly important where significant data is generated that could place undue load on data processors. In such cases, administrators, for example, servers, can find it difficult to investigate the performance of connected distribution channels and, in response, make changes to parameters of inventory. As is clear from the above description, the method of using a central computer system can provide a means whereby the administrators can maintain control of inventory parameters such as supply rates with a processor load that would not be possible without the steps of the embodiments of the method.
- The database management techniques described above, such as independent processing, in particular for processes that involve interaction between the central server and the distributed servers, and also processes that execute only central server side, provide embodiments that are diverse and suitable, for controlling overall efficiency, reliability, and redundancy, as uniquely required by different applications.
- Further, incorporating the use of individual- and group indictors, as explained in these embodiments, facilitates those kinds of applications described by maintaining a sufficient degree of conditional relationships between distributed database fields, while also reaping the efficiency and redundancy benefits.
- The appended claims are to be considered as incorporated into the above description.
- Throughout the specification, including the claims, where the context permits, the term “comprising” and variants thereof such as “comprise” or “comprises” are to be interpreted as including the stated integer or integers without necessarily excluding any other integers.
- It is to be understood that the terminology employed above is for the purposes of description and should not be regarded as limiting. The described embodiments are intended to be illustrative of the invention, without limiting the scope thereof. The invention is capable of being practiced with various modifications and additions as will readily occur to those skilled in the art.
- Various substantially and specifically practical and useful exemplary embodiments of the claimed subject matter, are described herein, textually and/or graphically, including the best mode, if any, known to the inventors for carrying out the claimed subject matter. Variations (e.g., modifications and/or enhancements) of one or more embodiments described herein might become apparent to those of ordinary skill in the art upon reading this application. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the claimed subject matter to be practiced other than as specifically described herein. Accordingly, as permitted by law, the claimed subject matter includes and covers all equivalents of the claimed subject matter and all improvements to the claimed subject matter. Moreover, every combination of the above described elements, activities, and all possible variations thereof are encompassed by the claimed subject matter unless otherwise clearly indicated herein, clearly and specifically disclaimed, or otherwise clearly contradicted by context.
- The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate one or more embodiments and does not pose a limitation on the scope of any claimed subject matter unless otherwise stated. No language in the specification should be construed as indicating any non-claimed subject matter as essential to the practice of the claimed subject matter.
- Thus, regardless of the content of any portion (e.g., title, field, background, summary, description, abstract, drawing figure, etc.) of this application, unless clearly specified to the contrary, such as via explicit definition, assertion, or argument, or clearly contradicted by context, with respect to any claim, whether of this application and/or any claim of any application claiming priority hereto, and whether originally presented or otherwise: there is no requirement for the inclusion of any particular described or illustrated characteristic, function, activity, or element, any particular sequence of activities, or any particular interrelationship of elements; no characteristic, function, activity, or element is “essential”; any elements can be integrated, segregated, and/or duplicated; any activity can be repeated, any activity can be performed by multiple entities, and/or any activity can be performed in multiple jurisdictions; and any activity or element can be specifically excluded, the sequence of activities can vary, and/or the interrelationship of elements can vary.
- The use of the terms “a”, “an”, “said”, “the”, and/or similar referents in the context of describing various embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted.
- Moreover, when any number or range is described herein, unless clearly stated otherwise, that number or range is approximate. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value and each separate subrange defined by such separate values is incorporated into the specification as if it were individually recited herein. For example, if a range of 1 to 10 is described, that range includes all values therebetween, such as for example, 1.1, 2.5, 3.335, 5, 6.179, 8.9999, etc., and includes all subranges therebetween, such as for example, 1 to 3.65, 2.8 to 8.14, 1.93 to 9, etc.
- Words indicating direction or orientation, such as “front”, “rear”, “back”, etc., are used for convenience. The inventor(s) envisages that various embodiments can be used in a non-operative configuration, such as when presented for sale. Thus, such words are to be regarded as illustrative in nature, and not as restrictive.
- Accordingly, every portion (e.g., title, field, background, summary, description, abstract, drawing figure, etc.) of this application, other than the claims themselves, is to be regarded as illustrative in nature, and not as restrictive, and the scope of subject matter protected by any patent that issues based on this application is defined only by the claims of that patent.
Claims (19)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/046,681 US20230078464A1 (en) | 2006-05-18 | 2022-10-14 | Computer-implemented interface for bookings for transportation services |
US18/366,589 US20230376505A1 (en) | 2006-05-18 | 2023-08-07 | Computer-implemented interface for bookings for transportation services |
Applications Claiming Priority (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU2006902685A AU2006902685A0 (en) | 2006-05-18 | The management of inventory in distribution channels | |
AU2006902685 | 2006-05-18 | ||
PCT/AU2007/000684 WO2007134379A1 (en) | 2006-05-18 | 2007-05-18 | The management of inventory allocations |
US22745109A | 2009-12-18 | 2009-12-18 | |
US14/877,669 US10198494B2 (en) | 2006-05-18 | 2015-10-07 | Control of distributed databases |
US16/150,799 US10740354B2 (en) | 2006-05-18 | 2018-10-03 | Computer-implemented method for managing inventory allocations |
US16/924,395 US11360999B2 (en) | 2006-05-18 | 2020-07-09 | Computer-implemented method for managing inventory allocations |
US17/749,091 US11475047B2 (en) | 2006-05-18 | 2022-05-19 | Computer-implemented interface for bookings for transportation services |
US18/046,681 US20230078464A1 (en) | 2006-05-18 | 2022-10-14 | Computer-implemented interface for bookings for transportation services |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/749,091 Continuation US11475047B2 (en) | 2006-05-18 | 2022-05-19 | Computer-implemented interface for bookings for transportation services |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US18/366,589 Continuation US20230376505A1 (en) | 2006-05-18 | 2023-08-07 | Computer-implemented interface for bookings for transportation services |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230078464A1 true US20230078464A1 (en) | 2023-03-16 |
Family
ID=55166899
Family Applications (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/877,669 Active 2029-02-23 US10198494B2 (en) | 2006-05-18 | 2015-10-07 | Control of distributed databases |
US16/150,799 Active 2027-07-13 US10740354B2 (en) | 2006-05-18 | 2018-10-03 | Computer-implemented method for managing inventory allocations |
US16/924,395 Active US11360999B2 (en) | 2006-05-18 | 2020-07-09 | Computer-implemented method for managing inventory allocations |
US17/542,933 Active US11334598B2 (en) | 2006-05-18 | 2021-12-06 | Computer-implemented management of bookings for transportation services |
US17/749,091 Active US11475047B2 (en) | 2006-05-18 | 2022-05-19 | Computer-implemented interface for bookings for transportation services |
US18/046,681 Abandoned US20230078464A1 (en) | 2006-05-18 | 2022-10-14 | Computer-implemented interface for bookings for transportation services |
US18/366,589 Pending US20230376505A1 (en) | 2006-05-18 | 2023-08-07 | Computer-implemented interface for bookings for transportation services |
Family Applications Before (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/877,669 Active 2029-02-23 US10198494B2 (en) | 2006-05-18 | 2015-10-07 | Control of distributed databases |
US16/150,799 Active 2027-07-13 US10740354B2 (en) | 2006-05-18 | 2018-10-03 | Computer-implemented method for managing inventory allocations |
US16/924,395 Active US11360999B2 (en) | 2006-05-18 | 2020-07-09 | Computer-implemented method for managing inventory allocations |
US17/542,933 Active US11334598B2 (en) | 2006-05-18 | 2021-12-06 | Computer-implemented management of bookings for transportation services |
US17/749,091 Active US11475047B2 (en) | 2006-05-18 | 2022-05-19 | Computer-implemented interface for bookings for transportation services |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US18/366,589 Pending US20230376505A1 (en) | 2006-05-18 | 2023-08-07 | Computer-implemented interface for bookings for transportation services |
Country Status (1)
Country | Link |
---|---|
US (7) | US10198494B2 (en) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10198494B2 (en) * | 2006-05-18 | 2019-02-05 | Allotz.Com Limited | Control of distributed databases |
US8732150B2 (en) | 2010-09-23 | 2014-05-20 | Salesforce.Com, Inc. | Methods and apparatus for suppressing network feed activities using an information feed in an on-demand database service environment |
US10430765B2 (en) | 2015-09-11 | 2019-10-01 | Salesforce.Com, Inc. | Processing keyboard input to perform events in relation to calendar items using a web browser-based application or online service |
US10572031B2 (en) | 2016-09-28 | 2020-02-25 | Salesforce.Com, Inc. | Processing keyboard input to cause re-sizing of items in a user interface of a web browser-based application |
US10796266B2 (en) * | 2018-05-08 | 2020-10-06 | The Boeing Company | Automated context driven build plan lifecycle |
Family Cites Families (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6188989B1 (en) | 1995-06-16 | 2001-02-13 | I2 Technologies, Inc. | System and method for managing available to promised product (ATP) |
US5787415A (en) * | 1996-10-30 | 1998-07-28 | International Business Machines Corporation | Low maintenance data delivery and refresh system for decision support system database |
US20030033205A1 (en) | 2000-01-10 | 2003-02-13 | D.K. Nowers | Method and system for facilitating fulfillment of electronic commercial transactions |
WO2001067356A1 (en) | 2000-03-07 | 2001-09-13 | Invinity Systems Corporation | Inventory control system and methods |
US6996538B2 (en) | 2000-03-07 | 2006-02-07 | Unisone Corporation | Inventory control system and methods |
AU2001257154A1 (en) | 2000-04-21 | 2001-11-07 | Leon R. Casaubon | System and method of supply chain management |
AU2001261127A1 (en) | 2000-05-02 | 2001-11-12 | Assettrade | Internet-based systems and methods for reallocating and selling used industrial equipment and machinery |
US10235368B2 (en) * | 2000-06-08 | 2019-03-19 | International Business Machines Corporation | System and method for updating external file referenced by database with transactional consistency using SQL |
JP2001350826A (en) | 2000-06-09 | 2001-12-21 | Nec Corp | Device for calculating reasonable inventory quantity |
US8473380B2 (en) | 2000-11-06 | 2013-06-25 | Propulsion Remote Holdings, Llc | Pay yourself first budgeting |
US7398225B2 (en) | 2001-03-29 | 2008-07-08 | American Express Travel Related Services Company, Inc. | System and method for networked loyalty program |
US20020143587A1 (en) | 2001-04-02 | 2002-10-03 | Microsoft Corporation | Optimized system and method for finding best fares |
US7870012B2 (en) | 2001-05-15 | 2011-01-11 | Agile Software Corporation | Method for managing a workflow process that assists users in procurement, sourcing, and decision-support for strategic sourcing |
US20030033179A1 (en) | 2001-08-09 | 2003-02-13 | Katz Steven Bruce | Method for generating customized alerts related to the procurement, sourcing, strategic sourcing and/or sale of one or more items by an enterprise |
US7707075B2 (en) | 2001-08-17 | 2010-04-27 | Expedia, Inc. | System and method for managing inventory |
US7783506B2 (en) | 2001-08-17 | 2010-08-24 | Expedia, Inc. | System and method for managing reservation requests for one or more inventory items |
US7499864B2 (en) | 2002-01-25 | 2009-03-03 | American Express Travel Related Services Company, Inc. | Integrated travel industry system |
US20040260581A1 (en) | 2001-08-23 | 2004-12-23 | American Express Travel Related Services Company, Inc. | Travel market broker system |
US20030088616A1 (en) | 2001-11-02 | 2003-05-08 | Qualte, Inc. | System and method for customer service application customization, integration, and distribution |
CA2364121A1 (en) | 2001-11-30 | 2003-05-30 | Ibm Canada Limited-Ibm Canada Limitee | Allocating inventory based on allocation priorities |
EP1459152A4 (en) | 2001-11-30 | 2006-02-08 | Demandtec Inc | Rule relaxation and subset optimization system |
US20030139949A1 (en) | 2002-01-18 | 2003-07-24 | Jafri Vajid Husain | Method, system and apparatus for managing multiple channels of travel services |
WO2003079153A2 (en) | 2002-03-11 | 2003-09-25 | United Parcel Service Of America, Inc. | Inventory management system for reducing overall warehouse and pipeline inventory |
US7734495B2 (en) | 2002-04-23 | 2010-06-08 | Kimberly-Clark Worldwide, Inc. | Methods and system for allocating shelf space |
JP2003323479A (en) | 2002-05-02 | 2003-11-14 | World:Kk | System, apparatus and method for distribution process |
WO2004027582A2 (en) | 2002-09-18 | 2004-04-01 | Mitsui Bussan Logistics, Inc. | System and method for distribution chain management |
US20040153359A1 (en) | 2003-01-31 | 2004-08-05 | Mein-Kai Ho | Integrated supply chain management |
US20040167809A1 (en) | 2003-02-21 | 2004-08-26 | Jafri Vajid Husain | Management of multiple channels of travel services display on a dual screen monitor |
US20040193457A1 (en) | 2003-03-28 | 2004-09-30 | Sapient Corporation | Travel cost management system |
EP1636670A4 (en) | 2003-06-04 | 2008-04-16 | Profitlogic Inc | Methods and apparatus for retail inventory budget optimization and gross profit maximization |
US20050004818A1 (en) | 2003-07-03 | 2005-01-06 | Hartono Liman | System and method for effective distribution of travel inventory allotments |
EP1652141A4 (en) | 2003-07-15 | 2008-03-12 | Profitlogic Inc | Methods and apparatus for inventory allocation and pricing |
US8355944B2 (en) | 2003-09-04 | 2013-01-15 | Webconcepts, Inc. | Methods and systems for collaborative demand planning and replenishment |
US7761305B2 (en) | 2003-10-16 | 2010-07-20 | Mack Leslie J | System and method of providing current hotel daily rate and availability information and the like |
US7778878B2 (en) | 2003-12-31 | 2010-08-17 | Amazon Technologies, Inc. | Profiling item sellers to inform item purchasing decisions and build trust in a multiple-seller marketplace |
US7537153B2 (en) | 2004-05-03 | 2009-05-26 | De La Rue International, Limited | Method and computer program product for electronically managing payment media |
US7275131B2 (en) * | 2004-12-22 | 2007-09-25 | International Business Machines Corporation | Cache refresh algorithm and method |
US20060200370A1 (en) | 2005-03-04 | 2006-09-07 | Sabre, Inc. | Availability-based pricing for multi-channel distribution |
US7912748B1 (en) | 2005-06-01 | 2011-03-22 | Sap Ag | Method and system for determining price markdown schedule |
EP1920393A2 (en) * | 2005-07-22 | 2008-05-14 | Yogesh Chunilal Rathod | Universal knowledge management and desktop search system |
US7379781B2 (en) | 2005-08-30 | 2008-05-27 | Logitech Europe S.A. | Constraint based order optimization system and available to promise system |
US20070143155A1 (en) | 2005-12-21 | 2007-06-21 | Travelocity.Com Lp. | System, method, and computer program product for reducing the burden on an inventory system by assembling a suggested themed travel itinerary in response to minimal user input |
US7778882B2 (en) | 2006-03-03 | 2010-08-17 | Mukesh Chatter | Method, system and apparatus for automatic real-time iterative commercial transactions over the internet in a multiple-buyer, multiple-seller marketplace, optimizing both buyer and seller needs based upon the dynamics of market conditions |
US10198494B2 (en) * | 2006-05-18 | 2019-02-05 | Allotz.Com Limited | Control of distributed databases |
WO2007134379A1 (en) * | 2006-05-18 | 2007-11-29 | Allotz.Com Limited | The management of inventory allocations |
JP4380692B2 (en) * | 2006-12-07 | 2009-12-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Apparatus, method, and program for refreshing summary table |
US8214238B1 (en) * | 2009-04-21 | 2012-07-03 | Accenture Global Services Limited | Consumer goods and services high performance capability assessment |
US9430541B1 (en) * | 2009-04-29 | 2016-08-30 | Netapp, Inc. | Data updates in distributed system with data coherency |
US8600944B2 (en) * | 2010-09-24 | 2013-12-03 | Hitachi Data Systems Corporation | System and method for managing integrity in a distributed database |
US9313533B2 (en) * | 2012-09-19 | 2016-04-12 | Hulu, LLC | Ad inventory management system |
US9280591B1 (en) * | 2013-09-20 | 2016-03-08 | Amazon Technologies, Inc. | Efficient replication of system transactions for read-only nodes of a distributed database |
-
2015
- 2015-10-07 US US14/877,669 patent/US10198494B2/en active Active
-
2018
- 2018-10-03 US US16/150,799 patent/US10740354B2/en active Active
-
2020
- 2020-07-09 US US16/924,395 patent/US11360999B2/en active Active
-
2021
- 2021-12-06 US US17/542,933 patent/US11334598B2/en active Active
-
2022
- 2022-05-19 US US17/749,091 patent/US11475047B2/en active Active
- 2022-10-14 US US18/046,681 patent/US20230078464A1/en not_active Abandoned
-
2023
- 2023-08-07 US US18/366,589 patent/US20230376505A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US11334598B2 (en) | 2022-05-17 |
US20160026671A1 (en) | 2016-01-28 |
US20190034508A1 (en) | 2019-01-31 |
US11360999B2 (en) | 2022-06-14 |
US20220092084A1 (en) | 2022-03-24 |
US20200342004A1 (en) | 2020-10-29 |
US20230376505A1 (en) | 2023-11-23 |
US10740354B2 (en) | 2020-08-11 |
US20220284041A1 (en) | 2022-09-08 |
US10198494B2 (en) | 2019-02-05 |
US11475047B2 (en) | 2022-10-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20230078464A1 (en) | Computer-implemented interface for bookings for transportation services | |
JP7253041B2 (en) | A method for managing a transportation service provider, a computer program containing instructions for performing the method, a non-temporary storage medium storing instructions for performing the method, and an apparatus for managing a transportation service provider | |
Li et al. | Comparative analysis on value of information sharing in supply chains | |
US20200356933A1 (en) | System and Method for Allocating Manufactured Products to Sellers Using Profitable Order Promising | |
US20020099596A1 (en) | Dynamic ratemaking for insurance | |
CN108985691A (en) | A kind of automatic replenishing method and system based on dynamic stock control | |
CN106020966A (en) | Systems and methods for intelligently distributing tasks received from clients among a plurality of worker resources | |
US20140067435A1 (en) | Revenue driven splitting of group travel requests into multiple subgroups | |
US20150095091A1 (en) | Customer-Prioritized Inventory Allocation for Supply Chain | |
CN108090225A (en) | Operation method, device, system and the computer readable storage medium of database instance | |
US20140136247A1 (en) | Use of group materialization rate to release inventory space | |
US7962351B2 (en) | Systems and methods for determining cost of insurance rates | |
CN110097455A (en) | Bank client Optimal Configuration Method and device | |
Albrecht | Optimization of safety stocks in models with an order service level objective or constraint | |
Protopappa-Sieke et al. | Optimal two-period inventory allocation under multiple service level contracts | |
AU2007252290B2 (en) | The management of inventory allocations | |
US7580766B1 (en) | Manufacturing resource planning by entity | |
US20130246306A1 (en) | Active share portfolio monitoring, calibration, management, and fee calculation tool | |
US8417624B2 (en) | System and process for protected retirement asset management | |
KR102482757B1 (en) | System for managing a sales framework | |
CN114240201A (en) | Wisdom data middling station based on supply chain background | |
Manshadi et al. | Redesigning VolunteerMatch's Ranking Algorithm: Toward More Equitable Access to Volunteers | |
Pal et al. | The cloudlet bazaar dynamic markets for the small cloud | |
Zhou et al. | Replenishment and transshipment in periodic-review systems with a fixed order cost | |
Ivanov et al. | Simulation Applications to Structural Dynamics in Service and Manufacturing Supply Chain Risk Management |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SOUTHBANK CAPITAL PTY LTD, AUSTRALIA Free format text: SECURITY INTEREST;ASSIGNOR:ALLOTZ.COM LIMITED;REEL/FRAME:061684/0154 Effective date: 20200429 Owner name: ALLOTZ.COM LIMITED, AUSTRALIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LOCH, ANDREW;JOHNSON, HELEN;TOOGOOD, GEOFFREY;AND OTHERS;SIGNING DATES FROM 20090610 TO 20090818;REEL/FRAME:061431/0557 Owner name: ALLOTZ.COM LIMITED, AUSTRALIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RUUL, DANIEL PAUL;REEL/FRAME:061431/0524 Effective date: 20060509 Owner name: SURGE PRICING PATENT HOLDINGS, LLC, DELAWARE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SOUTHBANK CAPITAL PTY LTD;REEL/FRAME:061431/0623 Effective date: 20211022 Owner name: SOUTHBANK CAPITAL PTY LTD, AUSTRALIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALLOTZ.COM LIMITED VIA RECEIVER JAMES PATRICK DOWNEY;REEL/FRAME:061431/0611 Effective date: 20210821 Owner name: PENINSULA ACCUMULATOR TRUST, DELAWARE Free format text: SECURITY INTEREST;ASSIGNOR:SURGE PRICING PATENT HOLDINGS, LLC;REEL/FRAME:061684/0939 Effective date: 20220203 Owner name: SURGETECH, LLC, TEXAS Free format text: CHANGE OF NAME;ASSIGNOR:SURGE PRICING PATENT HOLDINGS, LLC;REEL/FRAME:061684/0936 Effective date: 20220301 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: ROWLEY, MARTIN NEVIL, PORTUGAL Free format text: SECURITY INTEREST;ASSIGNOR:SURGETECH, LLC;REEL/FRAME:064706/0290 Effective date: 20230825 Owner name: SURGETECH, LLC, TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:PENINSULA ACCUMULATOR TRUST;REEL/FRAME:064710/0168 Effective date: 20230825 |
|
AS | Assignment |
Owner name: SURGETECH M LLC, PORTUGAL Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SURGETECH, LLC;REEL/FRAME:066599/0687 Effective date: 20240227 |