Patent Publication Number: US-8972290-B2

Title: Rental inventory management

Description:
PRIORITY CLAIM 
     This application claims domestic priority to and benefit under 35 U.S.C. §19(e) of prior Provisional application 60/819,702, filed Jul. 7, 2006, the entire contents of which is hereby incorporated by reference as if fully set forth herein. 
    
    
     TECHNICAL FIELD 
     The present disclosure generally relates to methods of managing an inventory of rental items. 
     BACKGROUND 
     The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. 
     In an item rental system, items that have been received from customers after rental must be processed so that some are available for a subsequent rental, and some are put away for a short to long-term storage, or eventual disposal or destruction. In a conventional system involving disc media rental items such as DVDs, received or returned rental DVDs are sorted and put away in racks or other organized long-term storage for subsequent picking for future customers, or for other storage. When a customer order calls for a particular returned rental DVD, a copy or unit of that DVD is picked from the put-away location and prepared for the customer. Thus, typically all returned DVDs are put away before subsequent picking for order fulfillment. 
     However, this approach may result in putting away too many DVDs that represent unpopular titles that are unlikely to be rented by any other customer within a reasonable time. Further, the approach may result in storing too many DVDs that are likely to be needed immediately for rental to another customer the same day or the next day. An example of a DVD rental service provider is Netflix, Inc., Los Gatos, Calif. (www.netflix.com). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the drawings: 
         FIG. 1  is a block diagram that illustrates an approach for renting items to customers according to various embodiments described herein. 
         FIG. 2  illustrates an approach for renting items to customers. 
         FIG. 3  illustrates a “Max Out” approach for managing the number of items that may be simultaneously rented to customers. 
         FIG. 4  illustrates a “Max Turns” approach for renting items to customers. 
         FIG. 5  depicts a set of customers that desire to A/V items from a provider. 
         FIG. 6  illustrates an approach for renting A/V items over a communications network such as the Internet using both “Max Out” and “Max Turns.” 
         FIG. 7  is a block diagram that illustrates a computer system upon which certain aspects and features of an embodiment may be implemented. 
         FIG. 8  is a block diagram of a server computer system that may be used to implement an example embodiment. 
         FIG. 9A  is a flow diagram depicting an overview of a method of sharing an item rental account. 
         FIG. 9B  is a flow diagram of a process of assigning a maximum allowed number of rental items to a profile. 
         FIG. 9C  is a flow diagram of processing a request to add a rental item to a profile member queue. 
         FIG. 10A  is a screen display diagram showing an example user interface display relating to browsing rental items. 
         FIG. 10B  is a screen display diagram showing an example user interface display relating to adding a queue or profile to an account. 
         FIG. 10C  is a screen display diagram showing an example profile introduction. 
         FIG. 10D  is a screen display diagram showing an example user interface display relating to entering attributes of a profile. 
         FIG. 10E  is a screen display diagram showing an example user interface display relating to browsing rental items. 
         FIG. 10F  illustrates an embodiment of a queue page. 
         FIG. 10G  illustrates an embodiment of a confirmation page. 
         FIG. 11  is a block diagram that depicts a distribution location arrangement that includes a plurality of distribution locations identified as DL 1 -DL 5 . 
         FIG. 12  is a flow diagram that depicts an example approach for managing a plurality of rental items across a plurality of distribution locations. 
         FIG. 13  is a flow diagram that depicts an example approach for managing rental items by re-inserting rental items into inventory at a distribution location. 
         FIG. 14  illustrates a hierarchical inventory management approach, in one embodiment. 
         FIG. 15A  and  FIG. 15B  illustrate an example process of placing rental items in storage locations. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details. In other instances, well-known structures and devices are depicted in block diagram form in order to avoid unnecessarily obscuring the invention. 
     Embodiments are described herein according to the following outline: 
     1. Functional Overview 
     2. Item Selection Criteria 
     3. Item Delivery 
     4. “Max Out” 
     5. “Max Turns” 
     6. Inventory Management—Generally 
     6.1 Inventory Management for Multiple Distribution Locations 
     6.2 Hierarchical Management of Rental Inventory 
     7. Sharing an Item Rental Account 
     7.1 Overview Of Profiles Approach 
     7.2 Features Of An Example Profiles Approach 
     7.3 Structural Overview 
     7.4 Functional Overview 
     7.5 Additional Features And Functions 
     8. Implementation Mechanisms—Hardware Overview 
     1. Functional Overview 
       FIG. 1  is a block diagram  100  that illustrates an approach for renting items to customers according to various embodiments described herein. As used herein, the term “items” refers to any commercial goods that can be rented to customers. Examples of items include movies, music and games stored on a non-volatile memory such as a tape, other magnetic medium, optical medium, read-only memory or the like, and embodiments are not limited to any particular type of item. In general, the decision of what items to rent is separated from the decision of when to rent the items. Customers may specify what items to rent using one or more item selection criteria separate from deciding when to receive the specified items. Furthermore, customers are not constrained by conventional rental “windows” and instead can have continuous, serialized rental of items. 
     According to one embodiment, a customer  102  provides one or more item selection criteria to a provider  104  over a link  106 . Link  106  may be any medium for transferring data between customer  102  and provider  104  and embodiments are not limited to any particular medium. Examples of link  106  include, without limitation, a network such as a LAN, WAN or the Internet, a telecommunications link, a wire or optical link or a wireless connection. 
     The item selection criteria indicate items that customer  102  desires to rent from provider  104 . In response to receiving the item selection criteria from customer  102 , provider  104  provides the items indicated by the item selection criteria to customer  102  over a delivery channel  108 . Delivery channel  108  may be implemented by any mechanism or medium that provides for the transfer of items from provider  104  to customer  102  and embodiments are not limited to any particular type of delivery channel. Examples of delivery channel  108  include, without limitation, mail delivery, courier delivery, or delivery using a delivery agent. Provider  104  may be centralized or distributed depending upon the requirements of a particular application. 
     According to an embodiment, a “Max Out” approach allows up to a specified number of items to be rented simultaneously to customer  102  by provider  104 . According to another embodiment, a “Max Turns” approach allows up to a specified number of item exchanges to occur during a specified period of time. The “Max Out” and “Max Turns” approaches may be used together or separately with a variety of subscription methodologies. 
     The approach just described for renting items to customers is now described with reference to a flow diagram  200  of  FIG. 2 . After starting in step  202 , in step  204 , customer  102  creates item selection criteria. In step  206 , customer  102  provides the item selection criteria to provider  104 . In step  208 , in response to provider  104  receiving the item selection criteria from customer  102 , provider  104  provides one or more items indicated by the item selection criteria to customer  102 . The process is complete in step  210 . 
     2. Item Selection Criteria 
     The one or more item selection criteria provided by customer  102  to provider  104  indicate the particular items that customer  102  desires to rent from provider  104 . Thus, the item selection criteria define a customer-specific order queue that is fulfilled by provider  104 . According to one embodiment, the item selection criteria specify attributes of items to be provided by provider  104  to customer  102 . Item selection criteria may specify any type of item attributes and embodiments are not limited to particular item attributes. Examples of item attributes include, without limitation, identifier attributes, type attributes and cost attributes. Item selection criteria may be changed at any time to reflect changes in items that customers desire to rent from a provider. 
     3. Item Delivery 
     According to one embodiment, items are delivered by provider  104  to customer  102  over delivery channel  108  based upon item delivery criteria. More specifically, the delivery of items from provider  104  to customer  102  is triggered by item delivery criteria being satisfied. The item delivery criteria may include a wide range of criteria and embodiments are not limited to any particular item delivery criteria. Examples of item delivery criteria include, without limitation, customer request/notification, customer notification that an item is being returned, customer return of an item, the occurrence of a specified date, the elapsing of a specified period of time or a customer payment. 
     The item delivery criteria may be specified by customer  102  to provider  104  or negotiated by customer  102  and provider  104  as part of a subscription service. For example, a particular subscription service may include item delivery criteria that specify that a particular number of items are to be delivered monthly. As another example, item delivery criteria may specify that an initial set of items is to be delivered by provider  104  to customer  102  upon initiation of a subscription service and that additional items are to be delivered to customer  102  upon return of items to provider  104 . Item delivery criteria may be applied uniformly to all items to be delivered to a customer, or may be item specific. For example, item delivery criteria may specify a particular date, i.e., the third Wednesday of every month, for all item deliveries. Alternatively, separate item delivery dates may be assigned to each item. 
     4. “Max Out” 
     According to one embodiment, a “Max Out” approach is used to manage the number of items that may be simultaneously rented to customers. According to the “Max Out” approach, up to a specified number of items may be rented simultaneously to a customer. Thus, the “Max Out” approach establishes the size of an inventory of items that may be maintained by customers. The specified number of items may be specific to each customer or may be common to one or more customers. In the present example, if the specified number of items is three, then up to three items may be rented simultaneously by provider  104  to customer  102 . If the specified number of items are currently rented to customer  102  and the specified item delivery criteria triggers the delivery of one or more additional items, then those items are not delivered until one or more items are returned by customer  102  to provider  104 . 
     According to one embodiment, in situations where the specified number of items are currently rented to customer  102  and the specified item delivery criteria triggers the delivery of one or more additional items, then the one or more additional items are delivered to customer  102  and customer  102  and a surcharge is applied customer  102 . The specified number of items may then be increased thereafter to reflect the additional items delivered to customer  102  and increase the size of the inventory maintained by customer  102 . Alternatively, the specified number of items may remain the same and number of items maintained by customer  102  returned to the prior level after items are returned to provider  104  by customer  102 . When used in conjunction with the “Max Turns” approach described hereinafter, the specified number of items may be unlimited. 
     The “Max Out” approach for managing the number of items that may be simultaneously rented to customers is now described with reference to a flow diagram  300  of  FIG. 3 . After starting in step  302 , in step  304 , one or more initial items are delivered to customer  102  to establish the inventory maintained by customer  102 . Note that an initial delivery of items is not required and according to one embodiment, the inventory of customer  102  is incrementally established over time. 
     In step  306 , a determination is made whether the item delivery criteria have been satisfied. If not, then the determination continues to be made until the item delivery criteria are satisfied. As described previously herein, the delivery criteria may include customer notification generally, customer notification that an item is being returned, the actual return of an item, the occurrence of a specific date, or that a specified amount of time has elapsed. 
     Once the item delivery criteria are satisfied, then in step  308 , a determination is made whether the specified number of items has been delivered. If not, then control returns to step  304  and one or more additional items are delivered by provider  104  to customer  102 . If however, in step  308 , the specified number of items have been delivered, then in step  310 , a determination is made whether the specified number of items, i.e., the “Max Out” limit, is to be overridden. As previously described, the specified number of items may be overridden by increasing the specified number of items, i.e., the “Max Out” limit, to allow additional items to be delivered to customer  102  and charging a fee to customer  102 . Alternatively, the specified number of items is not changed and a surcharge applied to customer  102 . This process continues for the duration of the subscription and is then complete in step  312 . 
     5. “Max Turns” 
     According to one embodiment, a “Max Turns” approach is used to rent items to customers. According to the “Max Turns” approach, up to a specified number of item exchanges may be performed during a specified period of time. For example, referring to  FIG. 1 , suppose that provider  104  agrees to rent items to customer  102  with a “Max Turns” limit of three items per month. This means that customer  102  may make up to three item exchanges per month. This approach may be implemented independent of the number of items that a customer may have rented at any given time under the “Max Out” approach. The approach is also independent of the particular item delivery criteria used. 
     According to one embodiment, the “Max Turns” approach is implemented in combination with the “Max Out” approach to rent items to customers. In this situation, up to a specified number of total items are simultaneously rented to customer  102  and up to a specified number of item exchanges may be made during a specified period of time. Thus, using the “Max Out” and the “Max Turns” approaches together essentially establishes a personal item inventory for customer  102  based upon the “Max Out” limit that may be periodically refreshed based upon the “Max Turns” limit selected. 
     In some situations, customer  102  may wish to exchange more than the specified number of items during a specified period. According to one embodiment, in this situation, provider  104  agrees to rent additional items above the specified number to customer  102  and to charge customer  102  for the additional items. For example, suppose that provider  104  agrees to rent items to customer  102  with up to three item turns (exchanges) per month. If, in a particular month, customer  102  requires two additional turns, then the two additional items are provided to customer  102  and a surcharge is applied to customer  102  for the additional two items. 
     In other situations, customer  102  may not use all of its allotted turns during a specified period. According to one embodiment, customers lose unused turns during a subscription period. For example, if customer  102  has a “Max Turns” limit of four item exchanges per month and only makes two item exchanges in a particular month, then the two unused exchanges are lost and cannot be used. At the start of the next month, customer  102  would be entitled to four new item exchanges. 
     According to another embodiment, customers are allowed to carry over unused turns to subsequent subscription periods. For example, if customer  102  has a “Max Turns” limit of four item exchanges per month and only makes two item exchanges in a particular month, then the two unused exchanges are lost and cannot be used. At the start of the next month, customer  102  would be entitled to six new item exchanges, two from the prior month and four for the current month. 
     The “Max Turns” approach for renting items to customers is now described with reference to a flow diagram  400  of  FIG. 4 . After starting in step  402 , in step  404 , customer  102  and provider  104  agree upon the terms of the “Max Turns” agreement. Specifically, customer  102  and provider  104  agree at least upon the maximum number of turns that are allowed in a specified period of time. 
     In step  406 , in response to one or more item delivery criteria being satisfied, provider  104  provides one or more items to customer  102  over delivery channel  108 . Any type of item delivery criteria may be used with the “Max Turns” approach and embodiments are not limited to any particular delivery criteria. For example, the initial one or more items may be delivered to customer  102  in response to a subscription payment made by customer  102  to provider  104 , the initiation of a specified subscription period, or by request of customer  102  for the initial rental items. The number of initial one or more items must not exceed the terms of the “Max Turns” agreement. 
     In step  408 , in response to one or more delivery criteria being satisfied, a determination is made whether additional items can be provided to customer  102  within the terms of the “Max Turns” agreement. For example, if the number of items rented to customer in the current subscription period is less than the agreed-upon “Max Turns,” then additional items can be rented to customer  102  within the terms of the “Max Turns” agreement. In this situation, this determination may be made in response to customer  102  returning one or more items to provider  104  or by customer  102  requesting additional items. 
     If, in step  408 , a determination is made that additional items can be rented to customer  102  within the terms of the “Max Turns” agreement, then control returns to step  406  where one or more additional items are rented to customer  102 . If however, in step  408 , a determination is made that additional items cannot be rented to customer  102  within the terms of the “Max Turns” agreement, then in step  410 , a determination is made whether to override the current agreement terms. If so, then in step  412 , the agreement terms are changed to allow for a larger number of terms and customer  102  is charged accordingly, or the terms are left unchanged and a surcharge is applied for the additional items to be delivered. Control then returns to step  406 , where one or more additional items are delivered to customer  102 . 
     If in step  410 , a determination is made that the current agreement is not to be overridden, then in step  414 , no items are delivered to customer  102  until the next subscription period. For example, the request for additional items may be received at the end of a subscription period and instead of renting the additional items immediately, they are instead delivered during the subsequent subscription period. Control then returns to step  406  where one or more additional items are rented to customer or the process is complete in step  416 . 
     The approach for renting items described herein is now described in the context of renting to customers audio/video (A/V) items, such as movies, games and music, stored on various media.  FIG. 5  is a diagram  500  that depicts a set of customers  502  that desire to A/V items from a provider  504 . Customers  502  communicate with provider  504  over links  506 , the global packet-switched network referred to as the “Internet,” and a link  510 . 
     Links  506  and  510  may be any medium for transferring data between customers  502  and the Internet  508  and between the Internet  508  and provider  504 , respectively, and embodiments are not limited to any particular medium. In the present example, links  506  and  510  may be connections provided by one or more Internet Service Providers (ISPs) and customers  502  are configured with generic Internet web browsers. Links  506  and  510  may be secure or unsecured depending upon the requirements of a particular application. 
     In accordance with an embodiment, customers  502  enter into a rental agreement with provider  504  to rent audio/video (A/V) items  512  from provider  504  according to the “Max Out” and/or “Max Turns” approaches described herein. Embodiments are not limited to any particular approach for entering into the rental agreement. For example, customers  502  and provider  504  may enter into a rental agreement by mail, telephone or over the Internet, by customers  502  logging into a web site associated with provider  504 . 
     Customers  502  create and provide item selection criteria to provider  504  over links  506  and  510  and the Internet  508 . Embodiments are not limited to any particular approach for specifying and providing item selection criteria to provider  504 . For example, according to one embodiment, customers  502  provide item selection criteria to provider  504  in one or more data files. According to another embodiment, customers  502  log onto a web site of provider  504  and use a graphical user interfaced (GUI) to specify attributes of the movies and music that customers desire to rent from provider  504 . 
     The item selection attributes may include any attributes that describe, at least in part, movies, games or music that customers  502  desire to rent. For movies, example attributes include, without limitation, title, category, director name, actor name and year of release. For games, example attributes include, without limitation, title and category. For music, example attributes include, without limitation, title, category, artist/group name and year of release. Customers  502  may identify specific movies or music by the item selection criteria, or may provide various attributes and allow provider  504  to automatically select particular movies and music that satisfy the attributes specified. For example, customers  502  may specify item selection criteria that include horror movies released in 1999 and let provider  504  automatically select horror movies that were release in 1999. As another example, customers  502  may specify item selection criteria that include adventure movies starring Harrison Ford. Customers  502  may also specify an order or priority for the specified item selection criteria. For example, customers  502  may specify specific movie titles and the order in which they want to receive them. As another example, customers  502  may specify that they want to receive a particular number of movies of different types. 
     Once customers  502  and provider  504  have entered into a rental agreement and customers  502  have provided item selection criteria to provider  504 , then A/V items  512  are rented to customers  502  over delivery channels  514  in accordance with the terms of the rental agreement. Specifically, according to the “Max Out” approach described herein, an initial set of A/V items  512 , such as movies, games and music, are delivered to customers  502  over delivery channels  514  according to the terms of the rental agreement. Subsequent A/V items  512  are delivered whenever the specified item delivery criteria are satisfied. For example, additional A/V items  512  may be delivered upon the return of one or more A/V items  512  to provider, a request from customers  502 , the arrival of a particular date, e.g., a specific day of the month, or the expiration of a specified period of time, e.g., fifteen days. 
     In accordance with the “Max Out” approach described herein, once the maximum number of A/V items  512  have been rented to a particular customer  502 , then no additional A/V items  512  are rented until one or more rented A/V items  512  are returned to provider  504 , or unless a surcharge is applied to the particular customer  502 . Alternatively, the rental agreement between the particular customer  502  and provider  504  may be modified to increase the maximum number of A/V items  512  that may be rented simultaneously to the particular customer  502 . 
     The rental agreement between customers  502  and provider  504  may also specify a maximum number of turns in combination with the “Max Turns” approach. In this situation, a maximum number of turns restrict how quickly customers  502  may refresh their A/V item  512  inventories. For example, suppose that a particular customer  502  agrees with provider  504  to rent up to four movies with a maximum of four turns per month. Under this agreement, the particular customer  502  may maintain a personal inventory of up to four movies and rent four new movies per month. Thus, the particular customer  502  can completely “replace” his personal inventory once per month. If the particular customer  502  agreed to a maximum of up to eight turns per month, then the particular customer  502  would be able to completely replace his personal inventory twice per month. 
     Provider  504  is illustrated as a single entity for purposes of explanation only. Provider  504  may be centralized or distributed depending upon the requirements of a particular application. For example, provider  504  may be a central warehouse from which all A/V items  512  are provided. Alternatively, provider  504  may be implemented by a network of distributed warehouses. 
       FIG. 6  is a flow diagram that illustrates an approach for renting A/V items  512 , e.g., movies, to customers over a communications network such as the Internet using both “Max Out” and “Max Turns” according to an embodiment. Referring also to  FIG. 5 , after starting in step  602 , in step  604 , a customer  502  enters into a rental agreement with provider  504 . In the present example, customer  502  uses a generic web browser to access an Internet web site associated with provider  504  and enter into a rental agreement that specifies that customer  502  may maintain a personal inventory of four movies (“Max Out” of four) and receive up to four new movies per month (“Max Turns” of four). Furthermore, the rental agreement specifies that new movies will be delivered upon return of a rented movie from customer  502 , i.e., the delivery criteria is a return of a movie by the customer. 
     In step  606 , customer  502  creates and provides movie selection criteria to provider  504  that indicates movies that customer  502  desires to rent. For example, the movie selection criteria may specify particular movie titles that customer  502  desires to rent. The movie selection criteria may also specify an order or priority in which customer  502  wishes to rent the movies. Instead of identifying particular movie titles, the movie selection criteria may specify movie preferences for customer  502 , e.g., types of movies, directors, actors, or any other movie preferences or attributes. In this situation, provider  504  automatically selects particular titles that satisfy the movie selection criteria. For example, the movie selection criteria may specify a preference for action movies starring a particular actor, with a preference for “new release” movies. Provider  504  attempt to provide movies to customer  502  that best satisfy the preferences indicated by the movie selection criteria. 
     In step  608 , one or more initial movies  512  are delivered to customer  502  over delivery channel  514 . The one or more initial movies  512  may be delivered to customer  502  via mail, courier, delivery agent or any other suitable means negotiated between customer  502  and provider and embodiments are not limited to any particular type of delivery mechanism. For purposes of explanation only, is presumed in the present example that movies are mailed between customer  502  and provider  504 . 
     The one or more initial movies  512  establish the personal movie inventory of customer  502 . Customer  502  may choose to receive any number of movies up to the “Max Out” limit of four movies. Typically, customer  502  will choose to initially receive four movies in the initial delivery. 
     Once the one or more initial movies  512  have been mailed to customer  502 , then in step  610 , a determination is made whether any movies  512  have been returned by customer  502  to trigger another movie delivery. In the present example, the delivery of additional movies is triggered by the receipt, e.g., via mail, of one or more movies from customer  502 . In the situation where customer  502  elects to not receive the maximum number of movies  512  in the initial delivery, then the delivery of additional movies  512  may also be triggered by a request from customer  502  for additional movies  512 . For example, customer  502  may notify provider  504  via telephone, email or by accessing the web site associated with provider  504 . 
     If, in step  610 , a determination is made that one or more movies  512  were received from customer  502 , then in step  612 , a determination is made whether the maximum number of turns (“Max Turns”) limit has been reached for the current cycle. In the present example, a determination is made whether four or more movies have been mailed in the current month. If not, then control returns to step  608 , where one or more additional movies  512  are mailed to customer  502  via delivery channel  514  up to the “Max Out” limit of four. 
     If, in step  612 , a determination is made that the “Max Turns” limit has been met for the current cycle, i.e., in the present example, four movies  512  have been mailed to customer  502  in the current month, then in step  614  a determination is made whether to override the current “Max Turns” limit. If so, then in step  616 , a surcharge is applied to customer  502  and control returns to step  608  where the additional movies  514  are mailed to customer  502 . If not, then in step  618 , a determination is made whether to continue the subscription service. If so, then no additional movies are mailed to customer  502  during the current cycle, e.g., the current month, and the control returns to step  610 . If, in step  618 , a determination is made that service is not to be continued, then the process is complete in step  620 . 
     In some situations, customer  502  may desire to increase or decrease the size of customer&#39;s  502  personal movie inventory by changing the current “Max Out” limit. According to one embodiment, customer  502  notifies provider  504 , e.g., by telephone, mail, email or by accessing the web site associated with provider  504 , that customer  502  wishes to change the “Max Out” limit. The movie rental agreement between customer  502  and provider  504  is then modified to reflect the change of the “Max Out” limit. In the situation where the “Max Out” limit is increased, then additional movies  512  may be immediately mailed to customer  502 . 
     6. Inventory Management—Generally 
     The approach described herein for renting items to customers provides superior inventory management to prior approaches. Specifically, the use of item selection criteria provides for efficient inventory management by allowing the greatest number of items to be rented at any given time. Moreover, the greatest number of customers is provided with their most preferred items. For example, customers may specify priorities for the items indicated by the item selection criteria. Thus, if a particular customer&#39;s first choice is not available, or already rented, then the item having the next highest priority can be rented to the particular customer. According to one embodiment, customers may indicate items that are not yet available for rent. Then, the items are delivered to customers when they become available. 
     For example, referring again to  FIG. 5 , suppose that a particular customer  502  desires to rent an as-yet-unreleased movie entitled “ABC.” The particular customer  502  indicates this movie to provider  504  by the item selection criteria. Since the movie ABC is not yet available, it cannot be delivered to the particular customer  502 . However, when the movie ABC does become available, it can be shipped immediately to the particular customer  502 , as well as other customers  502  who may have also requested the movie. This allows provider  504  to maximize the number of items rented while ensuring that customers  502  are able to rent the highest priority items that they requested. 
     According to another embodiment, as yet unknown items may also be rented by specifying attributes of the unknown items. For example, the particular customer  502  may request to rent the next new movie of a particular director, for which the exact name is unknown to the particular customer. As another example, the particular customer  502  may request to rent the next album of a particular group that is currently in process and does not yet have a title. 
     6.1 Inventory Management Across Multiple Distribution Locations 
     Some rental systems use multiple distribution locations to provide rental items to customers. The distribution locations are typically distributed geographically to provide the best availability to customers. In some situations, multiple distribution locations are disposed in close proximity to each other to provide load balancing and redundancy, for example in dense population areas. As used herein, the term “distribution location” refers to a location from which rental items are provided to customers. Example distribution locations include, without limitation, distribution centers, warehouses and hubs. The types and arrangement of distribution locations may vary depending upon the requirements of a particular application and embodiments are not limited to any particular types or arrangement of distribution locations. 
     One of the issues in rental systems is how to provide the best service to the largest number of customers. From a theoretical standpoint, the best service is provided by establishing a number of geographically disparate and autonomous distribution locations that are structured and operated identically. Each distribution location maintains enough units of each rental item so that customer demand at each distribution location can always be satisfied by the local distribution location. In reality, this approach is very expensive and impractical because at any given distribution location there are always some rental items that are not wanted by any customers and other rental items that are wanted by customers that a particular distribution location does not have. For example, in the context of renting movies on DVDs to customers using a group of distribution locations, it is highly likely that there will always be movie titles at a particular distribution location that customers do not want to rent and other movies titles that customers want to rent, but for which the particular distribution location does not have a sufficient number of copies in inventory. Given changing customer demand over time, each distribution location would need to store many thousands of DVDs to ensure the customer demand could always be satisfied. This would necessarily include storing copies of unpopular movie titles that may be rented only very infrequently and also storing many extra copies of popular movie titles to ensure that customer demand can be satisfied. Thus, given the costs associated with maintaining rental inventory, the problem is how to maintain as little rental inventory as is possible, while still being able to satisfy customer demand. 
     6.1.1 Inventory Free Distribution Locations 
     According to one embodiment, an “inventory free” approach is used for managing rental item inventory across multiple distribution locations. In general, at least some rental items that are not needed by two or more distribution locations are sent from the two or more distribution locations to a designated distribution location. For example, a first set of one or more rental items at a first distribution location that are not be needed at the first distribution location is identified. A second set of one or more rental items at a second distribution location that are not needed at the second distribution location is also identified. The first and second sets of one or more rental items are sent from the first and second distribution locations to the designated distribution location. Rental items sent to the designated distribution location may be permanently stored at the designated distribution location. Alternatively, rental items sent to the designated distribution location may be returned to the distribution location from which they were sent, or sent to other distribution locations, depending upon where the rental items are needed. 
     This approach for managing rental item inventory across multiple distribution locations at least reduces the amount of rental item inventory that must be maintained at individual distribution locations. In some situations, the approach allows distribution locations to be inventory free, meaning that the distribution locations do not maintain any inventory and that all rental items received by the distribution location are either rented to customers or sent to the designated distribution location. 
       FIG. 11  is a block diagram that depicts a distribution location arrangement  1100  that includes a plurality of distribution locations identified as DL 1 -DL 5 . One or more customers C 1 -C 13  are associated with each distribution location DL 1 -DL 5 . The fact that a particular customer is associated with a particular distribution location means that the particular customer receives rental items from the particular distribution location. In the present example, customers C 1 -C 3  are associated with distribution location DL 1 . Customers C 4  and C 5  are associated with distribution location DL 2 . Customer C 6  is associated with distribution location DL 3 . Customers C 7 -C 9  are associated with distribution location DL 4  and customers C 10 -C 13  are associated with distribution location DL 5 . 
       FIG. 12  is a flow diagram  1200  that depicts an approach for managing a plurality of rental items across a plurality of distribution locations. In step  1202 , a first set of one or more rental items at a first distribution location that are not be needed by customers associated with the first distribution location is identified. For example, a first set of one or more rental items, such as DVDs containing movies or music, at distribution location DL 1  that are not needed by customers C 1 -C 3  is identified. 
     In step  1204 , a second set of one or more rental items at a second distribution location that are not needed by customers associated with the second distribution location is identified. For example, a second set of one or more rental items, such as DVDs containing movies or music, at distribution location DL 4  that are not be needed by customers C 4  and C 5  is identified. 
     In step  1206 , the first and second sets of rental items are provided from the first and second distribution locations to a designated distribution location. The designated distribution location may be selected based upon a wide variety of selection criteria, depending upon the requirements of a particular application, and the embodiments are not limited to any particular selection criteria. For example, the designated distribution location may be selected because of its geographical proximity to the remaining distribution locations. As another example, the designated distribution location may be selected based upon its capacity to store and manage rental items sent to it from other distribution locations. In the present example, distribution location DL 3  is selected as the designated distribution location. Thus, the first set of rental items is provided from distribution location DL 1  to distribution location DL 3 . Also, the second set of rental items is provided from distribution location DL 4  to distribution location DL 3 . 
     The particular mechanism employed to send the first and second sets of rental items from the first and second distribution locations to the designated distribution location may vary depending upon the particular application and embodiments are not limited to any particular approach. For example, in an application where rental items are digital media, such as CDs, CD-ROMs or DVDs, the rental items may be hand carried or shipped by mail or courier or sent by other bulk transportation means. 
     Rental items may also be returned from the designated distribution location back to distribution locations that require the rental items. For example, suppose that a particular rental item was not required by distribution location DL 1  and was sent to the designated distribution location DL 3  as previously described. Sometime later, a determination is made that the particular rental item is now required by distribution location DL 1 . This may occur, for example, if a customer associated with distribution location DL 1  requests the particular rental item. In this situation, the particular rental item is returned from the designated distribution location DL 3  to distribution location DL 1 . Rental items are not limited to being returned to the distribution locations from which they were provided to the designated distribution location. For example, suppose that distribution location DL 5  indicates a need for the particular rental item that was previously provided to the designated distribution location DL 3  from distribution location DL 1 . In this situation, the particular rental item is provided from the designated distribution location DL 3  to distribution location DL 5 . 
     In the prior example, distribution locations exchange items with the designated distribution location. According to another embodiment, distribution locations exchange inventory directly with other distribution locations. For example, distribution location DL 1  may provide rental items not needed by distribution location DL 1  directly to another distribution that needs the rental items, such as distribution location DL 2 . Distribution locations with excess inventory may also sending excess rental items directly to the customers of another distribution location. In the prior example, distribution location DL 1  sends excess rental items directly to customers C 4  and C 5 . The rental items may then be returned from customers C 4  and C 5  to either distribution location DL 2 , or back to distribution location DL 1 , depending upon where the rental items are needed. This approach reduces the amount of time that rental items are “out of service” attributable to being in transit between distribution locations. 
     Although the approach is depicted in the figures and described in the context of five distribution locations and thirteen customers, the approach is applicable to any number of distribution locations and any number of customers. 
     6.1.2 Re-Insertion of Rental Items into Inventory at Distribution Locations 
     According to the “inventory free” approach described above, at least some rental items that are not needed by customers associated with distribution locations are sent to the designated distribution location. There may be situations where particular rental items are not currently needed by customers at a distribution location, but there is a high likelihood that the particular rental items will be needed by the customers within a specified time. For example, the demand for the particular rental items may be generally high at other distribution locations and it is expected that customers associated with the distribution location will request to rent the particular rental items within a specified time. According to one embodiment, in this situation, the particular rental items are maintained at the distribution location as “float” and not sent to the designated distribution location. Also, the particular rental items are re-processed as returned rental items prior to being again rented to customers. 
       FIG. 13  is a flow diagram  1300  that depicts an approach for managing rental items by re-inserting rental items into inventory at a distribution location. In step  1302 , a plurality of rental items is received at a distribution location from customers. For example, a plurality of DVDs containing movies returned by customers C 1 -C 3  is received at distribution location DL 1 . 
     In step  1304 , a first return processing is performed on the received plurality of rental items. Return processing may include many different types of processing, depending upon the requirements of a particular application, and embodiments are not limited to any particular type of return processing. For example, return processing may include recording that a particular rental item rented to a customer has been received at a distribution location. The recording may be made manually into an information system. Alternatively, a rental item may be scanned, for example using a bar code reader, either manually or automatically by a machine. In the present example, the first return processing includes scanning a label, bar code or other encoding on each DVD to record in an information system that each DVD in the plurality of DVDs has been received by the distribution location DL 1 . Any step that is described herein with reference to bar code scanning, or scanning in general, also may be performed using radio-frequency identification (RFID) tags on rental item units, and RFID tag reading or scanning. 
     In step  1306 , the plurality of rental items is evaluated and a set of one or more rental items is identified from the plurality of rental items. The set of one or more rental items are rental items that are not currently needed by customers associated with the distribution location, but that are likely to be needed by the customers within a specified time. 
     In the present example, the plurality of DVDs is evaluated and a set of one or more DVDs is identified that is not currently needed by customers C 1 -C 3  of distribution location DL 1 , but that is likely to be needed by customers C 1 -C 3 . The set of one or more DVDs is the “float” for distribution location DL 1  and may be maintained separate from other DVDs at distribution location DL 1 . As described in more detail hereinafter, the determination that a particular rental item is not currently needed but is expected to be needed within a specified time may be made based upon a variety of factors that may vary depending upon the requirements of a particular application. 
     The specified time may be selected based upon a variety of considerations. According to one embodiment, the specified time is selected based upon the cost of maintaining a rental item at a distribution location and the costs of returning the rental item to the designated distribution location and then retrieving the rental item back from the designated distribution location. For example, the specified time may be selected so that the cost of maintaining the rental item at a distribution location for the specified time is approximately equivalent to returning the rental item to and later retrieving the rental item from the designated location. Thus, if the rental item is likely to be needed by customers within the specified time, then it is cost effective to keep the rental item at the distribution location. On the other hand, if it is not likely that the rental item will be needed by customers within the specified time, then it is cost effective to send the rental item to the distribution location and later retrieve the rental item when it is needed. 
     In step  1308 , a second return processing is performed on the set of one or more rental items prior to being rented to customers. In the present example, the label, bar code, tag or other encoding on each DVD in the set of one or more DVDs is re-scanned. The second return processing may be performed separately, or together with other DVDs returned to distribution location DL 1 . For example, the set of one or more DVDs may be mixed with other DVDs returned from customers C 1 -C 3  and scanned together as a single batch. 
     In step  1310 , the set of one or more rental items is sent to the customers that requested the rental items. In the present example, the set of one or more DVDs is sent from distribution location DL 1  to customers C 1 -C 3 . 
     This approach results in the float being re-scanned prior to being rented again and avoids having to put the float back into inventory or organize the float in any way. Instead, the float has to simply be maintained until it is re-scanned. 
     The aforementioned process may be repeated any number of times to dynamically update the float. For example, once additional rental items received and the current float have been scanned, a new float may be determined. The new float may be identical to the current float. This would occur if all of the additional rental items are requested by customers and none of the rental items in the float are requested by customers, but a likelihood still remains that the rental items in the float will be requested by customers within a specified time. Some of the rental items in the current float may not be in the new float. This would occur if rental items in the current float have been requested by and rented to customers and are therefore not included in the new float. The new float may also contain new rental items that were not in the old float. This would occur if a determination is made that one or more rental items from the additional rental items are not needed by customers of the distribution location and therefore should be added to the float. Thus, the contents of the float may change over time and any portion of the float may be replaced at any time. There may also be some situations where the float disappears completely. This would occur if a determination is made that all of the rental items in the float are needed b customers. 
     6.1.3 Determining Whether a Rental Item is Needed at a Distribution Location 
     The determination of whether a particular rental item is needed, or not needed, at a particular distribution location generally depends upon whether customers associated with the particular distribution location need, or do not need, the rental item. The determination of whether customers need, or do not need, a particular rental item may be made based upon a wide variety of criteria that may vary depending upon the requirements of a particular application. 
     6.1.3.1 Time-Based Determinations 
     According to one embodiment, the determination of whether a particular rental item is needed, or not needed, at a particular distribution location is made based upon whether customers associated with the particular distribution location need, or do not need, the particular rental item by or within a specified time. For example, suppose that distribution locations DL 1 -DL 6  are configured to distribute digital media containing movies to customers. In this situation, the specified time might be a particular time each day, e.g., 6 am. Thus, according to the “inventory free” approach described herein, digital media that are not needed by customers associated with distribution location DL 1  by 6 am each day are sent to distribution location DL 3 . 
     Alternatively, a “low inventory” approach may specify that rental items that are not needed by customers within a specified time of being received at a distribution location are sent to the designated distribution location. Thus, for example, digital media that are not requested by customers within three days of being received at distribution location DL 1  are sent to designated distribution location DL 3 . This approach limits the amount of time that inventory is maintained by distribution locations other than the designated distribution location. 
     6.1.3.2 Actual and Predicted Customer Demand for Rental Items (including rental queues) 
     According to one embodiment, actual demand for rental items by customers associated with a particular distribution location is used to determine the types and numbers of rental items needed, and not needed, by the customers associated with the particular distribution location. For example, actual customer requests for rental items may be examined to determine the rental items currently requested by customers. This may include examining customer requests contained in customer request queues. The determined demand for rental items may be greater than the actual demand to provide a “cushion” or margin to accommodate an unexpected increase in demand. 
     The demand for rental items at a particular distribution location may also be predicted. For example, in the context of movies, the number of customer requests for a new release at a particular distribution location may be predicted based upon actual requests for prior new releases. Correlation analysis between new releases and prior new releases may also be used to predict the number of requests for new releases. The rental queues for customers associated with the particular distribution location may be examined to predict the future demand for rental items. 
     6.1.3.3 Actual and Predicted Returns of Rental Items 
     According to another embodiment, actual returns of rental items from customers are used to determine the types and numbers of rental items needed, and not needed, at distribution locations. Rental items that are returned to a particular distribution location are available to other customers associated with the particular distribution location. Thus, the number of actual returns may be used to determine whether a particular distribution location has sufficient local inventory to satisfy current demand, or whether the particular distribution location has excess inventory that can be sent to the designated distribution location. Alternatively, the rental items may be sent to another distribution location and provided to customers associated with the other distribution location. The predicted return of rental items may also be used to determine whether rental items are needed at the particular distribution location. For example, an indication may be received that a rental item is being returned and should be received on a particular date. As another example, the return of a particular rental item may be predicted based upon past rental experiences for the particular rental item and for the particular customer currently renting the particular rental item. 
     6.1.3.4 Net Ships 
     According to another embodiment, “net ships” is used to determine the types and numbers of rental items needed, and not needed, at distribution locations. “Net Ships” provides a general indication of whether demand exceeds available inventory and is defined as follows:
 
