WO2024102350A1

WO2024102350A1 - Improved resource supply system, method, and techniques

Info

Publication number: WO2024102350A1
Application number: PCT/US2023/036911
Authority: WO
Inventors: Thomas Michael DERBY; Owen Douglas FOWLER
Original assignee: Plentiful Stays, Inc.
Priority date: 2022-11-07
Filing date: 2023-11-07
Publication date: 2024-05-16

Abstract

Methods, systems, and techniques for handling resource inventory, supply and resupply of a resource that is reused and degrades over time or that is used once and no longer useful over time are provided. Example embodiments provide an Improved Resource Allocation and Supply System which enables users, such as inventory suppliers that provide a degradable (or use-once) resource to end consumers, to obtain, track, and replenish those resources using an "at-optimal-time" model that provides sufficient inventory based upon using a probabilistic model that provides sufficient inventory based upon modeled use and risk-tolerance of depleting inventory to zero, taking into account a variety of factors. Example embodiments also provide a Resource Modeling Framework that enables modeling of inventory usage, communication between different types of entities, and event modeling. In one example embodiment, an improved inventory and supply system for vacation rental properties is provided.

Description

IMPROVED RESOURCE SUPPLY SYSTEM, METHOD, AND TECHNIQUES TECHNICAL FIELD [0001] The present disclosure relates to methods, techniques, and systems for supply of resources and, in particular, to methods, techniques, and systems for a dynamic supply of resources based upon mathematical modeling and an at-optimal- time inventory approach. BACKGROUND [0002] Airbnb and VRBO have over nine million and growing listings combined for short-term rentals (as of 2022). Each of those listings needs hundreds of individual items for sleeping, bathing, dining, and kitchen. [0003] Unlike hotels, vacation rental owners don’t have access to voluminous supply closets with seemingly endless inventory of matched commercial linens and other hospitality items. Instead, they have limited storage space and rely on online retailers like Amazon or Wayfair or brick and mortar retailers like Costco and Target both for initial supply and replacements over time. There are long-term questions about the best way to supply a vacation rental that owners may or may not know to consider. For example, do they load up on towel set inventory in case the towel set they choose becomes unavailable at a future point in time? [0004] Consider an owner that has bought the 300 plus items needs to stock a sleeps-8 whole home rental and begins accepting bookings. When guests arrive usage of those items begins, but not in easily predictable ways where low effort in resupply can garner good results. For example, sometimes the rental will serve 2 adult guests, and sometimes 4 adults and 3 children; where those guests choose to sleep, determines wear. Some months the rental will be heavily booked and others not; that also determines wear. [0005] After a while, perhaps the owner notices while doing laundry that three hand- towels have become worn enough to require replacements, but the retailer is out of 25 1 CUSTOM3ER1 NUM5BER 11-1001AP the right color of bath linen sets. Besides, the owner doesn’t need whole new sets but only a few hand towels. The owner in this case is left with compromise choices, like replacing the just the damaged hand towels with others that don’t quite match, or replacing all the bath linens with new sets so everything matches. [0006] Also note that the supplier of the towels missed out on a sale because they ran out of stock in a particular color that the buyer needed. If they had been able to set their inventory levels better, they could have achieved more sales. Of course, they could err in the other direction too by overstocking, and therefore make the sale but incur unnecessary warehouse costs and have more than necessary cash tied up in inventory. [0007] Returning to the vacation rental owner: the three hand towels worn out should also have been taken as an indicator that other items too might need replacement. For example, there is also a stock of 29 washcloths: how many of those need replacing given that three hand towels were worn out? To keep up on all of the tracking tasks takes a lot of effort. [0008] Continuing with the example, the owner has decided on a plan for the bed sheets: replace them all after eighteen months, to keep things fresh. When the time comes to replace the sheets though the owner finds several issues: ^ The King sheets are more worn than the Queen sheets, which are more worn than the Full sheets. In fact, the full sheets are only for the futon, and may not have been used at all. ^ The bottom sheets on average seem to wear much more quickly than the top sheets, and some of the bottom King sheets are so worn the owner is embarrassed that they weren’t replaced sooner. The owner has a choice at this point: stick to the original plan and overspend, replacing all sheets for simplicity, or spend extra time and effort to figure out exactly what to replace. If the owner had bought extra sets early, this could be easier, but that would have consumed storage space and tied-up cash. 2 2 CUST5OM3ER1 NUM5BER 11-1001AP [0009] The burden of tracking all the items and orchestrating replacements takes significant owner effort. Somewhat automated solutions do exist such as Amazon Subscribe and Save and the Vacasa linens program. [0010] Amazon Subscribe and Save is a system by which consumers can purchase items through amazon.com in a subscription-like manner, where items are shipped every set period of time (frequency) at a set quantity (amplitude). Both the frequency and amplitude can be set by the buyer at start and changed by the buyer as needed, but there is no automatic adjustment of either: the buyer must actuate the changes. Subscribe and Save is the Amazon equivalent of our example owner’s plan to replace sheets after a set period of time, and it suffers from exactly the same issues. [0011] Vacasa, a vacation rental management company with over 40,000 vacation rental properties under management, has an optional program for clients called the Vacasa Linens Program that replaces all the sheets and towels after one year of renting. Again, this is the same as our example owner’s plan to replace sheets at a set interval, and is subject to the same issues. In the Vacasa system, a rental that is booked with ten times the guests of another rental will be on the same resupply schedule, as will each sheet regardless if it was on the heavily used king-size bed or the sparsely used full-size futon. [0012] It is possible to extend all of these problematic realities of supply into industries other than vacation rentals. For example, small boutique hotels are very similar in supply needs and therefore in supply problems. Stated in general, all supply systems that have products that are used at varying rates depending on real- world circumstances and events will suffer the same problems. [0013] Buyers of all sorts, including vacation rental owners, have different strategies available to mitigate these supply difficulties. A buyer of inventories that deplete over time might choose to keep a small inventory. This strategy brings the following advantages: less storage space is used, manually tracking the items is less prone to error and is easier to audit, and less cash is tied up. 25315 3 CUSTOMER NUMBER 11-1001AP [0014] But these benefits are countered by problems. A closer look at the cash advantage shows it isn’t as optimal as at first sight. The inventory was paid for ahead of usage, and therefore the full cost of the inventory is completely tied up before the first item is even put into use. Financing as a solution to cash issues has problems too, because in a lean month or a flush month, the same amount will be due. [0015] Other problems with the small inventory approach are that shortages are more likely. This is especially true for smaller operations. A rental with an inventory of 10 washcloths where 3 are damaged has a bigger problem than a larger rental that has 30 washcloths with 3 damaged. [0016] Another implication of smaller inventories is higher shipping costs as more frequent deliveries will need to be made for replacements. And because more deliveries are made the buyer also must put more time and effort into receiving items and putting them into use. [0017] Larger inventories mitigate the risk problems of running out of items and provide a buffer. Shipping costs are also reduced if all the items are eventually used. But larger inventories require bigger cash outlays, more storage space, and have overstock risk (maybe some portion will never be used). [0018] If the choice of a smaller inventory and the resulting negative trade-offs are accepted by a buyer, then it would be reasonable to think that what is needed is some sort of “just-in-time” resupply system, so that when the buyer notices (if the buyer notices) that an item needs to be replaced it can be done so very quickly. But this approach also has problems. When there is a simultaneous failure of many items just after a “just-in-time” delivery there could be dire short-term consequences. A “just-in-time” system would have to be perfect and instant to hedge against future risk, and is very sensitive to supply-chain disruptions. Another implication of “just-in- time” systems is frequent shipments and the associated costs. [0019] The seller supplying the buyer has similar problems, because the seller is also a buyer that uses items by shipping them. Consider a warehouse supplying vacation rentals. Even though, for example, towels are not used at the warehouse 25315 4 CUSTOMER NUMBER 11-1001AP in a traditional sense to dry things, they are used in that they are shipped and gone. In this way, keeping the warehouse “well-supplied” with towels is a different version of keeping a vacation rental “well-supplied” with towels, with similar drawbacks to small or large inventories. [0020] The supplier has some risk of running out of supply (remember the missed sale of bath linens in the above example), and fixing this by holding larger inventories has the drawbacks of large inventories. The supplier may also not actually know how many towels they have. This is evidenced by the fact that all inventory systems have some way of auditing inventory and altering levels. The less that is known about how many items there are actually in stock, the more the supplier is in danger of either over-supply or under-supply. [0021] The HP Instant Ink printer ink replenishment program is a contrast to systems such as Subscribe and Save that gets closer to solving some of these issues. Certain model HP ink-jet printers monitor ink use directly using electronic sensing equipment, which then charges the customer based on somewhat complex plans that allow for a certain number of pages to be printed. In other words, HP doesn’t charge for the use of the item, ink, but rather based on a correlated item, pages printed. The correlated item in this case can vary in quantity quite a lot compared to the item being resupplied, because ink used in printing text versus pictures is radically different. The HP system also requires electronic sensors for it to work. BRIEF DESCRIPTION OF THE DRAWINGS [0022] Figure 1 illustrates the advantages of an example PlentiModel deployment of the Gamma Framework for various example parties involved in the vacation rental industry. [0023] Figure 2 is an example block diagram of example entities and example connections called glinks between entities that collectively form the Gammaverse. [0024] Figure 3 is an example block diagram of an example glink connection. 2 5 CUST5OM3ER1 NUM5BER 11-1001AP [0025] Figure 4 is an example block diagram of an example simple scaled deployment of PlentiModel. [0026] Figure 5 is an example block diagram of an example simple deployment of PlentiModel on a single computer using an Excel document called Repository for data storage and user input. [0027] Figure 6 is an example flowchart roughly illustrating how PlentiModel makes a decision to send some number T new towels to a VRP (vacation rental property). [0028] Figure 7 is an example flowchart roughly illustrating how PlentiModel makes the decision to issue a purchase order for some number T new towels to a SUP (supplier). [0029] Figure 8 is an example bar chart of an example cascade ALS (available lifetime set). [0030] Figure 9 is an example block diagram of an example computing system that may be used to practice embodiments of the described herein. DETAILED DESCRIPTION [0031] Embodiments described herein provide enhanced computer- and network- based methods, techniques, and systems for handling resource inventory, supply and resupply, when the supply and/or inventory is associated with a “wear” component (e.g., when usage occurs more than once and degrades over time) and where tracking and estimating inventory is uncertain (e.g., tracking inventory uses a probabilistic distribution rather than a specific number). Example embodiments provide an Improved Resource Allocation and Supply System (“IRASS”) and associated Improved Resource Modeling Framework (“IRMF”). An example IRASS enables users, such as inventory suppliers that provide a degradable resource to end consumers, to obtain, track, and replenish those resources using an “at-optimal- time” model that provides sufficient inventory based upon modeled use taking into account a variety of factors. Such factors may include lifetime wear modeling, expected use of the resource, risk-tolerance of depleting inventory to zero and the 25 6 CUSTOM3ER1 NUM5BER 11-1001AP like. An example IRASS also enables users, such as warehouses, to implement a complete probabilistic inventory tracking system and system for replenishing warehouse inventory based on risk-tolerance of depleting inventory to low levels. An example IRMF provides a modeling framework that can be used to implement one or more IRASS embodiments, forecast resource usage and supply needs, model relationships between suppliers-consumers. It also provides an improved event driven processing system and framework that can provide synchronous or asynchronous event processing, is extensible to provide new events, entities, etc., and support for speculative events and probabilistic inventories. An example IRMF models relationships between entities and allows for controlled interactions between them by means of links which are associated with a set of rules that define the interactions and protocol between the entities so linked. It also provides the ability to execute a model of such relationships to produce predictions and guide business operations. [0032] The techniques of an IRASS and IRMF are generally applicable to any type of resource, Also, although the examples described herein often refer to a vacation rental property and the resources such as towels, linens, dishes, etc., the techniques described herein can also be used by any system that inventories some kind of resource. Also, although certain terms are used primarily herein, other terms could be used interchangeably to yield equivalent embodiments and examples. In addition, terms may have alternate spellings which may or may not be explicitly mentioned, and all such variations of terms are intended to be included. [0033] Example embodiments described herein provide applications, tools, data structures and other support to implement an Improved Resource Allocation and Supply System and Resource Modeling Framework. Other embodiments of the described techniques may be used with other resources and for other purposes, including, but not limited to: the supply of hotels, cruise ships, and other hospitality endeavors; the supply of primary households for both continuous-wear items like mattresses and towels, to single-use items like paper towels and dishwasher pods; 253R1 7 CUSTOME NUM5BER 11-1001AP the supply of running shoes and assorted exercise gear to individual consumers; and the corresponding supply of goods to warehouses that store the goods for the aforementioned supply purposes. It also may be used for supply of other resources such as that are used up (wear) over time, including mechanical components. In the following description, numerous specific details are set forth, such as data formats and code sequences, etc., in order to provide a thorough understanding of the described techniques. The embodiments described also can be practiced without some of the specific details described herein, or with other specific details, such as changes with respect to the ordering of the logic, different logic, etc. Thus, the scope of the techniques and/or functions described are not limited by the particular order, selection, or decomposition of aspects described with reference to any particular routine, module, component, and the like. EXAMPLE IMPROVED RESOURCE ALLOCATION AND SUPPLY SYSTEM AND FRAMEWORK [0034] PlentiModel is a software-controlled improved supply system for vacation rental properties (VRPs), where initial supply is followed by on-going resupply scheduled through computer modeling. Financial transactions, such as payments for supplies, are tightly coupled with the resupply rate to effectuate a “pay-for-as- used” model. This also allows for “at-optimal-time” supply which is more efficient both financially and resource consumption-wise than either hedging against inventory shortages through maintaining large inventories, or shipping “just-in-time” as items are needed. It provides a better than “just-in-time” system because while those systems mitigate the costs of small scale associated with smaller inventories, they can create inefficiencies in logistics and operations with too frequent resupplies. [0035] PlentiModel also inspired a larger resource transaction solution called the Gamma Framework. [0036] Specifically, PlentiModel was formed with many requirements in mind that pushed it toward generality and abstraction from the start. Some of those were: to U 2ST5 8 C OM3ER1 NUM5BER 11-1001AP supply and resupply a wide variety of items that differed substantially (from juice glasses to mattresses); to integrate financial considerations such as costs and profits; to be able to handle diverse data sources to drive its computations; and to balance the objectives of various parties within the vacation rental industry, such as VRP owners, professional VRP managers, VRP guests, VRP housecleaners, and suppliers to the industry. [0037] As the PlentiModel system grew, particularly when it started estimating warehouse inventory levels and assisting with warehouse resupply decisions, it became clear that substantial parallels existed between managing supply inventories at a VRP and managing supply inventories at a warehouse that supplied those VRPs. That parallel, along with the aforementioned embracing of generality and abstraction from the start, inspired a very broad generalization of PlentiModel which was eventually called The Gamma Framework. [0038] The Gamma Framework (referred to as Gamma for brevity) is a modeling framework for integrating the supply chains of an arbitrary number of businesses in a seamless, scalable modeling system. The framework includes methods and systems for: modeling inventory needs; tracking inventory that has a wear aspect (items that are used more than once and degrade over time and use); tracking inventory that has an uncertainty aspect (uses a probabilistic distribution for expected inventory levels rather than a specific number); speculative predictions of future inventory status based on expected future events; grouping of shipments to increase efficiency in logistics for “at-optimal-time” inventory; and integration of a variety of payment schemes, most notably “pay-for-as-used”. [0039] The description that follows of this example resource allocation and supply system and framework is divided into 4 main sections: ^ Overview of PlentiModel ^ Overview of the Gamma Framework ^ The Gamma Framework in Detail ^ PlentiModel in Detail 9 CU 2ST5OM3ER1 NUM5BER 11-1001AP A. Overview of PlentiModel [0040] Plentiful Stays, the company that developed both PlentiModel and Gamma, operates a business which focuses on the supply of degradable products to the vacation rental industry. Degradable products are products which suffer from ordinary wear from the passage of time and use by guests at the vacation rental property (VRP), and therefore need to be replaced on an on-going basis. Sheets are considered degradable products, as where furniture is not, because of the much slower rate that furniture degrades at. When a product degrades, the result of that degradation is called wear. [0041] Each individual property may contain hundreds of individual items that need to be replaced over usage by time and usage by guest. Guest usage per item can be estimated from the available booking data for the property. PlentiModel connects usage estimated by data and with customer payments, for a “pay-for-as-used” and “at-optimal-time” system. This system requires hundreds of calculations to determine the bill for each property, as each item at the VRP generates its own series of charges based on estimated usages. This system is also adaptable to other forms of “quid pro quo” other than money, such as exchanges of data, crypto- currency, or rewards points. [0042] Table 2 shows the actual charges generated by PlentiModel for a VRP called “La Chouette” for one month’s usages of degradable products. VRP Item Number Total f it Ch e 8

2T5OM3 10 CUS ER1 NUM5BER 11-1001AP La Chouette Top Cover (Twin) 3 $1.76 La Chouette Comforter (Heavy, Twin) 3 $1.29

