US20140089139A1

US20140089139A1 - System and method for provisioning assets for online transactions

Info

Publication number: US20140089139A1
Application number: US13/705,091
Authority: US
Inventors: James Shotwell; Sean Aguinaga; Eric Johnson; Sarina Kinder; Patrick Russell; Michael Swoboda
Original assignee: Auction com LLC
Current assignee: Auction com LLC
Priority date: 2012-09-26
Filing date: 2012-12-04
Publication date: 2014-03-27
Also published as: US9697565B2; WO2014052684A3; US20170249682A1; WO2014052684A2; US20140089126A1

Abstract

Information pertaining to the real property asset is received from a seller of the real property asset. From the information, a set of parameters are determined about the real property asset. The set of parameters are then used to select a set of agreements that are to control completion of the real property asset being sold using the online medium. The real property asset is then made available for sale using the selected set of contracts.

Description

PRIORITY INFORMATION

This application claims benefit of priority to Provisional U.S. Patent Application No. 61/706,097, filed Sep. 26, 2012; the aforementioned priority application being hereby incorporated by reference in its entirety.

TECHNICAL FIELD

Embodiments described herein relate generally to a system and method for provisioning assets for online transactions.

BACKGROUND

Numerous online auction forums exist that enable consumers and sellers to transact for various kinds of items, such as collectibles, electronics and other goods or services.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an example system for provisioning assets in an online market environment.

FIG. 2 is illustrates an example computer-implemented method for validating and making an asset available for online transaction.

FIG. 3 illustrates an example computer-implemented method for providing a contract for controlling disposition of an asset.

FIG. 4 is a block diagram that illustrates a computer system upon which embodiments described herein may be implemented.

DETAILED DESCRIPTION