Net Ships= S+D−R  
 
     where: 
     S is the number of units actually shipped, 
     D is the unfulfilled demand, which is the number of additional units that would have been shipped, assuming unlimited inventory, and 
     R is the number of units received 
     Thus, the sum of S and D represents the total demand. 
     Consider the following example in the context of renting copies of a particular movie title on digital media, e.g., DVDs. Suppose that for a particular distribution location, S=5; D=3 and R=6. In this situation, the Net Ships is two, indicating that for the particular distribution location, the total demand for the particular movie title was eight units and exceeded available inventory and receipts by two units. Since the demand cannot be satisfied by inventory currently available at the particular distribution location, either the customers must wait until copies of the rental item are returned, or until additional copies of the particular movie title can be provided to the customers from another distribution location. In some situations, Net Ships may be a negative value, which generally indicates that the number of units received exceeded the total demand for the particular rental item. For example, suppose that for the particular distribution location, S=5; D=0 and R=6. In this situation, the unfulfilled demand is zero and there were more units returned than shipped, for a Net Ships of negative one. Thus, the total demand of five was capable of being satisfied from the six returned units. 
     An average Net Ships over time may also be determined depending upon the requirements of a particular application. For example, the average Net Ships per movie title may be determined over multiple days. Net Ships and average Net Ships may be used to manage inventory by identifying trends. This is particularly useful in situations where the demand for rental items changes over time. For example, there is often an immediate and large demand for new release movie titles, followed by a peak demand and then a decrease in demand over time until a relatively low “steady state” demand is reached. Actual Net Ship data may be used to predict future demand for rental items and to manage inventory accordingly. 
     The number of rental items needed for “float” at any particular time may be estimated using statistical methods. According to one embodiment, if the number of users who have indicated an interest in a particular title of rental item is known, and the average number of days each customer takes to return a previously rented rental item is known, the expected number of shipments can be calculated, and hence the variance of the shipment rate. Similarly, if the number of users who already have that particular title is known, and the average length of time for which they keep it is known, then the expected number of returns can be calculated, and the variance of the return rate. By subtracting expected returns from expected shipments, the expected net shipments are calculated. By summing the variances of each process, the total variance is calculated. The standard deviation of the expected net shipments is equal to the square root of the variance. Assuming that it is desired to maintain enough float to satisfy natural random fluctuations in shipment volume for a certain period of time, the float should be enough to cover the expected net ships for that period of time, plus some multiple of the standard deviations. For example, to have sufficient float to satisfy natural random fluctuations in shipment volume 95% of the time, 1.64 standard deviations of additional float are required over and above the expected net ship rate, as determined by looking in a standard statistical table of normal distributions, or by other computational or simulation means. 
     6.1.3.5 Actual and Predicted Loss and Breakage of Rental Items 
     According to another embodiment, actual loss or breakage of rental items from customers is used to determine the types and numbers of rental items needed, and not needed, at distribution locations. For example, in the context of renting movies or music on digital media, such as CDs, CD-ROMs, DVDs and the like, a certain percentage of the digital media will be lost or damaged during transit between distribution locations and customers and between distribution locations. 
     Breakage and loss of rental items may also be predicted based upon actual loss and damage experience and the prediction used to determine the rental items needed at distribution locations. For example, the actual loss or breakage of rental items for each distribution location may be measured over time and the measurements used to predict future loss or breakage of rental items from particular distribution locations. 
     6.1.4 Using Upper and Lower Bounds to Manage Rental Item Inventory 
     One of the issues in inventory management is how to maintain proper inventory levels in situations where the demand for rental items changes over time. Even when a proper inventory level can be accurately determined for a particular demand level at a particular time, demand levels can quickly change, making the proper inventory level difficult to determine over time. 
     According to one embodiment, upper and lower bounds are used to manage rental item inventory at distribution locations in environments where demand for rental items changes over time. An upper bound represents the greatest number of rental items that are expected to be needed at a distribution location to satisfy customer demand. The lower bound represents the least number of rental items that are expected to be needed at a distribution location to satisfy customer demand. When available rental item inventory at a distribution location exceeds the upper bound, then there is an excess of rental item inventory at the distribution location and rental items are sent from the distribution location to the designated distribution location. When available rental item inventory at a distribution location falls below the lower upper bound, then there is insufficient rental item inventory at the distribution location and rental items are sent from the designated distribution location back to the distribution location. Thus, a lower bound defines a lower threshold of rental item inventory that is sufficient to satisfy customer demand, even when the customer demand varies over time. An upper bound defines an upper threshold of rental item inventory that limits the amount of excess inventory that is maintained by a distribution location. 
     The determination of whether rental inventory satisfies the upper and lower bounds may include consideration of actual current inventory as well as predicted returns of inventory. For example, the rental item inventory at a particular distribution location may currently be insufficient to satisfy the lower bound, but based upon predicted returns of rental items to the particular distribution location, the inventory will soon be sufficient to satisfy the lower bound. In this situation, additional rental item inventory may not be requested from the designated distribution location. According to one embodiment, net ships is used to evaluate whether upper and lower bounds are satisfied. 
     Upper and lower bounds may be determined based upon a variety of factors depending upon the requirements of a particular application and embodiments are not limited to any particular factors. For example, upper and lower bounds may be calculated based upon past demand for rental items. Past demand may reflect average past demand over a specified time or peak demand. Upper and lower bounds may also be calculated based upon predicted demand for rental items or a combination of past demand and predicted demand for rental items. 
     Separate upper and lower bounds may be determined for each type of rental item at a distribution location since the number of rental items that is required to satisfy customer demand may vary for each type of rental item at the distribution location. For example, in the context of providing movies to customers on digital media such as DVDs, separate upper and lower bounds for each movie title may be determined for the distribution location. Also, separate upper and lower bounds for each movie title may be determined for each distribution location. Thus, the determined upper and lower bounds for a particular move title at a first distribution location may be different than the upper and lower bounds determined for the same particular movie title at a second distribution location. 
     According to one embodiment, upper and lower bounds may be dynamically adjusted over time based upon actual inventory requirement experience or changes in predicted inventory requirements. For example, suppose that in actual experience, a lower bound is not being satisfied, meaning that inventory levels are falling below the lower bound. To avoid not having enough inventory to satisfy customer demand, the lower bound may be adjusted higher. In this situation, additional inventory is requested sooner, in response to either increased demand or decreased returns, than if the lower bound was lower. As another example, in actual experience, an upper bound may not be satisfied, meaning that inventory levels have exceeded the upper bound. To avoid having too much inventory, the upper bound may be adjusted lower. In this situation, inventory is sent to the designated location sooner, in response to either decreased demand or increased returns, than if the upper bound was higher. 
     6.2. Hierarchical Management of Rental Inventory 
     The appended claims represent summaries of approaches for hierarchical management of rental inventory. In a DVD rental system, discs returned by customers are processed so that some are available for a subsequent rental, and some are put away for a short to long-term storage, or eventual disposal or destruction. In a conventional system, DVDs are sorted and put away in racks or organized storage for subsequent picking for future customers, or storage. 
     In one embodiment of the present approach, returned discs are placed into trays in order as received and without sorting, the trays are then stored for variable amounts of time; a linear scan of all the contents of that tray is performed to select out discs for rental, or for continued storage, for used sale, or for destruction. 
     In one aspect the rental patterns of each title are reasonably stable from day to day, and volumes are large enough so that there are many copies of most titles being handled most days. There will be random fluctuations in daily volume on a given title, but they will remain within a few standard deviations of a running daily average on that title. 
     In another aspect the volume on a given title initially becomes large in the first few days of availability, and after a peak, declines steadily for a long period of time, during which surplus discs may be retired, until a steady state is reached. Subsequently, disc loss and breakage, and growth in customer demand require additional discs to be injected back into circulation. 
     In yet another aspect, external events (such as news about a star in the movie, or release of a sequel to the title) may trigger substantial short-term increases in traffic. 
     Reasonable foreseeable growth on titles in steady state will rarely exceed a fixed number of times (e.g. 10×) the number of units in use at the low point (steady state). The rate of replenishing units after steady state is a predictable break rate plus a predictable customer growth rate (e.g. a total of 4% per week). 
     6.2.1 Scan Again Later Approach 
     In one embodiment, returned rental items are processed early in a particular day of operation. The returned rental items become available for rental shipments later in the day. Some of the items that are not required for shipment today are saved in local storage locations and are not put away in long-term storage. As an example, one storage location is labeled “Scan again tomorrow.” On the next processing day (tomorrow), all rental items in the “Scan again tomorrow” storage location are added to tomorrow&#39;s rental returns to make a larger set of rental items from which tomorrow&#39;s rentals can be drawn. Newly released rental items are added to the system each day, and gradually displace the volume of older rental items. 
     In an embodiment in which rental items are DVDs, a rental service provider may maintain numerous copies of each DVD title so that the rental service provider can provide one copy of the same DVD title to many subscribers or customers. For example, the rental service provider might keep 100 copies of the movie “Titanic” in stock. If the average daily volume of a particular title in steady state is 100 discs received and shipped per day, the rental service provider may choose to keep a surplus “buffer stock” of 20 discs in “Scan again tomorrow” circulation, to allow for a low receipt of 90, and high shipment of 110 on a given day. The net ship rate is 100 discs in this example. However, a result of this choice is that some of the discs will be scanned repeatedly for many days without being used, rather than being sorted and put away in longer-term storage away from the receiving, scanning, processing and shipping area. If the cost of a repeated scan is 10 times less than the cost of a sort and put-away, followed by a pick operation to retrieve the disc again for another customer, then it is appropriate for the average “buffer stock” title to be scanned 10 times before a traditional system becomes cheaper. 
     A buffer of 2 or 3 standard deviations of the net ship rate is sufficient to have enough supply for the random fluctuation that might occur on any given day. Since the rate of returns and the rate of shipments are both proportional to the number of discs of a title at customers, the standard deviation is proportional to the square root of the number of discs at customers. 
     In one embodiment it is assumed that N square-roots of buffer inventory are sufficient for the scan-again-tomorrow storage locations to cover almost any possible variation in tomorrow&#39;s shipping. For example, if the buffer inventory is 20 discs as in the above example, then one or more multiples of SQRT(20) is sufficient—on the order of 5 to 10 discs in the scan-again-tomorrow storage locations. For a title early in its life (e.g., a recently released title that is just experiencing a decline in peak usage), there will be surplus discs above and beyond the N square roots on most days. These discs will be sorted into storage locations for scan-again-next-week, or scan-again-later. As a result, the surplus discs are sorted into storage locations that are held for long enough to avoid too many costly rescans, but not so long that the discs will not come back into rotation in time for gradual increases in demand. 
       FIG. 14  illustrates a hierarchical inventory management approach, in one embodiment. One or more customers  1402  receive rented inventory items through a shipping process  1406  and eventually return the rented items using a returns process  1404 . The shipping process may comprise for example mailing, pick-up at a store, downloading digital content, or any other delivery mechanism or method. The returns process  1404  may comprise return mailing, drop-off at a store, deleting digital content or expiration of digital content, online updating of a database to indicate that use of digital content is complete, or any other delivery mechanism or method. The term “database” herein refers to any form of organized data storage including but not limited to flat files, relational databases, object databases, and spreadsheets. 
     Rental items are processed at a distribution facility as part of a daily shipping process  1408  that employees or computers of the distribution facility perform periodically. The term “daily” is used in block  1408  only to illustrate one possible example of periodicity; process  1408  may be performed hourly, weekly, or at any other time interval that the distribution facility selects. Process  1408  may include a physical scanning location, a bar code scanner or RFID tag reader, a database, a computer interfaced to the scanner and database and having a display, and one or more computer programs or other software elements that implement certain computational and decision steps described herein with respect to  FIG. 14  and  FIG. 15A ,  FIG. 15B . 
     As part of shipping process  1408 , certain rental items are placed in one of a plurality of temporary storage locations denoted  1420 ,  1422 ,  1424 ,  1426 . When the rental items are DVDs, the storage locations may comprise bins that hold large numbers of DVDs. Any number of storage locations may be used and a hierarchy of four bins is shown in  FIG. 14  only to illustrate one possible example. In an embodiment, a first storage location  1420  is for items that will be scanned again tomorrow or at the next time that shipping process  1408  is performed or after another first time interval. A second location  1422  holds items to be scanned again after a second time interval, for example, four (4) weeks later. A third location  1424  holds items to be scanned again after a third time interval, for example, 16 weeks later. A fourth location  1426  holds items to be scanned again after a fourth time interval, for example, 64 weeks later. 
     The term “scan” herein refers, for example, to using a reading or scanning device to identify a barcode or tag on an inventory item that uniquely identifies the item. Scanning also includes comparing the scanned value to a database of customer orders. Thus, scanning includes determining whether a particular inventory item is needed for immediate shipping to a customer. Scanning assumes that the database is already updated to indicate what inventory items have been ordered or rented by customers and are needed for shipping at that time. Scanning may involve scanning barcodes, reading RFID tags, or other forms of machine-automated identification of units. 
     As a result of the scanning, each time that shipping process  1408  is performed, selected rental items also are removed from one or more of the storage locations  1420 ,  1422 ,  1424 ,  1426  and processed for shipping to customers  1402 . 
     In an embodiment, one instance of each storage location  1420 ,  1422 ,  1424 ,  1426  is associated with each processing day of the rental service provider. For example, if the rental service provider performs rental item processing on Mondays, Tuesdays, Wednesdays, Thursdays, and Fridays, then in one embodiment one set of each storage location  1420 ,  1422 ,  1424 ,  1426  is associated with each of Monday, Tuesday, Wednesday, and Thursday; special processing may be performed on one day, such as Friday. Viewed another way, each particular storage location (such as “scan again in 4 weeks” storage location  1422 ) comprises a cluster of four “scan again in 4 weeks” storage locations associated with Monday, Tuesday, Wednesday and Thursday. 
     Storage locations also may include a “scan again next week” storage location in addition to the specific storage locations shown in  FIG. 14 . 
     Periodically, the entire contents of each storage location  1420 ,  1422 ,  1424 ,  1426  is scanned. If a particular rental item in one of the storage locations is needed for shipping to a customer at the time that the entire storage location is scanned, then the rental item is removed and used in shipping process  1408  for shipping  1406  to customers  1402 . If a particular rental item also is not likely to be needed at the time of the next scan, then that rental item is moved to the next storage location lower in the hierarchy. In an embodiment, a rental item is not likely to be needed at the time of the next scan when there are more surplus discs than the N square roots of buffer inventory in that storage location; any such surplus discs are moved to the next storage location that is lower in the storage hierarchy. Therefore, rarely needed rental items tend to migrate to lower storage locations and do not need to be re-scanned every day when they are unlikely to be needed. Further, there is no need to put away all discs into long-term storage inventory every day; instead, the most-needed discs are always available in the local storage locations of the hierarchy of storage locations. 
     New discs  1410  represents any rental items that are newly released, made available or otherwise created. Such new rental items enter the daily shipping process  1408  as they are received at the rental service provider. Rental items also may be moved periodically to a used sale storage location  1414 . For example, excess rental items may be sold as used and removed from rental inventory according to various criteria. Additionally, excess rental items may be moved to a dump location  1412  if the rental items are unable to be sold as used. Rental items in dump location  1412  are eventually discarded. One example moving rental items to the used sale storage location  1414  and dump location  1412  is described further below. 
     Levels in the hierarchy of storage locations may be selected in several ways. According to one embodiment, storage locations are associated with weeks of processing. In one embodiment, a rental item service provider is substantially busier on Mondays and Tuesdays than Thursdays and Fridays. Therefore, scanning a scan-again storage location on Friday is appropriate to prepare for the growth of the weekend. 
     If the storage locations are associated with time periods that are too closely spaced in time (e.g., 1 week, 2 weeks, 3 weeks, etc.), there will be too many levels for efficient sorting of the day&#39;s contents into all the storage locations. However, if the storage locations are too widely spaced in time (e.g., 1 week, 10 weeks, 100 weeks), then much inventory will have to be carried in the short-term storage locations and repeatedly rescanned prior to use. Alternatively, inventory will become available too slowly to meet rising demand. Therefore, in an embodiment storage locations associated with scanning again in one, four, 16, and 64 weeks are used. In this description, these storage locations are respectively denoted SA-1, SA-4, SA-16, and SA-64. 
     Cost metrics may be used to select levels for storage locations. For example, assume that the biggest storage location that is easily handled at the plant is 50 units. Suppose rescanning takes $0.001 per unit, or $0.05 per storage location, but a missing unit costs $2.00 in customer satisfaction. Therefore, the average unit can be re-scanned 2,000 times. 
     Placing rental items into storage locations may be done in a variety of ways.  FIG. 15A  and  FIG. 15B  illustrate an example process of placing rental items in storage locations. 
     At step  1502 , returned rental items and new rental items are received into inventory. For example, returns  1404  and new discs  1410  are received at daily shipping process  1408 . Records of the returns  1404  and new discs  1410  are entered into a computer or database associated with process  1408 . 
     In step  1504 , the rental item inventory is scanned. In an embodiment, during each day&#39;s shipping scan as part of daily shipping process  1408 , units of each title are physically pulled out of cycle to be shipped to customers in response to orders in shipping process  1406 . The scan of step  1504  results in storing in a database or other information storage system a quantity on hand for each title or unique type of the rental items. Units to physically pull may be identified by software running on a computer associated with process  1408  and displayed on a computer display. 
     In step  1506 , the rest of the units of a title are divided among storage locations as indicated in successive steps. At step  1507 , any active customer orders for a particular title or type of rental item are fulfilled and placed into shipping  1406 . At step  1508 , a buffer inventory number for a particular title or type is retrieved. The buffer inventory number might be 20 units as in the example previously discussed. The buffer inventory number for each title or type of rental item may be stored in a database or other information storage system. 
     In step  1510 , a scan-again-tomorrow value is computed for the particular rental item title or type. In an embodiment, the scan-again-tomorrow is computed as two standard deviations of the number of buffer inventory of each title. Three standard deviations or other algorithms or formulae may be used to compute the value in step  1510 . The computation of step  1510  may be performed automatically by computer using a computer program that implements some of the steps of  FIG. 15A ,  FIG. 15B  and some of the approach of  FIG. 14 . The program may display the resulting scan-again-tomorrow value on a computer display for viewing by an operator. 
     In step  1512 , a quantity of the rental item equal to the scan-again-tomorrow value is moved to a local scan-again-tomorrow storage location  1420 . Movement may be manual, as by an operator physically taking the quantity of units from one place associated with daily shipping process  1408  and placing the units into a tray, bin, or other storage location. Alternatively, movement may be automated using robots or other material handling equipment. 
     “Local” in this sense may mean a storage location different than the long-term storage in which rental item units are typically put away pending picking for fulfilling a customer order. Local may mean near to the daily shipping process  1408  so that units in the local storage location are accessible for fulfilling customer orders without requiring a separate pick step to be performed with respect to a long-term storage location that is typically relatively distant from the process  1408 . The local storage and long-term storage may be about the same physical distance from the shipping process  1408  but typically the local storage does not require a separate pick step to be performed, typically by a different individual or by moving to a different room, shelf, rack, or other location. Thus, a local storage location is any storage location in which units are placed and not put away into other longer-term storage that requires a pick step for retrieval. 
     Referring now to  FIG. 15B , in step  1514 , if there are more units of the same title at the daily shipping process  1408 , then in step  1515  the process determines the next storage location lower in the hierarchy that is currently being filled for the title or type of rental item. For example, the next storage location lower in the hierarchy for a particular title or type of rental item could be any of storage locations  1422 ,  1424 ,  1426 . Step  1515  may comprise retrieving an identifier of the current lower storage location for a particular title or type of rental item from a database. 
     Step  1516  tests whether the lower storage location currently holds a quantity of units of the particular title that is equal to a limit value for that storage location. In an embodiment, the limit value is equal to a specified growth rate of units at customers plus one or more standard deviations of the weekly net ship rate. If the lower storage location is not at the limit, then in step  1524  a quantity of the rental item is moved to the lower storage location, without exceeding the limit. Movement may be manual or automated. 
     If the limit has been reached for the current lower-level storage location, then step  1518  tests whether that storage location is the last or lowest in the hierarchy. For example, in  FIG. 14 , if storage location  1426  has reached the limit of buffer inventory for the particular title, then step  1518  would have a true result. In that case, in step  1520  any additional inventory is moved to a Used Sale or Dump storage location such as Used Sale location  1414  or Dump location  1412  of  FIG. 14 . Movement may be manual or automated. However, if other lower-level storage locations are available then in step  1522  the process changes to the next storage location lower in the hierarchy and begins filling that lower location with units at step  1524 . 
     After steps  1524  or  1520 , or if the test of step  1514  is negative, the process of  FIG. 15B  is complete for a particular title or type of rental unit, and processing continues in  FIG. 15A  for other titles or types of rental units until all titles and types in daily shipping process  1408  have been processed. 
     Thus, in one embodiment, if there are still more units of a particular title at  FIG. 15A , then units are sent to the currently filling scan-again-next-week (SA-1) storage location, until the process determines that the pending SA-1 storage locations cumulatively contain up to a number of discs equal to a 4% growth rate of discs at customers plus two or three standard deviations of the weekly ship rate. This approach ensures that at the start of next week, there are sufficient copies for growth, and likely some which will be put right back into the SA-1 storage location for the following week. If there are still more units of the same title, then those surplus units are placed in the SA-4 storage location  1422 , until the storage location holds in total a number of units equal to 4% growth multiplied by 4 weeks, plus two or three standard deviations of the buffer inventory of that title. Any additional units of the same title are moved to successively lower storage locations  1424 ,  1426 , within the hierarchy using the same general approach. The number of units moved is adjusted according to the number of weeks associated with the lower storage locations. 
     In an embodiment, any units of a title in excess of ten times the number of units at customers may be moved to used sale storage location  1414 . Used sale storage location  1414  may be associated with discs that are previously viewed and allowed for sale to retail customers. Storage location  1414  may be termed the previously-viewed (PV) sale pre-packaging line. If previously viewed sale is not allowed for a particular title, then the disc may be moved to dump location  1412 . 
     In an embodiment, at the end of a processing period, such as at the end of a business week, the following steps are performed: 
     1. The four clusters of SA-1 storage locations from Mon-Thu are reprocessed, and replenishing units are transferred to a SA-0 storage location cluster (along with rental items culled from Friday&#39;s shipping run), and all these units are marked in a database or otherwise flagged as available for Monday&#39;s order generation. The number of replenishing discs needed is determined by counting or scanning the number of units of a particular title that are currently in the SA-0 storage location and determining the difference of that number and about two or three standard deviations of the buffer inventory number for that title. Thus, the SA-0 storage location is replenished with a number of units sufficient to ensure that an adequate buffer of inventory is in place. The specific algorithm or formula for determining the number of replenishing units is not critical, and other algorithms or formulae may be used. At certain times, the number of replenishing units might be zero. Movement of units for replenishing may be manual or automated. 
     2. The clusters of SA-4 storage locations from three weeks earlier are reprocessed and replenishing units are moved to the next storage location that is higher in the hierarchy, e.g., to the SA-1 storage location. Thus, one quarter of the SA-4 clusters are processed each week. 
     3. The clusters of SA-16 storage locations from 15 weeks prior are reprocessed and replenishing units are moved to the next storage location that is higher in the hierarchy. Thus, one sixteenth of the SA-16 clusters are processed each week. 
     Spikes in demand may be handled in various embodiments. In one embodiment, the majority of inventory is in the SA-1 and SA-4 storage locations. All the SA-1 and one quarter of the SA-4 inventory become available within one week. The rest of the inventory comes online gradually over the following three weeks. If more inventory is needed, then new copies are ordered. This approach is more efficient than implementing a special picking system to pull additional inventory manually in advance. 
     An improved rental item inventory management approach has been described. An effect of the improved approach is that not all returned rental items need to be returned to long-term storage, then picked and packed for a current order. Instead, adequate quantities of rental items likely to be needed in the near future for other customer orders are maintained in local hierarchical storage. An effect of the approach is that storage of rental item inventory is structured in a hierarchical, efficient and rapidly accessed order. An effect of the approach is that a rental service provider can fulfill rental orders more rapidly and using fewer resources. An effect of the approach is that the rental service provider can fulfill rental orders from the local hierarchical storage rather than using personnel or equipment to pick rental item units from long-term storage. 
     7. Sharing an Item Rental Account 
     7.1 Overview of Profiles Approach 
     In one embodiment, a method of sharing an item rental account is provided. Sharing an item rental account may comprise establishing a unique user identity for each of two or more persons in association with an account that has been previously established with the service provider. Each unique user identity is described in an account profile. Each account profile may be stored as a record in a database. 
     Use of profiles provides individualized or personalized features in an item rental system beyond queues of rental items. For instance, an account owner, such as a parent, can set up a different identity, distinguished by a unique username and password combination, for each member of the parent&#39;s household. Each profile is associated with a subordinate queue in a database of the item rental system. The parent can assign, to each profile, a maximum number of items that the person associated with an identity can obtain from the service provider at any one time. An item returned to an item rental service provider, and associated with a particular subordinate queue, is replaced by the next item in that queue. The account owner administers permissions and other characteristics of each profile and identity. The item rental service provider sends all rental items to the same postal address, and bills all transactions in the account to the same credit card. As another example of individualized or personalized features, personalized ratings and recommendations may be stored in association with a profile. Thus, each profile member rates rental items, the ratings are stored in a database in association with profile member identifying information, and the ratings are used to generate personalized rental item recommendations for each profile member without regard to the rental history of other profile members in the same account. 
     The preceding example has described the use of account profiles for multi-person households such as families with children. In an alternative embodiment, a single-person household can establish a plurality of profiles for an account, so that a single person can have plural separate queues of rental items. In another alternative, a two-person household that wants a shared queue with personalized recommendations or reviews can establish two profiles within a single account. 
     In one embodiment, each profile is associated in a database of an item rental service provider with a Queue of rental items, Ratings of rented items, a Rental History of previously rented items, and one or more personalized Recommendations of items that could be rented in the future. Thus, a person or identity associated with a profile can rate movies individually, receives item recommendations based upon their past ratings, is identified as a unique individual within an online user community, and can schedule or order the delivery of movies in that profile&#39;s Queue. In an embodiment, an account owner can delegate certain Account administration and Queue administration functions to a particular profile in the account. 
     In an embodiment applied in the context of renting audiovisual items such as movies and games, an account owner can set limits on the maturity level of movies that other identities can place in the queues of those identities. In another embodiment, each identity in an account receives age-appropriate online page presentations from the rental item service provider. For example, a server and appropriate software of the rental item service provider can determine that a current session involves a young child profile within an account and, in response, can present only web pages for G-rated movies that include larger buttons, cartoon-like artwork, simplified page layout, etc. 
     With the approach herein, persons associated with different profiles of an account may be resistant to any effort by the account owner to move away from the service provider to another service provider. Thus, the service provider in effect establishes a relationship with each identity of a profile. When persons associated with profiles interact in an online community product, each person can establish online relationships to particular friends, rather than establishing a relationship with a friend&#39;s households. 
     7.2 Features of an Example Profiles Approach 
     In one embodiment, a method of sharing an item rental account is implemented in an online item rental service that provides, through one or more appropriate networked servers and application programs, one or more of the following operational features for each profile identity: 
     1. Personalized rental item list, or queue, including functions to add and delete items from the Queue, view an item ship order, and view a rental history. 
     2. Personalized email notifications. 
     3. Storage of personalized favorite data values associated with rental items. For example, when rental items are movies, personalized favorite data values may include favorite actors, actresses, directors, genres, etc. 
     4. Personalized ratings and recommendations. 
     5. Personalized community relationships. 
     6. A maturity value or other constraint, managed by the account owner for all queues. 
     7. Personalized mailing labels for rental items that are delivered by mail. 
     8. Other account owner controls. 
     9. Allow profile members to receive shipments and receive system notices, newsletters, and select other communications. 
     10. Allow owners to remove a username/password combination, designating a Profile, from their Accounts. 
     11. Allow profile members to change a Profile into a stand-alone Account. 
     12. Enable an Account Owner to identify a Co-Owner who can participate in Account administration. 
     As described herein, a “User” or “Profile Member” is a subscriber to an item rental service who has unique authentication credentials into the service. Each User has a Profile. An “Account” is a billing relationship established by a customer with the item rental service; in an embodiment, an Account has at least one and no more than five Profiles. Other embodiments may have any number of Profiles in an Account. An “Owner” is the User that establishes and manages the Account and is responsible for the billing relationship. A “Queue” is a personalized list of rental items that a User manages at the item rental service. A “Subordinate” refers to any User identity established by the Owner within an Account. Embodiments may be used with any kind of rental item. Embodiments in which rental items are movies may use any format for such movies, including DVD, electronic download, etc. 
     7.3 Structural Overview 
       FIG. 8  is a block diagram of a server computer system that may be used to implement an example embodiment. One or more users  802 A,  802 B are coupled through a network  803  to a service provider server computer  804 . In this context, users  802 A,  802 B broadly represent any end station device suitable for connecting through a network to the server computer  804  and performing the functions described herein, such as a personal computer, workstation, wireless device, etc. For purposes of illustrating a clear example,  FIG. 8  shows two users; however, embodiments may serve any number of users. 
     Network  803  and links from users  802 A,  802 B to service provider computer  804  include, without limitation, a network such as a LAN, WAN or the Internet, a telecommunications link, a wire link, optical link or a wireless connection. 
     Server computer  804  includes a user account database  806  and profile management logic  820 . User account database  806  comprises one or more user accounts  808 A,  808 B,  808 N; any number of user accounts may exist in an embodiment. Each user account  808 A,  808 B,  808 N is associated with one or more users, such as users  802 A,  802 B or others. For each user account  808 A,  808 B,  808 N, one individual is designated as an account owner, and one or more other individuals are designated as profile members. A profile  810 A,  810 B is associated with each of the account owner and the other individuals, and one or more profiles are associated with an account. For example, a first profile  810 A is associated with user  802 A, who is an account owner, and a second profile  810 B is associated with user  802 B, who is a profile member of the same user account  808 A. Profiles  810 A,  810 B are both associated with user account  808 A, as indicated by arrows. 
     Generally, an account owner is responsible for payment to a service provider for rental item services, and controls attributes of all profiles associated with an account. In contrast, a profile member has a separate user identifier, item rental queue, and other attributes as described in sections 8.1 and 8.2 above, but is subject to limitations that the account owner sets, and is not responsible for payment. 
     User accounts  808 B,  808 N each has an account owner, and may have zero or any number of profile members. Each user account has a “max out” value  809  associated therewith, which indicates the maximum number of rental items that the account may receive at a time. 
     Each profile comprises a queue, a maturity level value, a value indicating the maximum number of rental items that an associated profile member is allowed to rent at a time (“max rental items out”), and one or more other attributes. For example, first profile  810 A comprises a queue  812 A, a maturity level value  814 A, a max rental items out value  816 A, and one or more other attributes  818 A. 
     Queue  812 A comprises an ordered list of rental items of the kind described above in section 1 through section 5. The maturity level value  814 A indicates the highest item maturity level that a profile member is allowed to rent. In an embodiment in which rental items are movies, the maturity level value  814 A may indicate the highest movie rating that a movie may have for a profile member to rent that movie. For example, maturity level value  814 A may store an MPAA rating value such as G, PG, PG-13, R, NC-17, etc. If the maturity level value  814 A is PG, then a profile member of first profile  810 A may rent only G-rated or PG-rated movies; however, a profile member of second profile  810 B may have a different maturity level value  814 B that allows renting PG-13 or R movies. Alternatively, a profile can store ratings under the TV rating system (TV-MA, TV-15, etc.). 
     Maturity level values  814 A,  814 B are examples of constraints that a profile may store. In other embodiments, a profile stores a constraint other than a maturity level value. Thus, embodiments are not limited to the use of maturity level values as constraints on rental activity for profile members; any other appropriate, desired or useful constraint may be used. Examples of other constraints that may be used include rental item genre, rental item media format, rental item length, parental advisory warning values, video game rating values, etc. 
     The max rental items out value  816 A specifies the largest number of rental items that the profile member of the first profile  810 A may receive at a time. The max rental items out value  816 A is some number equal to or less than the max out value  809  for the user account  808 A of profile  810 A. Further, the sum of the max rental items out value  816 A of first profile  810 A and the max rental items out value  816 B of second profile  810 B is equal to max out value  809 . Thus, if user account  808 A is allowed four (4) rental items out at a time, max out value  809  is “4” and max rental items out values  816 A,  816 B may be any combination of values that equals 4. The sum of values  816 A,  816 B could be less than max out value  809 , but such a configuration would represent less than optimal usage of the user account  808 A. 
     The other attributes  818 A,  818 B may store any other profile values that are found useful or convenient, such as the age of a person associated with a profile, a shipping address for a person associated with a profile, a date on which the profile was created, a flag indicating whether a person associated with a profile is participating in online community features, etc. 
     Other attributes  818 A,  818 B may indicate that a profile is associated with one of a plurality of alternative means of delivery. For example, if a rental service contemplated fulfillment of audiovisual items via either physical delivery or electronic delivery to one or more TV set-top boxes or other customer premises equipment, information in profiles can designate target set-top boxes for specific movies. As a specific example, assume a household owns two TV set-top boxes one in the living room for the parents&#39; use and one in the kids&#39; room for kids&#39; use. The parents might associate the parents&#39; set-top box with the parents&#39;-specific profile and queue, and the kids&#39; set-top box with the kids&#39; profile and queue. Any movies in the parents&#39; queue would be fulfilled either by DVD in a physical mailer addressed to the parents, or by electronic delivery to the parents&#39; set-top box, while any movies in the kids&#39; queue would be delivered either by DVD in a physical mailer addressed the kids, or by electronic delivery to the kids&#39; set-top box. Values of other attributes  818 A,  818 B may designate the particular mechanism for delivery. 
     Various other ways to combine binding of set-top boxes and profile queues are contemplated. For example, in various embodiments specific queues are designated for delivery by DVD only, or delivery to the set-top box only. In another embodiment, rules in a profile can designate that particular available queue entries of profiles are designated as electronic delivery only between other profiles associated with specific users rather than to specific hardware devices. 
     In one embodiment, user accounts, profiles, and the data structures and values within profiles are implemented using tables and relationships in a relational database system, such as Oracle, Microsoft SQL Server, etc. 
     Profile management logic  820  comprises one or more computer programs, other software elements, or processes that implement the functions that are described further herein. 
     7.4 Functional Overview 
       FIG. 9A  is a flow diagram depicting an overview of a method of sharing an item rental account. In step  902 , a request is received to add a queue or profile to an item rental account. In one embodiment, a user interface of an online item rental system provides an “Add Queue” option which, when selected by an owner or user of an item rental account, communicates a request to add a further queue to the account. Alternatively, a functionally equivalent user interface option may be termed an “Add Profile” option. 
     In step  904 , profile identifying information is received. Step  904  may involve receiving data specifying a name for a profile, a sign-in name, a password, a shipping address, or any other suitable combination of values that uniquely identities a profile. 
     In step  906 , a maturity level indicator is received. Step  906  may involve receiving user input for a value for maturity level value  814 A as described above in connection with  FIG. 8 . In embodiments for rental items for which a maturity level indicator is not needed, step  906  may involve receiving user input for a constraint other than maturity level, or step  906  may be omitted. 
     In step  908 , a community participation indicator is received. Step  908  may involve receiving user input that indicates whether to allow the associated profile member to participate in online community features of the item rental system. Examples of online community features include sharing queue contents, notifying other account owners or profile members of item rental activity, instant messaging, writing reviews, communicating with friends, etc. In an embodiment, the community participation indicator is “disabled” for subordinates by default, but “enabled” for the Account Owner. 
     In step  910 , values for one or more other profile attributes are received. Other attributes may include the age of a person associated with a profile, a date on which the profile was created, etc. Such other attributes may be received through user input or may be generated by the item rental system for an account profile record. The values received in steps  904 - 910  all may be received in a single user interface display screen, or the method may involve displaying a user interface dialog or a succession of screens in which the data is collected. 
     In step  912 , a profile record and associated item rental queue are created and stored in a database of the item rental system. The profile record may have the values shown in  FIG. 8 . 
       FIG. 9B  is a flow diagram of a process of assigning a maximum allowed number of rental items to a profile. Using the process of  FIG. 9B , an account owner can specify how many rental items the item rental service should send at a time to the profile member for a newly created profile. In one embodiment, after performing step  912  of  FIG. 9A , the item rental system automatically generates and displays a user interface screen that indicates the maximum number of items that the account may have out at a time, and that prompts the user to enter the maximum number of items that each profile may have out at a time. 
     Alternatively, at any time a user may provide user input requesting to enter such values. In such an embodiment, in step  914  a request to assign rental items to a profile is received. 
     In step  916 , values are received for the maximum allowed rental items for each profile of an account. For example, if an account has two profiles, then step  916  involves receiving a number of maximum allowed rental items for each of the two profiles, verifying that the sum of the two numbers does not exceed the maximum number of items that the associated account may receive at a time, and storing the two values in the database. 
     In step  918 , queues for each profile of the account are updated. Step  918  may involve computing, updating or displaying queue information such as the number of rental items that are available to use before a next subscription period ends, information indicating what rental items are scheduled for shipment, etc. Step  918  generally represents updating any information relating to an item queue or item queue functions that may require changes as a result of a change in the values received at step  916 . 
       FIG. 9C  is a flow diagram of processing a request to add a rental item to a profile member queue. In step  920 , login information for a profile member is received. The login information may comprise, for example, the sign-in name and password that the account owner supplied at step  904  of  FIG. 9A . Step  920  represents receiving and validating or authenticating the login information to verify that the login information identifies a valid, active profile. 
     In step  922 , a request is received to add a rental item to a queue for the profile member. For example, the profile member browses an online catalog of available rental items, selects a desired rental item, and selects a user interface widget that requests adding the selected rental item to the queue of the profile member. 
     In response, at step  924 , the item rental system determines whether a maturity rating for the selected rental item is greater than the allowed maturity level for the profile. In other embodiments for which maturity level values are not associated with rental items, step  924  may involve performing other tests or checks to determine whether the item rental system can rent the selected rental item to the profile member based on a stored constraint other than maturity level. Thus, a test specifically based on maturity level is not required at step  924 , and step  924  broadly represents testing for any configured constraint that applies to the rental item that the profile member has selected. 
     If the maturity rating for the selected rental item is not greater than the allowed maturity level for the profile, then in step  928  the rental item is added to the queue for the profile member. In step  934 , the queue is displayed so that the profile member can verify the addition and see the complete contents of the queue. Thereafter the rental item is provided to the profile member in the manner described above in sections 1-5. 
     If the maturity rating for the selected rental item is greater than the allowed maturity level for the profile, then in step  926  the profile member is prompted to provide a password of the account owner. Thus, to rent an item having a disallowed maturity rating, the profile member must override the allowed maturity level by providing the account owner&#39;s password as proof that the account owner approves of the item rental transaction at the requested maturity level. If the account owner&#39;s password is correct, as tested at step  930 , then control passes to step  928  as described above. 
     If the account owner&#39;s password is incorrect, then in step  932  an error message is presented. In that case, the profile member is required to either provide a valid account owner password at step  926 , or the profile member can abandon the transaction and not rent the item. 
     The broad approach of  FIG. 8  and  FIG. 9A-9C  is now illustrated in the context of one example user interface that may be used to implement an embodiment. Other embodiments of the approach herein may use any other form of user interface that is desired or appropriate.  FIG. 10A  is a screen display diagram showing an example user interface display relating to browsing rental items.  FIG. 10B  is a screen display diagram showing an example user interface display relating to adding a queue or profile to an account.  FIG. 1C  is a screen display diagram showing an example profile introduction.  FIG. 10D  is a screen display diagram showing an example user interface display relating to entering attributes of a profile.  FIG. 10E  is a screen display diagram showing an example user interface display relating to browsing rental items. 
     Referring first to  FIG. 10A , in one embodiment a graphical user interface (GUI)  1000  of a conventional browser program, such as Microsoft Internet Explorer, Mozilla Firefox, Netscape Navigator, etc., displays a first page  1002  for the Netflix® item rental service that is commercially offered by Netflix, Inc., Los Gatos, Calif. Page  1002  comprises a plurality of page selection tabs  1004  which, when selected by user input such as a mouse click, causes a server of the item rental service to generate and transmit to the browser page content  1008  associated with the selected tab. In one embodiment, tabs respectively entitled Browse, Recommendations, Friends, and Queue enable a user to browse rental items such as movies, display recommendations for rental items that are automatically generated by the item rental service, review rental activity of friends who also use the service, and display the user&#39;s item rental queue. Each tab  1004  may have one or more associated sub-functions that are represented by hyperlinks  1006 . 
     A profile combo box  1010  specifies a name of the currently active profile member. If a user account has a plurality of profiles associated with the account, selecting profile combo box  1010  causes the browser to display a list of the profiles, enabling user selection of different profiles. In an embodiment, profile combo box  1010  functions using JavaScript code that is delivered to the browser with page  1002 . 
     Referring now to  FIG. 10B , when an account has only one associated profile for the account owner, selecting profile combo box  1010  causes the browser to display two links entitled “Add a Queue?” and “Sign Out.” If other profiles are associated with the account, then the names of such profiles are also displayed. For purposes of illustrating a clear example, the following description assumes that an account had one profile and the account owner wishes to add a second profile and allocate rental items to the new profile. Therefore, for purposes of the example, assume that the “Add a Queue?” link is selected in profile combo box  1010  of  FIG. 10B . 
     Referring now to  FIG. 10C , in one embodiment, in response to selecting the “Add a Queue?” link a welcome page  1020  is displayed. Welcome page  1020  may comprise a panel  1022  providing information about how profiles function and a confirmation button  1024 . Selecting the confirmation button  1024  enables the account owner to confirm that the account owner wishes to create a profile that will function as stated in panel  1022 . Use of a welcome page  1020  is optional in an embodiment and may be omitted. However, the user of a welcome page  1020  may improve performance of an item rental system by preventing the needless creation of profile records by account owners who select “Add a Queue?” without fully understanding how profiles function. 
     Referring now to  FIG. 10D , in response either to selection of the “Add a Queue?” link or the confirmation button  1024 , the item rental service generates and transmits to the browser a member profile page  1030  comprising data entry fields that define a profile member and the capabilities of the profile member. In one embodiment, member profile page  1030  comprises name fields  1032 , a sign-in name field  1034 , password fields  1036 , maturity level combo box  1038 , an address display  1040 , a community check box  1042 , a save button  1044 , and a cancel button  1046 . 
     The name fields  1032  receive a name of a new profile member. The sign-in name field  1034  receives a name that the profile member will use to sign in to the profile, such as an email address or handle. The password fields  1036  receive a password that the profile member will use to obtain secure access to the profile and may include a password confirmation field to ensure that an entered password is accurate. 
     The account owner may specify a maximum maturity level allowed for the profile member using maturity level combo box  1038 . In other embodiments, a user interface widget other than a combo box may be used. In other embodiments, a constraint other than maturity level may be entered. 
     The address display  1040  indicates the shipping address to which rental items for the profile member will be sent. In one embodiment, address display  1040  is a data entry field, and the account owner may specify an alternate delivery address for the profile member. The account owner may specify whether the profile member can participate in online community features by selecting a community check box  1042 . 
     The account owner may select the save button  1044  to cause the item rental service to verify the entered data values and save the entered values in the database of the item rental service. The account owner may select the cancel button  1046  to discontinue entering a profile record. 
     If all the foregoing values are entered and the account owner selects the save button  1044 , then in response, the item rental service generates and sends to the browser a page requesting entry of the maximum number of items that the profile member may receive at a time. Referring now to  FIG. 10E , in one embodiment, an assignment page  1050  is displayed comprising a table  1052  that lists the profile names  1054 ,  1056  of each profile of the current account and comprises data entry fields  1058  for specifying the maximum number of items that each profile member is allowed to receive. 
     The account owner may modify values in fields  1058  using the keyboard or other user input and may save the entered values using a save button  1062 . In an embodiment, the sum of values in fields  1058  must be less than or equal to a maximum number of rental items allowed for the account, as indicated by a Membership Total value  1060 . Therefore, in one embodiment, selecting save button  1062  causes JavaScript code in the browser to verify that the sum of the fields is less than the allowed maximum. If not, then the account owner is prompted using a JavaScript error message to correct the entered values. The account owner may save the revised values, or discontinue entering a profile record by selecting the cancel button  1064 . 
     Assuming the entered values are correct and are saved, in response, creation of a new profile is complete, and the item rental service generates and sends to the browser a queue display page for the newly created profile. The account owner or the profile member then may add rental items to the queue. 
     Referring now to  FIG. 10F , in one embodiment a queue page  1070  may include a first list  1076  of rental items that the profile member has already received and a second list  1078  of rental items that are in the queue but not yet provided to or received by the profile member. In the example of  FIG. 10F , the profile member named “Jane Profile” has not received any rental items, and has one rental item (“Melinda and Melinda”) in queue. 
     Profile combo box  1010  displays the name of the current profile member (“Jane Profile”) by default. When the profile combo box  1010  is selected, the profile combo box displays the current profile member name  1072 , the account owner&#39;s name  1074 , and a sign out link. 
     To add other rental items to the queue, the profile member may select the Browse link  1004  to browse rental items, or may use a search box to enter the name of a particular rental item or other information about a specified rental item. In an embodiment, a profile member is allowed to add a rental item to the profile member&#39;s queue only if the maturity level value associated with that rental item is less than or equal to the maturity level value specified in the profile. 
     As an example, assume that rental items are movies, and that the maturity level in the profile for profile member “Jane Profile” is PG-13. If Jane Profile attempts to rent a movie having a maturity level higher than PG-13, the item rental service requires confirmation by the account owner as a condition of allowing the rental. For example, assume that Jane Profile browses movies available for rental, selects “The Talented Mr. Ripley,” which is rated R, and selects an Add button to add that movie to Jane Profile&#39;s queue. In response, the item rental service generates and sends to the browser a confirmation page. 
     Referring now to  FIG. 10G , in one embodiment, a confirmation page  1080  comprises item rental information  1082 , an information panel  1084 , a password field  1086 , and an Add Movie button  1088 . Rental information  1082  provides brief information about the selected rental item, so that the account owner can see what the profile member wishes to rent. Information panel  1084  comprises text explaining to the profile member that account owner approval is required for the rental item because its maturity level exceeds the maturity level configured for the profile. 
     If the proposed rental transaction is acceptable, then the account owner enters the account owner&#39;s password in the password field  1086  and selects the Add Movie button  1088 . In response, the item rental service validates the entered password. If the password is valid, then the item rental service adds the selected rental item to the profile member&#39;s queue and re-displays the queue, as in  FIG. 10F . If the password is invalid, then the item rental service re-generates the confirmation page  1080  and includes a message indicating that the password was invalid. The profile member can abandon the transaction by selecting the Browse, Recommendations, Friends, or Queue tabs, or by entering information in search box  1089 . 
     In an alternative embodiment, rather than displaying the information presented in confirmation page  1080  directly to the Profile Member, the item rental service may send an email message to the Account Owner to request approval for the proposed rental. The email message contains a hyperlink which, when selected by the Account Owner, causes a browser at the Account Owner&#39;s location to display confirmation page  1080 . This approach is useful to facilitate remote approval of a rental item, that is, when the Account Owner and the Profile Member are in separate locations and the Profile Member wishes to obtain remote approval to rent an item. 
     7.5 Additional Features and Functions 
     Other user interface displays and processes may implement the functions described above in section 8.1 and section 8.2. Further, various embodiments may implement any one or more of the following features and functions. 
     In one embodiment, if an Owner elects to downgrade to a rental service subscription plan that does not support the number of rental items assigned to the Owner&#39;s current number of Profile Queues, at the end of the next billing period (that is, when the downgrade takes effect), the item rental service sets all non-Owner Queues to “0” and the owner must reallocate items to Profiles. When the downgrade occurs, an Owner receives an email notifying the Owner that all rental items have been reassigned to the Owner and Owner must reassign rental items to Profiles in the Account. 
     In an embodiment, if the Owner upgrades his or her subscription with the item rental service, the item rental service receives a Program Change page that explains the rental items have been added to the Owner&#39;s Queue and that the Owner should immediately allocate those rental items using the process of  FIG. 10E . If the upgrade is “deferred” because a customer has already taken advantage of an immediate upgrade, the Program Change page specifies that rental items will be added in the future when the change takes effect and the Owner should allocate the rental items at that time. 
     In an embodiment, an Owner can view a full rental history for all Profiles in the Account. This approach enables the Owner to report problems for any items received in their Account. In an embodiment, the Owner can display either the Owner&#39;s rental history or an aggregate account rental history. 
     In one embodiment, multiple Users of Profiles in the same Account may have the same rental item in their Queue. If any User adds a rental item to the User&#39;s Queue that already exists in one or more of the other Queues in the Account (or is currently “out” to the household associated with the Account), the item rental service generates and sends a page to the User advising that the rental item resides in another User&#39;s Queue for the same household or has been shipped. In an embodiment, the page indicates which Queue and what position the item is in. However, the User is allowed to place the movie in their Queue. 
     In an embodiment, an Owner can place rental items into a Subordinate Queue, even if the Subordinate is restricted to a particular maturity level or restricted by another constraint. The rental items the Owner can place into a Subordinate Queue are not bound by the constraint of the Subordinate&#39;s Profile (e.g., An Owner can place an “R” movie into a PG-13 Queue.) 
     In an embodiment, the item rental service provides a Switch Profile with which an Owner can quickly work with the Queue and Profile information of another User without entering a password. In this embodiment, by allowing the owner to quickly become another user and by implementing the constraint override function described above, the item rental service allows the Owner to become another User, find a rental item using either search or browsing, add the selected rental item to the subordinate&#39;s Queue, position the rental item in the queue, and then log out of the subordinate account and return to the User&#39;s own Profile. 
     In an embodiment, an Owner can enable or disable restrictions on Subordinate users that define the types of email that the item rental service sends to the Subordinates. In one embodiment, restrictions can individually control each of the following: ship/receive notifications; newsletters; movie suggestions; critics&#39; reviews; account hold notices; and special offers. 
     In an embodiment, a co-Owner may be designated. To reduce the administration burden on the Owner, the Owner can designate one or more of the subordinate users in the Account as Co-Owner with full administration rights. For example, a family of 4 might have an Account where “mom” signs up using her credit card and email address (and is the Owner). “Mom” then creates three additional Users (“dad”, “teen”, “kid”) and designates “dad” as Co-Owner. “Dad” would have all the same administration rights as “mom”. 
     In an embodiment, Owners can “remove” a profile from an Account, and only Owners can do so. Removing a profile, in one embodiment, does not delete the profile but merely removes an association between the profile and the account. In an embodiment, when the Owner removes an profile from the Account, all existing identity, queue, ratings, recommendations, and rental history for the removed profile remains intact in the database in records for the removed profile. 
     If a Profile Member associated with a removed Profile attempts to log into the item rental service, the Profile Member is required to complete a sign-up process before receiving access to the Profile. This approach reduces the possibility that Profile Members associated with removed Profiles that had constraints would be able to perform actions (e.g., view previews, etc.) that were prohibited when the Profile was active. 
     In one embodiment, upon removal of a Profile, the Account Owner can request the item rental service to send an email to the newly removed Profile Member alerting the Profile Member to their new status, with instructions on how to reactivate the profile as a new account. 
     In one embodiment, a Spin-Off feature enables subordinate users not subject to maturity restrictions or other constraints to “spin off” their profile out of an existing account and establish it as a new account. Any profile that is restricted by a constraint cannot be spun out; the Account Owner must first remove the constraint. This approach helps eliminate the risk that a child Profile Member could attempt to make the child&#39;s Profile “private” without parental knowledge. 
     In an embodiment, when a profile user spins out, all existing identity, queue, ratings, recommendations, and rental history (for that profile) remain intact with that profile in the database, but the Profile is disassociated from the Account. If a Profile Member associated with a spun-off Profile attempts to log into the item rental service, the Profile Member is required to complete a sign-up process before receiving access to the Profile. 
     8. Implementation Mechanisms 
     The approach described herein for renting items to customers is applicable to any type of rental application and (without limitation) is particularly well suited for Internet-based rental applications for renting movies and music to customers. Embodiments may be implemented in hardware circuitry, in computer software, or a combination of hardware circuitry and computer software and is not limited to a particular hardware or software implementation. 
       FIG. 7  is a block diagram that illustrates a computer system  700 . Computer system  700  includes a bus  702  or other communication mechanism for communicating information, and a processor  704  coupled with bus  702  for processing information. Computer system  700  also includes a main memory  706 , such as a random access memory (RAM) or other dynamic storage device, coupled to bus  702  for storing information and instructions to be executed by processor  704 . Main memory  706  also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor  704 . Computer system  700  further includes a read only memory (ROM)  708  or other static storage device coupled to bus  702  for storing static information and instructions for processor  704 . A storage device  710 , such as a magnetic disk or optical disk, is provided and coupled to bus  702  for storing information and instructions. 
     Computer system  700  may be coupled via bus  702  to a display  712 , such as a cathode ray tube (CRT), for displaying information to a computer user. An input device  714 , including alphanumeric and other keys, is coupled to bus  702  for communicating information and command selections to processor  704 . Another type of user input device is cursor control  716 , such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor  704  and for controlling cursor movement on display  712 . This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. 
     The computer system  700  may be used as part of renting items to customers and for other aspects of the disclosure. For example, renting of items to customers is provided by computer system  700  in response to processor  704  executing one or more sequences of one or more instructions contained in main memory  706 . Such instructions may be read into main memory  706  from another computer-readable medium, such as storage device  710 . Execution of the sequences of instructions contained in main memory  706  causes processor  704  to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory  706 . In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software. 
     The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor  704  for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device  710 . Volatile media includes dynamic memory, such as main memory  706 . Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus  702 . Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. 
     Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read. 
     Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor  704  for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system  700  can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus  702  can receive the data carried in the infrared signal and place the data on bus  702 . Bus  702  carries the data to main memory  706 , from which processor  704  retrieves and executes the instructions. The instructions received by main memory  706  may optionally be stored on storage device  710  either before or after execution by processor  704 . 
     Computer system  700  also includes a communication interface  718  coupled to bus  702 . Communication interface  718  provides a two-way data communication coupling to a network link  720  that is connected to a local network  722 . For example, communication interface  718  may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface  718  may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface  718  sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. 
     Network link  720  typically provides data communication through one or more networks to other data devices. For example, network link  720  may provide a connection through local network  722  to a host computer  724  or to data equipment operated by an Internet Service Provider (ISP)  726 . ISP  726  in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”  728 . Local network  722  and Internet  728  both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link  720  and through communication interface  718 , which carry the digital data to and from computer system  700 , are exemplary forms of carrier waves transporting the information. 
     Computer system  700  can send messages and receive data, including program code, through the network(s), network link  720  and communication interface  718 . In the Internet example, a server  730  might transmit a requested code for an application program through Internet  728 , ISP  726 , local network  722  and communication interface  718 . One such downloaded application provides for the renting of items to customers as described herein. 
     The received code may be executed by processor  704  as it is received, and/or stored in storage device  710 , or other non-volatile storage for later execution. In this manner, computer system  700  may obtain application code in the form of a carrier wave. 
     The novel approach described herein for renting items to customers provides several advantages over prior approaches for renting items to customers. First, the decision of what items to rent may be separated from the decision of when to rent the items. Customers may specify what items to rent using the item selection criteria and receive the items at a future point in time, without having to go to the provider to pick up the items. The selection criteria may be user specific and may indicate a desired fulfillment sequence. Furthermore, customers are not constrained by conventional due dates and instead may establish continuous, serialized rental streams of items. The approach also allows more efficient inventory management. 
     The “Max Out” approach for inventory management allows users to maintain their own inventory of items that are periodically replaced by other items according to specified event criteria. The event criteria that trigger sending another item to a customer are very flexible and may be tailored to the requirements of a particular application. For example, as described herein, the event criteria may include a return of any of the items currently in use by the customer or merely customer notification. This is very convenient in the context of movie rentals since the return of a movie to the provider automatically triggers the sending of another movie to the customer. The “Max Turns” approach for inventory management, when used alone or in combination with “Max Out,” provides even greater flexibility for customers and providers. The max number of turns can be selected individually for particular customers depending upon their particular needs. 
     The “Max Out” and “Max Turns” approaches provide great flexibility in establishing subscription models to satisfy the needs of a particular application. Specifically, the size and replacement frequency of customer inventories can be tailored to each customer with individualized subscription plans. 
     In the foregoing specification, the invention has been described with reference to specific embodiments thereof. However, various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. 
     For example, the invention has been described as applicable to an implementation anticipating Internet based ordering and mail or other long-distance delivery of the items, where the special advantages of the method are very attractive. However the same invention may be applied in a more conventional video, games, or music rental-store setting, where subscription customers may be allowed rentals of a specified number of movies, games, or music selections at any time, and/or in one subscription period, without rental return due dates, in exchange for a periodic rental subscription fee.