[0043] At its core, PlentiModel uses known information about activity at the VRP (based on booking data) to estimate wear as a consequence of usage on each item in the VRP, and thus tracks the estimated condition of all items at the property at all times. This inventory status information can then be used to schedule shipments of replacements items from a warehouse to the VRP, ensuring it is “Well-Supplied, All the Time.” In addition, the system can perform speculative computations and project future needs and therefore group or organize shipments to improve logistics efficiencies. Taking in account projected needs so that inventory requirements can be balanced with logistics efficiency means that shipments can be made “at-optimal- time” rather than “just-in-time”. Logistics efficiencies may be measured by a variety of factors or variables, such as, but not limited to: supplier pick-and-pack times, which can be reduced by aggregating shipments; receiver unpack and put-in-service times, which can be also be reduced with fewer shipments; warehouse storage 253R1 11 CUSTOME NUM5BER 11-1001AP space, which can be reduced with more frequent shipments; inventory accuracy, which can be mitigated through a probabilistic understanding of inventory levels (see D.11. Modeling Single-Use Items); transportation costs, which can be reduced with less frequent shipments. Because certain efficiencies can be reached by reducing shipments, while others by increasing them, being able to aggregate shipments across time so that frequency and amplitude (size of) shipments can be set is key to optimizing the system over multiple variables (see D.15. The PlentiModel Shipping Algorithm). [0044] Because PlentiModel is also able to perform speculative computations of (see D.4. f. Speculative Modeling) potential future events, PlentiModel can be used for a wide variety of business-related tasks for Plentiful Stays, including business planning and growth forecasting. For example, Plentiful Stays created a group of twelve fictional, diverse VRPs, along with fictional booking data for each. PlentiModel was used to forecast supplies quantities, costs, and revenues over a ten-year period, which formed the backbone of Plentiful Stays long-term financial projections. [0045] As managing inventory levels at the Plentiful Stays warehouse became more burdensome, initial support was added to PlentiModel to assist in tracking item levels within the warehouse. This was a natural extension as PlentiModel already knows all items leaving the warehouse, so all that was necessary was to add support for incoming shipments to form a complete warehouse inventory tracking system. [0046] Support was then added to PlentiModel to automatically suggest resupply orders for warehouse items, such as sheets. Rather than keeping a large inventory, like typical businesses do, PlentiModel instead focuses on predicting usage, and ensuring that inventory levels are sufficient to meet current and immediate future needs. This reduced the need for carrying large inventories, which can be a challenge for a cash-limited startup. [0047] Figure 1 illustrates the advantages of an example PlentiModel deployment of the Gamma Framework for various example parties involved in the vacation rental 25315 12 CUSTOMER NUMBER 11-1001AP industry. The vertical axis 101 indicates the quality of the supply solution chosen by the vacation rental property owner or manager over time, while the horizontal axis 1-2 indicates the efficiency of use of owner resources such as cash, space, time, and effort. A PlentiModel aided vacation rental property can attain relatively high placement on both axes due to a stack of technology, which is indicated in the stacked rectangles 103. This benefits the VRP, the VRP owner, the HUB (warehouse) and guests. B. Overview of The Gamma Framework [0048] As mentioned above, the Gamma Framework (sometimes referred to as Gamma for brevity) is a modeling framework for integrating the supply chains of an arbitrary number of businesses in a seamless, scalable modeling system. The framework includes methods and systems for: modeling inventory needs; tracking inventory that has a wear aspect (items that are used more than once and degrade over time and use); tracking inventory that has an uncertainty aspect (uses a probabilistic distribution for expected inventory levels rather than a specific number); speculative predictions of future inventory status based on expected future events; grouping of shipments to increase efficiency in logistics for “at-optimal-time” inventory; and integration of a variety of payment schemes, most notably “pay-for- as-used”. [0049] More generally, Gamma is an abstract framework for modelling complex interoperating business processes. Gamma can be thought of as a graph in which the vertices represent semi-autonomous entities containing resources, and in which the edges between entities represent relationships (called glinks, or g-links). [0050] Gamma is agnostic about what an entity might represent as well as what constitutes resources. For example, the entity could be a consulting company, that has resources of people hours available for a project. The hours might be represented as probabilities rather than ordinary numerical quantities. 2 13 CUST5OM3ER1 NUM5BER 11-1001AP [0051] This entity flexibility is important, as it enables communication and collaboration between entities with minimal requirements of similarity. For example, even in the constrained environment of PlentiModel, entities have radically different internal representations of resources that indicate the same products in the real word. For example, the VRP entities use a method of representing inventory levels of things like towels that is entirely and necessarily complex, and very different from the inventory representation of towels stored by the warehouse entities (see D. PlentiModel in Detail section). Despite these radically different representations of resources, these two entity types communicate about resource transfers frequently. G-connections allow that to occur. [0052] In the small example of the VRP supply industry, PlentiModel’s treatment of resources in tailored ways per entity type is largely responsible for being able to plan resource transfers and implement for customers and suppliers a “pay-for-as-used”, “Well-Supplied, All the Time” system that accounts for projected needs enabling “at- optimal-time” supplies deliveries. This creates a great deal less “friction” for customers, warehousing, and suppliers. This friction is reduced through, but not limited to, the following mechanisms: customers have the burden of tracking and replacing items due to wear removed, and can therefore be “Well-Supplied All-the- Time” with minimal effort; supply needs over periods of time can be aggregated into fewer shipments for better logistics efficiency for both suppliers and customers, for “at-optimal-time” inventory resupply; “pay-for-as-used” means customer cash is used more efficiently. Expanding from the VRP industry to the larger economy, where inventory systems, customers, suppliers, and all other interconnected parties are diverse and to some extent siloed, Gamma will enable communication and collaboration that could vastly reduce friction at a large scale. [0053] In theory, just as there is only one Internet, consisting of websites (analogous to Gamma entities) and links between them, so too there is just one giant Gamma graph, containing all entities and their relationships through glinks. This theoretical entity is referred to as the Gammaverse. 253R1 14 CUSTOME NUM5BER 11-1001AP [0054] Figure 2 is an example block diagram of example entities and example connections called glinks between entities. Example glink 201 connects entity A 202 to Entity B 203. The cloud like border indicates that the block diagram could continue to show more entities and connections between them until all entities and connections built on the Gamma Framework are shown, which is collectively called the Gammaverse 200. C. The Gamma Framework in Detail [0055] Gamma consists of four primary elements: entities, events, glinks, and mirrors. [0056] Figure 3 is an example block diagram of an example glink connection. Glink connection 301 connects an Entity A 302 to an Entity B 303 using the Gamma Framework. The glink is expounded upon in the magnified box 304 which shows example mirrors 305, which look for events occurring at the entity toward which they face, and upon seeing an event therein of particular criteria, called a genesis events (e.g., events 308 and 309), create a corresponding event, called a mirror event (e.g., mirror events 306 and 307), to be processed by the other entity. 1. Entities [0057] Each vertex node within the Gammaverse graph is called an entity and represents a distinct location at which resources can be stored and used. Each entity is free to represent information about its inventory of resources in whatever way is most effective for the entity. [0058] For example, in PlentiModel, the VRP (Vacation Rental Property entity) uses a data structure called an Available Lifetime Set, which is designed to track wear on items within a set of, for example, 23 washcloths. On the other hand, the HUB (a warehouse entity), uses an Expected Inventory Distribution system, which is a probabilistic model of the number of items of each type stored at the warehouse. 2531 15 CUSTOMER NUM5BER 11-1001AP Each of these inventory representations are tailored to specifically address the objectives of their corresponding entities. [0059] Because Gamma requires minimal similarity between entities, the fact that each entity uses potentially different internal data structures does not cause problems for the system. a. Processing Time [0060] During simulation, as time passes, the state of an entity frequently needs to change. For example, the products in a vacation rental property (VRP) degrade automatically over time. The passage of time may also cause events to be generated; see below. 2. Events [0061] Discrete changes happen at an entity only when an event occurs at that entity. Events are used to represent things that happen, like shipments for example, at a particular moment in time. Multiple different event types are used to represent different types of activity. Each event, regardless of type, provides: ^ Event Date. This is when the event occurs. Note that although it is called a “Date”, it can conform to whatever time measurement scheme the entity uses. Events that have the same Event Date do not occur simultaneously. Events are “run” in the update procedure (see C.3. Running A Gamma Framework Model—the Update Procedure) in the order they appear in the list of events. ^ Event Entity. The entity at which the event occurs. ^ Event Status: Each event status must be either speculative or confirmed. This important concept is discussed further in Event Status. ^ Event Origin: Each event has an origin of either local, manual, or mirror. Local events are those created inside the entity. Manual events are those entered by user input. Mirror events are discussed in C.2. g. Mirrors. 25315 16 CUSTOMER NUMBER 11-1001AP [0062] Depending on the type of event being represented, an event typically will have additional data associated with it that describes the event in further detail. See D.2. PlentiModel Events for specific examples in PlentiModel. [0063] Events are processed by each entity in order from past to future, and each entity only processes its own events. This means that entities can be asynchronous, which fits in with the Gamma spirit of minimal similarity requirements between entities. The example PlentiModel deployment of Gamma forgoes the asynchronous entities option and runs its entities synchronously. In other words, in PlentiModel, all entities share the same processing time. It is to be understood though that PlentiModel may be implemented using an asynchronous model as supported by Gamma. [0064] There is no requirement that any entity know how to process any particular kind of event. New types of events can be added to the Gamma system at any time, allowing the framework to expand into new business processes. a. Event Status [0065] Events that have been confirmed to have occurred are called confirmed. Gamma also supports events that are expected to occur which are called speculative. Event status is closely tied to Epochs. b. Epochs: Past, Present, and Future [0066] The flow of time within every entity in the Gammaverse is from the past, through the present, and into the future. Gamma refers to each of these as an epoch, and each has a distinct semantic meaning somewhat different from conventional thinking. [0067] Events that occur in the past epoch must be confirmed, as it should be feasible to know whether or not those events have actually occurred. This rule is strictly enforced in Gamma; all events in the past epoch must be confirmed. 2531 17 CUSTOMER NUM5BER 11-1001AP Furthermore, a confirmed event cannot be changed to speculative unless the Date Time of the event is advanced enough to place it into the present or future epochs. [0068] Events that occur in the future epoch, on the other hand, should always be speculative, as there is no way of knowing that those events will actually happen as predicted. This rule is also strictly enforced in Gamma. A speculative event cannot be changed to confirmed unless the Event Date of the event is regressed enough to place it into the present or past epochs. [0069] In between the well-defined past and future epochs is the period of time that Gamma refers to as the present epoch. Events within the present epoch might be either speculative or confirmed. For example, the business may have received a pallet this morning, but that receipt hasn’t yet been logged, and the corresponding event will therefore remain speculative for part of the day. c. The Flow of Time [0070] As time advances events move from being in the future epoch to the present epoch, and finally into the past epoch. This implies that every event, at some point in its lifetime, will have to become confirmed before it can be allowed to slip into the past epoch. d. Plausibility [0071] An event that is speculative and in the past epoch, is said to be implausible. Gamma does not allow events to become implausible, through an active process called providing plausibility. [0072] In general, providing plausibility to an event to can be done in different ways. The approach Gamma uses depends on the type of the event . Although additional more complex rules could be introduced, a minimal Gamma system will have the following two plausibility algorithms: ^ For manual confirmation event types, Gamma assumes that the event hasn’t happened yet, or it would be confirmed. So, for these events, 253 18 CUSTOMER1 NUM5BER 11-1001AP Gamma advances the Event Date just far enough to keep it within the present epoch. That is, Gamma assumes that the event is “late”, but will still happen soon. ^ For automatic confirmation event types, Gamma assumes that the event happened and needs to be confirmed without any manual intervention. For example, vacation rental owners are not able to log into PlentiModel and acknowledge receipt of their resupply items. For these events, PlentiModel simply changes the event’s status to confirmed as it moves into the past epoch. [0073] Providing plausibility occurs whenever an event might become implausible. This includes: ^ At the creation of a new event ^ Whenever an event is edited by system users ^ When any system change causes the epoch boundaries to shift, including current date advancement e. Processing an Event [0074] In simulation, when the Event Date of an event occurs, the associated entity is required to “simulate” the actions of this event. The code implementing an entity is required to provide procedures for performing all events that it knows how to process. The event processing procedure will be discussed further in C.3. Running a Gamma Framework Model—The Update Procedure. f. Glinks [0075] The notion of the glink (short for Gamma Link) is used to allow a controlled source of interactions between two Gamma entities, known as the Initiator and the Respondent. The rules of Gamma glinks are designed to allow independently created entities to cooperate together with minimum constraints between the two systems. 2 19 CUST5OM3ER1 NUM5BER 11-1001AP [0076] Glinks are not limited in application to particular entities; once they are created instances can be applied to any entity pairs in the Gammaverse that can accept the glink signature. [0077] Each type of Gamma glink has a glink signature, which determines which types of events are passed across the glink, and which entity is the Initiator and which is the Respondent. For example, the primary glink used by Plentiful Stays operations is the VRP Supply glink. This is notated using a labeled double-arrow, like this: ^^{ோ^ ௌ௨^^^௬} ℐ: ^^ ^^ ^^ ^ ℛ: ^^ ^^ ^^. [0078] Here, the initiator ℐ represents a vacation rental property (VRP), and the respondent ℛ is a Plentiful Stays HUB that supplies items to the VRP. Note that the direction of the double arrow only indicates which entity is the Initiator of the glink and which is the Respondent; the glink is bi-directional through the operation of mirrors. g. Mirrors [0079] A Gamma glink operates by providing mirrors. Mirrors conceptually exist within glinks (they are associated with glinks) and therefore have one entity on each side, just as the glinks do. Mirrors have orientation and face only one entity, and they watch that entity for the occurrence of particular events, called genesis events. When such a genesis event occurs, the mirror creates a corresponding mirror event on the second entity. [0080] Mirrors are indicated using a single arrow function, like this: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_ℐ,^ → ^^ ^^ ^^ ^^_ℛ,^ . [0081] This mirror indicates that a resupply event involving item ^^ occurring on ℐ is a genesis event for this mirror and so the mirror will automatically create a c^{orresponding ship event on ℛ. For reference, the complete list of mirrors for the} V_{RP supply^ glink is listed below:} 2531 20 CUSTOMER NUM5BER 11-1001AP ^{^ோ^ ௌ௨^^^௬^} ℐ: ^^ ^^ ^^ ^ ℛ: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ → ^^ ^^ ^^ ^_^ℛ,^ [0082] Spoken in plain the VRP Supply glink indicates that whenever the VRP

(which is represented by generating the resupply event), Gamma will automatically request that these items be shipped from the HUB using a ship event, and then return the replaced items using the return event. Thus, the glink provides an agreed to protocol between the two entities. h. Glink Requirements [0083] For a glink to be established between entities I and R, the entities must be able to process any mirror event types required by the glink signature. As an entity adds the capability to process additional event types, it thus becomes more eligible to participate in various glinks. Note that an entity is not required to generate any of the source events types indicated by the glink signature, but is required to be able to process all the mirror event types indicated. [0084] Because it’s likely that in any Gamma deployment not every entity will have code for processing every possible mirror event, it follows that a particular glink may be invalid for particular Initiator and Respondent entities and therefore cannot be formed. 3. Running A Gamma Framework Model—the Update Procedure [0085] This section explains how to actually “run” a Gamma model, and therefore use it to produce modeling predictions and guide business operations. In this section we outline the Gamma update procedure, a formal process for recomputing part of the Gammaverse. [0086] In typical operation, a Gamma update operates on a one entity at a time principle (although some uses of Gamma may be programmed to deviate from this 25315 21 CUSTOMER NUMBER 11-1001AP assumption). That is, the events on single entity are re-simulated, while other entities a^{re not updated. Let ℰ represent the entity currently being updated. The notation} u_{pdateℰ will be used to represent the process of updating the event stream for entity} ℰ. [0087] Each entity can decide when it wants to do its own updates, depending on its needs. a. Step 1: Prepare a List of Events [0088] The first step is to prepare a list of events, in temporal order, to run the update on: ^ From the list of all events that occurred on ℰ in the last run (see C.3. f. Step 5: Record All Events): a. Discard all events with local origin that have speculative status. b. Discard all mirror events. Fresh versions are added back in the next step. ^ Look at all engagements ℰ is part of and add the most recent mirror events for ℰ. ^ Ensure plausibility for each event in the list (see C.2. d. Plausibility) b. Step 2: Setup Initial Entity State [0089] Next, Gamma configures the initial state for ℰ. In practice, this is done by simply “clearing” the state of ℰ to a “fully blank” configuration. ℰ is then actually configured by an onboard that occurs as the first event in the timeline. c. Step 3: Simulate Time Through the Event Horizon [0090] Now Gamma simulates all events on ℰ, in temporal order. This involves two distinct processes: ^ Advance time on ℰ to that of the first unprocessed event ^^. ^ Apply changes to the state of the ℰ caused by the event ^^, which is then marked as processed. 2T5OM3 22 CUS ER1 NUM5BER 11-1001AP [0091] This process continues until time_ℰ reaches the event horizon, a date past which events are not of significance for this run of the model. This is most easily implemented by using a virtual “event horizon” event, the processing of which actually stops the simulation. [0092] For example, a simulation of a vacation rental warehouse and its inventory serving 50 vacation rentals might only span 5 years into the future, so an “event horizon” event would be put in the queue of events for the warehouse to tell the system to stop the simulation with that event is reached. There could be events past that, which will be ignored. i. Advancing Time [0093] The results of the passage of time on ℰ is modeled in this stage. For example, for the Vacation Rental Property entity (VRP), this is where the degrading of items and the applying of wear at the VRP is performed, per the discussions in Section D. 4. The PlentiModel Vacation Rental Property Model (VRPM). [0094] While time is advancing, new events may be created, which can cause event crossing. ii. Event Crossing [0095] Event crossing occurs when, while trying to advance time on ℰ, new unprocessed events are created, so that such an unprocessed event ^^ could become the first unprocessed event if time_^ ^ time_^. This circumstance is called event crossing, and when it occurs the advance of time must be halted at time_^, as ^^ must be processed first before ^^ is processed. iii. Event Application [0096] Once ℰ reaches the same time as the first unprocessed event ^^, ^^ can now be processed. This is generally implemented by passing the event data for ^^ to a piece of code associated with ℰ for processing this event type. 25315 23 CUSTOMER NUMBER 11-1001AP [0097] Event processing can also generate additional events ^^’ for ℰ, provided they satisfy the causality rule: ^^ ^^ ^^ ^^_^ᇲ ^ ^^ ^^ ^^ ^^_ℰ . [0098] Events created in this process are local events and must be made plausible before they are accepted into the schedule for processing (see C.2. d. Plausibility). [0099] Once the event ^^ has been processed, it is marked as such, and no longer blocks the “flow of time.” In practice, this is most easily implemented by using a priority queue of unprocessed events. iv. History Caching [00100] Logically, Gamma completely re-simulates ℰ, from the date of its creation through the event horizon. As ℰ becomes older, following this approach literally every time (typically daily) ℰ needs to be updated would cause a lot of redundant, unnecessary computation. [00101] In practice, unless entity configuration has been changed (or a code update has occurred), the result of a Gamma simulation for ℰ will produce identical results to the previous simulation up to the point of the first manual event or mirror event that has been modified since the last run. [00102] This fact may be used to elide the redundant computations, and typically an entity update need run only over a short period of simulated time. d. Step 3½: Hypothetical Time [00103] To make current decisions, it is often necessary to consider a hypothetical future. The classic example of this within PlentiModel is that when shipping replacement items to a VRP, the system attempts to ensure the property is well- supplied for the next three months. [00104] To model this, it is necessary to run the Gamma time model, or portions of it, forward in a hypothetical fashion. These “what-if” questions are an important part of 25315 24 CUSTOMER NUMBER 11-1001AP systems that perform predictive modeling but can cause inefficiencies and logical consistency problems. [00105] Gamma has a structured theoretical approach to hypothetical time, whose basic principles are listed below: ^ Hypothetical time may only be considered when a Gamma entity ℰ is considering creating a local event, ^^. Note that ^^ must be a local event, not a manual event of mirror event. ^ The results of hypothetical time may affect the contents (or existence) of ^^, but must have no other effect on the system. ^ The simulation of hypothetical time operates just like regular time, except that local events are not created/simulated. Thus, only manual events or mirror events occur during hypothetical time. [00106] These rules remove the fundamental circularity of the definition. They also prevent nested hypothetical time from being necessary, as no locally generated events can be created, so no second layer of “hypothetical time” can begin. [00107] Within the vacation rental industry, this effectively means that bookings are considered in “hypothetical time,” but not potential resupply actions. This is exactly what’s needed, as PlentiModel is trying to eliminate the need for additional resupply events by creating one right now that meets all needs for the three-month future (three months is chosen by default but can be easily modified to other time spans). e. Step 4: Generate Mirror Events [00108] Once the primary simulation is complete, any events that are source events, i.e. have an applicable Gamma glink ℰ ^ ℱ, generate their corresponding mirror events for the remote entity ℱ. The latest version of these mirror events is recorded for each glink so that, when ℰ is updated at some future time, it can easily look them up to include in its processing. 2531 25 CUSTOMER NUM5BER 11-1001AP f. Step 5: Record All Events [00109] Finally, the collection of all events that occurred on ℰ is now recorded in a suitable database, along with the corresponding event horizon. This will be loaded at the start of the next simulation of ℰ, but is also used as the record of company activities. [00110] Note that the state of ℰ itself is discarded. D. PlentiModel in Detail [00111] Having introduced PlentiModel and Gamma, this section describes the major components of the PlentiModel as an example deployment of the Gamma Framework and details its inner workings. [00112] PlentiModel is a complex multi-tiered software architecture for not only modeling the condition of Vacation Rental Properties (“VRPs”) that are customers of Plentiful Stays, but also for determining the necessary supply of Plentiful Stays’s products to the VRP, appropriate customer charges, as well as assisting in the management of Plentiful Stays’ warehouses. [00113] Table 3 is an example list of items that PlentiModel might track for a sleeps- eight VRP [00114] Mattress (King) 1 Mattress Encasement (Kin ) 2

