Real estate transactions often involve a buyer, a seller, one or more agents (e.g., a listing agent for the seller and buyer's agent for the buyer), and numerous service providers (e.g., escrow professionals, appraisers, home inspectors, lenders, and so forth. In a typical purchase transaction, the seller lists a property using a listing server, often through a listing agent, while buyers go through a search process to identify potential properties to buy. Once the buyer identifies a property the buyer wants to buy, the buyer makes an offer to the seller, potentially each through their respective agents. The seller may either accept the offer, counteroffer at a different price or other terms, or reject the offer. Once an offer or counteroffer has been accepted, the transaction is typically considered pending and on the way to closing pending inspections, resolving various contingencies, securing funds from a lender, and so forth.
Because of the many events and parties involved in a real estate transaction, it is often difficult for prospective buyers and sellers to organize times at which the prospective buyer may tour a seller's property. Buyers need to react quickly to new listings, price drops, and open houses. They also need to coordinate with their agent (and possibly with co-buyers) on events like inspections, contingency removal, loans, and so on. Sellers also need to coordinate with their agent on events like changes to their listing, buyer inspections, and so forth. Keeping track of all of these details or otherwise trying to efficiently schedule property viewings by a potential purchaser can be overwhelming, if not impossible.
Preferred and alternative embodiments of the present invention are described in detail below with reference to the following drawing figures.
This patent application is intended to describe one or more embodiments of the present invention. It is to be understood that the use of absolute terms, such as “must,” “will,” and the like, as well as specific quantities, is to be construed as being applicable to one or more of such embodiments, but not necessarily to all such embodiments. As such, embodiments of the invention may omit, or include a modification of, one or more features or functionalities described in the context of such absolute terms.
Embodiments of the invention are operational with numerous general-purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with embodiments of the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Embodiments of the invention may also be practiced in distributed-computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Depending on the exact configuration and type of computing device, memory 104 may be volatile (such as random-access memory (RAM)), nonvolatile (such as read-only memory (ROM), flash memory, etc.) or some combination of the two. This most basic configuration is illustrated in
Additionally, the device 100 may have additional features, aspects, and functionality. For example, the device 100 may include additional storage (removable and/or non-removable) which may take the form of, but is not limited to, magnetic or optical disks or tapes. Such additional storage is illustrated in
The device 100 may also include a communications connection 112 that allows the device to communicate with other devices. The communications connection 112 is an example of communication media. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, the communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio-frequency (RF), infrared and other wireless media. The term computer-readable media as used herein includes both storage media and communication media.
The device 100 may also have an input device 114 such as keyboard, mouse, pen, voice-input device, touch-input device, etc. Further, an output device 116 such as a display, speakers, printer, etc. may also be included. Additional input devices 114 and output devices 116 may be included depending on a desired functionality of the device 100.
According to one or more embodiments, the combination of software or computer-executable instructions with a computer-readable medium results in the creation of a machine or apparatus. Similarly, the execution of software or computer-executable instructions by a processing device results in the creation of a machine or apparatus, which may be distinguishable from the processing device, itself, according to an embodiment.
Correspondingly, it is to be understood that a computer-readable medium is transformed by storing software or computer-executable instructions thereon. Likewise, a processing device is transformed in the course of executing software or computer-executable instructions. Additionally, it is to be understood that a first set of data input to a processing device during, or otherwise in association with, the execution of software or computer-executable instructions by the processing device is transformed into a second set of data as a consequence of such execution. This second data set may subsequently be stored, displayed, or otherwise communicated. Such transformation, alluded to in each of the above examples, may be a consequence of, or otherwise involve, the physical alteration of portions of a computer-readable medium. Such transformation, alluded to in each of the above examples, may also be a consequence of, or otherwise involve, the physical alteration of, for example, the states of registers and/or counters associated with a processing device during execution of software or computer-executable instructions by the processing device.
As used herein, a process that is performed “automatically” may mean that the process is performed as a result of machine-executed instructions and does not, other than the establishment of user preferences, require manual effort.
Referring now to
The client device 210 and the server 230 may include all or fewer than all of the features associated with the device 100 illustrated in and discussed with reference to
The client device 210 is linked via the network 220 to server 230 so that computer programs, such as, for example, a browser, running on the client device 210 can cooperate in two-way communication with server 230. The server 230 may be coupled to database 240 to retrieve information therefrom and to store information thereto. Database 240 may have stored therein data (not shown), such as real-property listings, that can be used by the server 230 to enable performance of various aspects of embodiments of the invention. Additionally, the server 230 may be coupled to the computer system 260 in a manner allowing the server to delegate certain processing functions to the computer system. In an embodiment, the client device 210 may bypass network 220 and communicate directly with computer system 260.
Still referring to
At a block 310, the user is provided access, via an electronic network, to a memory device on which are stored listings of parcels of real property. For example, upon navigating to the website, the user may, in a conventional manner, ensure personal credentials to login to an account maintained by, for example, the administrators of the website. Subsequently, the user may sort through and view MLS listings stored in database 240. In a conventional manner, the user may select one or more of the MLS listings of homes, including listings stored in database 240 of homes that are not offered for sale at the time the user navigates to the website, that the user is interested in purchasing for inclusion in a “wish list” associated with the user's account.
At a block 320, a selection of a set of the stored listings is received from the user. For example, the user may submit to the server 230 a set of one or more listings from the wish list associated with parcels of real property that the user desires to visit in what may be referred to herein as a “tour” of such parcels. An embodiment may provide the user with the ability to indicate a “top-priority” parcel to be included in a tour and on which the development of an itinerary, discussed in greater detail below, may be based. Additionally, for each parcel selected by the user, an embodiment may provide suggestions of other parcels located within a predetermined distance and being similar in price and/or amenities. In an embodiment, if one of the parcels selected for the tour becomes subject to a pending sale, or otherwise becomes unavailable, before the user undertakes the tour, the user's wish list may be consulted and a “backup” parcel may be chosen therefrom and suggested to the user as a substitute parcel for the tour.
At a block 330, at least a portion of an itinerary is generated in response to receiving the selection. The itinerary may include an indication of at least one time at which the user will receive permitted physical access to at least one parcel of real property associated with the selected set of stored listings. For example, in response to receiving from the user the selection of parcels that the user desires to include in the tour, a tour itinerary is generated that includes a tour appointment time of finite duration (e.g., 3 PM to 6 PM), on a date selected by the user, during which the user will be admitted to the selected parcel(s). The starting time and duration of the appointment time, according to alternate embodiments, may or may not be initially suggested by the user. In the latter case, the start time and duration of the appointment time may be suggested to the user based on, for example, the quantity and location of the parcels included in the tour.
The itinerary may also include the identity of an agent who will accompany the user on the tour, and order in which the selected parcel(s) will be visited, and a schedule of time periods within the appointment time during which each parcel will be respectively visited and/or during which access to each parcel will be granted. In various embodiments, one or more of the determination, for purposes of generating the itinerary, of appointment time start and duration, the agent, the order of parcel visitation and the time period allotted for visitation of each parcel may be manually made by a representative of the website administrator using one or more of server 230 and computer system 260 and/or made automatically by one or more of the server and computer system.
Regardless of whether the choice of agent is determined manually or automatically, such determination may be based on an electronic record of agent availability, which may be stored in database 240. That is, each eligible agent may post to database 240 their own respective schedule of availability that may be manually or automatically consulted to determine which agents may be available to accompany the user on the tour during the appointment time chosen or requested by the user. Additionally, using a graphical user interface according to an embodiment, the agent may specify conditions under which the agent will make herself available to accompany a user on a tour. For example, the agent may specify that a certain price threshold for each parcel included in the tour must be met before the agent is willing to conduct the tour. The agent may specify that he is only willing to conduct a tour if the tour is the first one taken by a particular user, or if the tour is a second or subsequent tour taken by a particular user. Consequently, the tour itinerary would be generated, manually or automatically, based on these conditions.
Additionally, regardless of whether the appointment time and/or time periods are determined manually or automatically, such determinations may be based on one or more of the following exemplary factors, each of which may be embodied in a numerical score or other data type:
Market—for example, a particular metropolitan city within which the parcels requested to be included in the tour are located;
Service region—for example, a particular neighborhood or region of the market city within which the parcels requested to be included in the tour are located;
Number of homes included in the tour;
Number of single-family homes included in the tour;
Number of condominiums included in the tour;
Total square footage of all parcels included in the tour and/or square footage of one or more individual parcels included in the tour;
Number of tours the user has previously completed;
Number of homes on the tour that the user has previously toured;
Relative duration of the user's previous tours;
Price of one or more parcels included in the tour;
Characteristics, such as, for example, geographic location and sale close rate, of the agent leading the tour;
A calculation of travel time between or among the parcels included in the tour; and
Whether the tour occurs on a weekday or weekend and/or by day of the week on which the tour occurs.
In an embodiment, and based on a predetermined threshold distance between or among the parcels included in the tour, the itinerary may be generated to include two different appointment times, each perhaps on separate days, as a solution to logistical difficulties associated with traveling such distances.
At a block 340, the itinerary is provided to the user. For example, the server 230 and/or the computer system 260 provides the tour itinerary to the user. The tour itinerary may be provided to the user via one or more of a website, short message service (SMS) message, e-mail or other appropriate notification method requested by the user. If the itinerary requires time to develop, such as may be the case when the availability of one or more parcels requested for the tour must be confirmed, the user may, in real-time or otherwise, receive or be given access to updates on the state of the itinerary. An embodiment may allow listing agents to log in to the website and indicate for storage in database 240 specific time when does during which a particular parcel will be made available for touring. Subsequently, these stored time windows may be consulted in the process of generating the itinerary.
In an embodiment, more than one itinerary may be generated. As such, the itinerary provided to the user may, in effect, be merely a suggested itinerary. For example, if the user is dissatisfied with one or more of the appointment time/duration or agent selection, the user may, using a graphical user interface associated with the website, select from one or more other available appointment times/durations and/or agents.
At a block 410, a user is provided access, via an electronic network, to a user interface enabling the user to view listings of parcels of real property stored on a memory device and provide a selection of a set of the stored listings. For example, upon navigating to the website, the user may, in a conventional manner, ensure personal credentials to login to an account maintained by, for example, the administrators of the website. Subsequently, the user may sort through and view MLS listings stored in database 240. In a conventional manner, the user may select one or more of the MLS listings of homes, including listings stored in database 240 of homes that are not offered for sale at the time the user navigates to the website, that the user is interested in purchasing for inclusion in a “wish list” or “favorites” set associated with the user's account.
In an embodiment, the user may select the stored listings by selecting a city, a neighborhood within a city, or other subregion of the city from one or more menus presented in the user interface. Consequently, all listed parcels located in the selected city or neighborhood/subregion would, in effect, be included in the selected set of stored listings.
At a block 420, the selected set is received by the server 230, for example.
At a block 430, the user is provided access, via the electronic network, to a user interface enabling the user to (a) view a set of dates and at least one indication of a quantity of open houses hosted on each date of the set of dates at parcels associated with the selected set of listings, (b) provide a selection of a date on which the user desires to attend (i.e., tour) multiple open houses hosted on the selected date, and (c) provide a selection of a time window on the selected date during which the user desires to attend the multiple open houses. For example, as illustrated in
In an embodiment, the day indicators 515 may be populated with open house information, as illustrated in
As illustrated in
In an embodiment, and as illustrated in
At a block 440 the selected date and time window are received by the server 230, for example.
At a block 450, and in response to receiving the selected date and time window, an itinerary including an indication of a suggested sequence of attendance of open houses of a set of the multiple open houses and suggested time periods within the time window on the selected date during which each open house of the set of the multiple open houses may be attended is generated. For example, one or more of the server 230 in computer system 260 may generate the itinerary based on a calculation of travel time between or among the parcels of the selected set hosting open houses and may include an additional predetermined amount of time as a “buffer.” The algorithm employed to generate the itinerary may optimize based on distance or, alternatively, may optimize based on waypoints. Because of the finite duration of the time window selected by the user, the finite amount of time during which any given open house is hosted, and distances between the parcels at which open houses are being hosted on the selected day, all open houses occurring within the selected time window on the selected day may not be included in the itinerary. In an embodiment, the duration of the suggested time periods may be adjustable by the user.
In an embodiment in which the computer system 260 generates the itinerary, the computer system may perform the following algorithmic steps. First, the computer system 260 determines the day and time window selected by the user. Next, the database 240 is consulted to identify all open houses scheduled to occur during at least a portion of the selected time window. Next, a determination of “outlier” open houses is made. An open house qualifies as an outlier if its ending time is at least 45 minutes (i.e., the default allotment setting for time spent at an open house plus travel time to the open house) later than the latest previous open house ending time and still within the selected time window. As such, it is an open house that is guaranteed to be scheduled because there are no conflicts within its time slot. Next, the outlier open houses are designated as lowest priority for purposes of their inclusion in the itinerary. Next, the open houses occurring during the selected time window are scheduled according to the following factors in descending order qualifying importance: (a) earliest start time of the open house, (b) shortest duration of the open house, and (c) priority (i.e., importance) of the open house as may be indicated by the user. Next, review the open houses that now populate the itinerary and substitute higher-priority open houses for lower-priority open houses. It should be noted that the above-described algorithmic steps would likewise be performed in embodiments in which the server 230 alone or a combination of the server and computer system 260 generates the itinerary.
At a block 460, the itinerary is provided to the user. For example, the server 230 and/or the computer system 260 provides the tour itinerary to the user. The tour itinerary may be provided to the user via one or more of a webpage 800, such as is illustrated in
As illustrated in
An embodiment may include a user interface (not shown) accessible to the user after the open house tour has been conducted and enabling the user to indicate which homes they actually saw on the tour, and enter notes on them. Tracking the homes seen by the user enables the administrator of the website to ignore those homes when the user plans the next tour (although the user may override this setting).
While the preferred embodiment of the invention has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
PRIORITY CLAIM The present application claims priority from U.S. Provisional Application No. 61/710,606, filed Oct. 5, 2012, which is incorporated by reference as if fully set forth herein.
Number | Date | Country | |
---|---|---|---|
61710606 | Oct 2012 | US |