Patent Publication Number: US-2022230234-A1

Title: Rent to own transaction system

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims the benefit of U.S. Provisional Patent Application No. 63/138,010, filed on Jan. 15, 2021, which is incorporated reference in its entirety. 
    
    
     BACKGROUND 
     This disclosure relates to systems and methods for rent-to-own (RTO) execution through an ecommerce transaction. 
     Rent-to-own (RTO) is a type of transaction where items such as furniture, consumer electronics, home appliances, real property, mobile phones, and the like are rented or leased in exchange for periodic rental payments, with an option to purchase at some point during the agreement. Typically, the lessee can purchase the leased item at any time during the agreement, and can terminate the agreement by simply returning the property. Moreover, in some RTO transactions, the customer can make the periodic payments on the merchandise for a pre-specified period of time, at which point they would own the good outright. Many RTO transactions further allow the customer to pay off the remaining balance on the agreement at any point in time in order to obtain permanent ownership of the good. 
     SUMMARY 
     Disclosed example systems and methods relate to an online process for a rent-to-own (RTO) transaction. In accordance with some examples, an RTO transaction system includes a retail computer configured to communicate with a customer computer. A product inventory is displayed on the customer computer, which further receives a product selection by a customer. The retail computer receives identifying information from the customer via the customer computer, and the identity of the customer is verified based on the received identifying information. An RTO agreement based on the product selection and the identifying information is created by the retail computer, and the RTO agreement is displayed on the customer computer, whereby an execution of the RTO agreement by the customer via the customer computer is received by the retail computer. 
     In accordance with further examples, an RTO transaction system includes a customer computer configured to communicate with a retail computer associated with an RTO store. The customer computer displays a user interface and receives identifying information regarding a customer via the user interface display. The identifying is transmitted information to the retail computer. The customer computer displays on the user interface an indication of an identification of the customer from the retail computer that is based on the transmitted identifying information. A product inventory is received from the retail computer and displayed on the user interface. A product selection is received via the user interface and transmitted to the retail computer. The user interface then displays an RTO agreement received from the retail computer based on the product selection and the identifying information, and an execution of the RTO agreement is received via the user interface, then transmitted to the retail computer. Product delivery instructions are received via the user interface and transmitted transmit to the retail computer. 
     In accordance with still further disclosed aspects, an RTO transaction method includes communicating with a remote customer computer, determining a geographical location of the customer computer, and displaying a product inventory on the customer computer based on the determined geographical location. A product selection and identifying information from the customer are received via the customer computer. The identity of the customer is verified based on the received identifying information. An RTO agreement based on the product selection, the identifying information, and the financial information is displayed on the customer computer, and the RTO agreement is executed via the customer computer. Product delivery information is provided, and the product is delivered based on the received product delivery information. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Aspects of the present disclosure are best understood from the following detailed description when read with the accompanying figures. It is noted that, in accordance with the standard practice in the industry, various features are not drawn to scale. In fact, the dimensions of the various features may be arbitrarily increased or reduced for clarity of discussion. 
         FIG. 1  is a block diagram illustrating an example of a rent-to-own (RTO) transaction system. 
         FIG. 2  is a block diagram illustrating an example of a computer system suitable for use in the RTO transaction system shown in  FIG. 1 . 
         FIG. 3  is a flow diagram illustrating an example of an RTO transaction process. 
         FIG. 4  is a block diagram illustrating an example of a geographic location process. 
         FIG. 5  is a block diagram illustrating an example of a product browsing process. 
         FIG. 6  is a block diagram illustrating an example of a risk analysis process. 
         FIG. 7  is a user interface screenshot illustrating an example of a verification interface. 
         FIG. 8  is a user interface screenshot illustrating an example of a customer approval notification. 
         FIG. 9  is a user interface screenshot illustrating an example of a customer denial notification. 
         FIG. 10  is a user interface screenshot illustrating an example of a customer conditional approval. 
         FIG. 11  is a block diagram illustrating an example of a checkout process. 
         FIG. 12  is a user interface screenshot illustrating an example of RTO agreement information. 
         FIG. 13  is a user interface screenshot illustrating an example of an RTO agreement signing trigger. 
         FIG. 14  is a user interface screenshot illustrating an example of an RTO agreement execution verification. 
         FIG. 15  is a block diagram illustrating an example delivery process. 
         FIG. 16  is a flow diagram illustrating example transaction paths for an RTO transaction process. 
     
    
    
     DETAILED DESCRIPTION 
     The following disclosure provides many different embodiments, or examples, for implementing different features of the provided subject matter. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed. 
     Further, spatially relative terms, such as “beneath,” “below,” “lower,” “above,” “upper” and the like, may be used herein for ease of description to describe one element or feature&#39;s relationship to another element(s) or feature(s) as illustrated in the figures. The spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation depicted in the figures. The apparatus may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein may likewise be interpreted accordingly. 
     In a rent-to-own (RTO) transaction, items such as furniture, consumer electronics, home appliances, real property, mobile phones, and the like are rented or leased in exchange for periodic rental payments (e.g. weekly or monthly), with an option to purchase at some point during the agreement. Typically, the lessee can purchase the leased item at any time during the agreement, and can terminate the agreement by simply returning the property. The RTO process usually involves a customer shopping for goods at a retail store or through web sites or mobile shopping applications. Once the product selection has been made, the customer completes the lease application process at the retail store. 
     Aspects of this disclosure relate to RTO transactions that may be entirely or nearly entirely completed through an e-commerce system, including disbursement of funds and signing of contractual agreements between the involved parties. More specifically, example implementations include a customer initiating an RTO transaction with or without selecting product(s), with the intent to conduct business with an RTO company through an e-commerce transaction. This simplifies the RTO process for the customer, often eliminating the requirement for the customer to shop at a retail store, and/or visit such a retail establishment to complete the RTO transaction and take possession of the goods. 
     Such RTO transactions may involve several steps and processes and use systems from the customer side (e.g. home computers, laptop computers, tablet devices, mobile phones, etc.) and the RTO company side (e.g. point-of-sale systems, retail store computers, servers, etc.) to establish geographic location identification, product selection and associated product inventory counts, risk and decision analyses, checkout processes, appropriate initial payments to secure the parties&#39; intent of the RTO transaction, signing of RTO contractual agreements, product delivery, etc. 
       FIG. 1  depicts an embodiment of an RTO transaction system suitable for implementing various principles disclosed herein. Various methods, apparatuses and systems are presented, and are discussed with reference to an RTO company that offers RTO or lease-to-own (LTO) arrangements to customers. In general, RTO and LTO are used interchangeably herein. An RTO arrangement is but one example of a transaction in which the methods, apparatuses and systems disclosed herein are useful. 
       FIG. 1  depicts a consumer or customer  100  and a retailer  102 , such as an RTO retailer. In the situation depicted by  FIG. 1 , the customer  100  is desirous of acquiring a product offered by the RTO retailer  102  via an RTO agreement.  FIG. 1  illustrates the customer  100  in different scenarios, including the customer being located at the retailer  102  establishment and the customer being located at a location  118  remote from the retailer  102 , such as at the home of the consumer.  FIG. 1  illustrates examples of a customer computing device including a computer  104   a  such as a desktop or laptop computer, and a mobile device  104   b  such as a smart phone or tablet (collectively referred to as the customer computer  104 ). Other consumer computers are within the scope of the disclosure. 
     The customer  100  may access a website via the customer computer  104 , and/or the customer computer  104  may include and app to access capabilities permitting the user to conduct some or all of the functions involved in various shopping and RTO transactions discussed herein. For the sake of clarity, this website and/or app may be referred to herein as the “RTO” website or app where confusion may arise as to which particular website or app is being referred to. Such a website or app may be published by an RTO company offering RTO arrangements to customers. In some instances, the customer  100  may not have the app installed on his device  104 . According to some embodiments, a barcode  106 , such as a matrix barcode (example: a QR code) may be printed on an item or surface within the establishment  102 , along with an instruction that informs the customer  100  that scanning the barcode  106  with the camera integrated within the smart device  104  will result in a web browser installed on the device navigating to a site wherein the app may be downloaded. According to this embodiment, the barcode  106  encodes a universal resource locator (URL) associated with a webpage wherein the user may initiate the process of downloading the aforementioned app. According to some embodiments, the particular app accessed by the customer  100  to scan the barcode (example: a “camera app”) accesses capabilities exposed via the operating system of the device  104  to recognize and respond to the presence of a barcode in the visual data captured by the camera. The executable code providing these capabilities may be dynamically linked into the app&#39;s code space. The barcode  106  may also include information causing an app on the smart device (example: an “app store” app) to launch and open to a screen on which the app is available for download. According to other embodiments, the retailer  102  may provide written or oral instructions directing the customer  100  to download the app as a precondition to entry into an RTO transaction. 
     The RTO website and app (collectively referred to as the RTO app for brevity) communicate and interoperate with a backend system  108  operated by or on behalf of an RTO company extending RTO arrangements. The backend system  108  may, according to some embodiments, communicate with additional computer system(s)  110  to provide the various functions involved in creating and managing an RTO arrangement. The backend system  108  additional computer system(s)  110  shown in  FIG. 1  are shown as being located remotely from the retail establishment  102 , though these computer systems could be implemented by computer systems located at the retail establishment  102 . In general, the RTO app, backend system  108  and additional external systems  110  cooperate to implement various shopping and RTO processes discussed herein. 
     According to some embodiments, the retail location or store  102  is outfitted with a terminal  114 , such as a computer or tablet. The terminal  114  may have the RTO app and/or other software installed to cause it to operate similarly to the customer computer  104 . For example, the terminal  114  may be operated by personnel of the RTO company and/or made available for use by the customer  100  when located at the retail store  102 . The retail store  102  may further include a point of sale system  122 , which also may communicate with the backend system  108  and additional systems  110 . Among other things, the backend system  108  includes a data store  112  storing various information such as product descriptions, inventory information for the retail establishment  102 , customer information, RTO agreement information, etc. Processes  120  can interface with the datastore  112 , and create, update, and delete information stored therein, among other things. 
       FIG. 2  depicts a schematic illustration of one embodiment of a computer system  200 , which can function as a server system, a laptop, tablet, smartphone, a mobile device, including systems such as the customer computer  104 , the terminal  114 , the backend system  108 , the additional systems  110 , etc. It should be noted that  FIG. 2  is meant only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate.  FIG. 2 , therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner. 
     The computer system  200  is shown comprising hardware elements that can be electrically coupled via a bus  205  (or may otherwise be in communication, as appropriate). The hardware elements may include one or more processors  210 , including without limitation one or more general-purpose processors and/or one or more special-purpose processors (such as digital signal processing chips, graphics acceleration processors, and/or the like); one or more input devices  215 , which can include without limitation a mouse, a keyboard, touchscreen and/or the like; and one or more output devices  220 , which can include without limitation a display device, a printer and/or the like. 
     The computer system  200  may further include (and/or be in communication with) one or more storage devices  225 , which can comprise, without limitation, local and/or network accessible storage, and/or can include, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like. The storage devices  225  may be configured to implement the data store  112  shown in  FIG. 1 , among other things. 
     The computer system  200  may also include a communications subsystem  230 , which can include without limitation a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device and/or chipset (such as a BLUETOOTH™ device, an 802.11 device, a WiFi device, a WiMax device, cellular communication facilities, etc.), and/or the like. The communications subsystem  230  may permit data to be exchanged with a network (such as the network described below, to name one example), other computer systems, and/or any other devices described herein. In many embodiments, the computer system  200  will further comprise a working memory  235 , which can include a RAM or ROM device, as described above. 
     The computer system  200  also can comprise software elements, shown as being currently located within the working memory  235 , including an operating system  240 , device drivers, executable libraries, and/or other code, such as one or more application programs  245 , which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more processes such as the RTO app and web site discussed herein might be implemented as code and/or instructions executable by a computer (and/or a processor within a computer); in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods. 
     A set of these instructions and/or code might be stored on a computer-readable storage medium, such as the storage device(s)  225  described above. In some cases, the storage medium might be incorporated within a computer system, such as the system  200 . In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium, such as a compact disc), and or provided in an installation package, such that the storage medium can be used to program, configure and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system  200  and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system  200  (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.) then takes the form of executable code. 
     It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used, and/or particular elements might be implemented in hardware, software (including portable software, such as applets, etc.), or both. Further, connection to other computing devices such as network input/output devices may be employed. 
     As mentioned above, in one aspect, some implementations may employ a computer system (such as the computer system  200 ) to perform methods in accordance with various disclosed embodiments. According to a set of embodiments, some or all of the procedures of such methods are performed by the computer system  200  in response to processor  210  executing one or more sequences of one or more instructions (which might be incorporated into the operating system  240  and/or other code, such as an application program  245 ) contained in the working memory  235 . Such instructions may be read into the working memory  235  from another computer-readable medium, such as one or more of the storage device(s)  225 . Merely by way of example, execution of the sequences of instructions contained in the working memory  235  might cause the processor or processors  210  to perform one or more procedures of the methods described herein. 
     The terms “machine-readable medium” and “computer-readable medium,” as used herein, refer to any medium that participates in providing data that causes a machine to operate in a specific fashion. In an embodiment implemented using the computer system  200 , various computer-readable media might be involved in providing instructions/code to the processor or processors  210  for execution and/or might be used to store and/or carry such instructions/code (e.g., as signals). In many implementations, a computer-readable medium is a physical and/or tangible storage medium. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical and/or magnetic disks, such as the storage device(s)  225 . Volatile media include, without limitation, dynamic memory, such as the working memory  235 . Transmission media include, without limitation, coaxial cables, copper wire and fiber optics, including the wires that comprise the bus  205 , as well as the various components of the communication subsystem  230  (and/or the media by which the communications subsystem  230  provides communication with other devices). Hence, transmission media can also take the form of waves (including without limitation radio, acoustic and/or light waves, such as those generated during radio-wave and infrared data communications). 
     Common forms of physical and/or tangible 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, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, 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 instructions and/or code. 
     Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor or processors  210  for execution. Merely by way of example, the instructions may initially be carried on a magnetic disk and/or optical disc of a remote computer. A remote computer might load the instructions into its dynamic memory and send the instructions as signals over a transmission medium to be received and/or executed by the computer system  200 . These signals, which might be in the form of electromagnetic signals, acoustic signals, optical signals and/or the like, are all examples of carrier waves on which instructions can be encoded, in accordance with various embodiments of the invention. 
     The communications subsystem  230  (and/or components thereof) generally will receive the signals, and the bus  205  then might carry the signals (and/or the data, instructions, etc. carried by the signals) to the working memory  235 , from which the processor(s)  205  retrieves and executes the instructions. The instructions received by the working memory  235  may optionally be stored on a storage device  225  either before or after execution by the processor(s)  210 . 
       FIG. 3  is a flow diagram illustrating aspects of an RTO transaction process  300  in accordance with some examples. As noted above, in some examples the RTO transaction system may be implemented with the backend system  108  shown in  FIG. 1 , also referred to herein as the retail computing system or computer  108 .  FIG. 2  illustrates aspects an example computer system  200  suitable for the backend, or retail computer  108 , as well as for the customer computer  104 . The computers  104  and  108  thus include the processor(s)  210  and the memory  225 / 235  communicably connected with and readable by the processor  210 . The memory stores instructions that, when executed by the processor  210 , cause the retail computer  108  to communicate with the customer computer  104  as indicated in block  310 . This may be through a displayed web page and/or the RTO app. Accordingly, in some examples communicating with the customer computer  104  includes displaying a web page user interface on the customer computer  104 . 
     In addition to providing a shopping experience for the customer  100 , the interface provided on the customer computer  104  allows the customer to initiate an online order that could result in, for example, a web lead, a product reservation, a denial, or a full online RTO transaction. The customer  100  may select a desired product first, or receive an RTO decision online first. In either scenario, the customer  100  is identified at block  312  through various remote processes. With existing RTO transactions, the customer  100  is simply identified in the retail location  102  by checking a picture ID such as a driver&#39;s license. For a completely remote RTO transaction, other identification procedures are employed. Based on the identity verification in block  312 , a risk analysis may then be performed in block  314 . If the risk analysis at block  314  is satisfactory, the RTO agreement is created as indicated a block  316  by the retail computer  108 . The RTO agreement may then be displayed for the customer  100  on the customer computer  104 , by which the customer  100  may execute the agreement as indicated at block  318 . 
     As noted above, in various examples the customer  100  may begin the RTO process by selecting a desired product. This process may include a geographic location identification, and product inventory counts associated with retail locations  102  associated with the identified location. 
       FIG. 4  illustrates example process steps associated with a geographic location process  330 . Once the retail computer  108  communicates with the customer computer  104  and identifies the customer as indicated in blocks  312  of  FIG. 3 , the consumer location is identified at block  332 . Location identification may be accomplished through various process and provide varying ranges of precision dependent upon the consent of the customer  104 . For instance, GPS processes may be used for location identification, or the customer  104  can simply enter his or her address or zip code. The location information is mapped against proprietary regions by the retail computer  108  and reflected appropriately to the consumer  100  on the customer computer  104 . The closest region may be selected by the customer  104  or automatically tied to the closest region. In some examples, products leased to the customer  100  may be supplied directly from the retail location  102 . In this situation, if a valid region is selected as determined in block  334 , inventory corresponding to that region will be pulled from the retail system  108  and displayed accordingly to the consumer computer  104  as shown in block  336 . Inventory counts may further be displayed at block  336 . If there is not a valid region association, special order information may be provided at block  338 , for instance, a direct ship option to consumer may be available in the determined location. In other examples, stock may be supplied from a centralized warehouse. In such situations, the geographical location information may be used to determine if products are able to be shipped to the customer  100 . 
     Various additional options are available for displaying available products as indicated in blocks  336  and/or  338 . For instance, multiple retail stores  102  may be located within an identified region (block  334 ). One store  102  may be designated as the “home” store based on factors such as proximity to the customer  100  or size of the store. If the home store does not have certain products in stock, another store in the region could provide the product based on an “internal” product transfer. In other embodiments, arrangements are made with outside suppliers to provide products that may be shipped directly to customers or to a designated retail store  102 . Thus, products identified in block  336  may be based on availability in the identified region, not necessarily only what is available at particular store(s) in the region. 
     Different geographical location processes may be employed in the process  330  shown in  FIG. 4 . For instance, the location determination  332  may be made using GPS, IP address information, or other location algorithms, or by the customer selecting a zip code, for example. Once the region is determined and validated in block  334 , this information may be used by the retail computer  108  to display relevant inventory to the customer  100 . This allows the customer  100  to choose the nearest product(s), which may be displayed by way of delivery lead times and/or cost based on the verified location. Specific stores in the region may display inventory unique to those stores, including both new and used items. Displaying and providing the ability to rent used items in addition to new items through the online medium (i.e customer computer  104 ) can significantly improve store operational abilities. 
       FIG. 5  illustrates an example of aspects of a product browsing process  340 . At block  342  products are displayed on the customer computer  104 . The displayed products and quantities thereof may be determined in accordance with the process  330  shown in  FIG. 4 . The displayed products may further include special order products (i.e. not readily available at the local RTO location  102 , and are shipped directly from the supplier to the retail store  102  or to the customer  100 ), or be identified as evergreen (i.e. products that are available for a longer period of time). Special order products may be associated with the identified region. 
     The customer  100  may choose to add a product to a virtual cart in block  344 , which can be performed multiple times to get the desired items into the cart as indicated at blocks  346  and  348 . The cart may be saved, wherein the product(s) will be in the cart until they choose to proceed (or the product is no longer available). There are multiple ways that a consumer may proceed following finalizing product selections. A customer  100  may decide to submit a lead in block  350 , which may then go through a risk analysis step such as operation  314  of  FIG. 3 , and then processed by the retail computer  108 . A store employee may then coordinate further with the customer. 
     The customer  100  may also reserve the product in block  352 , where an initial payment may be taken but no RTO agreement is completed. The customer  100  may choose to go to the associated store  102  to then sign an RTO agreement, communicate with retail personnel further, continue with the online process at a later time, etc. Still further, the customer  100  may choose to conduct a full checkout and transaction online as indicated in block  356 , which allows them to sign the RTO agreement online and pay for the product as well in some examples. This may further include the ability to schedule a delivery to the customer&#39;s home  118 . 
       FIG. 6  illustrates aspects of an example a risk analysis process  360 . A number of options are provided for the customer to initiate the risk analysis through the customer computer  104 , which are communicated to the retail computer  108 . The retail computer  108  is configured to processes received information through a superset of various points of data. A recommendation is generated by the retail computer  108 , which is then provided back to the customer  100  via the customer computer  104 . As noted above, the risk analysis  360  may be conducted subsequent to a product selection using the customer computer  104 , or it may occur prior to product selection. 
     As noted above, the customer  100  identification is verified at block  312 , which may be followed by a risk analysis  314  based on the identification process  312 . In some examples, these steps may be combined. To ensure the RTO contractual agreement is established with the correct parties, initial checks will protect against various fraudulent actors (e.g. bots or other types) in blocks  312  and  314 .  FIG. 7  is a screen shot illustrating an example of one verification interface screen  380  displayed on the customer computer  104 , such as through the RTO phone app or website. The illustrated example uses a simplified phone number analysis where the customer&#39;s phone number, email, and the last four digits of their social security number are entered. This allows a number of additional calculations through the retail computer  108  and/or additional systems  110 . The information obtained through the phone number verification may be used to perform a risk analysis  314  to assess the risk associated with the customer identification  312  (i.e. is the customer actually the person purported). As noted above, for transactions conducted in person, such as in the retail store  102 , identity may simply be verified by checking a photo ID. The process illustrated in  FIGS. 6 and 7  provides an online process for identification. Some implementations allow the customer to select remote processes for identification verification other than the phone number check. Other identifying information could be provided by the customer  100  to the retail computer  108  (and/or additional systems  110 ) via input screens on the customer computer  104 . The customer  100  may provide, for example, images of photo IDs, personal information, references, etc. via the customer computer  104  that are compared against reference information obtained or stored in the retail computer  108  or in the systems  110  for the identity verification  312  and risk assessment  314 . 
     Various decisions may result from the identity verification  312  and risk analysis  314 .  FIG. 6  illustrates three examples, including approval  370 , where the customer  100  is provided an approved monetary amount. An example of an approval user interface screen  382  is shown in  FIG. 8 . The approved amount may be used for RTO transactions including products in the customer&#39;s cart, or may be used for future product selections made via the customer computer  104  and/or in the retail store  102 . A customer  100  may alternatively receive a denial  372  from the risk analysis at which point, they are provided the appropriate information.  FIG. 9  illustrates an example of a user interface screen  384  providing denial information. Still further, a customer  100  may receive a conditional approval  374 , which requires additional steps of validation. Such additional steps may be accomplished by the customer  100  contacting or visiting the associated retail store  102 .  FIG. 10  illustrates an example of a conditional approval interface screen  386 , notifying the customer  100  that additional verification is required, and that the selected item can be reserved. 
     In some examples, the identity verification process  360  uses a mixture of proprietary data stored, for example, in the data store  112  and executed by the processes  120  together with multiple additional data feeds provided from the additional systems  110  for risk analysis assessment process  314 . Because of the improved identification verification  312  and risk analysis  314 , the consumer may be provided with a weekly rate for rental payments, for example. This improves both the consumer&#39;s ability to determine a weekly financial impact, as well as from the retail store perspective as the weekly rate is often a primary method utilized within the store  102 . Operationalizing that through the online experience, simplifies and provides consistency and reduces the risk of RTO transactions. 
     Moreover, the risk assessment process  314  is used in some embodiments to determine what product inventory is displayed on the customer computer  104  in the product display process  342  of  FIG. 5 . For instance, special order products or products supplied by partner stores (i.e. not necessarily related to the retail store  102 ) are only displayed for customers meeting a certain risk level as determined in the risk analysis process  314 . 
       FIG. 11  illustrates aspects of a checkout process  390  including further steps associated with the RTO agreement creation  316  and execution (i.e. signing) process  318  discussed above. Following an initial payment at block  392 , a digital RTO agreement is generated by the retail computer  108  displayed on the local customer computer  104 , which is followed by a signing event from the consumer. Data is collected, aggregated and appropriate terms are displayed to the consumer computer  104 . The customer  100  may then indicate approval, triggering a signing action  394 . Subsequently, the RTO agreement is executed at block  318 . In some embodiments, the initial payment may occur post agreement signing. 
       FIG. 12  depicts an example of a user interface screen  396  including RTO agreement data that may be displayed for the customer  100  on the customer computer  104 . The example of  FIG. 12  displays information such as rental details, purchase option information, benefits options, etc. It is noted that in certain disclosed embodiments, a consumer  100  is provided multiple different payment frequencies to choose from. In the user interface  396  shown in  FIG. 12 , a monthly payment frequency is employed. However, the improved processes disclosed herein facilitate the use of other payment frequencies such as weekly, bi-weekly, bi-monthly, etc. This provides a benefit to the consumer  100 , allowing the customer  100  to choose which frequency best fits him or her, in turn resulting in more consistent payments to the store  102 . This can reduce the overall financial impact to the store. 
     After review of the RTO agreement information, the RTO agreement itself may be displayed on the customer computer  104 , and the customer  100  may trigger the signing action  394  by clicking the “start” button shown in the interface screen  398  shown in  FIG. 13 . In response to the signing action trigger  394 , an electronic signature may be obtained as indicated in block  318  using the example interface screen  400  shown in  FIG. 14 . Completion of execution of the RTO agreement may be indicated by clicking the “finish” button shown in  FIG. 14 . 
       FIG. 15  illustrates example aspects of a process  410  for delivery of products associated with the RTO agreement. The consumer  100  is provided options of pick up or scheduling a delivery in block  412 . Upon choosing pickup, the store information is displayed at block  414  so the customer  100  can confirm the store address for pickup location, followed by the scheduling a date and time for pickup at block  416 . Once the consumer has confirmed, a confirmation page  418  may be displayed on the customer computer  104 . 
     If the customer  100  chooses delivery of the product in block  412 , then the delivery address may be verified in block  420  followed by scheduling the desired date and time for delivery in block  422 . After the selection is complete, the confirmation page  418  is displayed on the user computer  104 . It is noted that, as discussed in conjunction with the geographic location process  330  of  FIG. 4 , the initial location determination process may include automated location procedures (e.g. GPS, IP address location, triangulation, etc.) or by manual entry by the customer  100 . In some embodiments, while the initial geographic location determination  332  may be made by an automated process, the actual products to be delivered using the delivery process  410  are based on the verified delivery address  420  or the store address  414 . 
     In some embodiments, the risk assessment process  314  shown in  FIG. 6  is additionally used to determine aspects of product delivery and shipping to a customer  100 . For instance, a delivery choice in block  412  could only be allowed for customers  100  meeting some predetermined risk level as determined in the risk assessment process  314 . For a customer  100  who does not satisfy the predetermined risk level, only store pickup is allowed at block  412 . 
     For special order products or products supplied by partner stores (i.e. not necessarily related to the retail store  102 ), such products are only displayed for customers meeting a certain risk level as determined in the risk analysis process  314 . 
       FIG. 16  is a flow diagram illustrating an example process  500  illustrating various paths the customer  100  may take in the RTO transaction process  500 . The consumer  100  can start an online order as indicted at block  502 , which can progress to web lead (i.e. signal for the retail store  102  to follow up), a product reservation, a denial, or an RTO transaction completed entirely online. Following the order start  502 , customer may take an upper path  510  of initially selecting a product via the customer computer  104 , or a lower path  512  of first getting an RTO decision. 
     Referring to the upper path  510 , a product  520  is selected. Selection of the product  520  may be in accordance with the processes illustrated in  FIGS. 4 and 5  discussed above. Upon selection of one or more products  520  (i.e. products are placed in the virtual cart), information is provided for the approval process to arrive at a decision  522 . The approval process may proceed along the lines discussed in conjunction with  FIGS. 5 and 6 . Upon an approval  524 , which may correspond to the approval  370  shown in  FIG. 6 , the customer  100  may choose to proceed further to the checkout process  526 , allowing for a payment mechanism and RTO agreement creation. As also discussed in conjunction with  FIG. 6 , the approval process resulting from the identity verification  312  and risk analysis  314  may further include a denial  372  and a conditional approval  374 . 
       FIG. 16  illustrates an example of a conditional approval  526 , in which the customer  100  is notified to finish the RTO transaction at the retail store  102 . The conditional approval  526  results in an additional path  510   a  branching off the upper path  510 .  FIG. 16  further illustrates a denial  528 , forming a further path  510   b  branching off the upper path  510 . 
     Continuing with the top path  510 , the customer  100  may choose to proceed further to the online checkout process  530 , allowing for a payment mechanism and RTO agreement creation as discussed in accordance with  FIGS. 11-14 . If the customer  100  chooses to continue with the online checkout process  530 , the top path  510  continues by determining whether any promotions  532  exist that are associated with the order  502 . If a promotion  532  is available, it may be applied to the initial payment  534 . If no promotions are applicable, information regarding the first payment  534  is displayed for the customer  100  and the payment is collected as discussed above in conjunction with  FIG. 11 . The RTO agreement  536  is then created and executed, resulting in the completed RTO agreement  538 . Thus, as shown in the top path  500  of  FIG. 16 , the RTO agreement  536  may be completed entirely online with the customer  100  located remotely from the retail location  102  if desired. 
     Referring back to the checkout process  530  of the top path  510 , the customer may choose not to complete the online process  530 , resulting in another path  510   c  branching off the top path  510 . The path  510   c  allows the customer  102  to reserve the selected product(s) and complete the transaction in the retail store  102 . If there is no reservation, the path  510   c  ends. If a reservation has been made, since the customer has already been approved  524  for an RTO transaction the checkout process continues in the retail store  102 , including determining whether a promotion  532  is available, and receiving the initial payment  534  with or without a promotion  532 . The RTO agreement may then be completed in the retail store  102 . 
     Similarly, the path  510   a  requires completing the transaction in the retail store  102 . Assuming the conditional approval  526  is satisfied upon the customer  100  visiting the retail store  102 , the process may continue in the store  102 . If the selected product  520  was reserved during the online shopping process, the checkout process may continue with determining whether a promotion  532  is available, and receiving the initial payment  534  with or without a promotion  532 . The RTO agreement may then be completed in the retail store  102 . 
     Referring back to the product selection  520  and subsequent decision process  522  of the upper path  510 , the customer may alternatively decide not to complete the decision process  522 . For example, rather than provide the information for the identity verification  314  and risk analysis  314  of  FIG. 6 , the customer  100  skip the decision process  522  and continue on yet another path  510   d  branching off the upper path  510 . The path  510  is also completed in the retail store  102  and proceeds similarly to the path  510   a.    
       FIG. 16  also illustrates a lower path  512  where the customer  102  chooses not to select a product through the online shopping process discussed in conjunction with  FIGS. 4 and 5 . In the event of such a “no product” start  540 , the customer may still complete the online decision process  522 . As noted above, information is provided for the approval process to arrive at a decision  522 . The decision process  522  may proceed along the lines discussed in conjunction with  FIGS. 5 and 6 . Upon an approval  524 , which may correspond to the approval  370  shown in  FIG. 6 , the customer  100  would not proceed to the checkout process  526 , since no product(s) have yet been selected. However, the path  512  may include determining whether a promotion  532  would apply to the transaction. Thus, as shown in the lower path  512 , the decision process  522  may be completed entirely online. The customer  100  may then shop online using the RTO app or web page on the customer computer  104 , or select products in the retail store  102 . In some examples, details regarding the approval  524  such as approved total rental amounts, payment amounts, etc. may be displayed on the customer computer  104  for the customer  100  for use in selecting appropriate products. 
     As also noted above, the decision process  522  of the lower path  512  may also include a denial  372  or a conditional approval  374  as shown in  FIG. 6 . In  FIG. 16 , the conditional approval  526  for the lower path  512  results in an additional path  512   a  branching off the main lower path  512 . As with the upper path  510 , the path  512   a  corresponding to the conditional approval results in the customer  100  being notified to finish the decision process at the retail store  102 . The conditional approval  526  results in an additional path  510   a  branching off the upper path  510 . The denial  528  forms a further path  512   b  branching off the lower path  512 . Still further, the customer may alternatively decide not to complete the decision process  522  of the lower path  512 , resulting in another path  512   c  branching off the lower path  512 . Since the path  512   c  does not include either a product selection  520  or the decision process  522 , the transaction process is effectively suspended, though any applicable promotions may be identified. 
     Thus, as shown in  FIG. 16 , disclosed processes allow the customer  100  to seamlessly transition between online and store shopping experiences with appropriate preapprovals (resulting from the decision process  522 ). Such preapprovals, for example, may streamline the RTO shopping experience for the customer  100 . In some embodiments, at the start of the order  502 , the customer  100  may log into a predetermined customer account. If the customer previously completed the decision process  522  as discussed above, such information may immediately be displayed for the customer on the customer computer  104 . This log in process may also be used for RTO shopping in the retail store  102 , using the point of sale system  122  and/or the in-store terminal  114 . Upon product selection, the customer may complete the checkout process as shown in  FIGS. 11-14 , as well the product delivery process  410  of  FIG. 15 . 
     It is further noted that upon completion of the RTO agreement  538 , subsequent rental payments may be made by the customer via the user computer  104 . This may provide more consistent and regular payments from the customer  100 , whether the RTO transaction was conducted online, in the retail store  102 , or through a combination thereof. 
     Still further, the identification verification process  360  and checkout process  390  using the customer computer  104  (especially the mobile device  104   b ) or the terminal  114  may be used in conjunction with an RTO process completed in the retail store  102 . This standardizes the identification verification process  360  and checkout process  390 , providing consistency between online and in-store RTO transactions. 
     The foregoing outlines features of several embodiments so that those ordinary skilled in the art may better understand the aspects of the present disclosure. Those skilled in the art should appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the embodiments introduced herein. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that they may make various changes, substitutions, and alterations herein without departing from the spirit and scope of the present disclosure.