25315 26 CUSTOMER NUMBER 11-1001AP Fitted Sheet (Full) 3 Top Cover (Full) 2 2 8 4 6 4 9 1 1 1 1 1 1 1 1 1 1 1 1 30

[00115] PlentiModel tracks the item status for all properties within a single Plentiful Stays region. Each region is envisioned to be serviced from a centralized warehouse and service center referred to as a HUB. The HUB forms the center of deliveries, returns, and warehousing of products for the region. However, some items may be drop-shipped directly to VRPs from suppliers. In PlentiModel, the SUP entity refers to suppliers. [00116] As each HUB operates independently (as an entity), this forms a simple scalability model for use of PlentiModel. [00117] Figure 4 is an example block diagram of an example simple scaled deployment of PlentiModel where HUB entities (regional warehouses) are serving 27 CU 2ST5OM3ER1 NUM5BER 11-1001AP numerous VRP entities (vacation rental properties, the small rectangles with no labels) and where one SUP entity (supplier) is serving all three HUBs, and a second SUP entity is drop-shipping to VRPs in each region. [00118] Because each entity can have its own operating code and still communicate and coordinate with other entities, the code used in one type of entity may be useful in other entities that exist in completely different industries. An example is that the section of operating code for an entity representing a VRP that addresses the degrading of sheets may also be useful when applied to an entity representing a boutique hotel. Additional extensions are also possible though; the same section of operating code might be usefully applied to the degrading of running shoes for an entity representing an individual jogger. [00119] So, while the mathematics and algorithms behind the PlentiModel system are currently deployed within the vacation rental property management space as concepts they have broad applicability to a wide variety of industries and commercial applications. [00120] The PlentiModel system uses a preliminary version of important concepts from Gamma. These concepts are introduced here as they specifically apply to an example PlentiModel implementation. [00121] Time flows within PlentiModel on a day-granular basis. That is, the timestamp of when events happen is only tracked to the accuracy of a day. 1. PlentiModel Entities [00122] An individual location where items are stored and/or used is referred to in PlentiModel as an entity. Each entity keeps its own data structures, based on type, to track what items are at the location, and in what condition, at the current point in the simulation. Currently, PlentiModel contains only three entity types, but is designed (following the Gamma model) for arbitrary additional types to be able to be added. 25 28 CUSTOM3ER1 NUM5BER 11-1001AP a. Vacation Rental Property (VRP) Entity [00123] The VRP entity is used to model the contents of an entire vacation rental property. The entity contains detailed information about individual Plentiful Stays items, and their current state, within the property. It may also be used to track the current lifetime/wear status of non-Plentiful items. For example, a new customer may want to keep a mattress they just bought, and that mattress could be tracked by the PlentiModel system to inform when that mattress should be replaced. b. Plentiful Warehouse Hub (HUB) Entity [00124] The HUB entity is used to model inventory levels at one of Plentiful Stays’ warehouses. These warehouses are used to provide items to all properties within the HUB’s region. [00125] As items are not “used” at the warehouse, this entity focuses on tracking the number of items available, similarly to a traditional inventory application. However, PlentiModel expands on this by allowing for statistically uncertain information to be tracked, as described in D.11. Modeling Single-Use Items. c. Supplier (SUP) Entity [00126] The SUP entity represents a traditional supplier that is used by Plentiful Stays to provide products. Suppliers can send products directly to VRP’s via drop-shipping, or their products can be warehoused at the HUB and distributed from there. [00127] Since suppliers operate outside of the Plentiful Stays universe, these entities are stub entities. Stub entities typically track little data, and events that occur on a stub entity are usually handled by sending a notification to the corresponding outside entity. In this case, the ship events that occur on a supplier need to be translated into a Purchase Order for that particular supplier. 2531 29 CUSTOMER NUM5BER 11-1001AP 2. PlentiModel Events [00128] Changes to entities are caused by PlentiModel events, which represent things that happen, like shipments for example, on a particular date. Multiple different event types are used to represent different types of events. Each event, regardless of type, provides the three basic Gamma event properties: ^ Event Date. This is the date on which the event occurs. ^ Entity. This is the entity at which the event occurs. ^ Status. This represents the status of the event and takes on the possible values speculative or confirmed. [00129] For clarity of notation, event types will be written using a bold font. Each specific event type provides additional information about the event. The major event types used within PlentiModel are outlined below, organized by the entity type to which they apply. Note that the same event name may be used for events applying to different entity types; this normally is only done when the events are similar in function or purpose. a. Vacation Rental Property (VRP) Events [00130] These events occur at a specific vacation rental property and model the activities that occur at the VRP. i. The onboard Event [00131] This event represents the start of the customer relationship between the owner of the VRP and Plentiful Stays. No items are shipped to the property until this event has occurred. [00132] This event has no additional data fields. ii. The adjust service Event [00133] The adjust service event applies to VRPs and is used to change the required “service level” for a particular collection of items—pillows, for example. 30 CU 2ST5OM3ER1 NUM5BER 11-1001AP [00134] The additional data for an adjust service event contains: ^ Item Group. This is the item group whose service level is going to be modified. The item group specifies a specific product, “dinner forks” for example, but also may specify a specific collection of these at the VRP. This is used when multiple collections of the same product type are tracked separately at the property; of particular note is the tracking of individual mattresses, by placing each in its own item group. ^ Qty. This non-negative integer specifies the service level for this item group at the VRP that is to be satisfied. The service level is the number of guest-usable items of this type that must be available at all times. ^ Usage Information. This optional field provides information about which channels and/or guest types are able to use this item group. By default, all channels and all guest types use this collection of items, but that may be modified using this field. For example, this field would be used to indicate that only guests staying in channels ^^ and ^^ can use the king bed in the master suite. iii. The booking Event [00135] The booking event is used to represent booking information for the VRP. It includes the following additional data: ^ Duration. This is the number of nights for the stay. The check-in date is already known from Event Date; the check-out date may be computed by adding Duration to check-in. ^ Guests. This field indicates how many guests, of each guest type, are a part of this booking, in the format “3 Adult, 2 Child.” Guest types that are omitted are assumed to have zero quantity. 31 CU 2ST5OM3ER1 NUM5BER 11-1001AP iv. The adjust discount Event [00136] The adjust discount event is used to configure discounting information for this VRP. This is part of the billing system of PlentiModel. [00137] Additional data fields include: ^ Product Category. This is the product, or group of products, whose discount we are adjusting. ^ Discounts. Four percentage values representing each of the discount types: a. Initial Charge Discount b. Aging Charge Discount c. Usage Charge Discount d. Termination Charge Discount [00138] The discount that applies to a bill is based on the discounts current on the date of billing, not the date of provided services. [00139] To eliminate a discount on a given date, simply adjust all discount values to 0%. v. The breakage Event [00140] The breakage event is used to indicate that the owner/housekeeping of a VRP has reported a broken, damaged, stolen, destroyed, etc. item. [00141] Additional data for breakage events includes: [00142] Item Group. This is the item group (by name) from which the breakage occurred. [00143] Quantity. This positive integer represents the number of items which were reported broken from this group. vi. The resupply Event [00144] The resupply event is used to represent the delivery of new items to the vacation rental property, along with any possible returned items. A separate 2 32 CUST5OM3ER1 NUM5BER 11-1001AP resupply event is used for each product that is shipped, even though they may be packaged together with other products. [00145] Additional data includes: ^ Item Group. This is the item group (by name) which is being resupplied. ^ Quantity Sent. This is a non-negative integer representing the number of brand-new items of this type that have been sent to the VRP. ^ Quantity Returned. This is a non-negative integer representing the number of used-up items of this type that the VRP must return. ^ Source. This entity-valued item is the entity from which this resupply event took place. Often this will be the corresponding Plentiful Stays’ HUB warehouse for this VRP; however, drop- shipment strategies are used for products such as mattresses. b. Warehouse Hub (HUB) Events [00146] This section presents the events that occur at a HUB. i. The config hub item Event [00147] This event is used to configure the supply of an item at a HUB. This causes the specified product to be stocked at the given HUB. [00148] Additional data includes: ^ Product. This is the product which is being stocked by the warehouse. ^ Source. This entity-valued item is the entity from which the HUB orders shipments of this product. This will normally be a Supplier entity. ^ Usage Per Year. This is an estimate of the mean number of units of this product used per year. PlentiModel uses this to forecast shipments of this item. This value will be notated as ^^_௬^^^. ^ Reliability. This percentage value ^^ represents the uncertainty of the Usage Per Year estimate, expressed as the percentage of the mean. That is, 33 CU 2ST5OM3ER1 NUM5BER 11-1001AP ^^_௬^^^ ൌ ^^ ^^_௬^^^ . [00149] The reliability value is used in the internal inventory level models to represent the inherent uncertainty of future predicted inventory levels; see D. 11. Modeling Single-Use Items. ii. The ship Event [00150] The ship event represents a shipment of items out of the HUB to a VRP. This event is a “mirror” of the resupply event on the VRP. [00151] Additional data: ^ Destination. This is the entity (which must be a VRP) to which items are being shipped. ^ Product. This is the product that is being shipped to the VRP. ^ Quantity Sent. The quantity of this product being sent to the VRP. [00152] Note that each individual product within a shipment creates its own ship event in the current implementation. iii. The return Event [00153] The return event represents the return of product from a VRP and is the last step of the “ship-resupply-return” sequence. This event is a “mirror” of the resupply event on the VRP. [00154] Additional data: ^ Source. This is the entity (which must be a VRP) from which items are being returned. ^ Product. This is the product that is being returned from the VRP. ^ Quantity Returned. The quantity of this product being returned from the VRP. [00155] Note that each individual product within a shipment creates its own return event in the current implementation. 2 34 CUST5OM3ER1 NUM5BER 11-1001AP iv. The resupply Event [00156] The resupply event is used to represent the delivery of new items to the HUB. A separate resupply event is used for each product that is shipped, even though they may be packaged together with other products. [00157] Additional data includes: ^ Product. This is the product (by name) which is being resupplied. ^ Quantity Sent. This is a non-negative integer representing the number of brand-new items of this type that have been sent to the HUB. ^ Source. This entity-valued item is the entity from which this resupply event took place. This will normally be the Supplier entity that was configured by the config hub item event. However, ad-hoc shipments of items to the HUB are also represented using the resupply event. c. Supplier (SUP) Events i. The ship Event [00158] The ship event represents a shipment of items out of the supplier to a HUB. This event is a “mirror” of the resupply event on the HUB. [00159] Additional data: ^ Destination. This is the entity (which must be a HUB) to which items are being shipped. ^ Product. This is the product that is being shipped to the HUB. ^ Quantity Sent. The quantity of this product being sent to the HUB. [00160] Note that each individual product within a shipment creates its own ship event in the current implementation. [00161] The collection of ship events created for a supplier for a given date must be translated into a purchase order (PO) for delivery to the supplier. 2T5OM3 35 CUS ER1 NUM5BER 11-1001AP 3. PlentiModel Glinks [00162] The PlentiModel implementation does not directly implement the abstract Gamma glink notion. However, it does effectively implement the following glinks. a. VR Supply Glink [00163] The VR Supply glink allows a vacation rental property (VRP) to be resupply from a Plentiful Stays HUB. The glink and its mirrors are formally represented below. ^^{ோ ௌ௨^^^௬} ℐ: ^^ ^^ ^^ ^ ℛ: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ → ^^ ^^ ^^ ^^_ℛ