Embodiments described herein relate generally to a system and method for provisioning assets for online transactions.
Some embodiments described herein include a system and a method in which a real property asset is provisioned for sale in an online medium. Among other benefits, embodiments recognize that transactions for real property assets have requirements and complexities that are not present with other types of assets. For example, transactions for real property require determination of information that can affect or preclude the transfer of legal title. Additionally, transactions for real property generally require written contractual agreements. Under conventional approaches, sellers, for example, employ realtors and other professionals (e.g., title company) to provide services, such as generating legal instruments needed for completing a transaction for a real property asset.
Embodiments recognize that in an online medium, the role of professional intermediaries and services (e.g., realtors) can be lessened or eliminated. For example, the party to the transaction (e.g., home owner) can utilize the online medium to showcase their home without many of the intermediary costs of offline sales.
Among other benefits, examples described herein include a service that performs different processes for provisioning an asset for online transaction. The provisioning processes include programmatically selecting, generating or assembling contractual agreements for the seller or buyer based on information determined about the real property asset. Still further, the provisioning processes can also include performing a preliminary validation of basic information needed for transacting the real property asset (e.g., identification of the real property asset or seller). Among other benefits, provisioning processes as with various examples described herein can make the online transaction more transparent and credible to prospective buyers, while further reducing the need for professional middlemen and services.
In an embodiment, information pertaining to the real property asset is received from a seller. From the information, a set of parameters are determined about the real property asset. The set of parameters are then used to select a set of agreements that are to control completion of the real property asset being sold. The real property asset is then made available for sale using the selected set of contracts.
In still another embodiment, information pertaining to the real property asset is received from the seller. The information about the real property asset is made available for search or viewing to a population of buyers during a pre-auction period. As an alternative or addition, one or more steps to validate a real property asset and its seller can also be performed. The real property asset can then be made available for sale during an auction period that is initiated after the pre-auction period is over.
As used herein, an “agreement” is intended to mean a contractual agreement (e.g., meeting of the minds). The term “contract” is intended to mean a memorialized (e.g., documented) legally binding agreement that binds at least one party to a transaction. Additionally, a “seller” is a person or entity who can control sale of an asset. Examples of a seller include an owner or a trustee. A “real property asset” can include (i) a property interest (e.g., fee simple, time share) for land, dwellings and other real-estate, and (ii) a legal or financial instrument that is directed a real property and which can be transacted (e.g., mortgage-based securities).
Some embodiments described herein relate to the auctioning of real property assets. In particular, embodiments recognize that transactions for real property assets pose several challenges. Among the challenges, embodiments recognize that transactions for real property assets have numerous statutory requirements before the real property assets can be transacted. For example, unlike consumer electronics or goods, a seller must generally do more than upload images and description for selling a real property asset. For example, transactions for real property assets often require verification of information such as (i) the underlying property that is to be sold, (ii) the owner of the property in question, (iii) the available funds or financing of the buyer, as well as numerous other kinds of information. Furthermore, numerous types of transactions exist for purchasing real property assets, such as trustee auctions, foreclosure sales (e.g., seller is financial institution), short sales (seller is owner, subject to financial institution approval), escrow sales, or consumer to consumer transactions. Each type of transaction may require its own set of considerations or limitations when provided for in an online environment.
One or more embodiments described herein provide that methods, techniques and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically means through the use of code, or computer-executable instructions. A programmatically performed step may or may not be automatic.
One or more embodiments described herein may be implemented using programmatic modules or components. A programmatic module or component may include a program, a subroutine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines.
Furthermore, one or more embodiments described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing embodiments of the invention can be carried and/or executed. In particular, the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash or solid state memory (such as carried on many cell phones and consumer electronic devices) and magnetic memory. Computers, terminals, network enabled devices (e.g., mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, embodiments may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.
System Overview
FIG. 1 illustrates an example system for provisioning assets in an online market environment. A system 100 such as described by an example of FIG. 1 can be implemented in a variety of computing environments. For example, system 100 can be implemented as part of an online market environment, such as an online auction. Still further, the system 100 can be implemented as a network service that augments or facilitates an online market place. Accordingly, system 100 can be implemented as a network service, through a combination of servers or other network enabled computing devices. In variations, system 100 can be implemented on other computing platforms, including stand-alone systems. Thus, for example, system 100 can operate on a product or service that is maintained on a single computing device or storage device.
While online market places are commonly used to transact various kinds of assets, examples described herein recognize that some kinds of assets, such as real property assets, require or otherwise benefit from provisioning steps. For example, real property transactions typically require contracts at the time the transaction is made legally binding. Under conventional approaches, a seller can make a real property available for sale, and then research and provide the additional documentation, either when or after the buyer commits to purchasing the real property. However, the commitment made by the buyer is often subject to the service agreement of the online medium (e.g., auction provider), until the time the buyer executes an additional contract. More particularly, the agreement made between buyer and seller at the time the online sale is made is often not the actual agreement the parties will utilize to complete the transaction. For example, the buyer's commitment to purchase real-property online may subject the buyer to the terms of service of the online provider, and potentially to a cause of damages to the seller. But the remedies available to the seller may be hindered with the absence of a contract that would, for example, satisfy legal requirements (e.g., statute of frauds, state provisions) and offer remedies such as establishment of escrow or forfeiture of deposit. If the seller does provide an additional agreement, then under conventional approaches, the seller needs to research and provide the agreement for the seller's particular property.
Also, assets such as real-property are relatively expensive and can have issues as to legal title. In an online medium, the buyer and seller may never meet, or even be represented by an agent. As a result, problems such as the possibility of error or fraud can be greater as a result.
With reference to FIG. 1, the system 100 provides components that include a seller interface 110, a draft asset catalog 120, a validation sub-system 130, and a contract engine 140. The system 100 can also include components such as a live asset catalog 150, and a marketing sub-system 160.
In more detail, the seller interface 110 can enable a seller of an asset (e.g., real property) to specify information for the sale of a respective property. The information 111 specified by the seller can include (i) the address and/or parcel number of the real-property, (ii) the full legal name of the seller, as well as the name of the owner of the property. This information 111 can identify the type of the transaction, as well as the nature of the seller providing the property. For example, the seller can be the home owner, and the real property may be offered for sale in an “as-is” transaction. Alternatively, the seller can be an owner, but the type of transaction may be a short-sale (subject to approval by a lender). Still further, the seller can correspond to a trustee (in case of foreclosure) or lender, and the type of sale can correspond to a foreclosure or trustee sale. The information 111 can also include a property description that can be provided to identify, for example, the property type (e.g., single-family residence, condominium, commercial), obligations encumbered with the property (e.g., Homeowner association), basic property information (e.g., number of bedrooms or bathrooms, square footage of house, square footage of parcel, etc.) disclosures (e.g., termites, water damage, etc.), pictures, and other information.
In an embodiment, the information 111 can be received and held in the draft asset catalog 120, pending validation. The validation sub-system 130 can include interfaces or programmatic components that enable the information 111 to be accessed and validated. In one implementation, the validation sub-system 130 includes a seller verification 132, an asset verification 134, an operator interface 136 and a format engine 138. The seller verification 132 can operate to verify the identity of the seller. For example, the full legal name of the seller can be verified, as well as whether the seller is the legal owner of the real-property. The seller verification 132 can utilize one or more external or third-party sources 131 to verify (i) the identity or legal name of the seller, and/or (ii) that the seller has authority to sell the real property. The third-party sources 131 that can be used can include county records or listings, credit agencies etc. The asset verification 134 can operate to identify information provided about the real property. For example, the asset verification 134 can verify that the address or parcel number provided from the seller exists. The asset verification 134 can also operate to verify other information provided from the seller is correct, such as the square footage of the home or lot, the number of bedrooms or bathrooms etc. The asset verification 134 can also utilize third-party sources, such as prior property listings or country records. As an addition or alternative, the asset verification 134 can operate to determine or validate the valuation of the real property asset. For example, the asset verification 134 can include a process that determines comparables for the real property asset, then uses the comparables to estimate a value for the real property asset.
The seller verification 132 and/or asset verification 134 can include processes which programmatically (i) retrieve information from the draft asset catalog 120, and/or (ii) cross-reference such information with the third-party sources 133. The seller verification 132 and/or asset verification 134 can also include triggers for requesting human intervention when, for example, asset or seller verification is inadequate. For example, in some rural counties, no online sources may exist to identify the seller of a lot. In some implementations, the operator interface 136 operates to enable human operators (e.g., realtors, operators of system 100 etc.) to perform validation steps. In some implementations, if seller or asset verification is not possible even through use of manual sources, then the validation sub-system 130 can implement a marker or disclaimer for association with the information 111 of the particular asset. The marker or disclaimer can serve as notification that the seller and/or asset was not validated (or not validated completely) through the system 100.
In addition, the format engine 138 can operate to normalize the transaction information 113 that is to be generated from the information 111 of the seller. Among other functions, normalization can include reformatting the asset information 111 as provided by the seller. For example, the address of a real property can be modified to reflect a particular convention. Additionally, the normalization can include augmenting or replacing asset information 111 with alternative information, such as information derived from alternative sources (e.g., public records). For example, the format engine 138 can operate to correctly list the address, parcel number and other information in order to ensure the property of the seller conforms to conventions and legal standards. An output of the format engine 138 can include correction 117 or other parameters 119 for augmenting information provided from the seller (e.g., add parcel number to address provided from seller).
In some embodiments, the transaction information of the draft asset catalog 120 is published online in draft form in order to communicate with buyers the availability of the property in the near future. A publishing component 162 can provide an interface for which prospective buyers or interested parties can search and navigate to see information from the draft asset catalog 120 in advance of the asset being made available for sale. Thus, the asset (e.g., real property) can be made searchable or available for viewing in advance of the asset being made available for purchase via the marketing subsystem 160.
In an example, a live asset catalog 150 includes records 152 that identify assets available for transactions for the marketing subsystem 160. The live asset catalog 150 can be provided as either a separate or integrated data store in connection with the draft asset catalog 120. After individual assets identified by asset information 111 are validated, or otherwise subjected to validation processes or steps, transaction records 152 can be created which correspond to that particular asset that is being made available for sale. The transaction record can include, for example, a sale price, the bid price, a hidden reserve price (e.g., in the case of an auction), as well as transaction information 113 and/or other information provided as part of asset information 111. In one implementation, a transaction handler 155 monitors or otherwise detects when transaction information 113 can be made available as a record with the live asset catalog 150 (e.g., when the asset is available for bidding). For example, the transaction handler 155 can convert transaction information 113 (as well as other information provided with a particular asset) into a corresponding transaction record 152 after a designated duration of time, or after the transaction information 113 indicates that the validation process for the particular asset is complete (or as complete as possible).
As an addition or alternative, the transaction information 113 can be augmented with one or more sales contracts that control disposition of the asset in a sale. In one implementation, the contract engine 140 can correspond with programmatic component that implements logic and/or rules to select contracts 141 or agreements for individual assets from the contract catalog 144. As an alternative or variation, the contract engine 140 can correspond to a programmatic component that implements logic and/or rules to select terms or conditions of agreements, such as portions of contracts, and then assembles such agreements or portions into one or more contracts. As examples, the contract engine 140 may operate to select passages or paragraphs, sentences, terms, field values or other agreements, and then assembles the various portions into one or more contracts.
In operation, the contract engine 140 determines parameters from asset information 111 (provided by the seller) or transaction information 113 (normalize and are validated information) in order to identify one or more contract parameters 143. The contract engine 140 can also prompt the user into entering information that corresponds to the contract parameters 143. The contract parameters 143 can include various kinds of parameters from which contract engine 140 can select contacts 141 from the contract catalog 144. At least some of the parameters 143 can be determined from asset information 111 and/or transaction information 113.
In the case of real property, the contract parameters 143 can include several criteria or conditions that require the presence of certain contractual terms, conditions or agreements. Examples of such required parameters 143 include geographic region of the asset(e.g., state and county were real property is located), property type (e.g., single-family dwelling, condominium, commercial real estate etc.), presence of encumbrances such as homeowner association, information about the seller (e.g., whether the seller is the owner or an institution), information about the type of transaction (e.g., short sale, trustee sale, foreclosure sale, luxury sale etc.) and or other criteria which can generate specific contractual requirements (e.g., wetland provisions for real property). In one implementation, the seller interface can prompt the seller to provide the information needed to determine the contract parameters 143. As an addition or alternative, the contract engine 140 can include or otherwise utilize processes that scan the asset information 111 for the contract parameters 143. The contract parameters 143 can also include contractual terms, conditions or agreements selected as preferences or conditions by the seller or other party to the transaction. For example, the seller can elect an “As-Is” sales contract, or mandate certain provisions such as the length of escrow. The seller's specification of such parameters can be optional, while the designation of such parameters can be determinative of the particular contract or agreement used for a given asset.
Thus, for example, some of the contract parameters 143 can be determined from user input which may specify a choice or selection of the user of a particular type of contract provision. By way of example, the contract parameters that can be determined for a given real property include all of the following determinations: (i) seller state and county, (ii) the property type, (iii) whether the sale is subject to other conditions (e.g., approval of lender), (iv) whether sale is cash sale, (v) whether the seller is a financial institution or lender, (vi) whether the real property is subject to a home owners association, (vii) whether the real property is located in lands that is classified by particular laws (e.g., Federal designation of wetlands), and/or (viii) whether real property is owner occupied.
In an embodiment, the contract engine 140 includes logic to select contracts, or portions of contracts (such as contractual provisions, appendixes, etc.) based on the various parameters 143 that are determined from the seller (or asset information 111) or about the asset. The contract engine 140 can also include logic that designates a priority of select parameters over other parameters in selecting a set of contracts (or contract provisions) for a particular transaction. For example, many contractual terms required for the various parameters 143 are subjected to state or country specific regulations or laws. To further the example, in one implementation, the contract parameters 143 relating to state and country can be the first determinative factor in the contract selection. Subsequent determinations of contracts or contractual provisions can be based on a contract library subset that is specific to the region or state of the real property.
As mentioned, the contract engine 140 can assembly a set or collection of contracts 141 (or agreements) that control the sale of the asset. The set of contracts 141 can refer to a single document that includes selected sections with terms and obligations selected by the contract engine 140, and/or separate documents selected based on specific parameters. The contracts 141 can satisfy various legal requirements (including state, county and federal) so that execution of the documents would enable all parties involved in the transaction to receive the full protection and remedies available under the applicable laws. The contracts can be made viewable with the asset listing so that a buyer and seller are fully aware of the controlling contracts and conditions before completing a sale.
In one implementation, once selected, the contracts 141 can be linked or associated with the transaction record 152 for the individual asset. For example, documents corresponding to selected transactions can be linked with the transaction record for viewing by prospective buyers. The live asset catalog 150 can store the information for the individual transaction records 152, as well as for the linked contracts 141 of the particular transaction record.
In a variation, the selected contracts 141 are provided to the seller for modification and/or approval. Thus, the seller can have final approval of the contracts 141 that are included with the sale of the real property. The seller may also be able to override the contract selection from the contract engine 140.
The marketing sub-system 160 can include components for enabling one or more types of market places for the transaction records 152 of the live asset catalog 150. For example, the marketing sub-system 160 can implement an online auction that offers assets of the live asset catalog 150. When an asset is live, a clock may be initiated that controls, for example, the timing of a bidding process. In one implementation, the marketing sub-system 160 includes the publishing component 162 and a transaction component 164. The publishing component 162 can enable individuals to search and discover assets from the live asset catalog. The transaction component 164 can implement the logic for the enabling the transaction to receive bids etc. For example, the transaction component 164 can implement auction rules that include reserve bids and timing logic for when the auction is extended. These and various other features can be implemented to promote the sale of the assets identified by the transaction records 152 of the live asset catalog 150.
The marketing sub-system 160 can include logic for implementing different marketing environments. In one embodiment, the marketing sub-system 160 implements an auction environment. Bidders can view the assets (e.g., real property) using the publishing component 162. The transaction component 164 can be used to receive bids, and to track bidding processes (e.g., including use of timers etc.) in running an auction to its completion.
Methodology
FIG. 2 is illustrates an example computer-implemented method for validating and making an asset available for online transaction. FIG. 3 illustrates an example computer-implemented method for providing a contract for controlling disposition of an asset. In describing examples of FIG. 2 and FIG. 3, reference may be made to elements of FIG. 1 for purpose of illustrating suitable elements or components for performing a step or sub-step being described.
With reference to an example of FIG. 2, an asset can be identified for transaction (210). The asset can be identified by seller. For certain types of assets, such as real property, the seller can alternatively correspond to a trustee. For example, a trustee can represent a person who is appointed to handle a trustee sale. The trustee sale refers to a process where a real property is converted from an owned property into a foreclosed property.
The seller can provide information about the asset. A validation process can be performed based on the asset information. In some embodiments, the validation process that it is performed can differ depending on the type of seller. For example, different validation processes can be performed for real property when the sellers a trustee, as opposed to an owner.
In one embodiment, the validation process includes verification of the owner or seller. This can include determining that the seller has control or rights to make an asset available for sale. If the seller is an owner, validation can include determining a seller has legal right to sell the asset. In the case of real property, a county recording office can be checked (e.g., programmatically) to ascertain the name of the holder to legal title for the real property. If the seller is a trustee, trustee verification can include confirmation of the foreclosure or an event that caused the trustee to take control of the disposition of the real property. The owner verification can be performed programmatically, by checking, for example, online public records (e.g., county record offices) using programmatic agents or bots.
As an addition or alternative, the asset can also be verified as part of the asset validation process. The asset verification can include ensuring that identification of the asset is properly done, including properly formatted with correct information. In the case of real property, the parcel number and address of the property can be checked against public sources to ensure that the asset exists and is correctly identified. With reference to FIG. 1, for example, the asset information 111 as provided by the seller can be programmatically parsed or structured (e.g., using an input field or template) so that asset information is programmatically identifiable. This information can then be cross-referenced to publicly available information to ensure the asset is correctly identified. In the case of real property, the parcel number and/or address can be identified. For other types of assets, the serial number, model number and/or manufacturer number etc. can be verified using available catalogs.
Other validation operations or processes can also be performed for the asset. For certain types of property, for example, public sources can be check for liens, or recorded interest. For example, programmatic agents or bots can be used to access public sources for security filings and liens against identified assets.
Additionally, the asset information 111 provided by the seller can be normalized (230). Normalization of the asset information 111 can include formatting, augmenting and editing information provided by the user so that it conforms in structure and format to predetermined convention. For example, address information can be reformatted for particular convention. The name of the seller can also be formatted so that it follows a predetermined convention. The use of predetermined conventions can enable the asset to be validated, as well as to be searched and discovered.
In some embodiments, an asset can be made available for publication in a time period that precedes when the asset is made available for sale (240). In particular, the asset can be made available for a duration of time that is predetermined and or set by certain rules, so as to have a beginning period and ending period. For example the asset can be subjected to an auction that has a set duration of time, or which is extendable based on certain rules and logic decisions that are predetermined. Prior to the duration when the asset is made available for sale, the asset can be published and made available for discovery for potential buyers or bidders. For example, during the validation stage (e.g., see step 220), the asset can be made available for publication and viewing. Thus, even though the asset may be subjected to a validation process that can take several hours or days, the asset can still be viewed and researched by prospective buyers in advance of the time when the asset is actually transacted.
Subsequently, after, for example, the validation process is complete and/or the asset is published, the asset is made live, or subject to transaction (250). For example, the asset can be made available for an auction or other form of transaction.
With reference to FIG. 3, when information about an asset is received from a seller, a set of contract parameters can be determined for the underlying asset (310). In one implementation, the seller interface provides a guide or template for which the user can submit information. The guide or template structures the asset information 111, so that fields in the template can correlate to contract parameters. In the context of real property, examples of contract parameters can include the state and county where the real property is located, the type of seller, the type of real property, as well as one or more conditions that require satisfaction. As examples, condition can include (i) whether the real property includes an occupant, (ii) whether the real property is subjected to a homeowners association, and/or (iii) whether the real property subject to additional conditions, such as the approval of a lender. Additionally, the contract parameters can, either programmatically or through input from the user, determine whether Federal provisions, such as wetlands provisions, is applicable for the particular real property.
In variations, some or all of the contract parameters are programmatically determined by parsing the asset information 111. For example, the user may provide structured, or alternatively, relatively unstructured data that includes various kinds of information regarding an asset. Programmatic components of, for example, the seller interface 110 and/or the contract engine 140 can be used to programmatically identify information that correlates to individual contract parameters 143. Additional input verification from the seller may be warranted to ensure that parameters are correct.
In some embodiments, select contract parameters 143 can also be determined that are optional, or set to a particular preference or choice (320). For example, the default settings of contract engine 140 can specify certain contracts absent user input or overriding interest. Additionally, the seller can specify a preference for a type of contract (e.g., “AS-IS”), or contractual term (324). For example, the seller can specify the state or county that is to settle a dispute should one arise as an alternative to a default jurisdiction (e.g., jurisdiction where property resides), or whether arbitration or mediation is provided. The optional parameters can take precedence over an existing contract or contractual term, or alternatively augment an existing contract or contractual term as an additional agreement. Thus, for example, past practice as determined by the administrator of system 100 can be used as default settings from which contracts are selected or assembled via contract engine 140. As an addition or variation, the seller or owner's preference as to contracts or contractual terms can be used as a basis for selecting contracts or contractual terms. These additional parameters can be used to influence the selection of contracts or contractual language, as well as to make additional contractual selections from the contract library 144.
The various contractual parameters are determined for a particular asset can then be used to select a contract, a set of contracts, or to assemble one or more contracts using selective contractual sections or passages (330). The contract parameters can include those that are required (e.g., would be needed to comply with state or federal laws) as well as those that are optional (e.g., based on best practice or default settings of the administrator of the system 100, or preference of the seller/owner).
Once determined, the selected contract, set of contracts or assembled contracts can be linked with a record that identifies the asset and its information (e.g., normalized information) (340). In this way, when the transaction for the asset is completed, the parties to the transaction can understand the contract that is to control final disposition of the asset.
Computer System
FIG. 4 is a block diagram that illustrates a computer system upon which embodiments described herein may be implemented. For example, in the context of FIG. 1, system 100 may be implemented using one or more servers such as described by FIG. 4.
In an embodiment, computer system 400 includes processor 405, memory 406 (including non-transitory memory), storage device 410, and communication interface 418. Computer system 400 includes at least one processor 405 for processing information. Computer system 400 also includes a main memory 406, such as a random access memory (RAM) or other dynamic storage device, for storing information and instructions to be executed by processor 405. Main memory 406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 405. Computer system 400 may also include a read only memory (ROM) or other static storage device for storing static information and instructions for processor 405. A storage device 410, such as a magnetic disk or optical disk, is provided for storing information and instructions. The communication interface 418 may enable the computer system 400 to communicate with one or more networks through use of the network link 420 (wireless or wireline).
Computer system 400 can include display 412, such as a cathode ray tube (CRT), a LCD monitor, and a television set, for displaying information to a user. An input device 415, including alphanumeric and other keys, is coupled to computer system 400 for communicating information and command selections to processor 405. Other examples of input device 415 include a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 405 and for controlling cursor movement on display 412. While only one input device 415 is depicted in FIG. 4, embodiments may include any number of input devices 415 coupled to computer system 400.
Embodiments described herein are related to the use of computer system 400 for implementing the techniques described herein. According to one embodiment, those techniques are performed by computer system 400 in response to processor 405 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another machine-readable medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 405 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement embodiments described herein. Thus, embodiments described are not limited to any specific combination of hardware circuitry and software.
Although illustrative embodiments have been described in detail herein with reference to the accompanying drawings, variations to specific embodiments and details are encompassed by this disclosure. It is intended that the scope of embodiments described herein be defined by claims and their equivalents. Furthermore, it is contemplated that a particular feature described, either individually or as part of an embodiment, can be combined with other individually described features, or parts of other embodiments. Thus, absence of describing combinations should not preclude the inventor(s) from claiming rights to such combinations.

Claims

What is claimed is:

1. A method for provisioning a real property asset for sale in an online medium, the method being implemented by one or more processors and comprising:

(a) receiving information pertaining to the real property asset from a seller of the real property asset;

(b) determining, from the information, a set of parameters about the real property asset, the set of parameters including one or more required parameters;

(c) using the set of parameters to select a set of agreements that are to control completion of the real property asset being sold using the online medium; and

(d) making the real property asset available for sale using the selected set of contracts.

2. The method of claim 1, wherein (b) determining a geographic region of the real property asset and a type of the real property asset, and wherein (c) includes determining at least one contract for use in completing a transaction for the real property asset based on the geographic region and the type of real property asset.

3. The method of claim 2, wherein determining at least one contract includes selecting a contract from a library of contract based at least in part on the set of parameters, including the geographic region and the type of the real property asset.

4. The method of claim 1, wherein (b) includes determining the set of parameters including a type of a seller for the real property asset.

5. The method of claim 1, wherein (b) includes determining the set of parameters including an occupancy characterization for the real property asset.

6. The method of claim 1, wherein the real property asset corresponds to a real-estate property, and wherein (b) includes determining the set of parameters including a type of the real property asset.

7. The method of claim 1, wherein the real property asset corresponds to a real-estate property, and wherein (b) includes determining a legal characterization of the real property asset that subjects the real property asset to federal or state laws.

8. The method of claim 1, wherein (d) includes making the real property asset available for sale on an online auction.

9. The method of claim 1, further comprising validating the real property asset and the seller.

10. The method of claim 9, wherein validating the real property asset includes verifying an address of the real property asset.

11. The method of claim 10, wherein validating the real property asset includes verifying that the seller has authority to sell the real property asset.

12. The method of claim 1, wherein (b) includes inferring at least one parameter based on the information received from the seller.

13. The method of claim 12, wherein inferring at least one parameter is based on a geographic location of the real property asset.

14. The method of claim 12, wherein inferring at least one parameter is based on an address of the real property asset.

15. A method for provisioning a real property asset for sale in an online medium, the method being implemented by one or more processors and comprising:

(b) enabling information about the real property asset to be searched and viewed by a population of buyers during a pre-auction period;

(c) performing one or more steps to validate the real property asset and that the seller has authority to sell the real property asset; and

(d) making of the real property asset available for sale during an auction period, the auction period being initiated after the pre-auction period is over.

16. The method of claim 15, wherein performing the one or more steps includes performing one or more steps to verify an address of the of the real property asset.

17. The method of claim 15, wherein performing the one or more steps includes performing one or more steps to verify an authority of the seller to sell the property asset.

18. The method of claim 15, further comprising programmatically formatting the information received from the seller so the information pertaining to the real property asset is recorded in accordance with a convention.