b. VR [00164] Other products for the vacation rental property (VRP) are directly drop- shipped from suppliers (SUP). In this case, no return items are generated. This glink is as follows: ^^{ோ ^^^^^^^^} ℐ: ^^ ^^ ^^ ^ ℛ: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_ℐ → ^^ ^^ ^^ ^^_ℛ c. Hub Supply Glink [00165] The HUB Supply glink allows the HUB to be supplied from suppliers. It looks similar to the VR Dropship glink. ு^{௨^ ௌ௨^^^௬} ℐ: ^^ ^^ ^^ ^ ℛ: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_ℐ → ^^ ^^ ^^ ^^_ℛ Figure 5 is an example block diagram of an example simple deployment of PlentiModel on a single computer using an Excel document called Repository for data storage and user input. The Repository in this example contains definitive data about the VRP entities (vacation rental properties), the SUP entities (suppliers), the HUB entity (hub warehouse for the region), and all of the glinks between these, along with all events that PlentiModel creates, and all events that are entered manually. 25OM3ER1 36 CUST NUM5BER 11-1001AP Booking entities (in this case stub entities, D.1. c. Hub Supply Glink) provide data on bookings which is entered manually into the Repository document. PlentiModel instructs what to charge customers but the actual billing is completed outside of PlentiModel using Quickbooks. 4. The PlentiModel Vacation Rental Property Model (VRPM) [00166] The PlentiModel platform uses a complex model of the vacation rental property (“VRP”) to estimate usage of all of the Plentiful Stays-provided products within the property. These models are then used by PlentiModel to estimate the property condition moving forwards, and thus determine when additional shipments from Plentiful Stays are required to ensure that the property remains “well-supplied, all the time.” [00167] Figure 7 is an example flowchart roughly illustrating how PlentiModel makes the decision to send some number T new towels to a VRP, requesting the same number T towels being removed from inventory and returned to the HUB. Some terms used in the flowchart have not yet been described, and the reader may find it valuable to return to this figure after completing the “4. PlentiModel in Detail” section which also describes Figure 6 where the towels are requested. [00168] Concurrently, Plentiful Stays’ innovative “pay-for-as-used” billing model issues monthly bills based on the proportion of each item’s available lifetime lost during the month. This causes charges to mostly^\ track with rental success: months in which the owner has more guests will have higher bills, and leaner months have lower bills. For example, since guest-heavy months with fewer days rented could result in comparatively higher PlentifulStays bills compared with one guest staying for the whole month, the charges “mostly” track rental success. On average the charges track rental success. [00169] The VRPM is a series of computations which determine whether a specific VRP, after a selected period of time passes, remains well-supplied; that is, has all of the products present, and in sufficiently good condition, to service the needs of 37 CU 2ST5OM3ER1 NUM5BER 11-1001AP the vacation rental’s next guests. This computation (or sub-pieces of it) drives most of the behavior of PlentiModel, and so is laid out as an effective sub-module of the PlentiModel system. In the context of the Gamma framework, the well-supplied computation is executed in hypothetical time; see C. 3. d. Step 3½: Hypothetical Time. [00170] By incorporating speculative events of future use into its modeling, PlentiModel enables aggregating shipments across time into fewer shipments. Optimization of shipping frequency can be considered across multiple competing objectives, such as frequent shipments receiving as little inventory as possible to save on storage space and cash tied-up (“just-in-time”), or less frequent shipments with more inventory per shipment and thus saving on logistics and receiving costs. By being able to consider speculative shipments and aggregating them across time one can optimize across both objectives. a. Activity Signals [00171] The modeling process in PlentiModel starts with activity signals. These consist of any system-known data that can be used to predict wear on the items in use at a location. For the current usage in the vacation rental industry, this consists of booking data, gathered either manually from the owner or from automated systems such as AirBNB, VRBO, or other third-party VR booking software. [00172] PlentiModel assumes that this data provides the starting date and duration in days of the stay, as well as guest counts by guest category. As distinct types of guests will have different preferences and usage patterns, PlentiModel allows each guest to be assigned a type, such as “adult,” “child,” or “infant”. (In the present implementation of PlentiModel, these are the three guest categories in use; however, PlentiModel allows arbitrary categories to be defined/created. [00173] The PlentiModel system can accommodate multiple simultaneous bookings, for example in properties where individual rooms are offered for rent. This flexibility also allows for live-in owners to be accounted for; PlentiModel requires information 3 U 2ST5 8 C OM3ER1 NUM5BER 11-1001AP about all users of the property in order to generate meaningful predictions. All persons using the property will be referred to as guests for convenience and use the same activity signals. b. Channels [00174] In order to meaningfully predict how guests use items in a VRP, PlentiModel maps the logical concept of guests into channels, which generally correspond to sleeping locations. For example, guests that do not stay in the master suite place no wear on the king bed located there—or use the bath robes only provided in the ensuite. [00175] To model this, each property within PlentiModel defines a set of guest channels. A set of preference data indicates how desirable each channel is for each guest category, and a constrained optimization problem is then solved to estimate the probability of each channel being utilized during any given day, based on the number of guests of each type present on that day. [00176] Channels shall be represented in this document using capital letters in a math font, like this: ^^, ^^, ℂ, etc. c. Usage Signals [00177] Next, PlentiModel maps these channel utilization numbers into estimates of the amount of usage for each type of item modeled by PlentiModel. PlentiModel supports semi-arbitrary usage types. Each type of usage is tracked independently of the others. [00178] The primary sources of usage in the current PlentiModel system are aging (the passing of time), and guest-nights, which represents a single guest using an item for one day. However, the PlentiModel system also logically permits semi- arbitrary types of usage, including data such as laundry cycles. Any quantity that directly relates to wear and tear on items in the VRP that can be meaningfully 25315 39 CUSTOMER NUMBER 11-1001AP calculated from the available activity signals may be used to add additional types of usage within PlentiModel. [00179] Items in the VRP, depending on their location, may only really be used by guests in specific channels. For example, channels ^^ and ^^ are normally used to represent the two sides of the bed in the master suite. Obviously, that mattress, and the sheets on it, only logically receive wear from guests in channels ^^ and ^^. This is indicated in PlentiModel by, for each set of items added to the VRP, indicating which channels are serviced by those items. d. Item Set Condition [00180] These usage signals, having just been mapped to individual item supplies, are then used to model the loss of lifetime for the items within the property, a process referred to as applying wear. This is done using a complex model tracking the lifetime of individual items within fungible sets of items, stored in a data structure known as an Available Lifetime Set. e. Well-Supplied Test Criteria [00181] PlentiModel finally analyzes the ALSs at the end of the model to determine whether or not the property is still well-supplied. The definition of this term is nuanced; it requires not only that there be items at the property, but that they be of an appropriate quality for continuous, on-going operations. f. Speculative Modelling [00182] The entire VRPM presented above is not only used to account for actual past events but is also used in a speculative way. That is, given the bookings that we expect to have in the coming months, what will the condition of the property be at a future date? 40 CU 2ST5OM3ER1 NUM5BER 11-1001AP i. Predicting Future Activity [00183] To do this, PlentiModel forms an estimate of expected future bookings. Early versions of PlentiModel used a simplistic estimate based on the expected average guests per night in each channel of the VRP (a value between 0.0 and 1.0. It then runs the VRPM model using these artificial activity signals. More sophisticated models will use a combination of pre-booked reservations (which are not guaranteed to occur but are likely) and an estimator for additional booking for the unreserved portions of the calendar. [00184] This system of looking ahead is what enables “at-optimal-time” inventory, which not only considers what inventory is needed now (sufficient for “just-in-time” inventory), but speculates about what is needed a specified number of days into the future, so that it can accumulate needs across time and satisfy them in a single shipment or a reduced number of shipments for “at-optimal-time” inventory. g. Determining shipments Plans [00185] Based on the VRPM process, PlentiModel determines when to ship supplies to the VRP, and in what quantities. The algorithm for this process avoids shipments when it can defer the shipments to the next regular shipping day (typically monthly) without having the property become ill-supplied before new items arrive. [00186] Once a shipment is determined to be required, PlentiModel schedules a delivery. The Plentiful Stays business model calls for the return of worn-out items, normally in the same quantity as we send out items. PlentiModel ships sufficient items to keep the property well-supplied for a more substantial time (3 months) so as to attempt to limit the number of shipments to the property to being quarterly. h. Determining Billing and Payment [00187] The Plentiful Stays model uses a “bill as you use” process, which actually charges customers when their items are degraded by usage. This is directly driven by the modeling of the VRPM for each past month. 2 41 CUST5OM3ER1 NUM5BER 11-1001AP i. Monitoring Warehouse Inventories [00188] PlentiModel also tracks inventory levels within the HUB. It uses a novel statistical inventory model based on the same math that a VRP uses to track single- use items within the vacation rental. 5. Modeling Multi-Use Items [00189] Many products within the vacation rental industry are degrading products, such as mattresses, sheets, dishware, etc. These products are reused day after day, guest after guest, and degrade accordingly. The lifetime of these products is limited by two basic factors: ^ Accumulated wear causing chips, discoloration, piling, dents, or other defects occurring during normal usage, cleaning, etc., depending on the particular product. Statistical in nature, wear can, over the long term, be effectively predicted. Accumulated wear degrades the item slowly over time, until it reaches a point where it is no longer suitable for use. ^ Breakage caused by accidents or malicious actions (including theft) that causes the sudden non-viability of an item. [00190] Thus, these reusable products can be referred to as continuous-wear products because they degrade in a continuous fashion over their lifetime, as opposed to the single-use products described in D.11. Modeling Single-Use Items. The mathematics of continuous-wear products described in this section forms the basic mathematical underpinning of PlentiModel’s model of vacation rental properties, and thus ultimately determines both the resupply and billing decisions of the system. [00191] Note that a product typically will be treated in the vacation rental as a multi- use item but be treated as a single-use product within a HUB; modelling depends on the location and use of an item, not the item’s inherent identity. 2531 42 CUSTOMER NUM5BER 11-1001AP 6. Item Available Lifetime [00192] To represent the state of an individual continuous-wear product, the PlentiModel system uses a single real number referred to as available lifetime, which is defined as the proportion of usable lifetime of this item remaining at any point in time. Thus, a new item always has an available lifetime of 1.0, and when the lifetime value reaches 0.0 (or below), the item is no longer considered acceptable for use, and must be replaced. Because this definition of available lifetime does not depend on the particulars of the product, or how it wears out, it can be used for almost any continuous-wear product, both within the Vacation Rental sector, but also in extensions of this market, and ultimately in completely different business verticals. 7. Item Available Lifetime Sets [00193] In many cases, however, there are multiple identical items within the a VRP. In some cases, like with queen mattresses, these are placed in particular rooms and can (and should) be tracked separately. More common, however, are situations like towels. There may be a two dozen towels in a particular property, but no one keeps track of which one is which, or which towel gets used for a shower on Thursday; in other words the towels are fungible. [00194] To accommodate the need to track items that are fungible, PlentiModel works using an item set, which is a set of identical items that are not individually tracked. Each item has its own available lifetime value, forming an available lifetime set. Because the items in a set are not distinguished, available lifetimes are always presented in descending order. For example, the available lifetime set of a collection of two brand-new towels, two towels that have reached “half-life,” and two that are u^{nusable would look like:} 1_{.0, 1.0, 0.5, 0.5, 0.0, 0.0.} [00195] In physical reality, for the products under consideration for the vacation rental industry, items always come in unit quantities; we never have “half a towel.” In order to address various mathematical challenges, and to allow the system to extend 43 CU 2ST5OM3ER1 NUM5BER 11-1001AP further, PlentiModel actually works in fractional item quantities. To support this, each item in an available lifetime set has a quantity (which may be fractional or even negative) associated with each item, separated from it using an at-sign. The towel e^{xample could then be written using a notation such as:} 2_{.0 @ 1.0, 2.0 @ 0.5, 2.0 @ 0.0 .} [00196] Note that single-item sets can also be represented in this notation. A single king mattress that has received 2 years of typical usage out of an estimated 8-year l^{ifespan would be:} 1_{.0 @ 0.75 .} a. Mathematical Notations for Available Lifetime Sets [00197] For mathematical convenience, we let ^^_^ represent the quantities within an available lifetime set (ALS), where ^^ one to the number of items in the

set, which we shall denote ^^. Similarly, let ^^_^ represent the corresponding available lifetime. Several useful quantities are now defined based on these. i. Total Quantity and Stocking Failure [00198] The total quantity of items that are available within an ALS is easily computed by summation of quantities over all items in the set: ^^ ^^ ൌ ^ ^^_^ . Summation ranges (here 1 to ^^)

cases where this is clear from context. [00199] Note that this is not necessarily the same value as ^^, the number of items in the set, unless all items have ^^_^ ൌ 1.0. [00200] In general, although individual negative quantity records are permitted in an ALS, the ALS handling system requires that ^^ ^^ ^ 0. [00201] When this is not the case, we will declare the ALS to be in stocking failure. That is, the modeled supply of items is negative, which is impossible. This will not normally occur during PlentiModel operations and is an indication of a potential 25315 44 CUSTOMER NUMBER 11-1001AP internal error. Small (relative to floating-point precision) stocking failure may occur because of numerical rounding issues. In general, the appropriate action in such cases is to replace the ALS with an empty one, representing no items, and proceed ii. Total Available Lifetime and Service Failure [00202] A second value that will turn out to be of particular importance about an available lifetime set is the total available lifetime, which is the sum of available lifetimes over all items in the set: ^^ ^^ ^^ ൌ ^ ^^_^ ^^_^ . ^ [00203] This formula applies quantities or lifetimes happen to go

negative (both of which occur system use). Negative quantities will be used to represent item breakage and negative lifetimes occur naturally after an item is no longer usable. [00204] In general, although individual negative quantity records are permitted in an ALS, the system requires that ^^ ^^ ^^ ^ 0. [00205] When this is not the case, PlentiModel declares the ALS to be in service failure. That is, the modeled supply of items is no longer able to provide any usable service to guests of the vacation rental. Obviously, PlentiModel hopes to supply the vacation rental property in such a way that this never occurs in reality, but it will often o^{ccur during simulations of “what-if” scenarios. When it does, simply setting all ^^^ ൌ} 0_{is a straightforward way to indicate that there is no available service.} 8. Applying Wear by Type [00206] In order to model wear to an item set, we modify its available lifetime set to reflect the new status of the items. There are several distinct types of wear that occur within the PlentiModel system, necessitating multiple mathematical formulations. 25315 45 CUSTOMER NUMBER 11-1001AP a. Mathematical Notations [00207] We use the mathematical notation that a “primed” variable represents the updated version of a value. So, for example, ^^_^ ^ᇱ is the new quantity, and ^^_^ ^ᇱ is the new lifetime. Wear operations do not normally change quantities; however, we introduce the general concept for later use and to establish the standard nomenclature used herein. We use Greek letters to represent sources of wear, such as ^^ or ^^. b. Uniform Wear [00208] One type of wear that occurs is wear that applies to all items within the set uniformly. The primary source of this type of wear comes from simple aging. Many products simply degrade, discolor, or otherwise fail due to the simple ravages of time. Obviously, this type of wear applies to all items within the item set. [00209] So, if a duration of time passes such that a wear level of ^^ applies to this item set, then the updated set would be: ^^_^ ^ᇱ ൌ ^^_^ _^^^ ^ᇱ _{ൌ ^^^ െ ^^.} [00210] The corresponding result for total available lifetime would thus be: ^^ ^^ ^^^ᇱ ൌ ^^ ^^ ^^ െ ^^ ^^ ^^. [00211] That is, the total available lifetime is reduced by ^^ for each item in the set and is thus multiplied by the total quantity ^^ ^^. i. Mathematical Notation [00212] The uniform wear operator will be denoted mathematically as wear_{^୬୧^୭୰୫}^ ^^^. ii. Service Failure [00213] Note that this operation causes a service failure if ^^ ^^ ^^ ^ ^^ ^^ ^^. This happens when the wear being applied exceeds the capability of the items in the item set to provide service. 2T5OM3 46 CUS ER1 NUM5BER 11-1001AP [00214] Note that individual items in the ALS can slip into negative available lifetime without causing a service failure. Consider this example ALS for four queen sheets a^{t a vacation rental property that has 2 queen beds:} 1_{.0@0.85, 1.0@0.61, 1.0@0.34, 1.0@0.03.} [00215] The fourth sheet only has 3% of its life left and will need to be replaced soon in an ideal world. However, suppose supply chain issues were to prevent shipping of new items to the VRP. In this case, additional uniform wear of ^^ ൌ 0.1 might occur b^{efore new product can be sent. This would then leave a new ALS of:} 1_{.0@0.75, 1.0@0.51, 1.0@0.24, 1.0@ െ 0.07.} [00216] This indicates that one of the four sheets is no longer useable. However, this does not cause a service failure because the ^^ ^^ ^^ is still positive, at 1.43. The represented situation is quite realistic; although the VRP does not have a full set of four usable sheets at this time, it still can be properly set up for guests since there are only two queen beds at the property. iii. Full Lifetime Data [00217] One then needs to examine where the value of ^^ comes from—a towel may have been sitting for one week, but how is that translated into ^^ in the above equations? [00218] In PlentiModel, this is addressed by use of estimated full lifetime data. That is, how much usage would be required to completely exhaust an item from a lifetime of 1.0 to 0.0? For aging, PlentiModel takes this as a quantity of years, which will be denoted as ^^ ^^_ୟ^୧୬^. This is the duration of time corresponding to ^^ ൌ 1.0. ^{[00219] For example, fresh flowers might have a full lifetime of}

^{a week ( ^^ ^^ୟ^୧୬^ ൌ} 1_{/52). Other products might have a nearly inexhaustible lifetime if they are unused} and undisturbed. In these cases, a large full lifetime may be appropriate. The limit of this, of course, is to use ^^ ^^_ୟ^୧୬^ ൌ ∞. This value will cause ^^ ൌ 0 in all cases, implying that there is no wear caused by product aging. 25 47 CUSTOM3ER1 NUM5BER 11-1001AP [00220] In selecting a value, it is important to remember that ^^ ^^_ୟ^୧୬^ represents the full lifetime of a product that only is wearing out due to time, not use! For example, there is a colloquial recommendation to replace your mattresses every eight years— but that does not imply ^^ ^^_ୟ^୧୬^ ൌ 8, as the recommendation assumes it’s being slept in! iv. Calculating ^^ [00221] Once ^^ ^^_ୟ^୧୬^ is chosen for a product, the necessary value for ^^ to use with arbitrary durations ^^ can be calculated by a simple proportion: ^^{^} ^{^^ ൌ} ^_{^ ^^^^^^^} ^.

c. [00222] The above methodology is used to model uniform wear types such as aging. Other types of wear, however, do not apply to all items uniformly. Consider a guest pouring his morning cup of coffee. He obviously picks one cup to use, and most of them do not receive any wear at all. And the total wear is one coffee, regardless of the number of cups in the kitchen. [00223] This observation means the proper equation for total available lifetime, given an amount of proportional wear ^^, must be: ^^ ^^ ^^^ᇱ ൌ ^^ ^^ ^^ െ ^^. [00224] So, the question then becomes how to apportion this wear amongst the individual items within the set? It would be mathematically acceptable to simply assign all items the same wear, but this does not correspond to typical usage within many environments, including the Vacation Rental. Owners and housekeeping will tend to place the better-looking items in front or might keep really worn items in storage “just in case” they need them. And guests will tend to reach for the items in front and avoid any obviously damaged items. [00225] Note that pushing the wear modelling towards the better items (that is, those with larger available lifetime) will naturally cause a degree of coalescing to the ALS; 2531 48 CUSTOMER NUM5BER 11-1001AP that is, it tends to make the lifetime values within the ALS more comparable to each other after the wear occurs. Too much coalescing, however, will make the mathematical model unstable, in that ALS will always indicate completely identical items. [00226] The compromise formula that PlentiModel uses is that in these cases, wear is assigned proportionally to current lifetime. This formula has certain advantages: ^ It applies no wear to items with no lifetime left ( ^^_^ ൌ 0). ^ Continual proportional wear makes all items reach un-usability simultaneously. In other words, the model does not predict that items break and get removed from service during use. ^ The coalescing of the ALS to a single value only occurs when no lifetime is left, thus avoiding losing information about the distribution of wear in the items. [00227] The proportional wear operator will be denoted as wear_{୮୰୭୮୭୰^୧୭୬ୟ୪}^ ^^^. [00228] If the wear is to be applied proportionally, this means each lifetime is multiplied by a constant: ^^_^ ^ᇱ ൌ ^^ ^^_^ . [00229] All that remains, then, is to

proportionality constant ^^ that makes the TAL update come out right. This can easily be seen to require ൌ ^{^^} ᇱ ^^ ^^ ^^ െ ^^ ^_^ ^{^^ ^^} ^_{^ ^^ ^^} ^ൌ ^_{^ ^^ ^^} ^. [00230] Note that this confirms the observations made above; any level of wear ^^ up to ^^ ^^ ^^ generates a positive value for ^^. When the wear equals the pre-existing ^^ ^^ ^^, all items are reduced to zero lifetime. If ^^ ^ ^^ ^^ ^^, then a service failure occurs. i. Calculating ^^ using Full Lifetime Data [00231] Just as for the uniform wear case, PlentiModel needs to be able to calculate how much wear ^^ occurs for a particular event. This is done in a comparable way to the uniform case, again using estimated full lifetime data. 2531 49 CUSTOMER NUM5BER 11-1001AP [00232] For our coffee mug example, there are a variety of ways it gets “used” that might be modelled proportionally: ^ A guest uses a coffee mug for their morning coffee (a drink activity) ^ The mug goes through the dishwasher cycle (a wash activity) [00233] For each such wear source, PlentiModel requires a full lifetime data value. That is, how many times can this be done before the item is completely used up. These will again be denoted using the mathematical notation ^^ ^^_^, only this time these are in counts of uses, not number of years. [00234] So, for the drink wear activity, imaging using the mug over and over without washing it, and all on the same day; how many times can it be used for coffee before it’s worn out? This will determine the full lifetime value, ^^ ^^_{^୰୧୬୩}. For wash, it’s repeated dishwasher cycles: load, run, unload, repeat. When does it fail? This gives ^^ ^^_^ୟ^୦. [00235] Based on this data, PlentiModel then calculates the proportional amount of wear ^^ for an individual drink or wash wear event and applies these using the above mathematics. d. Applying Multiple Wear Types [00236] In most cases, a variety of distinct types of wear are occurring simultaneously, in the sense that no information about what order the wear occurs in is available. It may be known that a guest that has a coffee on Monday, but what time of day this happens, and when the dishwasher is run during the day has a mathematical, albeit small, effect on the resulting wear model. i. Mathematical Properties [00237] The notation ^^_^ ∘ ^^_ଶ shall be used to indicate the operation of first applying wear event ^^_^, and then wear event ^^_ଶ. This follows mathematical conventions when we realize that a wear event is mathematically a function mapping one ALS value onto a modified one. 2531 50 CUSTOMER NUM5BER 11-1001AP [00238] It is easy to show mathematically that two different uniform wear events commute and are equivalent to a single event of the total wear: ^^ ^^ ^^ ^^_௨^^^^^^^ ^^_^^ ∘ ^^ ^^ ^^ ^^_௨^^^^^^^ ^^_ଶ^ ≡ ^^ ^^ ^^ ^^_௨^^^^^^^ ^^_^ ^ ^^_ଶ^ . [00239] wear events both commute and add: ^^

^^_^ ^ ^^_ଶ^ . [00240] In general:

_{^^^ .} [00241] in certain

note that both uniform and proportional wear operators can be expressed as an affine operator on the lifetimes within the ALS: ^^_^ ^ᇱ ൌ ^^ ^^_^ െ ^^ [00242] for appropriate values ^^ and ^^. Because each wear operator is affine, their functional composition is also affine, and therefore any sequence of wear operations on a fixed ALS can be expressed as a single affine operator. [00243] Secondly, the effect of wear operators on the total available lifetime (TAL) is always simply additive, based directly on the parameters ^^, ^^, and ^^ ^^, which are constant for a particular set of wear operators applied to a given ALS. Therefore, the final TAL for a sequence of wear operators is independent of order. [00244] Combining these facts, it becomes clear that the space of wear operations is a two-dimensional affine family, one dimension of which is eliminated by the fixed final TAL. Thus, all possible re-orderings of a set of wear operators applied to a given ^^ ^^ ^^ form a one-dimensional family. [00245] In practice, however, it is still necessary for PlentiModel to choose one of these particular affine operations as the wear operator to use for a particular day. ii. Combined Wear Operator [00246] To address this in an unambiguous way, PlentiModel logically slices all wear events occurring during a specific day (which is the quanta of time used within PlentiModel) into smaller slivers of wear, uniformly distributed during the day. For 2531 51 CUSTOMER NUM5BER 11-1001AP example, splitting the example coffee service into ^^ ൌ 24 slivers (also known as hours) yields the repeating pattern: ^ One hour of aging ^ One 24^th of a drink event ^ One 24^th of a wash event [00247] This can then be repeated 24 times to produce a model of the changes to the ALS for that day. The mathematics behind PlentiModel then considers what happens as we take the limit ^^ → ∞. It can be easily shown that the particular order of the repeating slices does not have an impact on the final limit, and thus this can be taken as the definition of a new combined wear operator, accounting for both types of wear. This is how all wear is actually applied within PlentiModel. ^{[00248] Let the wear operator wearୡ୭୫ୠ୧୬^^^ ^^, ^^^ represent the combination of} w_{ear^୬୧^୭୰୫^ ^^^ and wear୮୰୭୮୭୰^୧୭୬ୟ୪^ ^^^ based on this infinite slicing procedure. First,} note that the final total available lifetime ( ^^ ^^ ^^′) is easily determined, since TAL is not affected by wear ordering, as noted above: ^_{^ ^^ ^^} ^ᇱ _{ൌ ^^ ^^ ^^ െ} ^{^} _{^^ ^^ ^^ ^ ^^} ^{^} _. [00249] Through a series of complex algebraic manipulations, the following can be shown to be the mathematical equivalent of the operator defined above: ^^_^ ^ᇱ ൌ ^^_^ _^^^ ^ᇱ _{ൌ ^^ ^^^ െ ^^} [00250] for the values of ^^ and ^^ as specified below: ఒ ^^{^ ^^ ^^′} ்ொఓାఒ ^^{^′} .

iii. Service Failure [00251] For the combined wear formula, note that the formula goes mathematically unstable if ^^ ^^ ^^ ^ 0. This is why we require all ALS to have ^^ ^^ ^^ ^ 0. 2T5OM3 52 CUS ER1 NUM5BER 11-1001AP [00252] If the new ^^ ^^ ^^^ᇱ ^ 0, this scenario indicates that, at some point over the duration of the combined wear application, the system reaches the ^^ ^^ ^^ ൌ 0 state, indicating that it can no longer provide service from that point forward in the model. [00253] In this case, PlentiModel declares a service failure. Obviously, PlentiModel hopes to supply the vacation rental property in such a way that this never occurs in reality, but it may occur during simulations of hypothetical “what-if” scenarios. 9. Changing Total Quantity [00254] The quantity of product to be supplied at a vacation rental property within PlentiModel will be referred to as its stocking level. This is determined for a given VRP based on calculations that will be discussed in D.12. a. Cascade ALS. [00255] However, this is an objective—in many cases, the current total quantity ( ^^ ^^) of items at the VRP will not, in the short term, agree with the stocking level. When the VRP is under-supplied, PlentiModel will attempt to correct this deficiency as soon as possible. If the VRP is over-supplied, then PlentiModel allows the situation to wait until the next shipment is required. [00256] Adjustments to an ALS that modify its ^^ ^^ can need to be made for several reasons: ^ Shipment of additional new items to the property ^ Voluntary removal of items from service (such as retiring worn-out items, or discontinuing service) ^ Involuntary removal of items from service (i.e., breakage) [00257] The methodologies PlentiModel uses to implement each of these operations by modifying the associated ALS are described in this Section. a. Adding New Items (Deliveries) [00258] Adding brand-new items to an ALS is simple; we just introduce a new “@” pair representing the new items at the beginning of the ALS. For example, shipping two new coffee mugs to a property might transform its ALS from 253 53 CUSTOMER1 NUM5BER 11-1001AP 1.0@0.84, 1.0@0.24 ^{[00259] to become} 2_{.0@1.0, 1.0@0.84, 1.0@0.24.} i. Mathematical Notation [00260] In order to be able to talk about these operations, each stocking level adjustment will be represented as a function mapping one ALS onto a new one. The additional of inventory as per above will be notated as supply_^. b. Voluntary Removal of Items (Returns) [00261] Removing items voluntarily means removing the “worst” items from the ALS; we want to retire the old, worn-out items rather than newer inventory. In simple cases where only whole items are represented in the ALS, this is simple; the proper mathematical formulation is more complicated when fractional or negative quantity items are present, however. [00262] Let ^^ be the (possibly fractional) quantity of items to be removed. It should be clear that we require 0 ^ ^^, and in order to avoid a stocking failure, we also require ^^ ^ ^^ ^^. The desired transformation will have the property that: ^^ ^^^ᇱ ൌ ^^ ^^ െ ^^ ^{[00263] We begin with a simple example: To remove 0.75 of an item from the ALS} 0_{.5@1.0, 1.0@0.5, 0.5@0.2} ^{[00264] would produce the new ALS} 0_{.5@1.0, 0.75@0.5} [00265] Here, the first 0.5 of removal came from the lifetime level 0.2, and thus and additional 0.25 had to be removed from lifetime level 0.75. [00266] In general, the removal process can be described in general this way: ^ A valid drop consists of removing zero or more items from the end of the ALS list, and then possibly reducing the value of ^^_^, which is the quantity of the last item remaining in the list, while maintaining ^^_^ ^ 0. ^ The removal of ^^ items from an ALS is the minimal valid drop (drops fewest items) which satisfies ^^ ^^^ᇱ ൌ ^^ ^^ െ ^^ after the drop. 25315 54 CUSTOMER NUMBER 11-1001AP [00267] In effect, this rule addresses negative quantity items it may encounter during voluntary removal by discarding the item pair and increasing the amount of reduction that remains to be accomplished. i. Mathematical Notation ^{[00268] The function notation for the process of item removal from an ALS shall be} r_emove^. c. Involuntary Removal of Items (Breakage) [00269] In the involuntary case, it is impossible to guarantee that the coffee mug that is broken is the most worn one. For simplicity, we assume that items break one at a time, in unit quantity (that is, the amount of the removal ^^ always ൌ 1.0). i. Estimating Lost Available Lifetime [00270] Most breakage events happen because items are being handled, either by guests or housekeeping staff. As in general items with higher availability are assumed by PlentiModel to be used more, it is logically consistent to assume this for breakage as well. [00271] To reflect this, PlentiModel asserts that the likelihood of an item breaking is proportional to its available lifetime. It is then easy to see that the estimated probability of breakage for pair within an ALS can be computed as follows: ^^{^} ^{^ ^ ^^} ^{^ ^} ^ ^ൌ ^_{^ ^^ ^^} ^. [00272] Note that these are obviously guaranteed to sum to 1.0, but that negative probabilities can occur. PlentiModel simply allows this to occur as it does not cause fundamental challenges. [00273] Next, PlentiModel computes the expected loss of available lifetime from this breakage event. This can be computed simply by adding up the losses that occur from each case: 2 55 CUST5OM3ER1 NUM5BER 11-1001AP ^ ^^ ^^ ^^ ^^ ^^ ^^ ^{^^ ^^}ଶ ^^ ^ ^{^ ^} ^_^^௧ ൌ ^ ^^_^ ^^_{^ ൌ ^} . ^ _^ ^^ ^^ ^^ [00274] Updating the [00275] Now, this

subtracted from the system, while destroying exactly one unit of quantity. That is, we want: ^^ ^^ ^^′ ൌ ^^ ^^ ^^ െ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_^^^௧ _{^^ ^^′ ൌ ^^ ^^ െ 1.0.} [00276] No item within the ALS is likely to exactly match the lifetime that must be removed. So instead of attempting to remove an item pair, PlentiModel applies breakage by simply adding a new item pair െ1.0@ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_^^^௧ [00277] to the ALS. Note that this item has a negative quantity. It must be sorted into the proper position in the ALS based on the value of lifetime_୪୭^^. ii. Mathematical Notation ^{[00278] Mathematically, the breakage operation on an ALS shall be notated as} b_reak^. 10. Termination [00279] As we will see in a later section, the PlentiModel billing system uses a bill-as- you-wear model, in which billing occurs for all activities that reduce the TAL for an item set. [00280] When a customer of Plentiful Stays chooses to leave the system, either entirely or for individual products, they must still pay for the remaining partial lifetime for the items (which they keep possession of). Rather than charging customer a sudden and possibly hefty bill, PlentiModel accounts for this by applying termination wear to these items over time. [00281] Items that have been terminated are tracked separately by PlentiModel, using the same available lifetime set (ALS) structure as in-service items use. Termination wear is applied in a uniform basis over time to the items (thus incurring termination 56 CU 2ST5OM3ER1 NUM5BER 11-1001AP charges). The rate at which this occurs is calculated in an analogous way to standard aging wear, based on a rate of termination wear, ^^. One distinction is that termination never applies wear to negative levels. [00282] So, if a duration of time passes such that termination wear of ^^ applies to this item set, then the updated set would be: ^^_^ ^ᇱ ൌ ^^_^ _^^^ ^ᇱ _{ൌ ^^ ^^ ^^ ^ ^^^ െ ^^, 0^.}

a. Total [00283] Corresponding to the total available lifetime (TAL), the lifetime represented in the terminated items is defined as the total termination lifetime (TTL), using a similar definition: ^^ ^^ ^^ ൌ ^ ^^_^ ^^_^ . ^ [00284] Here, however, ^^ and ^^ refer to the quantity and lifetime, respectively, of terminated (rather than active) items. b. Termination Properties [00285] This novel approach to termination has many notable properties: ^ Customers are billed for the lifetime remaining in their items, as modeled by the system ^ Every portion of “lifetime” for items is accounted for both in the modelling and the billing system ^ If a customer terminates an item at the end of its usable life, there are no termination fees ^ The rate of charge of termination fees (which is based on termination wear) decreases over time and goes to zero once all termination wear has occurred. ^ The maximum period of time that the termination may be “financed” over is selectable by Plentiful Stays, based on the Full Lifetime Data for termination of the product. 2T5OM3 57 CUS ER1 NUM5BER 11-1001AP ^ Individual products can have unique termination properties and be aggregated smoothly into the overall billing system. 11. Modeling Single-Use Items [00286] Single-use items, in contrast to the multi-use items discussed above, are “used up” when they are used. This applies to items like paper towels, bath products, and other items within the vacation rental property. [00287] This is also the proper model for most products within the HUB, even if those products are considered “Multi-Use” within the VRP. Sheets are shipped to VRPs from the HUB, and then are effectively “used up” from the point of the warehouse. [00288] The modeling system for single-use items is used both for single-use items at the VRP but is also the basis for the HUB modeling system within PlentiModel. Currently, Plentiful Stays does not offer any single-use (at the VRP) products for sale. The technology presented here is used extensively, however, in modeling VRP multi-use products, which are “single-use” within the warehouse (once an item is shipped, it can’t be shipped again, obviously, so it’s single-use.) [00289] Figure 6 is an example flowchart roughly illustrating how PlentiModel makes the decision to issue a purchase order for some number T new towels to SUP (supplier). Some terms used in the flowchart are not yet described, and the reader may find it valuable to return to this figure after completing the “4. PlentiModel in Detail” section. [00290] Modeling single-use items is quite different from multi-use items. For the multi-use case, PlentiModel keeps a fixed quantity of the item (referred to as the stocking quantity) available at the property at all times. The focus becomes of the remaining available lifetime in those items and replacing used-up items with fresh items from the warehouse. [00291] For single-use items, however, the focus shifts to the quantity of the items provided. In traditional inventory systems, this is modeled as a single value representing the “known” quantity. However, within PlentiModel, it is impossible to 58 CU 2ST5OM3ER1 NUM5BER 11-1001AP know the exact quantity, because the wear (use) of the item is modeled from activity signals, and thus is not fully determined. [00292] To accommodate this, PlentiModel uses a statistical inventory model, in which a distribution for the expected quantity of inventory found at a location is kept, rather than a single value. This innovation naturally incorporates concepts such as auditing, estimated usage, uncertain shipment quantities, and other features into a single integrated system. a. Inventory Distributions [00293] Rather than use a single value to represent the inventory level, PlentiModel takes a more general approach based on using a probability distribution to represent inventory levels. These will be referred to as an inventory distribution and play the corresponding central role in handling single-use items that the available lifetime set does for multi-use items. i. Mathematical Notations [00294] Inventory distributions will be represented using double-struck capital letters such as ^^ or ^^. ii. Normal Distributions [00295] For simplicity, PlentiModel uses a standard Normal distribution to represent inventory distributions for an individual product at a location. This same distribution is, logically, used to represent quantities to be shipped in to or out of the location. Because the sum or difference of two Normal distributions is another Normal Distribution, this makes the required “inventory arithmetic” simple. [00296] This distribution does allow for “fractional” inventory levels. For some products, like fuel oil, this is logical. However, other products do not logically permit fractional levels. However, this does not substantially impact performance of the system for typical cases, and the Normal distribution may be used. An inventory 253 59 CUSTOMER1 NUM5BER 11-1001AP distribution based on a difference of two Poisson distributions (which are integer values) may be able to model exact integer valued inventories. Use of the Poisson distributions has not been found to be necessary for the current suite of products offered by Plentiful Stays [00297] The normal distribution with mean ^^ and variance ^^^ଶ will be represented using the notation ^^_ఓ;ఙమ

iii. [00298] Note that, depending on the distribution family used, negative inventory levels may be possible. This is certainly true for the Normal distributions used by PlentiModel. [00299] These negative inventory levels can be justified by thinking of the inventory level as what would be present after all outstanding transactions/obligations have been satisfied. If the current obligations exceed available inventory, then this results in a negative number. In practice, the “negative lobe” of the distributions will be de minimis, or the current distribution will not satisfy the well-supplied test outlined in Section D.12. The Well-Supplied Test for Single-Use Items. [00300] PlentiModel defines the probability contained within this “negative lobe” as the infeasibility of an inventory distribution. The infeasibility of an inventory distribution can thus be defined mathematically as follows: ^_{^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ൌ ^^ ^^} ^{^} _{^^ ^ 0} ^{^} _. iv. Uncertainty [00301] A Normal distribution ^^ is a two-parameter family of functions, normally represented by the parameters mean ( ^^ _^^) and variance ( ^^ _^ ^ଶ ^). PlentiModel actually stores the mean and variance of the distribution, rather than using the mathematically less-stable standard deviation. This approach also simplifies the 25315 60 CUSTOMER NUMBER 11-1001AP mathematical presentation significantly. As the variance increases, the distribution becomes “flatter” and expresses less and less certainty about the inventory level. [00302] At one end of the scale, ^^ _^^ ൌ 0 represents an inventory with no uncertainty, in other words the exact inventory level ^^ _^^ is known. One example where this occurs

is the starting condition of empty warehouse, which contains nothing. Such distributions will be referred to as fully certain. The PlentiModel implementation supports full certainty. [00303] The logical extrapolation of this to the other limit occurs as ^^ _^^ → ∞, and represents the condition of having no information about the level at all.

This is referred to in Gamma terminology as a fully uncertain distribution function. Note that the value of ^^ _^^ is not really well-defined for the fully uncertain inventory distribution. The implementation supports full uncertainty,

which requires special care in certain computational lines. b. Adding/Removing Items from Inventory [00304] The process of adding/removing items from an inventory distribution is quite simple. Thinking about the shipping container as just another inventory location, with its own uncertain inventory, shows that the process is really to add or subtract a shipment ^^ from the inventory ^^. The equations for inventory addition are easily shown to be ^ ^^ ^ ^^^_ఓ ൌ ^^_ఓ ^ ^^_ఓ _{^^ఙమ .} [00305] Similarly, the

are ^^ െ ൌ ^^_ఓ െ ^^_ఓ _{^^ఙమ .} [00306] Note that these

^^ or ^^ are fully uncertain, then so is the result, which is logically consistent. 2 61 CUST5OM3ER1 NUM5BER 11-1001AP c. Auditing [00307] From the equations above, we can see that shipment activities (in or out) can only increase the variance of the inventory distribution ^^. So, uncertainty would simply increase over time, until eventually the system expresses near total uncertainty about inventory levels, and therefore will be unable to meaningfully control the system. [00308] The operation that counteracts uncertainty is actually counting the available inventory, i.e., performing an audit. [00309] Just as shipping operations for single-use products in PlentiModel inherently include uncertainty, so too does the representation of auditing. The counting process is usually imperfect for a variety of reasons, especially of large inventories. It also may in many cases be impossible to conduct a detailed audit of quantities. For example, asking a VR owner to measure their linear feet of toilet paper currently on the property is not likely to be practical. i. Audit Quanta [00310] PlentiModel works with auditing on the basis of a Normal distribution known as the audit quanta. The audit quanta value represents the expected inventory distribution if the audit process counts exactly 1.0, in the absence of other information. [00311] That is, if the original inventory distribution is fully uncertain, and we count 1.0 in the audit, the final result for the inventory distribution after the audit is the audit quanta. Let this distribution, which is fixed for a particular product ^^ within a given warehouse in PlentiModel, be referred to as ^^ ^^_^. [00312] Often, the audit quanta ^^ ^^_^ will have an expected value of 1.0, indicating an unbiased counting method. However, this may not reflect reality. In many cases, it is easier to undercount than overcount, and this can be reflected by ^ ^^ ^^_^^_ఓ ^ 1. [00313] Using uncertainty in the audit quanta, that is allowing ൫

represents uncertainty in the counting process. In the limit, setting the audit quanta to a fully 2 62 CUST5OM3ER1 NUM5BER 11-1001AP uncertain value (൫ ^^ ^^_^൯_ఙమ → ∞) indicates that auditing is impossible; that is, nothing is learned from the counting process. ii. Grouped Auditing [00314] The audit quanta concept can also be used to represent cases in which the counting is not done on individual items. For example, we might count pallets of i^{tems holding 24 pillows each. In this case, it would be appropriate to set ^ ^^ ^^^^ఓ ൌ} 1_{2, possibly adjusted for counting biases.} iii. Selecting the Audit Quanta [00315] The appropriate audit quanta for a particular product and counting procedure can be estimated by experimental data. In practice, however, the PlentiModel algorithm is not strongly sensitive to this data, so any reasonable guess will likely perform well, possibly requiring slightly higher inventory levels. iv. Scaling the Audit Quanta [00316] To make use of the audit quanta value, PlentiModel must obviously be able to be able to “scale” up this value for cases in which the count of items is a value other than 1.0. A simple argument based on dividing the available items into separate piles and counting each of them shows that the proper scaling to generate the audit distribution ^^, given the count of items from the audit is ^^ would be: ^^_ఓ ൌ ^^൫ ^^ ^^_^൯_௨ _.

v. Applying the Audit [00317] Finally, PlentiModel must apply the resulting audit distribution ^^ to update the inventory distribution ^^. Insight into how this might be accomplished can be found by realizing that the existing inventory distribution can be thought of as the result of an 2ST5 63 CU OM3ER1 NUM5BER 11-1001AP audit distribution ^^ applied to a fully uncertain inventory level (recall this was the definition of how audit distributions work). [00318] Viewed this way, we can see that the operation we need is to combine two audit distributions. This yields a symmetric operator that will be denoted as ^^ ⋅ ^^. The operator is symmetric with one minor exception caused by a contradiction explored in the next section: D.11. c. vi. Mathematical Implementation. [00319] An application of standard Bayesian statistics shows that this operator can be defined for general probability distributions via the formula ^^{^ ^^^ ^^ ൌ ^^^ ^ ^ ^} ^{^ ^^^ ^ ^^ ^^ ൌ ^^} ^{^^ ^^ ^^ ⋅ ^^ ൌ ൌ} _^ . ^_{^ ^^^ ^^ ൌ ^^^ ^^ ^^^ ^^ ൌ ^}

[00320] It is a well-known property of the Normal distributions that this operation ^^ ⋅ ^^ yields another Normal distribution, with mean and variance given by the following formulae: మ ^^ ^ మ ^_{^^ ⋅ ^^^} ^{^^ఙ} _ఓ ^^_ఓ ^^_ఙ _{ఓ ൌ} ^^ ^ ^^ This “self-replicating”

one of the reasons that working with the Normal distribution is so convenient here. If a distribution family is used that is not self-replicating, then an approximation to the result would have to be made at this point. [00321] These formulas must be carefully implemented for the cases in which ^^_ఙమ or ^^ మ → ∞. It is easy to show that when ^^_ఙమ → ∞, ^^ ⋅ ^^ ൌ ^^; a

applies for ^^_ఙమ → ∞. In the case where ^^ and ^^ are both fully uncertain, so is the result. [00322] One final case that causes issues is if both ^^ and ^^ are fully certain. This case represents the idea that we are completely certain how many items are inventory, but the count from the audit indicates complete certainty in some other value. This 64 CU2ST5OM3ER1 NUM5BER 11-1001AP case is a mathematical contradiction, and the formulas above degenerate. PlentiModel resolves this case by assuming that the audit represents more current information, and therefore in this case PlentiModel takes the audit information ^^ as the final result. d. Termination [00323] Just as for multi-use items, PlentiModel must have an approach for handling termination of single-use items. The situation is different from that for multi-use items, as there is no “stocking level” that is being directly controlled. If too many paper towels are shipped to a VRP, the expected behavior is simply for the customer to work through those over time, thus delaying shipment of new products. [00324] So, termination here only applies when a customer leaves a particular supply service, such as paper towels, all together. Just as for the multi-use case, a separate termination inventory distribution ^^ is maintained, separate from the active inventory distribution ^^. At the moment of termination, the full existing active inventory is “shipped” to the termination inventory distribution, replacing the active distribution with a fully certain zero. [00325] Then, over time, PlentiModel applies termination wear to the termination inventory distribution, and this generates termination charges just as for the multi- use item case. This process terminates when the total termination lifetime ( ^^ ^^ ^^) equals zero, which will occur when the mean value ^^_ఓ ൌ 0.

12. The “Well-Supplied” Test for Multi-Use Items [00326] The primary objective of the PlentiModel system is to ensure that the managed vacation rental properties are well-supplied with items at all times. This is done by monitoring not only actual usage that has occurred for each item set at the property but expected usage before the next shipment. 253 65 CUSTOMER1 NUM5BER 11-1001AP [00327] This leaves the question of how to assess whether a predicted state of the property, as expressed by its collection of Available Lifetime Sets (ALS), is well- supplied or not. [00328] The strategy that PlentiModel uses to define the well-supplied test uses the following logical sequence of steps: 1. Define the notion of a cascade ALS, which is an ALS designed to represent a potential supply of items to a VRP based on idealized shipping and wear rates for that rental. 2. Select a particular idealized cascade to target, which we will call the perfect cascade. The perfect cascade is the idealized cascade which best targets VRP supply and efficiency needs, as outlined below. 3. Define a template ALS for each item group at the VRP. This is based on a slightly modified form of the perfect cascade that allows some “imperfections” in the supply—this avoids requiring “perfection” anymore—simply good enough will do. 4. Assert that the property is well-supplied at any given time if it is at least as well supplied as the “template” ALS. This requires a comparison operator to determine if one ALS is superior to another. [00329] Each of these four components is discussed in its own section below. a. Cascade ALS [00330] A cascade ALS is a hypothetical ALS describing the quantities and lifetimes of a particular item set at a VRP. It is designed to represent an abstract ideal set of items to be present at the rental. It is idealized from the real-world in the following ways: ^^{The cascade assumes shipment of partial items is allowed; it can send} 0_{.35 of a wine glass, for example, whereas in reality this is impossible;} 66 CU 2ST5OM3ER1 NUM5BER 11-1001AP ^ The cascade assumes that we ship the same quantity of product, ^^, each and every month and have the VRP owner return an equal amount of “used-up” items each month; ^ Thus, the total quantity (TQ) remains constant for all time. PlentiModel requires this value to be integral, and it is referred to as the stocking level (level_{^^୭ୡ୩୧୬^}); ^ cascade assumes that typical, average wear occurs each and

This wear operator will be represented by wear_ୟ^^. [00331] Given these assumptions, the cascade ^^ is the unique ALS that has the following properties: ^^{^ ^^^ ^^^ ൌ ^^ ^^ ^^ ^^ ^^^௧^^^^^^} ^_{^^ ^^ ^^ ^^ ^^ ∘ ^^ ^^ ^^ ^^ ^^ ∘ ^^ ^^ ^^ ^^^ ൌ ^^.} [00332] This last says take the proposed

cascade ^^ and 1. Ship ^^ new items 2. Have owner return ^^ worn items 3. Apply one month of average wear [00333] If ^^ is a cascade, this brings the ALS right back to where it started. This property allows the “idealized cascade” to go on in perpetuity, keeping a uniform set of items at the property at all times, month after month. [00334] Under some circumstances, it is possible for the idealized cascade to not exist. This happens when the monthly wear levels are so extreme that it is impossible to keep the VRP supplied. For example, since perfect cascades are defined on a monthly shipping basis, it is clear that fresh flowers will wilt before the month is up, no matter how many are shipped, and therefore there can be no perfect cascade. Since the cascade can be defined on any time scale one desires, there is an extension to a continuous cascade, which provides for continuous shipping of infinitesimal product quantities. This extension would address the theoretical issue 67 CU 2ST5OM3ER1 NUM5BER 11-1001AP cited here. This is not currently implemented in PlentiModel but is a known extension as part of Gamma i. Computing a Cascade [00335] Given values for level_{^^୭ୡ୩୧୬^}, ^^, and wear_ୟ^^, PlentiModel uses the fact that the “ship-return-wear” cycle is convergent to approximate the cascade by starting with an initial ALS of ^^ ^^ ^^_^^^௧^^^ ൌ ^^ ^^ ^^ ^^ ^^_^௧^^^^^^@1.0; [00336] that is, a full then applying the “ship-return-

wear” cycle to this ALS as many as necessary compute the perfect cascade to the desired precision. It can be mathematically shown that the perfect cascade can be mathematically determined to be an offset exponential pattern, where ^^_^ ൌ ^^^{^} െ ^^ for some real values ^^, ^^, and thereby produce a more precise mathematical derivation of the exact perfect cascade; however, the approximation approach cited above is less prone to programmer error [00337] When a cascade does not exist for the given parameters, it can be shown that this process will eventually produce a service fault during a monthly wear application step of our approximation algorithm. Though it is possible that the algorithm terminates with an approximation before this occurs. In this case, the cascade is almost feasible, and the approximation is still valid ii. Understanding Cascade Structure [00338] In order to illustrate general properties of a cascade structure, which then informs later details of the PlentiModel method, a simple example suffices to explain the general case. ^^ ^^ ^^ ^^ ^^_^௧^^^^^^ ൌ 5

[00339] This run procedure outlined above, yields the following result (rounded to three decimal places): 68 CU 2ST5OM3ER1 NUM5BER 11-1001AP ^^. ^^@ ^^.775, 0.8@0.579, 0.8@0.409, 0.8@0.262, 0.8@0.135, 0.8@0.024, 0.2@ െ 0.072. [00340] Figure 8 is an example bar chart of the above example cascade ALS. Note that: ^ Because the items are of fractional size, there are 7 individual items in the ALS, even though level_{^^୭ୡ୩୧୬^} ൌ 5. ^ Each item within the ALS has quantity equal to ^^ ൌ 0.8 except the last item, which contains the remaining residual quantity (0.2) so that the total adds up to level_{^^୭ୡ୩୧୬^} ൌ 5. ^ The ending item has negative available lifetime. In general, multiple negative items may exist at the end of a cascade. ^ The available lifetime in each ALS item lies on a descending curve with positive curvature. The typical cascade starts with items at close to perfect quality, falling towards items with negative available lifetime at the end. b. Defining the “Perfect” Cascade [00341] The next step in the PlentiModel approach to defining the well-supplied concept is to identify a single perfect cascade from all possible cascades for an item group. PlentiModel does this in a way to achieve the following objectives: ^ The product returned from the VRP in each shipment has zero net available lifetime ^ The product supply is expected, on average, to meet wear needs of the property ^ The supply sent to VRP is minimized subject to the above requirements, keeping costs low [00342] In order to focus on a single instance of the cascade calculation as the perfect cascade to use for defining the well-supplied concept, PlentiModel must chose values for the three basic parameters of the process: ^ ^^ ^^ ^^ ^^_^௩^ ^ level_{^^୭ୡ୩୧୬^} 69 CU 2ST5OM3ER1 NUM5BER 11-1001AP ^ ^^ i. Calculating ^^ ^^ ^^ ^^_^௩^ [00343] The average monthly wear for a particular item group in a VRP is determined by PlentiModel based on average monthly rental data and an assumption of 30 days of aging per month. This data is then run through PlentiModel’s product usage model to determine usage rates for individual products, which in turn determines wear rates (see section D. 14. The PlentiModel Wear Calculation for Vacation Rental Properties). ii. Selecting level_{^^୭ୡ୩୧୬^} [00344] The total quantity of a given product necessary at the VRP is influenced by several factors. Most important is the quantity of items that are required to be in service at the property. This value is determined on an ad-hoc basis based on details of the rental property. For example, Plentiful Stays currently requires at minimum two fitted queen sheets be available for each queen mattress in the property (whether PS provides that mattress or not). [00345] The quantity of “in service” items required at a property is called the service level and will be denoted level_{^^୰^୧ୡ^}. [00346] It is obviously required that level_{^^୭ୡ୩୧୬^} ^ level_{^^୰^୧ୡ^}, and it might be expected that level_{^^୭ୡ୩୧୬^} ൌ level_{^^୰^୧ୡ^}. However, in certain cases, the stocking level must actually be higher than the service level. This occurs in cases where multiple items have to be shipped every month, and thus multiple items are returned each month. It can happen in this case that some of the individual returned items in the cascade have negative available lifetime and are thus unusable! ^{[00347] To resolve this, PlentiModel uses a retry-based algorithm. It begins by setting} l_{evel^^୭ୡ୩୧୬^ ൌ level^^୰^୧ୡ^, and calculates a perfect cascade from this data. This} c^{ascade is then subjected to a service test described below. If this fails, then} l_{evel^^୭ୡ୩୧୬^ is incremented and a new cascade computed. This process repeats until} 25 70 CUSTOM3ER1 NUM5BER 11-1001AP the service test succeeds. PlentiModel thus keeps level_{^^୭ୡ୩୧୬^} as small as possible because this minimizes wear due to aging, and thus customer charges (see section D.16. The PlentiModel Billing System). iii. Determining ^^ [00348] Given a hypothesized value for level_{^^୭ୡ୩୧୬^}, PlentiModel must finally compute the required value of ^^ before we can compute the perfect cascade itself. [00349] To see what the proper value for ^^ is, note that since the perfect cascade regenerates itself, it is clear that the changes to its total available lifetime (TAL) through the three steps must sum to zero: ^^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^ ^^_ఈ^ ^ ^^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^ ^^_ఈ^ ^ ^^ ^^ ^^ ^^൫ ^^ ^^ ^^ ^^_^௩^൯ ൌ 0. [00350] First, observe that since ^^ ^^^ ^^ ^^^ is given, as level_{^^୭ୡ୩୧୬^}, we can determine exactly how much total available lifetime (TAL) will be lost because of the wear_ୟ^^ operator. That is, Δ ^^ ^^ ^^൫wear_ୟ^^൯ is known. [00351] Secondly, the perfect cascade would like to return items that have no life left in them. Returning items that are still usable is inefficient and returning items that have already expired means the vacation rental is not well-supplied. In other words, PlentiModel would prefer that ^^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^ ^^_ఈ^ ൌ 0. [00352] Finally, there’s a simple expression for the change in TAL because of a supply operation: ^^ ^^ ^^ ^^^ ^^ ^^ ^^ ^^ ^^ ^^_ఈ^ ൌ ^^. [00353] Combining these three results allows us to compute the proper value for ^^ as follows: ^^ ൌ െ ^^ ^^ ^^ ^^൫ ^^ ^^ ^^ ^^_^௩^൯. [00354] PlentiModel uses this computation to determine the value for ^^ for each hypothesized value for level_{^^୭ୡ୩୧୬^}. Note that changes to level_{^^୭ୡ୩୧୬^} result in changes to wear_ୟ^^, and thus a new value for ^^ is computed for each trial. 2531 71 CUSTOMER NUM5BER 11-1001AP iv. Sample Perfect Cascade [00355] As it happens, the cascade that was presented in Figure 8 is in fact a perfect cascade. It is easily verified that the value of ^^ (0.8) in the example is equal to െΔ ^^ ^^ ^^൫wear_ୟ^^൯, as required. [00356] We can now verify that the “returned items” from the cascade have exactly zero available lifetime. To see this, note that we must return ^^ ൌ 0.8 items each month. These items will be all of the last set entry (0.2@ െ 0.072), plus some portion (^{0.6) of the penultimate entry (0.8@0.024). This adds up to:} 0_{.6 ⋅ 0.024 ^ 0.2 ⋅ െ0.072 ൌ 0.000} _{as required by the perfect cascade test.} v. Well-Supplied Template ALS [00357] Next, PlentiModel performs adjustments to the perfect cascade to generate a well-supplied template ALS. [00358] To see why this modification is necessary, note that a typical perfect cascade will have items at nearly full lifetime, so ^^_^ ^ 1.0. This occurs because there is always a shipment (of size ^^) every month, so the perfect cascade will contain this item with only one month’s wear on it. [00359] Given this, it will prove impossible for any ALS we might compare this with to be superior unless it also has equally fresh items, even in some tiny amount. Since in reality we can’t ship a “tiny amount,” this would force PlentiModel to ship at least one new unit every month, which does not meet objectives. [00360] So, a modification is made to the perfect cascade to generate the template, which consists of PlentiModel adding the following two items to the ALS: െ1.0@1.0 ^_1.0@0.0. [00361] This seeming nonsense set of items can be understood if carefully unpacked. The first item removes one item of full quality from the set, by adding a negative quantity. The second item replaces this item with an item of zero quality. Thus, the 2531 72 CUSTOMER NUM5BER 11-1001AP total quantity of items is unchanged, but the total available lifetime is reduced by one. [00362] This modification effectively allows PlentiModel to be up to one whole item short in lifetime, but not quantity, when trying to match the perfect cascade. [00363] Sample Template ALS [00364] Applying this process to our sample perfect cascade would yield the following template: െ^{1.0@1.0, 0.8@0.775, 0.8@0.579, 0.8@0.409, 0.8@0.262,} 0_{.8@0.135, 0.8@0.024, 1.0@0.0, 0.2@ െ 0.072.} [00365] Note that the 1.0@0.0 item is presented before the negative quality item, as required by the ALS rules. c. ALS Superiority [00366] With this background material in place, PlentiModel now uses the template to determine whether a particular VRP is well-supplied. To do this it must be able to compare the items currently at the VRP and see if they are superior (or equal) to those in the template. i. Mathematical Notations [00367] Since in this section we are comparing two (or more) ALSs, it is necessary to be able to distinguish computations on different ALS items. We shall use capital script letters (such as ^^ and ℬ) to indicate individual available lifetime sets. [00368] Computations on these ALSs shall be indicated by using subscripts on the basic variables introduced previously. So, for example, ^^ ^^ _^^ is the total quantity for ALS ^^, and ^^ ^^ ^^_ℬ is the total available lifetime for ALS ℬ. 25OM3ER1 73 CUST NUM5BER 11-1001AP ii. High-Lifetime Quantity [00369] An important concept in comparing two ALSs is to compute the total quantity of high-lifetime items, that is, items with an available lifetime ^ some threshold value ℓ. This is defined mathematically as follows: ^^ ^^ ^^^ℓ^ ൌ ^ ^^_^ . ^_{௪^^^^ ^^ஹℓ} _{[00370] Note 0.}

[00371] Now, we can define a comparison operator between two ALSs based on ^^ ^^ ^^. For two ALSs ^^ and ℬ over the same product (say, towels), we will say that ^^ is superior to ℬ this fashion: ^_{^ ^ ℬ ≡ ∀ℓ: ^^ ^^ ^^ ^^} ^{^} _ℓ ^{^} _{^ ^^ ^^ ^^ℬ} ^{^} _ℓ ^{^} _. [00372] In other quality level ℓ, ALS ^^ has

at least as many items at or above that quality level as ℬ does. [00373] Required Properties of ALS Superiority [00374] As defined, superiority has many important mathematical properties that are necessary to its use within PlentiModel. [00375] The first two are the standard properties of a partial order: ^^ ^ ℬ ∧ ℬ ^ ^^ ⇒ ^^ ≡ ℬ ^^ ^ ℬ ∧ ℬ ^ ^^ ⇒ ^^ ^ ^^ [00376] Note that

order; not any two ALSs are comparable. _{[00377] Because ^^ ^^ ^^} ^{^} _െ∞ ^{^} _{ൌ ^^ ^^, it can be easily shown that} ^^ ^ ℬ ⇒ ^^ ^^ _^^ ^ ^^ ^^_ℬ [00378] Next is a property

^^ ^ ℬ ⇒ ^^ ^^ ^^ ^^_௫^ ^^^ ^ ^^ ^^ ^^ ^^_௫^ℬ^ [00379] In other words, if one ALS is superior to another, it remains so after any possible wear is applied. This property is non-trivial; it can be shown by proving it for uniform and proportional wear separately, and therefore also applies to any chain 74 CU 2ST5OM3ER1 NUM5BER 11-1001AP of these, including the “combination” wear generated by the “limit of slices” technique. [00380] This property is crucial to defining any notion of ALS superiority. If one product supply is truly superior to another, it must logically mean that it is superior in all possible future wear scenarios. The definitions of ALS have been carefully selected so that this property holds. 13. The “Well-Supplied” Test for Single-Use Items [00381] PlentiModel requires a corresponding set of calculations to those in the previous section for handling single-use items. The well-supplied test for single-use items is, however, considerably simpler. [00382] This is possible because single-use inventories are correctable. That is, a single shipment of items can always restore the inventory to a healthy distribution of products; the only question is, how much product needs to be sent? Contrast this with the multi-use case, where there is no practical way to generate the perfect cascade, with its graduated product lifetime curve, by shipping new items. [00383] PlentiModel defines an inventory distribution ^^ as well-supplied if there is a low chance that we have already run out of that product. If we define the allowed chance of running out of this product as the shortage probability ^^_{^୦୭୰^ୟ^^}, then the inventory is well-supplied if: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ _^^ ^ ^^_^^^^௧^^^. 14. The PlentiModel Wear Calculation for Vacation Rental Properties (VRP) [00384] The first step in coordinating activities at the Vacation Rental Property (“VRP”) is to take the available information (“activity data”) about usage of the property and convert that into estimates of wear for each item set in use at the property. This section explains these steps that PlentiModel uses to do these computations. 253 75 CUSTOMER1 NUM5BER 11-1001AP a. Collecting Raw Activity Data [00385] Raw activity data for the Vacation Rental market consists primarily of booking information. This is reported to PlentiModel using a booking event. [00386] Each booking event contains the following information: ^ Date on which the booking starts (the date of an event is present for all events) ^ Duration of the booking, in days (logically equivalent to the end date of the booking) ^ A listing of guests for the booking, by guest type; for example, “2 adult, 3 child, 1 infant.” [00387] PlentiModel allows for overlapping booking events, so it is permissible to have a booking from Jan 1 through the 9^th, as well as Jan 3 through the 4^th. [00388] The creation or editing of booking events within PlentiModel may be performed manually, but they could also be collected automatically from third-party software & services, such as AirBNB and VRBO, or rental manager software such as Escapia. Each additional source of booking data requires a custom-written code module to collect data from that particular source and enter it into the PlentiModel database. [00389] Note that, consistent with the highly speculative nature of the PlentiModel algorithm, booking data for future dates should be collected and updated within PlentiModel as soon as it is available; this maximizes the quality of PlentiModel’s projections and thus improves supply for vacation rental owners. b. Resolving Booking Data into Daily Guests [00390] The first step of computation PlentiModel uses is to convert this booking event data into the number of guests, of each guest type, at the property on each day. Let ^^_௧ to be the number of guests of type ^^ at the VRP. [00391] This is a logically straightforward calculation, simply summing up, for each date, the guests, by type, from all booking events that overlap that date. In practice, 253 76 CUSTOMER1 NUM5BER 11-1001AP PlentiModel uses a traditional differential algorithm for accomplishing this to improve efficiency. c. Mapping Guests into Channels [00392] Next, PlentiModel must map our guests at the property into channels. Or, informally, the system determines which beds everyone sleeps in. This is a statistical calculation, so it really computes an estimated probability that each channel is used by a given type of guest. [00393] The novel approach used for doing this in PlentiModel is based on forming the problem as a constrained quadratic programming problem, which can then be solved using standard mathematical optimization packages. i. Mathematical Notation [00394] Let ^^_௧,ℂ be the estimated probability of a guest of the given guest type ^^ sleeping in the specified channel ℂ. PlentiModel’s task then is to compute ^^_௧,ℂ for each combination of guest type ^^ and channel ℂ. ii. Channel Preferences [00395] PlentiModel must have some basis for deciding who would like to sleep where. For example, in the “2 adult, 3 child, 1 infant” booking example given earlier, one would expect that the two adults are a couple and would typically sleep in the master suite (channels ^^ and ^^). This means that [00396] In order to have some basis for deciding who would like to be where within the VR, PlentiModel uses assigned guest preference data. For each pair of guest types ^^ and channel ℂ, the non-negative real value ^^_௧,ℂ represents the relative preference for this combination. A zero value indicates that this will never occur (such as an adult sleeping in a crib, for example). 77 CU 2ST5OM3ER1 NUM5BER 11-1001AP (a) Configuring Channel Preference Data [00397] This data is configured when the VR is first setup by Plentiful Stays. The attraction of the master suite for adult guests, for example, can be represented by assigning a larger value for ^^_{ୟ^^୪^, ^^} and ^^_{ୟ^^୪^, ^^}. In general, use zeros sparingly; even tall adults will sleep on the couch if there’s no place else, so a positive (but smaller) value is appropriate here. iii. Setting up the Optimization Problem [00398] Since PlentiModel solves for the channel mapping using a constrained quadratic optimization problem, it must now translate our problem into the appropriate form. (a) The Objective Function [00399] PlentiModel “flips” our problem upside down and works using “dis- preferences.” That is, we minimize guest upset rather than maximizing guest preferences. This leads to the basic minimization problem: ^_{^ ^^ ^ ^^ ൌ ^} ^{^^ଶ} ^௧,ℂ _൩. [00400] As an unconstrained

returns ^^_௧,ℂ ൌ 0. Clearly, some constraints are needed to complete the formulation. These are presented next. (b) The Constraints [00401] The necessary constraints of our problem turn out to be of three types: ^ All estimated guest probabilities must be non-negative; ^ A single channel ℂ cannot be utilized more than 100%; ^ The total estimated probabilities for each guest type ^^ must sum to the number of that guest type at the rental. [00402] These translate into mathematical notation as follows: ∀_௧,ℂ: ^^_௧,ℂ ^ 0 CU 2ST5OM3ER1 NUM5BER

∀_ℂ : ^ ^^_௧,ℂ ^ 1 ∀௧ ^^_௧ iv.

of the Optimization Problem [00403] It can easily be seen that this problem is a constrained positive-definite convex quadratic programming problem, and thus has a single unique well-defined solution unless the constraints are infeasible. [00404] Infeasibility occurs in a mathematical sense when it is impossible for the VRP to accommodate the guests requested. A simple example of this is a “sleeps 4” where there are actually six guests. [00405] Note that, although not explicitly constrained, it is easy to see mathematically that ∀_௧,ℂ: ^^_௧,ℂ ^ 1 [00406] also holds.

v. Solving The Optimization Problem [00407] As a convex quadratic programming problem, this system can be solved using a variety of available optimization packages. In fact, the problem has special structures (diagonal objective matrix, sparce constraints) that may make specialty solvers more efficient. [00408] In addition to “mathematical infeasibility” discussed earlier, infeasibility can also occur in a numerical sense, because of rounding errors. A “sleeps 4” that has four guests is likely to run into this issue. It is therefore important that whatever optimization package is used manages this case gracefully and will return a “near solution” for cases where minor infeasibility occurs. [00409] Finally, to prevent any weird things from happening in this case, PlentiModel forces all of the computed estimated probabilities to the range 0..1 via a simple post- pass. 2T5OM3 79 CUS ER1 NUM5BER 11-1001AP d. Generating Estimated Item Wear [00410] The next step of this process is to use these calculations to estimate wear applied to actual items within the VRP. The primary wear types used by PlentiModel currently are aging (the passing of time), and guest-nights, which represents a single guest using an item for one day. [00411] Aging obviously occurs directly with the passage of time, and so is not related to daily guest-channel data, just the number of days that pass. This wear type (wear_ୟ^୧୬^) is of uniform wear type. [00412] However, guest-night data is determined based on a general linear mapping from daily guest-channels. That is, there is a coefficient of usage ^^_^,௧,ℂ, which indicates how much usage of product ^^ occurs because of a guest of type ^^ occupying channel ℂ. This logically three-dimensional space is configured when items are added or removed from a VRP, using the adjust service event. By default, items provided at the VRP are assumed to service all channels and guest types equally, which would be represented by the values ∀ ^^,ℂ: ^^_^,௧,ℂ ൌ 1. [00413] However, limitations on types are permitted. Omitted cases

are assigned ^^ ൌ 0, indicating that no usage occurs. Values between zero and one indicate some chance of usage occurring. [00414] The total guest-night data for each item set (and thus ALS) is calculated by summing all the contributions: ^^ ^^ ^^ ^^_{^௨^^௧ି^^^^௧^,^} ൌ ^ ^^_^,௧,ℂ ⋅ ^^_௧,ℂ. [00415] Note that

15. The PlentiModel Shipping Algorithm [00416] This section describes the algorithm used by PlentiModel to determine when, and how much, to ship to an individual VRP to ensure it remains well-supplied all the time. [00417] The algorithm balances several competing objectives: 2531 80 CUSTOMER NUM5BER 11-1001AP ^ Resupply shipments should arrive on a semi-predictable schedule (same day of the month) ^ Fewer larger shipments of items are preferred, with all items coming from the same location arriving on the same day ^ Minimal turnover of products while still maintaining the well-supplied status [00418] The procedures for handling this depend on speculative VRPM as a fundamental operation, which is repeatedly performed to investigate various “what- if” scenarios. a. Supplier Parallelism [00419] Although most products sold by Plentiful Stays are provided directly from a Plentiful Stays warehouse (HUB), other products such as mattresses are directly drop-shipped by manufacturers. [00420] PlentiModel address this by treating each supplier (including Plentiful Stays itself) as a separate shipping problem. Shipments from one supplier do not affect shipments from other suppliers. b. When Does PlentiModel Require a Shipment? [00421] The PlentiModel algorithm schedules a shipment from supplier ^^ on any given day ^^ based on the following test: a shipment is required if VRPM simulation of the property will become ill-supplied for a product sourced from ^^ before the next regularly scheduled shipment date. [00422] Note that this means that PlentiModel can ship on any day whatsoever if conditions at the VRP demand this. For example, if the owner reports that a pillow has been destroyed then PlentiModel will immediately schedule a pillow delivery if the property has become ill-supplied. [00423] Normally, however, this causes shipments to occur on a regularly scheduled shipment date. This is because when ^^ is a regularly scheduled shipment date, then the next such date suddenly jumps to one month out. If the property is close to 2531 81 CUSTOMER NUM5BER 11-1001AP running out of any product, this is likely to push it over the edge into ill-supply, forcing the shipment. c. What Items Does PlentiModel Send in a shipment? [00424] Once the decision to “send a box” from supplier ^^ has been made, it makes little sense to just send one pillow to meet the immediate need. Instead, PlentiModel ships sufficient quantity of each product to keep the property well-supplied until a date in the future, referred to as the target resupply date. i. Determining Target Resupply Date [00425] The target resupply date ^^ ^^ ^^ is chosen to be the last regularly scheduled shipment date that occurs before date ^ ^^ ^ 92^; i.e., three months from ^^. Note that the value of 92 used here can be easily changed if Plentiful Stays decides a longer or shorter resupply period is appropriate. ii. Computing Resupply Wear [00426] Next, PlentiModel analyzes for each product the expected wear over the resupply period. This is logically the functional composition of each daily wear function, based on all wear expected to occur on that day between ^^ and ^^ ^^ ^^. This net wear function will be notated as wear_{୰^^^୮୮୪^}. [00427] Note that, although the net wear function wear_{୰^^^୮୮୪^} will, of course be a linear function when applied to an ALS with known total quantity ( ^^ ^^); however, it is not, in general a specific instance of our generalized combination wear methodology. iii. Selecting Product Quantity to Send and Return [00428] In the Plentiful Stays business model, new items are shipped to the VRP in exchange for existing, more worn items currently at the VRP. This allows the company to perform quality control, and also avoid having clients sell Plentiful Stays products outside the system. 25315 82 CUSTOMER NUMBER 11-1001AP [00429] Normally, the send and return quantities will be equal. However, when changes to the stocking level level_{^^୭ୡ୩୧୬^} have recently occurred, this may not be the case. [00430] The basic algorithm used to determine how much to send of a specific product is based on simulating wear_{୰^^^୮୮୪^} repeatedly for larger send quantities until the property is well supplied, starting with a zero send level. ^^{^ ^^ ^^ ^^ ൌ 0} ^begin ^{return ൌ max ^ ^^ ^^^ ^^ ^^ ^^^ ^ ^^ ^^ ^^ ^^ - ^^ ^^ ^^ ^^ ^^^௧^^^^^^, 0^} e_{xit if ^^ ^^ ^^ ^^ ^^ ^^^^^ௗ ∘ ^^ ^^ ^^ ^^ ^^ ^^^^௧௨^^ ∘ ^^ ^^ ^^ ^^^^^௨^^^௬ ∘ ^^ ^^ ^^ is well-supplied} [00431]

at zero. Customer is then asked to return any items in excess of their stocking level for this product after delivery, and then PlentiModel applies the expected wear, out to the t^{arget resupply date. If this is ill-supplied, then we need additional items; increment} s_{end, and repeat from the beginning.} ^{[00432] This occurs until the property is well-supplied, and this determines send and} r_{eturn for this product. This process must then be repeated for all products provided} to the property by the current supplier ^^. iv. When Does PlentiModel Do Shipping Analysis? [00433] This analysis can be expensive to compute even for a single day ^^. Thus, PlentiModel only performs the computations whenever changes occur that might require a shipment: ^ At the time of changes to the required service level for an item group at a VRP; ^ Immediately following a shipment to the VRP (relevant in the case where the shipment amount actually sent is not in accordance with PlentiModel predictions); ^ On each preferred shipment date; 83 CU 2ST5OM3ER1 NUM5BER 11-1001AP ^ Immediately following a breakage event. 16. The PlentiModel Billing System [00434] In a traditional model, items would be billed for when they are delivered to the VRP or would be financed for fixed periods starting on that delivery date. These solutions would produce a chaotic, unpredictable financing model since the date of item delivery is chosen not by the customer, but by the PlentiModel algorithm. Further, these approaches provide no correlation between monthly charges to the customer and their rental success in any given month. [00435] So, instead of these approaches, this disclosure uses an innovative “pay-for- as-used” approach. The basics of this approach include: ^ An initial charge is applied to the customer whenever their stocking level of a product is increased. This corresponds to the shipment of new items that increase how many items are stored at the property, as opposed to new items intended to replace worn items. ^ After this, monthly usage charges accrue whenever the available lifetime of items is reduced based on activity at the rental. ^ When the customer makes changes that reduce their stocking level of a product, including leaving the program entirely, monthly termination charges accrue, corresponding to “bleeding off” any remaining available lifetime over time. a. Total Item Costs [00436] The billing model in PlentiModel begins with an assessed total item cost ( ^^ ^^ ^^) to provide an individual item within a VRP. This value is based not only on the wholesale cost of a replacement item to Plentiful Stays, but also additional expenses such as warehousing, shipping, and employee costs associated with the item. It should be the best estimate Plentiful Stays has as to their total costs for shipping the item to customer and the “after the sale” service process. 253 84 CUSTOMER1 NUM5BER 11-1001AP [00437] All customer charges are then based on the current total item cost for an item. What this means is that customers rates are based on the current replacement costs for the item, varying from month to month—not the costs associated with the item when they acquired it. This contrasts with a traditional “financing” approach, in which costs are associated with a fixed price at the time of purchase. [00438] This approach is necessary because PlentiModel can replace items at arbitrary times. Out of a set of twelve spoons at a VRP, each may well have been shipped at a different time, and thus have a different “retail price” at the time they were shipped. Tracking information at this level would simply produce confusing bills and outraged customers. b. Initial Charges [00439] Whenever the stocking level (level_{^^୭ୡ୩୧୬^}) of a product is increased by an adjust service event, the customer is charged an initial charge for the increase. This consists of a percentage of the total item cost ( ^^ ^^ ^^) to Plentiful for providing the needed items, as shown below: ^^ℎ ^^ ^^ ^^ ^^_^^^௧^^^ ൌ ^^ ^^ ^^ ∙ ^^_^^^௧^^^ . [00440] The initial charge system is used to offset some of the upfront costs to Plentiful Stays for shipping new items to customers and allows the company to control how much of each product’s total item cost is being “financed” by Plentiful Stays. For example, if ^^_{୧୬୧^୧ୟ୪} ൌ 0.5, then only 50% of each product’s ^^ ^^ ^^ must be financed by Plentiful Stays. i. Lost Service Phenomenon [00441] The initial charge for customers also accounts for the “lost service” phenomenon. When a new property is started, PlentiModel will send it a complete s^{et of brand-new items. This might have an ALS such as} 6_{.0 @ 1.0.} 25315 85 CUSTOMER NUMBER 11-1001AP [00442] This is, in fact, of much higher quality than the “perfect cascade” we are trying to imitate, because there are no worn items in this set. [00443] If PlentiModel sent no replacement items until they had entered end-of-life status, then all six items would be on their last legs before new items are sent out, s^{imilar to:} 6_{.0 @ 0.07,} [00444] and at this point Plentiful Stays would have to replace all six as a set, producing this oscillating cycle of “feast or famine” in perpetuity. [00445] This pattern never approaches the “perfect cascade” static condition that PlentiModel is trying to get to. The mathematics of well-supplied have been defined precisely to avoid this condition. Instead, PlentiModel will start replacing items much earlier, building a glide path to the “perfect cascade.” [00446] The inevitable side-effect of this choice, however, is that items will get returned in the first few shipping cycles that have substantial life remaining in them, and therefore are not billed. The initial charge may be selected to approximately cover this “lost service”. (Note that systems in which these pre-used items that are returned from one rental are then distributed to other customers as part of their initial supply are possible. So long as the initial mix of new/used items is such that the “well-supplied” definition is satisfied, this would be permissible. Plentiful Stays has currently chosen not to do this for business marketing reasons.) ii. Wear Charges [00447] As time goes on, the VRPM simulation will cause available lifetime to be used up, both by time passing and by guest utilization. Each month, the total lost lifetime within each item set is summed, and this becomes the basis for the wear charges on that month’s bill. 2531 86 CUSTOMER NUM5BER 11-1001AP iii. Aging Charges [00448] Total available lifetime ( ^^ ^^ ^^) lost from aging effects is accumulated, and an aging base cost is calculated by multiplying this by the total item cost: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_^^^^^ ൌ െ ^^ ^^ ^^ ^^_^^^^^ ^^ ^^ ^^. [00449] Note that since ^^ ^^ ^^ falls over time, Δ ^^ ^^ ^^_ୟ^୧୬^ is a negative value. [00450] This base cost is then multiplied by two factors to determine actual customer charges. First is a customer risk factor, determined by Plentiful Stays’ estimate of the risk of non-payment. This will normally be a number slighter larger than 1.0. [00451] Then, a profit margin is attached to this to determine customer charges. The profit margin for aging charges may be set independently for each product using the PlentiModel Pricing System (see Section D.17. a. i. Pricing Rules) 1 ^{^^ℎ ^^ ^^ ^^ ^^} _^^^^^ ^{ൌ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^} _^^^^^ ^{∙ ^^ ^^ ^^ ^^} _^௨^௧^^^^ ^∙ 1_{െ ^^ ^^^^^^^} ^. [00452] because

these items are not “financed”—customer must pay initial charges in full before receiving items. c. Usage Charges [00453] Similarly, total available lifetime lost for usage affects is accumulated, and a usage base cost is calculated by multiplying this by the total item cost: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_௨^^^^ ൌ െ ^^ ^^ ^^ ^^_௨^^^^ ^^ ^^ ^^. [00454] Then, a profit

customer charges. The profit margin for usage charges may be set independently for each product using the PlentiModel Pricing System (see D.17. a. i. Pricing Rules) 1 ^{^^ℎ ^^ ^^ ^^ ^^} _௨^^^^ ^{ൌ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^} _௨^^^^ ^{∙ ^^ ^^ ^^ ^^} _^௨^௧^^^^ ^∙ 1_{െ ^^ ^^௨^^^^} ^. 2ST5 87 CU OM3ER1 NUM5BER 11-1001AP d. Termination Charges [00455] Whenever the stocking level (level_{^^୭ୡ୩୧୬^}) of a product is decreased by an adjust service event, the excess items currently at the property are placed into termination status. [00456] The set of items that are “terminated” are removed from the “usage” ALS and placed into its own available lifetime set (ALS) data structure. Terminated items are subject to a special kind of wear, termination. [00457] Like other types of wear, termination produces monthly charges, referred to as termination charges, until there is no more available lifetime left in these items. In this way, the “unpaid for” balance of available lifetime is now paid for during the termination phase of the product. [00458] This approach has several interesting and unique properties: ^ The effective “financing term” for termination varies depending on how much life is left in the item, from zero days if the item was already used up when terminated, to a maximum set by the associated full lifetime data for termination for the product. ^ The termination charges for a month of termination always remain the same until the item finally runs out of life; that month will have a pro-rated charge based on how much life was left. ^ The overall termination charges for a product are normally non-increasing; they stay the same from month to month or decrease. Only further adjust service events can increase the termination charge rate. (Assuming that total item cost ( ^^ ^^ ^^) does not change. Changes to ^^ ^^ ^^ can cause increases in termination charges. This can be avoided, if desired, by “locking” in the TIC for each item at the time of its termination, at the expense of a somewhat more complex model.) 25315 88 CUSTOMER NUMBER 11-1001AP e. Computing Termination Charges [00459] Termination charges are computed using exactly the same methodology as other types of wear, except that it uses changes to the total termination lifetime ( ^^ ^^ ^^, see Section D.10. Termination) instead of the ^^ ^^ ^^: ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^_{௧^^^^^^௧^^^} ൌ െ ^^ ^^ ^^ ^^_{௧^^^^^^௧^^^} ^^ ^^ ^^ ^^{^ℎ ^^ ^^ ^^ ൌ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ∙ ^^ ^^ ^^ ^^ ∙ 1} [00460] non-

17. The PlentiModel Product Configuration System [00461] In order to support the above complex calculations, PlentiModel requires a number of detailed parameters on an individual product or property basis. In some cases, specifying all of these values individually would be time-consuming and error prone. To address this, PlentiModel provides methodologies to affect multiple products within groups. a. Product Categories [00462] When they are configured, individual products are placed into one or more product categories. These are simply unique string values that will then be used later to describe groups of products. PlentiModel automatically creates a singleton product category for each product, using the name of the product as the name of the category. Additional categories can be added to each product. By convention, all products are automatically added to the all category, making it possible to conveniently apply rules to all products in the system. [00463] In the following subsections, the structures within PlentiModel that use product categories to specify the parameters needed for the pricing calculations outlined above are explained. 2 89 CUST5OM3ER1 NUM5BER 11-1001AP i. Pricing Rules [00464] The billing system described in the previous section used a variety of values to compute actual customer rates: ^ Initial charge percentage ^ Aging wear profit margin ^ Usage wear profit margin ^ Termination wear profit margin [00465] Logically, each of these is individually controllable for each product supplied by Plentiful Stays. [00466] PlentiModel allows the user to configure one or more pricing rules for determining these values. Each pricing rule applies to a named category and gives a value for each of the four pricing data values cited above, in that order. [00467] For example, we might indicate a general preference for a 35% initial charge a^{nd 50% profit margins for all products using this rule:} P_{ricing^all^: 35%, 50%, 50%, 50%.} (a) Resolving Ambiguity [00468] Obviously, if a product has no pricing rule that applies to it, this is an error, as there is then no way to assign prices for this product. [00469] Another important situation to resolve is when there are two (or more) pricing r^{ules that apply. For example, suppose we have the following set of rules:} ^{Pricing^all^: 35%, 50%, 50%, 50%} P_{ricing^sleep and bath^: 45%, 40%, 40%, 40%} _{Pricing^mattresses^: 60%, 45%, 45%, 65%} [00470] What pricing rules would we use for a Queen Mattress? PlentiModel resolves ambiguity for pricing rules by following the rule that rules specified later take precedence over earlier ones. This causes our example to behave as we would expect, and the Queen Mattress has a termination wear profit margin of 65%. 2 90 CUST5OM3ER1 NUM5BER 11-1001AP ii. Discount Rules [00471] A set of “base charges” is computed by the PlentiModel billing system. These are then modified by a customer-specific system of discounts in order to incentivize individual customers to purchase larger portions of the PlentiModel product offerings. [00472] This is managed by a set of discount rules, similar to the pricing rules previously described. These rules, however, are applied on an individual property basis. That is, each VRP has its own set of discount rules. [00473] (a) Default Rule [00474] In order to ensure that every product at every property has some sort of discount rule to use, PlentiModel automatically inserts the following discount rule for each property: [00475] Discount[all]: 0%, 0%, 0%, 0% (b) Resolving Ambiguity [00476] Obviously, all products will have a discount rule to apply, because of the default rule cited above. However, PlentiModel must still resolve multiple applicable discount rule situations. [00477] Here, the rule is different than for the pricing rules: PlentiModel gives the customer the best possible discount for every category. So, if PlentiModel is c^{onfronted with the following discount rules:} ^{Discount^all^: 35%, 50%, 50%, 50%} D_{iscount ^sleep and bath^: 45%, 40%, 40%, 40%} _{Discount ^mattresses^: 60%, 45%, 45%, 65%} ^{[00478] then the computed net discount rule for a Queen Mattress would be} D_{iscount ^queen mattress^: 60%, 50%, 50%, 65%} 2T5OM3 91 CUS ER1 NUM5BER 11-1001AP EXAMPLE COMPUTING SYSTEMS [00479] Figure 9 is an example block diagram of an example computing system that may be used to practice embodiments of the components of IRASS or IRMF described herein, such as a VRP entity or a HUB entity, the communications between them and resource modeling. Note that one or more general purpose virtual or physical computing systems suitably instructed or a special purpose computing system may be used to implement the IRASS/IRMF components. Further, the IRASS/IRMF components may be implemented in software, hardware, firmware, or in some combination to achieve the capabilities described herein. [00480] Note that one or more general purpose or special purpose computing systems/devices may be used to implement the described techniques. However, just because it is possible to implement the IRASS/IRMF components on a general purpose computing system does not mean that the techniques themselves or the operations required to implement the techniques are conventional or well known. [00481] Each computing system 900 may comprise one or more server and/or client computing systems and may span distributed locations. In addition, each block shown may represent one or more such blocks as appropriate to a specific embodiment or may be combined with other blocks. Moreover, the various blocks of the IRASS/IRMF component 910 may physically reside on one or more machines, which use standard (e.g., TCP/IP) or proprietary interprocess communication mechanisms to communicate with each other. [00482] In the embodiment shown, computer system 900 comprises a computer memory (“memory”) 901, a display 902, one or more Central Processing Units (“CPU”) 903, Input/Output devices 904 (e.g., keyboard, mouse, CRT or LCD display, etc.), other computer-readable media 905, and one or more network connections 906. The IRASS/IRMF component 910 is shown residing in memory 901. In other embodiments, some portion of the contents, some of, or all of the components of the IRASS/IRMF component 910 may be stored on and/or transmitted over the other 92 CU 2ST5OM3ER1 NUM5BER 11-1001AP computer-readable media 905. The components of the IRASS/IRMF component 910 preferably execute on one or more CPUs 903 and manage the modeling, supply and resupply of resources between entities, as described herein. Other code or programs 930 and potentially other data repositories, such as data repository 906, also reside in the memory 901, and preferably execute on one or more CPUs 903. Of note, one or more of the components in Figure 9 may not be present in any specific implementation. For example, some embodiments embedded in other software may not provide means for user input or display. [00483] In a typical embodiment, a IRASS/IRMF component 910 includes one or more inventory tracking systems 911, one or more inventory modeling modules 912, one or more communications and events engines 914, and one or more data repositories such as inventory data 915. In at least some embodiments, some of these modules/engines are is provided external to the IRASS/IRMF component and are available, potentially, over one or more networks 950. Other and /or different modules/engines may be implemented. In addition, the IRASS/IRMF component may interact via a network 950 with application or client code 955 (such as a billing system) that uses results computed by the IRASS/IRMF component 910, one or more client computing systems 960, and/or one or more third-party information provider systems 965, such as purveyors of lifespan data used in data repository 915>. Also, of note, the data repository 915 may be provided external to the IRASS/IRMF component as well, for example in a knowledge base accessible over one or more networks 950. [00484] In an example embodiment, components/modules of an IRASS/IRMF component 910 are implemented using standard programming techniques. For example, the IRASS/IRMF component 910 may be implemented as a “native” executable running on the CPU 103, along with one or more static or dynamic libraries. In other embodiments, the IRASS/IRMF component 910 may be implemented as instructions processed by a virtual machine. In general, a range of programming languages known in the art may be employed for implementing such 9 U 2ST5 3 C OM3ER1 NUM5BER 11-1001AP example embodiments, including representative implementations of various programming language paradigms, including but not limited to, object-oriented, functional, procedural, scripting, and declarative. [00485] The embodiments described above may also use well-known or proprietary, synchronous or asynchronous client-server computing techniques. Also, the various components may be implemented using more monolithic programming techniques, for example, as an executable running on a single CPU computer system, or alternatively decomposed using a variety of structuring techniques known in the art, including but not limited to, multiprogramming, multithreading, client-server, or peer- to-peer, running on one or more computer systems each having one or more CPUs. Some embodiments may execute concurrently and asynchronously and communicate using message passing techniques. Equivalent synchronous embodiments are also supported. [00486] In addition, programming interfaces to the data stored as part of the IRASS/IRMF component 910 (e.g., in the data repositories 915 and 916) can be available by standard mechanisms such as through C, C++, C#, and Java APIs; libraries for accessing files, databases, or other data repositories; through scripting languages such as XML; or through Web servers, FTP servers, or other types of servers providing access to stored data. The repositories 915 and 916 may be implemented as one or more database systems, file systems, or any other technique for storing such information, or any combination of the above, including implementations using distributed computing techniques. [00487] Also the example IRASS/IRMF component 910 may be implemented in a distributed environment comprising multiple, even heterogeneous, computer systems and networks. Different configurations and locations of programs and data are contemplated for use with techniques of described herein. In addition, the [server and/or client] may be physical or virtual computing systems and may reside on the same physical system. Also, one or more of the modules may themselves be distributed, pooled or otherwise grouped, such as for load balancing, reliability or 25315 94 CUSTOMER NUMBER 11-1001AP security reasons. A variety of distributed computing techniques are appropriate for implementing the components of the illustrated embodiments in a distributed manner including but not limited to TCP/IP sockets, RPC, RMI, HTTP, Web Services (XML- RPC, JAX-RPC, SOAP, etc.) and the like. Other variations are possible. Also, other functionality could be provided by each component/module, or existing functionality could be distributed amongst the components/modules in different ways, yet still achieve the functions of an IRASS/IRMF component. [00488] Furthermore, in some embodiments, some or all of the modules of an IRASS/IRMF component 910 may be implemented or provided in other manners, such as at least partially in firmware and/or hardware, including, but not limited to one or more application-specific integrated circuits (ASICs), standard integrated circuits, controllers executing appropriate instructions, and including microcontrollers and/or embedded controllers, field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and the like. Some or all of the system components and/or data structures may also be stored as contents (e.g., as executable or other machine-readable software instructions or structured data) on a computer-readable medium (e.g., a hard disk; memory; network; other computer-readable medium; or other portable media article to be read by an appropriate drive or via an appropriate connection, such as a DVD or flash memory device) to enable the computer-readable medium to execute or otherwise use or provide the contents to perform at least some of the described techniques. Some or all of the components and/or data structures may be stored on tangible, non- transitory storage mediums. Some or all of the system components and data structures may also be stored as data signals (e.g., by being encoded as part of a carrier wave or included as part of an analog or digital propagated signal) on a variety of computer-readable transmission mediums, which are then transmitted, including across wireless-based and wired/cable-based mediums, and may take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). Such computer program products may also take 253R1 95 CUSTOME NUM5BER 11-1001AP other forms in other embodiments. Accordingly, embodiments of this disclosure may be practiced with other computer system configurations. CONCLUSION [00489] From the foregoing it will be appreciated that, although specific embodiments have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. For example, the methods and systems for performing resource inventory, supply, and resupply discussed herein are applicable to other architectures Also, the methods and systems discussed herein are applicable to differing protocols, communication media (optical, wireless, cable, etc.) and devices (such as wireless handsets, electronic organizers, personal digital assistants, portable email machines, game machines, pagers, navigation devices such as GPS receivers, etc.). 253 96 CUSTOMER1 NUM5BER 11-1001AP

Claims

CLAIMS 1. A method in a computing system for automatically supplying and resupplying degradable resources on a predictive basis, comprising: automatically modeling usage of one or more resources, wherein at least one of the resources degrades over time and has an associated predicted available lifetime, and wherein expected use of at least one of the one or more resources is uncertain; automatically tracking inventory of the one or more resources based upon the modeled usage of the one or more resources, wherein the tracking includes predicting available lifetime remaining for each of the one or more resources, wherein at least two of the one or more resources have different predicted available lifetimes; receiving an indication of one or more future expected events from one or more external computing systems; based upon a set of rules, the indicated future expected events, and tracked inventory of the one or more resources, automatically predicting future inventory status of the one or more resources; and automatically causing additional units of at least some of the one or more resources to be forwarded based upon the predicted future inventory status of the one or more resources.

2. The method of claim 1 wherein the method is practiced by a computing system that automatically manages inventory for a rental property and the one or more resources are items automatically supplied to the rental property, without human intervention.

3. The method of claim 2 wherein the predicting available lifetime remaining for each of the one or more resources is based at least in part on rental property booking data. 253 97 CUSTOMER1 NUM5BER 1001AP

4. The method of claim 3 wherein the predicting available lifetime remaining for each of the one or more resources uses the booking data to determine a mapping of guest counts to guest locations occupied in the property during a stay and a mapping of guest locations to wear of one or more resources used at the guest locations.

5. The method of claim 2 wherein the items automatically shipped to the rental property are shipped automatically by a computing system of an external supplier based upon communications from the computing system.

6. The method of claim 1 wherein automatically causing additional units of least some of the one or more resources to be forwarded based upon the predicted future inventory status defers forwarding when there is sufficient inventory for an associated future expected event.

7. The method of claim 1 wherein automatically causing additional units of least some of the one or more resources to be forwarded based upon the predicted future inventory status ships sufficient of the one or more resources to accommodate an associated future expected event until a second future expected event.

8. The method of claim 1, further comprising: causing a billing computer system to invoice a consumer of the one or more resources based upon the predicted available lifetime remaining for each of the one or more resources.

9. The method of claim 1 wherein the method is practiced by a computing system that automatically warehouses inventory of items for a rental property and forwards the one or more resources to the rental property based upon the automatically predicted future inventory status of the one or more resources. 25 98 CUSTOM3ER1 NUM5BER 1001AP

10. The method of claim 1 wherein the resources comprise one or more resource types, wherein each type of resource degrades based upon different factors and at different rates, resulting in different associated predicted available lifetimes.

11. The method of claim 10 wherein some of the one or more resource types include towels, linens, dishes, and/or mattresses.

12. The method of claim 1 wherein the predicted available lifetime of one of the one or more resources is determined based upon an available lifetime set of fungible resources that comprise the one of the one or more resources.

13. The method of claim 12, further comprising determining the total available lifetime of the one of the one or more resources by computing a sum of each of the fungible resources in the available lifetime set.

14. A computing system having a memory and a computer processor, the memory storing instructions configured, when executed on the computer processor, to execute one of the above claims.

15. A computer readable medium containing instructions for controlling a computer processor to execute at least one of claims 1-9. 2 99 CUST5OM3ER1 NUM5BER 1001AP