HK1184264A - Creating a database that stores information about individual habitable units - Google Patents

Description

Creating a database storing information about individual living units

(Cross-reference to related applications; claims of benefit)

The present application claims the following benefits: (1) U.S. provisional application 61/403070 filed on 9/10 2010; (2) united states provisional application 61/465508 filed on 21/3/2011; (3) U.S. patent application No.13/208147 entitled "CREATINGA DATABASE THAT STORES INFORMATION ABOUTINDIVIDUAL HABITABLE UNITS" filed on 11/8/2011; and (4) U.S. patent application No.13/208153 entitled "SEARCHING ADATABASE THAT STORES INFORMATION ABOUTINDIVIDUAL HABITABLE UNITS" filed on 11/8/2011.

Technical Field

The present invention relates to creating a database storing information about individual living units (IHUs) based on a floor plan of the IHUs.

Background

When planning a vacation or business trip, many users use a travel website that provides information about multiple hotels to make reservations. However, travel sites are limited because each hotel has very little information presented to the user. For example, a typical travel website may display the address of a hotel, a range of acceptable prices for the hotel, and one or more snapshots of the hotel's yard and possibly one or more "show" rooms.

Travel websites generally do not have information about individual rooms. In other words, the user cannot tell whether she has subscribed through the travel website to a first floor of rooms, a room with special scenery, a room with a certain amount of square size, or a room near an elevator or stairs. In fact, the user must directly contact the hotel to determine some of this information, which is not available at all.

Drawings

In the drawings, there is shown in the drawings,

FIG. 1 is a block diagram illustrating a system for creating a database storing information about a number of individual living units according to an embodiment of the present invention;

figure 2 is a screen shot of a user interface that allows one or more users to provide input specifying hotel objects shown in a digital image of a hotel floor plan, according to an embodiment of the present invention;

FIG. 3 is a screen shot of a user interface that allows one or more users to provide input to fit a rendered image to a map, according to an embodiment of the invention;

FIG. 4 is a block diagram illustrating a user interface that allows a user to annotate or mark individual human-residing cells shown in a rendered image according to an embodiment of the present invention;

FIG. 5 is a block diagram illustrating a system for processing search queries for a personal occupancy unit database in accordance with an embodiment of the present invention;

6A-6D illustrate exemplary search results generated in response to a search query against a personal dwell unit database in accordance with embodiments of the present invention;

7A-7B are flow diagrams illustrating a process for ranking a group of individual living units according to an embodiment of the invention;

FIG. 8 is a block diagram that illustrates a computer system upon which an embodiment of the invention may be implemented.

Detailed Description

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Individual living unit

An individual living unit is a structure in which one or more individuals may live for a period of time. Non-limiting examples of IHUs include in hotel rooms, motel rooms, villasRooms, flats, apartments, cabins, passenger cabins, hotels and bungalows. Accordingly, an IHU may be purchased or rented by one or more individuals. As a single entity or entity that may include one or more building structures (e.g., Hilton @)^TMOr Marriot^TMCourtyard), a group of IHUs may be owned, managed, and maintained. Non-limiting examples of such building structures include hotels, motels, suite complexes, and apartment complexes. A group of IHUs maintained or managed by a single business entity or institution may cover only a few acres of land, while some larger complexes, such as vacation hotels, may include IHUs distributed over 1 or 2 square miles. A single business entity or institution may own or manage different groups of IHUs at different locations, e.g., one group of IHUs at SanFrancisco, California, and another group of IHUs at Las Vegas, Nevada.

An IHU may comprise a single room. However, some IHUs contain two or more rooms that may be separated by a wall (or other partition) containing a door between two rooms of the same IHU.

Also, many IHUs, such as many hotels and motels, have one or more walls that abut another IHU. The IHUs form an "adjacent group" when each IHU in the group shares a wall with at least one other IHU in the group. However, in some cases, an IHU that is part of the same complex does not share walls with any other IHU in the group. For example, a business entity may have a suite of individually situated bungalows or houses in a small geographic area, such as a few acres.

Many building structures that include multiple IHUs include multiple floors, such that there are multiple IHUs on each floor. In many cases, the floors of such building structures have the same floor plan. Thus, one set of IHUs on one floor may have the same size and configuration as another set of IHUs on another floor of the same building.

For the sake of brevity, an example is given below in which the IHU is a hotel room and the building complex to which the IHU belongs is a hotel. However, the techniques described herein are not limited to any particular type of IHU or building complex.

Summary of creation of database of hotel rooms

Techniques are provided herein for creating a database that maintains information about hundreds or thousands of hotel rooms. As described above, the same techniques are equally applicable to creating databases for other types of IHUs.

Creating such a database includes three main steps that are performed at least once for each hotel in one embodiment: drawing, matching and labeling. Each of these steps is described in more detail later.

In one embodiment, in the drawing step, an image of the floor plan of the hotel is displayed to a "system" user (as opposed to an "end user" submitting a search query for the database of hotel rooms generated after these three steps). A system user provides a drawing input representing the boundaries of hotel rooms located in the area represented by the floor plan image. The result of processing the draw input is a draw image that reflects the boundaries of each "drawn" hotel room represented in the floor plan. As part of the mating step, the system user provides a mating input that causes the rendered image to be placed on a map associated with geographic coordinates. The map may display a satellite map of the hotel based on the floor plan. The orchestration input may also cause the rendered image to be scaled and rotated to better match the hotel shown in the map. Alternatively, the mating input may cause the map to be scaled and rotated to better match the rendered image.

As part of the annotation step, the system user provides annotation input that annotates each hotel room reflected in the rendered image. The callout input can represent a room number for each hotel room and one or more other details about each hotel room, such as a room category describing characteristics about the hotel room, the number and size of beds in the hotel room, and the floor on which the hotel room is located.

System overview

Figure 1 is a block diagram illustrating a system 100 for creating a database storing information about a number of hotel rooms, according to an embodiment of the present invention. The system 100 includes a floor plan database 110, a tagging tool 120, and a hotel room database 130. Although shown as separate databases, databases 110 and 130 may be on the same physical storage device. Databases 110 and 130 may include volatile and/or non-volatile memory.

The floor plan database 110 stores digital images of multiple floor plans for multiple hotels that may be owned and operated by different entities. Each digital image may take one of many different image formats including, but not limited to, JPEG, PNG, GIF, BMP, RAW, and TIFF.

Some hotels contain only a single building with a single floor. In this case only a single digital image of the floor plan is required. If the hotel contains multiple single-story buildings with different floor plans, a single image of each floor plan may be required in order to obtain information about each hotel room in the hotel. Many hotels contain a single building with multiple floors. Some of such hotels have the same floor plan for each floor. Thus, in this case, only a single image of a single floor plan is required in order to obtain information about each hotel room in the hotel. As long as different floors of the hotel have different floor plans, obtaining accurate information about each hotel room in the hotel necessitates a single image of each different floor plan.

Floor plan

The hotel floor plan may be obtained in a number of ways. For example, a person (such as a hotel employee or boss of a hotel) may take a picture of a hotel floor plan and email the picture to a person who has access to the floor plan database 110. Similarly, one person may provide (e.g., by mail) a printed copy of the hotel floor plan to another person who has access to the floor plan database 110. As another example, an employee of a hotel may be able to access a computer terminal that can cause digital images to be sent directly to the floor plan database 110.

Because the digital image of the hotel floor plan is only a set of pixel values that do not represent various characteristics of the hotel room, a tagging tool 120 is provided to allow a system user to create a virtual floor plan including different hotel objects reflected in the digital image based on the digital image. The virtual floor plan enables information to be derived about hotel rooms, which information would be of interest to an end user searching for a hotel room to make a reservation.

System overview (configuration)

The marking tool 120 is a software application for marking floor plans. In one embodiment, the markup tool 120 includes a drawing component 122, a fitting component 124, and a labeling component 126. The markup tool 120 can execute on one or more computing devices.

In alternative embodiments, the components of the markup tool 120 are separate software applications that may or may not be executed on separate computing devices. In this manner, each component of the marking tool 120 may be deployed and maintained separately from other components of the marking tool 120.

The rendering component 122 receives as input a digital image from the floor plan database 110. When displaying (via a display device not shown) the digital image from the floor plan database 110, the drawing component 122 also receives input from the system user representing the boundaries of the plurality of hotel rooms represented in the digital image. The drawing component 122 generates a "drawn" image based on the "drawing" input and the digital image. The rendered image is provided to the orchestration component 124.

When a map of the hotel corresponding to the hotel floor plan is displayed, the fit component 124 receives a "fit" input from the system user to move the drawing image over the map. The display of the map may include a satellite image of the hotel to assist the system user in providing input when making appropriate size and orientation adjustments. In addition to moving the rendered image, the "fit" input may include zooming the rendered image, i.e., increasing or decreasing the display size of the rendered image.

The annotation component 126 receives an "annotation" input that annotates each hotel room represented in the rendered image with certain information. The annotation input can be received before or after the fitting component 124 moves the rendered image on the map. The information for each hotel room represented in the rendered image may include the number of the hotel room, the category (or type) of the hotel room, the number of beds in the hotel room, the type of bed in the hotel room, and the floor on which the hotel room is located.

Finally, the label information for the hotel floor plan is stored in the hotel room database 130 along with information about the hotels of the hotel floor plan that are not affiliated with the hotel. The one or more computing devices may query the hotel room database 130 for information about multiple hotel rooms of a single hotel or multiple hotel rooms from different non-affiliated hotels.

Drawn boundaries for hotel rooms

Figure 2 is a screen shot of a user interface 200 that allows one or more system users to provide input specifying hotel objects shown in a digital image of a hotel floor plan, according to an embodiment of the present invention. The user interface 200 is an element of the drawing component 122.

The user interface 200 displays a plurality of tools 210A-L that allow a system user to indicate various objects indicated on floor plans of a hotel on a digital image of the floor plan (or simply "floor plan"). Thus, when displaying the floor plan images, the system user may use the user interface 200 and the floor plan images to draw the boundaries of the hotel rooms reflected in the floor plan images, and optionally other objects (e.g., elevators and stairs) reflected in the floor plan images. An input that causes a hotel object to be drawn or displayed on a computer screen is referred to as a "draw input".

The objects drawn by using the user interface 200 may be displayed in the same or different area of the computer screen as the area of the computer screen displaying the floor plan image. For example, the floor plan image may be displayed in the upper right corner of the computer screen, while the object is drawn in another area of the computer screen. As another example, the floor plan may be centered on and occupy most of the computer screen, while the object is drawn to appear "above" the floor plan. In this manner, hotel objects are drawn by "tracking" the corresponding objects shown in the floor plan images. Such tracking may allow for the most accurate information of hotel rooms to be automatically determined, such as room size, room scenery, and various distances such as distance to elevators and distance to stairs.

Alternatively, when the hotel object is drawn, the floor plan image is not displayed. For example, a system user may draw the boundaries of multiple hotel rooms of a hotel based on the system user's memory or based on a hard copy of a floor plan on a table adjacent to the computing device receiving the drawing input. In other words, there is no need to display the floor plan image while receiving the drawing input.

The types and number of tools 210A-L provided by the user interface 200 may vary widely. Object selector 210A allows a system user to select an object displayed via user interface 200. The rectangle tool 210B allows the system user to draw a square or rectangle that is the basis for drawing a room. The custom shape tool 201C allows a system user to draw custom (i.e., non-rectangular) shapes. Line drawing tool 210D allows a system user to draw lines.

The articulating tool 210E allows two objects to be "articulated" together. The articulating tool 210E is helpful when there are two dissimilar objects that the system user wishes to abut each other. Without the articulating tool 210E, the system user must manually adjust one object relative to the other to precisely secure them together.

The replication tool 210F allows objects to be replicated. One example of using replication tool 210F is when there are multiple rooms on a particular floor that have the same shape and a single floor plan. Thus, if there are 20 hotel rooms having the same floor plan, then only one hotel room needs to be drawn by the system user (e.g., by using the rectangle tool 210B), and then the system user selects the copy tool 210F to produce a copy of the drawn hotel room.

The copy neighborhood tool 210G allows objects to be copied, but only to areas adjacent to the object. The difference between the copy neighboring tool 210G and the copy tool 210F is that the copy tool 210F can be used to copy objects, and the copy can be moved to any area in the drawing. On the other hand, by copying the neighborhood tool 210G, the system user is limited to moving the copy to one edge of the original object. For example, if the original object is a square, then the copy may be applied to one of the four sides of the original object. However, the entire edge of the copy need not touch the entire edge of the original object. In fact, a portion of the replicated edge must contact a portion of the edge of the original object.

The mirroring tool 210H allows for the creation of a mirrored copy of an object. This tool is helpful given that many hotel rooms in a single building or complex are mirror images of another hotel room in the same building or complex.

Once the object is created by using one or more of these tools, the object may be further modified by moving, rotating (i.e., clockwise or counterclockwise) and scaling the object to match the corresponding object reflected in the floor plan image.

The delete tool 210I allows objects to be deleted. Undo tool 210J allows previous operations to be undone. Selecting the hidden drawing tool 210K causes the drawing to be hidden (at least temporarily) or semi-transparent so that the floor plan image can be more easily viewed with little obstruction to the drawing. Similarly, selecting the hidden image tool 210L causes the floor plan image to be hidden (at least temporarily) or semi-transparent, so that the rendering being created by the system user can be more easily viewed with little obstruction of the floor plan image.

After the object is drawn (e.g., by using the rectangle tool 210B or the custom shape tool 210C), the object may be designated as one or more types of hotel objects, such as hotel rooms, elevators, stairs, swimming pools, skating rinks, lobbies, gyms, sales areas, washing services, and restaurants. The drawn object may be designated as a type of hotel object by, for example, right clicking on the object and selecting a particular hotel object type from a list of object types displayed in response to right clicking on the object, or through a drop down menu available on the user interface 200. Alternatively, the system user may be allowed to provide any annotations to the drawn object, regardless of whether the appropriate hotel object type is available for the drawn object. For example, a system user may be able to designate a rendered object as "Concierge Lounge".

When a hotel object type identified by the drawing component 122 is used to specify a drawing object, the drawing component 122 can automatically mark the object to visually distinguish the object from other drawing objects. For example, if the object is designated as an elevator, the drawing component marks the object with an "X". As another example, if the object is designated as a staircase, the drawing component marks the object with a vertical line or a vertical line.

In a related embodiment, instead of drawing objects and then specifying objects, the user interface 200 may contain different tools for each hotel object. Thus, the user interface 200 may include hotel room tools, stair tools, elevator tools, window tools, and the like.

The user interface 200 may contain a window tool (not shown) for creating window objects. For example, after selecting the window tool, the system user selects one side of the hotel room object and creates and displays a window object between the ends of the selected side. The window object may be adjusted along the selected edge. Alternatively, the window object may be created in a fitting step, which will be described in detail later.

The result of receiving all inputs while displaying the floor plan image is a rendered image. The rendered image includes hotel objects (e.g., hotel walls/boundaries, stairs, elevators, doors, windows, etc.) corresponding to the hotel objects shown in the floor plan image initially (i.e., prior to receiving any system user input) displayed via user interface 200. The rendered image may now fit on the map.

Fitting room boundaries onto base images

FIG. 3 is a screen shot of a user interface 300 that allows one or more system users to provide input to fit a rendered image (e.g., generated by rendering component 122) onto a portion of a base image, in accordance with an embodiment of the present invention. The user interface 300 is part of the mating component 124 and displays the base image. The base image may be a satellite image, a spatial image (e.g., taken from an airplane), a map image, or a mixture of a map image and a satellite/spatial image.

The base image is associated with a mapping that maps points on the base image to a plurality of spatial coordinates. The plurality of spatial coordinates may be geographic coordinates such as longitude and latitude. Thus, points on the base image may be associated with different sets of longitude and latitude coordinates. The granularity of the mapping may vary from one base image to another. The granularity of the mapping refers to the number of points in the mapping relative to the size of the base image. Thus, if the first base image and the second base image have the same size and the first base image has more points in its mapping than in the mapping in the second base image, the mapping of the first base image has a finer granularity than the second base image.

The user interface 300 also displays a rendered image 302 overlaid on the base image. In this example, the drawing image 302 is a rotated and reduced version of the drawing image 202 shown in fig. 2. The rendered image 302 also represents the location on the exterior wall where the window is located.

The user interface 300 includes a control component 310 for zooming in on the geographic area represented by the base image. Zooming in on the geographic area represented by the base image includes adjusting a scale of the base image or adjusting a ratio of a size of the display to a size of the geographic area represented in the display. For example, prior to zooming, 1 inch of the screen of the display of the base image is equal to 1/4 miles. After zooming in, 1 inch of the screen equals 1/16 miles.

The control means 310 comprises control means for moving the base image up, down, left and right such that a different part of the base image is displayed after each such movement.

The user interface 300 also includes control means for rotating the rendered image 302 clockwise or counterclockwise. In addition to or instead of the control component 310, the user interface 300 includes an image control component for scaling (or resizing) the rendered image 302. Thus, instead of zooming in or out on the map by using the control component 310, an image zoom control component may be used to "fit" the drawing image 302 over a portion of the base image. In an embodiment, both the base image and the rendered image 302 may be rotated and scaled based on input from a system user.

Once the system user is satisfied with the location of the rendered image 302 on the base image and the scaled size of the rendered image 302 relative to the base image, the system user may provide input (e.g., select a "done" button) that results in the determination and saving of the geographic coordinates of the hotel rooms represented in the rendered image 302.

In one embodiment, in response to activation of the "done" button, the geographic coordinates of each hotel room are determined based on (a) where the room fits in the base image and (b) the mapping of the base image to the geographic coordinates. The orchestration component 124 may include a room-to-geographic location mapping component that identifies the geographic location of each corner of each hotel room. These locations may be used to determine the dimensions of the hotel room. The determined hotel room size can be very accurate, especially if the floor plan of the hotel room is rectangular. Hotel rooms, however, may have more complex floor plans, such as circular or non-convex shapes. Thus, the steps performed to determine the room size may approximate the actual room size.

Additionally or alternatively, the dimensions of one or more of the hotel rooms may be represented in the floor plan itself, or may be represented by another source, such as a website describing the hotel. In these scenarios, the system user may manually enter (e.g., in a marking step described later) room size data representing the dimensions of each of the one or more hotel rooms into the markup tool 120.

In a related embodiment, the floor plan image is aligned with the base image prior to the drawing of the hotel room, rather than after the drawing of the hotel room. Finally, a mapping is created between hotel room boundaries and the spatial coordinates reflected in the floor plan images.

Marking rooms

After the rendered image 302 is created, the hotel room represented in the rendered image 302 is "marked" or annotated with information about the hotel room. The information marked by each hotel room is stored in the hotel room database 130. The marking or labeling step may be performed after or before the mating step.

Fig. 4 is a block diagram illustrating a user interface 400 that allows a system user to mark or annotate the hotel rooms shown in the rendered image 302 (or 202), according to an embodiment of the present invention. The label or annotation is the value of a particular attribute of a particular hotel room. Thus, the type of indicia that may be associated with a hotel room corresponds to the type of attribute of the hotel room. Thus, the following are non-limiting examples of types of tags: room number, room size, number of beds, size of bed, room category, number of rooms (in hotel room or unit), whether smoking is allowed, whether there is a balcony, distance to elevator, and whether the landscape is "good".

In an embodiment, a mechanism is provided for tagging a batch of hotel rooms without requiring a system user to specify a tag for each of the hotel rooms. One situation where batch marking is helpful is when many hotel rooms share the same attributes (or attribute values) with other hotel rooms. For example, certain hotels allow smoking in some hotel rooms but not others. Thus, rather than requiring the system user to individually mark hotel rooms with a smokeless indication that smoking is not allowed, the system user can identify a group of hotel rooms by manually selecting each hotel room shown on the display and then selecting the "smokeless" indication once. The set of inputs results in no smoke designation being associated with each hotel room within the set. The number of inputs in this scheme can be modeled as "n + 1", where n is equal to the number of hotel rooms associated with the tag.

Alternatively, a system user may mark multiple hotel rooms by typing in a single label rule. A tag rule is an association between a tag and a pattern that can be matched across multiple hotel rooms. After entering the mode, the system user may then select one or more attribute indicators (e.g., "smokeless" indicators) once. Instead, after typing the tag, the system user may type the mode. In both schemes, the tags are associated with a schema used to create the tag rules.

An example of a pattern is a range of hotel room numbers, an example of which is as follows: 101 to 149, 201 to 249, and 301 to 349. Another example of a pattern includes regular expressions, examples of which are as follows: "*01- *03,*15- *17". This pattern, which contains regular expressions, represents rooms on each floor with 01, 02, 03, 15, 16 and 17 as the last two digits of the room number. Thus, a pattern that includes regular expressions representing a group of hotel rooms may be shorter than a prescribed range representing the same group of hotel rooms.

One way to mark multiple hotel rooms with a single tagging rule is to first create data that establishes a room category. Many hotels designate each hotel room as belonging to a room category. Different hotel rooms in a single hotel (e.g., in the same building or complex) belong to different room categories. Non-limiting examples of room categories include "two-person room", "two-person luxury room", "extra large coastal viewing room", "extra large room", "top large viewing room", and "large luxury room". Generally, all rooms in a hotel that belong to the same room category have the same attributes or characteristics, such as size, number of beds, number of rooms, smoke/no smoke, terrace, balcony, and whether pet is allowed. Thus, a system user may define one or more room categories and then select attributes/characteristics that are shared by all (or most) hotel rooms belonging to a particular room category. After defining one or more room categories, multiple hotel rooms may be marked or annotated by associating a single label with a single room category. In this manner, a single schema is associated with multiple attributes.

To assist the system user in creating and immediately viewing multiple tab rules, a user interface (not shown) may be displayed showing multiple columns: one for the room category, one for a group of room numbers, and one for a floor range. Each row in the room category column may be implemented as a drop down menu that lists multiple room categories when selected. The list of room categories may be limited to only those available at the hotel in question. In each row below the room number column, the system user may enter a pattern (e.g., "+ -01," + -03 "or" 604, 607 "). In each row below the column of floor ranges, a system user may enter data representing one or more floors, such as a floor range (e.g., "4-7"). Thus, while providing input for one room category, a system user may be able to view hotel room ranges and patterns in relation to other room categories. This may help the user to be sure that the same hotel room is not designated (represented in different patterns) as belonging to two or more different room categories.

Executing or processing the tag rule results in data identifying a particular room (e.g., a room number for a particular hotel) with the tag indicated in the tag rule. For example, the processing tag rule "2 large: 101-123 "results in the creation of 23 records, each representing a" 2 big "and a different hotel room number for numbers 101-123. If a record has been created for each of the hotel rooms, "2 big" is added to the "bed type" column for each record.

Additionally or alternatively, a system user may type an "exception tag rule" that contains a tag and identifies a pattern that represents multiple hotel rooms not associated with the tag. For example, the exception label rule may indicate that all hotel rooms in hotel X are smokeless rooms except the rooms ending with 17, 19, and 21. Processing the exception label rule results in data associating, for example, (1) room 101 having a smokeless attribute value and (2) room 117 having a smoking attribute value.

As described above, a building may include multiple floors, where the floor plan of one floor in the building is the same as the floor plan of one or more other floors in the building. With this knowledge, it is not necessary to generate a drawing image (e.g., drawing image 302) for each floor of the corresponding hotel. In fact, each hotel room shown in the rendered image is assumed to have the same spatial and geographic coordinates and the same characteristics (e.g., room size, room category) as the corresponding hotel room on another floor. Also, typically, the room number of a hotel room on one floor has the same suffix as the corresponding hotel room on another floor. For example, a hotel room with room number 101 corresponds to a hotel room with room number 201, which corresponds to a hotel room with room number 301 (if there are additional floors). Thus, a set of tags associated with hotel room #101 is automatically associated with hotel rooms #201, #301, etc. The auto-correlation may be based on one or more of the regular expressions mentioned above.

In a related embodimentEach hotel room in a particular hotel may be classified as belonging to one of a plurality of room categories such as a "grand size" category, a "president" category, and a "luxury" category. The names of the various room categories may correspond to names established by (or on behalf of) the hotel or may be selected by the system user of the tagging tool 120. Each category is associated with the same set of attribute values (such as "400 ft" for room size)²"" number for beds "2" and type for beds "king and king") but not necessarily all possible attributes. For example, many hotel rooms from the same category may change the distance to the nearest elevator and/or stairs. If a hotel room is associated with a particular room category and the particular room category is associated with a particular set of attribute values, the hotel room (and each other hotel room associated with the particular room category) "inherits" the particular set of attribute values. In other words, at least some of the attribute values for hotel rooms may be identified by first determining a category for the hotel room and then identifying the attribute values associated with the category.

Automatic correction label

Some errors may occur because some of the process of marking hotel rooms reflected in the rendered image 302 may necessitate significant user input (such as assigning room numbers or creating rules). Some errors are difficult to recover manually, especially if rules are used, such as rules where the pattern is a regular expression, for associating attribute values with a large number of hotel rooms. An example of an error is the presence of multiple hotel rooms with the same room number in the same hotel. Contradictory data is another type of error. For example, a first data stored in hotel room database 130 may indicate that smoking is not allowed in a particular hotel room, while a second data stored in hotel room database 130 may indicate that smoking is allowed in that particular hotel room.

Thus, in an embodiment, after marking a set of hotel rooms for a particular hotel, the tagging tool 120 (or another process) analyzes the rules to recover from any errors. Such analysis may include generating (at least temporarily) a plurality of records, each record storing attribute values for respective hotel rooms. If the auto-correction process attempts to enter into the record another attribute value (for a particular attribute) that contradicts a certain attribute value (for the same particular attribute) already stored in the record, then the operation is performed. Operations may generally include generating an alert that is provided to a system user of the markup tool 120 or other system 100.

Scenery from hotel rooms

In an embodiment, hotel room database 130 stores, for each of one or more hotel rooms, visual information representing a landscape from the hotel room. Examples, non-limiting examples of items of visual information include computer-rendered images, actual digital photographs taken by a digital camera, and videos.

In an embodiment, multiple images from a view of a hotel room may be related to a particular hotel room in hotel room database 130. For example, for a single hotel room, there may be an image of a particular landscape looking straight out (i.e., perpendicular to the width of the window) from the window of the hotel room, an image of a particular landscape looking 45 ° to the right, an image of a particular landscape looking 45 ° to the left, and an image of a particular landscape looking 30 ° down (e.g., if the hotel room is on a high floor).

As described above, the image related to a specific hotel room and stored in the hotel room database 130 may be an actual image created by a camera operated by a user located in the hotel room. The user then causes the image to be sent over the network to a storage device that is accessible to another user (e.g., a user of system 100) that has access to hotel room database 130. The image may be sent with data indicating from which particular hotel room the image was taken. The other users then cause the images to be stored in the hotel room database 130 in relation to the particular hotel room.

In an embodiment, the one or more images representing a landscape from a hotel room may be computer-rendered images automatically generated based on the geographic location of the windows of the hotel room and the orientation of the windows. The rendered image 302 may include a window object representing a window in a hotel room. Once the rendered image 302 is "fitted" to a portion of the base (e.g., satellite or map) image, the geographic location of the window object may then be determined, for example, based on the correlation of the rendered image to the base image and the mapping of the real-world geographic coordinates to the base image. The geographic location is used as an input into the image rendering service. To generate an exact image of the scenery from the hotel room, the orientation of the scenery is also identified. The orientation of the scenery may be determined in various ways. For example, the orientation corresponds to a straight line direction perpendicular to the width of the window and away from the interior of the hotel room.

In addition to geographic coordinates and orientation, another value that may be used to generate computer-rendered images is altitude, height, or height to the ground. In the absence of altitude, the computer-rendered image may be based on an assumption that the landscape is from ground level or from, for example, 20 feet tall. However, the view from a hotel room on floor 10 of the hotel may be substantially different from the view from a hotel room on floor 1 of the same hotel, even if the two hotel rooms have the same longitude and latitude coordinates. The altitude or height of the view from the hotel room may be determined based on the height of each floor of the hotel, the floor on which the hotel room is located, and the known altitude of the foundation of the hotel. For example, if a particular hotel room is at floor 6 of the hotel building and the hotel floor is generally 10 inches high and the center of the window is generally 5 feet above the floor of the hotel room, then the height of the particular hotel room to ground level is about 55 feet (assuming floor 1 is the floor level of the hotel building).

In an embodiment, a third party service may be used to obtain visual information (e.g., images or videos) based on the location of the window in the hotel room (e.g., longitude, latitude, altitude) and optionally based on the angle from which the occupant may like to see outside the window. The tagging tool 120 or another computing entity associated with the system 100 sends geographic location data (e.g., latitude and longitude coordinates) and orientation data (representing, for example, S, NW or NNE) to a third party presentation service. The third party presentation service generates a computer presentation image (preferably based on a combination of satellite images, ground-level photographs, aerial photographs, 3D modeling of buildings, and digital terrain data) based on the input and sends the computer presentation image to the markup tool 120 (or another computing device of the system 100 not shown).

In a related embodiment, a public or private database storing images (and/or videos) is accessed to identify images created at geographic locations. An example of such a common database of images is given by Flickr^TMProvided is a method. Currently, many images are created by a camera with geo-location capability that enables the images to be associated with a particular geo-location. The geographic location may be based on longitude and latitude coordinates. An image in the public database may be a candidate for storage in relation to a hotel room if the image is associated with a geographic coordinate that exactly or approximately matches the geographic coordinate associated with the hotel room. Thus, a public or private database of images may be searched for images that are relevant to a particular geographic location corresponding to the geographic location of the hotel room to identify a set of candidate images. The system user may view each candidate image in the group to determine whether the image is or may be an accurate depiction of a landscape from the corresponding hotel room. If so, the image is associated with the corresponding hotel room. If not, the image is discarded.

Because the orientation may be incorrect (e.g., the image is a landscape of a hotel room rather than a landscape from the hotel room), the image may not contain an accurate depiction of the landscape from the hotel room. Also, the geographic location associated with the image may be inaccurate. For example, a camera creating an image may not have an accurate geographic location component, which may result in any image created by the camera deviating by a few feet or meters.

Images from the publicly accessible database and for scenery from a hotel room may be used to supplement any computer-rendered images associated with the hotel room in hotel room database 130.

Realizing hotel room database

In an embodiment, hotel room database 130 stores individual records, lines, or objects for each hotel room for which information is known. A table (or relationship) may be created for each hotel and the columns of the table correspond to attributes or characteristics of the hotel rooms of the hotel such as room number, room category, number of beds, room size, floor number, etc. The attribute values stored in the columns may be based on user input received in the labeling step described above. Some of the attribute values may be automatically determined. Non-limiting examples of attributes for which values may be automatically determined include distance to an elevator, distance to a stairway, distance to a vending machine, room dimensions (e.g., determined based on geographic coordinates of the boundaries of the room), and one or more landscapes from a hotel room.

Storing a separate set of attribute values for hotel rooms for each hotel room reflected in the hotel room database 130 may result in the size of the hotel room database 130 being unnecessarily large. Many hotel rooms from the same hotel have the same attribute values. For example, all hotel rooms in a hotel ending in one of 01-23 may have the same dimensions, e.g., square feet. As another example, all hotel rooms in a hotel ending at 04 may have a distance of 10 feet to the elevator. Thus, in an embodiment, hotel room database 130 stores a plurality of tag rules that reflect information about a plurality of hotel rooms. As described above, each tag rule associates one or more attribute values with a pattern that identifies a plurality of specific hotel rooms. A single label rule may reflect information about a single hotel or multiple hotel rooms in multiple hotels. For example, a particular chain hotel may have multiple buildings in different cities, each building having the same floor plan. Thus, a hotel room on floor 2 of a hotel in one location (e.g., one city) may have the same attribute value as a hotel room on floor 2 of a hotel in another location (e.g., a different city).

In an embodiment, hotel room database 130 includes non-volatile memory that stores a plurality of tag rules. Later, one or more processes (not shown) analyze the plurality of label rules, generate rows (or records) for each hotel room reflected in the plurality of label rules, and store the rows in a volatile memory (not shown). A record may be generated when the system that receives and processes search queries for hotel room database 130 is started. In this manner, for each search query, information about each hotel room can be quickly accessed (in volatile memory) without having to process any of a plurality of tag rules in response to receiving the search query.

Room category mapping

Additional information about hotel room categories may be retrieved from multiple sources. A non-limiting example of such information is pricing information that may change relatively frequently. Non-limiting examples of sources from which pricing information may be retrieved include representatives or websites of the hotel itself and third party sources such as Tracelocity, Orbitz and Expedia. The third party sources typically identify the room category of a particular hotel by using an identifier that is different from the identifier used by the particular hotel itself. For example, a particular hotel may have a hotel room category designated as 2QD, which represents "2 large size beds, luxury rooms". The third party source may refer to the same hotel category from that particular hotel as a "luxury large room".

Thus, when pricing information about a hotel is retrieved from a third party source, the identifier used by the third party source eventually needs to match the identifier used by the hotel. Thus, in an embodiment, hotel room database 130 (or an associated storage device) stores mapping information that maps a room category identifier (used by a third party source) to another room category identifier (used by a particular hotel) for a particular hotel. The hotel room database 130 has stored data associating (e.g., by using tagging rules) one or more hotel rooms with a particular room category used by the hotel to which the one or more hotel rooms belong. For example, a particular room category may first be identified in a floor plan image from a hotel or a website of the hotel. For a particular room category, one or more room category identifiers are retrieved from one or more third party sources. A system user may manually create a mapping between an identifier used by the hotel and one or more room category identifiers.

When the winery room database 130 is updated to store pricing information relating to, for example, a plurality of hotel rooms of a particular hotel, pricing data is retrieved from a third party source, an appropriate room category mapping (i.e., relating to the particular hotel) is identified, and the associated room category identifier is identified. The hotel room database 130 is then updated to store pricing information related to all hotel rooms (of a particular hotel) associated with the corresponding room category identifiers.

Modifying data in hotel room databases

Even after the floor plan is drawn, fitted, and marked, there may be missed information for one or more hotel rooms in the hotel room database 130. For example, the floor plan image may not contain any indication as to whether smoking is allowed in a room or the location of a hotel lobby relative to hotel rooms. Also, some of the information reflected in the floor plan images may be incorrect. For example, the housekeeping service may have moved, or the room number reflected in the floor plan image may be incorrect. Thus, in embodiments, an update tool is provided for a system user to update information about a particular hotel room or multiple hotel rooms. For example, an update tool may be used to modify a tag rule. Thus, the update tool has access to the hotel room database 130. The update tool (not shown) may be part of the marking tool 120 and may be a separate tool altogether.

User rating

In an embodiment, a user evaluation tool is provided that allows for the storage of evaluations from users (or hotel employers) in the hotel room database 130 in relation to the appropriate room. The user evaluation tool may be part of the system 100. The user rating tool receives ratings from the user that may be submitted via email, text (SMS) message, web page input, or a dedicated application executing on the user's device, such as a smart phone. These user ratings may be helpful to other users (i.e., end users) who submit search queries for processing by the hotel room database 130. Thus, even if a particular hotel room is deemed to match a particular end user well, a poor rating of that particular room from another user may convince that particular end user to consider other hotel rooms or at least view their information. Conversely, even if a particular hotel room is not deemed to best match a particular end user, a good assessment of that hotel room will persuade the end user to retain the room.

Searching for a summary of hotel rooms

According to an embodiment, a search query targeted at information about an individual living unit (e.g., a hotel room) is processed, and the information is identified and returned to an end user, such as the end user who conceived the search query. This information identifies the individual hotel room (e.g., by room number) and contains attribute values (e.g., number of beds, room size) for the individual hotel room. In contrast, previous responses to search queries about hotels typically return only information about hotels. In other words, there is typically no idea of providing information about individual hotel rooms to end users.

System overview

Figure 5 is a block diagram illustrating a system 500 for processing search queries for a hotel room database 130, according to an embodiment of the present invention. System 500 includes client devices 510A-N, network 520, and website 530. The website 530 contains a web server 532 and hotel room data 534. Although only two client devices are shown in FIG. 5, more client devices may submit search queries to the website 530. Also, although only a single web server 532 is shown, the website 530 may include multiple web servers 532 capable of accessing hotel room data 534 and processing search queries on behalf of the website 530.

Each of client devices 510A-N is capable of receiving input from an end user and sending a search query over network 520 to web server 532. The input from the end user may be voice input or text input. An application (e.g., a web browser or an application created by an entity hosting web server 532) executing on each of client devices 510A-N receives input and formulates a search query that web server 532 can process. Non-limiting examples of client devices 510A-N include desktop computers, laptop computers, tablet computers, and smart phones.

Web server 532 processes search queries received from client devices 510A-N. For each search query, the web server 532 identifies one or more hotel rooms that satisfy the criteria associated with the search query and sends data identifying the one or more hotel rooms to the client device that issued the search query.

As described above, the web server 532 accesses the hotel room data 534 in response to the search query. Hotel room data 534 may be stored in volatile or non-volatile memory. For example, hotel room data 534 may be the same data reflected in hotel room database 130. As another example, the hotel room database 130 may be a non-volatile storage device, while the hotel room data 534 may be stored in a volatile memory and may be generated from tag or label data stored in the hotel room database 130.

Client devices 510A-N and web server 532 are capable of communicating over network 520. Embodiments of the present invention are not limited to a particular communication protocol for communicating data and messages between client devices 510A-N and web server 532. A non-limiting example of a communication protocol that may be used by the entities shown in fig. 1 is the hypertext transfer protocol (HTTP).

Communication is enabled between client devices 510A-N and web server 532 via network 520. Network 520 may be implemented by any medium or mechanism that provides for the exchange of data between various computing devices. Examples of such networks include, but are not limited to, a network such as a Local Area Network (LAN), Wide Area Network (WAN), ethernet, or the internet, or one or more terrestrial, satellite, or wireless links. The network may comprise a combination of networks such as those described above. The network may transmit data according to a Transmission Control Protocol (TCP), a User Datagram Protocol (UDP), and/or an Internet Protocol (IP).

Search query

The search query (issued by one of client devices 510A-N) may be associated with one or more search criteria that limit the information about the personal hotel room returned in response to the search query. Each search criterion corresponds to an attribute of the hotel room reflected in the hotel room data 534. Non-limiting examples of search criteria include:

location data representing the location of a hotel room (e.g., state, city, zip code, "street");

name data representing the name of the hotel (or multiple names of multiple hotels);

price data representing a threshold value (e.g., < $ 250) or price range (e.g., $ 100- $ 220) that the end user is willing to pay;

floor data representing one or more floors at which the hotel room should be located (e.g., < floor 3) or a relative floor level (e.g., "low" or "high");

landscape data representing whether a landscape from a hotel room is important and/or whether an actual photograph (i.e., non-computer-rendered) of the landscape from the hotel room is available;

elevator data indicating whether the proximity of the elevator to the hotel room is important;

connected room data indicating whether a connected room with a hotel room is important;

represents the size of the hotel room (e.g., 7300 ft)²) Or room size data in the size range ("400-600 square feet");

room category data representing categories relating to hotel rooms;

bed data representing the number of beds and/or the size of the beds (e.g., king, queen, double) in the hotel room;

smoking data indicating whether smoking is allowed in a hotel room;

balcony data indicating whether a hotel room has a balcony; and

representing the distance from a hotel room to an object within the hotel (or on the same real estate as it) where the hotel room is located, such as an elevator, stairs, vending machine, swimming pool, hotel accommodations, hotel lobby, and noise source; and

representing the distance from the hotel room to an object outside the hotel (or on a different real estate than it) where the hotel room is located, such as a restaurant, a night club, a business district of the city where the hotel is located, and a noise source.

Non-limiting examples of noise sources include popular nightclubs, road construction, and noisy factories.

A search query sent by a client device (e.g., client device 510) may specify one or more search criteria. Such search criteria may include one or more criteria selected by an end user search initiating a search query. Such search criteria are referred to herein as "user-specified search criteria".

Additionally, the search criteria of the search query may include one or more criteria that are not selected by the end user initiating the search query. Such search criteria are referred to herein as "default criteria". For example, assume that the end user specifies (a) a city and (b) a particular hotel, without specifying any other search criteria. The web page displayed on client device 510A may represent one or more criteria that have been "pre-selected," even if no other criteria are specified by the end user. For example, a web page may indicate that a room landscape quality is "important" even if the end user does not specify any criteria related to the room landscape. Similarly, in the absence of any user-specified search criteria on the object, the default criteria may indicate that the end user's preferences are "high" for floors, "far" for elevators, and "unimportant" for connecting rooms.

As another example, the search query may specify the name of a city, and the default criteria may be that a landscape from a hotel room is important. Thus, in response to receiving the search query, the web server 532 identifies and returns information about hotel rooms that are (1) located in the city and (2) associated with the landscape that is considered "good". Thus, information about hotel rooms with landscapes that are not considered "good" is not part of the information returned in response to the search query.

Default criteria

When performing a search for hotel rooms, there are various ways in which the system can select default criteria to use in combination with user-specified criteria. For example, the default criteria may be selected based on a prescribed criteria to default criteria mapping and/or a user characteristics to default criteria mapping, both of which are described in more detail below.

With respect to the specified criteria-to-default criteria mapping, one or more criteria specified in the search query are correlated to one or more default criteria. In other words, if the criterion X is mapped to the criterion Y, then the criterion Y is added to all searches for which the end user specified the criterion X. The web server 532 accesses such a prescribed criteria-to-default criteria mapping in response to receiving a search query. Such a mapping may be helpful if it is known that when a search query specifies one or more particular criteria, the end user submitting the search query is generally interested in hotel rooms related to one or more other criteria.

For example, if the search query specifies Las Vegas, NV and the criteria-to-criteria mapping associates Las Vegas, NV with high landscape quality, the web server 532 identifies hotel rooms having a landscape that is deemed "good" and marks these hotel rooms as high-ranking, e.g., relative to hotel rooms that do not have high landscape quality.

As another example, the search query specifies a smoking, indicating that the end user submitting the search query will only consider hotel rooms where smoking is allowed. In response to receiving the search query, the web server 532 identifies a criteria-to-criteria mapping that associates the smoke with the balcony. Thus, the web server 532 identifies hotel rooms that not only allow smoking but also have a balcony.

With respect to the user characteristic-to-default criteria mapping, one or more characteristics or attributes of the end user are associated with one or more default criteria. That is, if property X is mapped to criterion Y, then criterion Y is added to the search performed by the end user having property X. The web server 532 accesses this user characteristic to default criteria mapping in response to identifying information about the end user initiated search query. Such a mapping may be helpful if it is known that end users with particular characteristics are generally interested in hotel rooms related to one or more criteria when they submit search queries.

The network server 532 may determine the user characteristics in one or more ways. For example, the end user may be registered by an entity operating web server 532 and managing hotel room data 534. An end user is "logged in" before receiving a search query from the end user. Thus, each search query initiated by an end user when the end user logs in contains identification data identifying the end user. The identification data may be associated with one or more default criteria. For example, when an end user is initially registered with a service, the end user may have selected one or more search criteria preferences (e.g., smokeless). The web server 532 then uses the one or more search criteria for the particular search query and subsequent search queries to identify hotel rooms for the particular end user even if the particular and subsequent search queries do not specify the one or more search queries.

The identification data identifying the end user may be correlated with characteristic data representing one or more characteristics of the end user. The characteristic data may in turn be related to one or more default search criteria. For example, the identification data may be associated with age information, which may indicate that the end user is over 80 years old, and over 80 years old may result in the selection of "accessibility" as a search criterion.

Non-limiting examples of characteristic data include the geographic location of the client device submitting the search query, the time of day the search query was submitted by the client device, the type of client device (laptop, desktop, tablet, or smartphone), and the particular group to which the end user belongs (e.g., a group of frequented travelers). Geographic location, time of day, and type of client device are examples of characteristics that may be determined without end user login at all or registration through web server 532. Each characteristic may be associated with one or more default criteria. For example, the identification data associated with a particular end user submitting a search query (whether the particular end user is registered or logged on) includes an IP address associated with a particular geographic location (i.e., characteristic) such as germany. Since it is known that people from germany generally prefer balconies, the web server 532 only identifies hotel rooms with balconies based on the characteristic-to-criterion mapping, or at least ranks hotel rooms with balconies high compared to hotel rooms without balconies.

Search results

The search results generated by web server 532 and displayed by the client device (e.g., client device 510A) include information about one or more particular hotel rooms. Each search result in the set of search results may correspond to a different hotel room. Each search result identifies a particular hotel room by, for example, the room number. Each search result includes information about one or more attributes of the corresponding hotel room, such as room size, room price, room category, number of beds, size of bed, floor number, whether smoking is allowed, whether it is on a balcony, distance to elevator, distance to stairs, etc. Also, each search result in a set of search results need not contain the same amount or type of information about the corresponding hotel room as every other search result in the set of search results.

Fig. 6A-D are exemplary web pages depicting a set of search results 160 based on a search query specifying a particular hotel located in a particular city, according to an embodiment. In fig. 6A, web page 600 also contains an image 620 (e.g., a computer presentation or actual digital photograph) of a landscape from a particular hotel room in a particular hotel. Image 620 may change periodically, e.g., every 3 seconds, to display an image of a landscape from another hotel room in a particular hotel. The web page 600 also contains an aerial view 630 of the floor plan of the particular hotel. The end user may select a hotel room depicted in the in-air landscape 630, which may result in displaying an image of the landscape from the selected hotel room. In this example, a particular hotel has multiple floors. To enable the end user to view information about rooms from different floors, the aerial landscape 630 includes a floor selector 632 that allows the end user to select a particular floor in a particular hotel.

In an embodiment, a set of search results identified based on a single search query includes information about hotel rooms from different hotels (e.g., different chains of hotels or different hotels of the same chain of hotels), such that each search result may contain information identifying the hotel to which the corresponding hotel room belongs. Alternatively, search results corresponding to hotel rooms from the same hotel may be grouped together, in which case hotel data representing the names of the hotels reflected in the search results is displayed only once.

As described above, one or more search results are related to a room landscape. As described above, the hotel room landscape may be computer-presented or may be an image created by the user's camera. Each of the one or more search results may have a link (e.g., labeled "view landscape") that, when selected by the end user, causes an image of a landscape from the corresponding hotel room to be displayed. In addition, at least one image of a landscape from a particular hotel room is displayed when a set of search results is displayed to the end user in response to a search query envisioned by the end user. A particular hotel room may correspond to a search result that is "at the top" of the search result list (or the search result with the highest ranking). For example, image 620 may be an image of a landscape from a hotel room deemed to be the best match in search results 610.

In an embodiment, a search results page containing a set of search results contains a room category option. Since any particular hotel category classifies hotel rooms differently from other hotels, the room category option reflects which hotel rooms change in the search results. For example, if a hotel room reflected in the set of search results is from hotel a, then the room category option displayed with the set of search results is based on hotel H and determined, for example, by web server 532 (or a related process). The room category may be based on the price of the room in hotel a, the number and size of beds in the hotel room of hotel a, and/or whether the hotel room in hotel a has balconies. Also, one or more of the room categories for hotel a may have names that are only meaningful to hotel a, such as "premium suite," administrative standard room, "and" presidential suite. If the second search query specifies hotel B, the room category option displayed to the end user submitting the second search query is updated to reflect the category associated with the hotel room located in the hotel bed.

The web page 600 includes a room category option 640. As shown in FIG. 6B, selecting the room category option 640 causes a room category selection window 642 to be displayed. Window 642 shows 10 room categories categorized into 3 price categories represented by "$".

In an embodiment, a search results page that includes a set of search results generated based on a search query includes preference options. The preference options correspond to one or more search criteria that may change after a set of search results is displayed to an end user.

The web page 600 contains room preference options 650. As shown in FIG. 6C, selecting the room preference option 650 results in the display of a room preference selection window 652. Window 652 shows four hotel room attributes that may be selected: floors, landscape, elevators and connected rooms. The default attribute values are high, important, far and don't care, respectively. After search results 610 are displayed, if the end user selects one or more different attribute values (e.g., "near" for the distance to elevator attribute selection), then a different set of search results are displayed, or at least search results 610 may be recorded (e.g., based on an update rating).

User selection of a search result may result in display of additional information about the hotel room corresponding to the search result. For example, as shown in fig. 6D, selecting search result 612 results in the display of additional hotel data 614 containing floor number, distance to the nearest elevator, whether it is a corner hotel room, whether it is with a description of connected rooms, room size, landscape, and bed type. Selecting search results 612 may also result in an air scene 630 indicating the location of a hotel room relative to other hotel rooms in the hotel on the same floor.

In an embodiment, the web page displaying the search results may contain a "subscribe now" link or button. For example, web page 600 contains a "make a reservation" link that when selected causes reservation information to be displayed. The reservation information indicates how the end user may reserve a hotel room from the hotel. The reservation information may include the phone number of the corresponding hotel and may optionally include a series of one or more questions that require a query of hotel receptionists for reservation of a hotel room. Alternatively, the "make a reservation" link may be a link to a website of the respective hotel where the end user may make a reservation.

As another example, user selection of a search result (or a "book now" button corresponding to the search result) may result in display of information provided by web server 532, where the information (e.g., one or more web pages provided by web server 532) may allow the end user to book a corresponding hotel room from the end user's client device. In this manner, web server 532 (or a related process) operates on behalf of the end user by obtaining information from the end user and interacting with the hotel server ("transparently" to the end user) to book hotel rooms corresponding to the search results.

As described above, hotel room data 534 may store one or more user ratings related to a particular hotel room. The user rating may be specific to the hotel room or may be generally relevant to the hotel. Thus, in embodiments, to adjust these user ratings, the search results may contain user ratings or links to one or more user ratings. The user rating may take any form, such as a number of asterisks or actual text from the user who created the user rating.

Grading hotel rooms

In an embodiment, a respective set of hotel rooms is rated based on one or more rating criteria before web server 532 provides a set of search results to a client device (e.g., client device 510A) generated in response to receiving a search query. A set of hotel rooms is ordered based on a ranking score associated with each hotel room.

Figures 7A-B are flow diagrams illustrating a process 700 for rating a group of hotel rooms, according to an embodiment of the present invention. Although process 700 is described as being performed by web server 532, one or more other processes associated with web server 532 may perform one or more of the steps of process 700.

In step 705, the web server 532 receives a search query relating to a set of one or more search criteria. At least one search criterion in the set is a user-specified search criterion. One or more of the search criteria in the group may be a default criterion.

In step 710, the web server 532 identifies a set of search results based on one or more search criteria. Each search result in the group corresponds to a different hotel room.

In step 715, the web server 532 identifies a set of one or more ranking criteria. The one or more ranking criteria may be the same as or different from a set of one or more search criteria. For example, while the search query specifies a particular chain of hotels in a particular city and the landscape from the hotel rooms is important, in addition to using the room landscape as the grading criterion, the network server 532 may use the hotel room price-hotel room size ratio as the grading criterion. As another example, the search criteria associated with the search query may indicate that the end user is interested in high floors, "good" scenery, nearby elevators, and connected rooms. After identifying a set of hotel rooms based on the search criteria, the web server 532 may use the same criteria as the ranking criteria.

In step 720, the web server 532 identifies search results in the set of search results that have not yet produced a ranking score.

In step 725, the web server 532 determines, for each of a set of one or more grading criteria, a preliminary value for the grading criteria associated with the hotel room identified in step 720. The grading criteria correspond to attributes of the hotel room. Therefore, the type of the preliminary value changes according to the type of the criterion or the room property. For example, if the grading criterion is distance to an elevator, then the preliminary value for a particular hotel room may be20 feet. If the grading criterion is room size, then the preliminary value for a particular hotel room may be 500ft². If the grading criterion is a room landscape, then the preliminary value for a particular hotel room may be "good", "bad", or "none". If the grading criterion is a floor, the preliminary value for a particular hotel room may be "high", "low", or "first floor" and/or a particular value (e.g., "5") indicating the particular floor on which the particular hotel room is located.

In step 730, for each preliminary value determined in step 725, the web server 532 determines a normalized value based on the preliminary value. Each normalized value for a particular hotel room is between two values, such as between 0 and 100 or between 0 and 1. Alternatively, the normalized value may be related to a hotel room prior to receiving a search query from the web server 532 using the normalized value. Therefore, the preliminary value does not have to be determined. In other words, step 725 may not be necessary.

In step 735, the web server 532 applies a weight to the normalized values for each normalized value determined in step 730. For example, step 730 results in three normalized values: 0.9, 0.6 and 0.3. If the importance of the first two ranking criteria is considered twice as important as the third ranking criteria, the following weights may be applied to the three ranking criteria, respectively: 2. 2, and 1. In other words, 0.9 and 0.6 are both multiplied by 2, while 0.3 is unchanged. However, this step is not necessary if the importance of the ranking criteria is deemed equal.

The weights determined for the ranking criteria may be based on whether the search query specifies the ranking criteria. For example, if the search query specifies that room scenery is important and connected rooms are not, then a positive weight (e.g., > 1.0) is applied to the normalized values associated with the room scenery attributes of the particular hotel room, while no weight (or a negative weight) is applied to the normalized values associated with the connected room attributes of the particular hotel room.

Additionally or alternatively, the weights determined for the ranking criteria may be predetermined or established prior to the web server 532 receiving the search query. For example, if a room landscape is not specified in the search query and is used as a ranking criterion, the weight for the room landscape ranking criterion may be 1.5; otherwise, if a room landscape is specified in the search query, the weight for the room landscape ranking criterion may be 2.0.

In step 740, the web server 532 combines the weighted values generated in step 735 to generate a ranking score for the hotel room. The web server 532 associates the rating score with the hotel room. The weighting values may be combined by simply adding the weighting values generated in step 735. Alternatively, one or more of the outliers may be removed. For example, the lowest weight value and the highest weight value may be removed, and the remaining weight values may then be combined.

In step 745, the network server 532 determines whether there is another hotel room (of the group of hotel rooms identified in step 720) that has not yet generated a ranking score. If so, step 700 proceeds to step 720. If not, step 700 proceeds to step 750.

In step 750, the web server 532 ranks a group of hotel rooms based on the ranking scores associated with the hotel rooms in the group.

In step 755, the network server 532 sends at least a subset of the set of hotel rooms to the client device (e.g., client device 510A) (or another client device) that submitted the search query.

For example, the end user of client device 510A forms a search query that specifies San Francisco as a city, a room size of at least 500 square feet, landscape from a hotel room as important, connected rooms as unimportant, floor level "high," and a distance to an elevator of less than 50 feet. Client device 510A sends a search query to web server 532 over network 520. The web server 532 only identifies those hotel rooms located in the San Francisco that are at least 500 square feet in size and within 50 feet of elevator distance. The network server 532 ranks the hotel rooms based on the landscape of the identified hotel rooms and how close the hotel rooms are to the elevators. Scenery from a hotel room may be classified as being associated with one of three preliminary "values": no scenery, poor scenery or good scenery. If the identified hotel room has a good view, the normalized value for this preliminary value may be "1.0" (representing a perfect score). "poor landscape" may be assigned a normalized value of "0.2", and "no landscape" may be assigned a normalized value of "0".

With respect to the distance to the elevator, hotel rooms less than 10 feet from the elevator may be assigned a normalized value of "1", hotel rooms from 10 feet to 20 feet may be assigned a normalized value of "0.9", hotel rooms from 20 feet to 30 feet may be assigned a normalized value of "0.8", and so on.

Match indicator

In an embodiment, a set of search results may indicate how well each search result "matches" the search criteria specified in the search query. For example, based on objective factors, the search results may represent a percentage match (e.g., "100%" or "22%") or a qualitative match (e.g., "perfect," "good," or "bad"). For example, as part of the ranking process, the web server 532 determines how perfect the ranking score would be given a weight. The perfect score is, for example, 1.0 for each normalized value of the property, where the appropriate weight is applied to each normalized value. The resulting value may be 1.0 × 2+1.0 × 1= 5. Each rank score associated with each search result is compared to (e.g., divided by) the perfect score to obtain a percentage match. An indication of a percentage match or a quality of match is indicated in search results displayed on the client device.

Hotel room availability

An end user submitting a search query for hotel room data 534 may wish to book hotel rooms on a particular date (e.g., 11/26/12) or a particular range of dates (e.g., 10 months 12 to 10 months 23). Thus, in embodiments, the end user may include date information in the search query, and, in response to receiving the search query, the web server 532 may provide the end user with only information regarding hotel rooms available on the date indicated in the date information. In other words, if a particular hotel room is not available on the proposed booking date indicated in the search query, information about the particular hotel room is not displayed to the end user contemplating the search query, even though the particular hotel room may have the best match based on the search criteria associated with the search query.

In an embodiment, the availability of one or more hotel rooms is determined by the web server 532 in response to a search query from a client device. For example, the web server 532 identifies a set of hotel rooms that satisfy the search criteria associated with the search query. The web server 532 then sends the request to a remote hotel server maintained by the hotel where the group of hotel rooms is located. The request includes an identification date identifying each room in a group of hotel rooms, for example, by room number and date identifying one or more dates on which the reservation was sought. The hotel server has access to an availability date that indicates, for each hotel room in the group, whether the hotel room is available for reservation on any particular date. In response to the request from the web server 532, the hotel server sends a response to the web server 532 indicating whether each of the hotel rooms is available for the indicated date. In response, the web server 532 may filter the search results based on the availability date from the hotel server and send the filtered search results to the client device.

As another example, prior to receiving a search query targeting any of the respective hotel rooms, the hotel room records in the hotel room data 534 are updated to reflect when the respective hotel room is available. In other words, for hotel room availability, processing a search query for hotel room data 534 does not trigger a request transmission to one or more remote hotel servers. The hotel room records in the hotel room data 534 may be updated in the manner described above, such as the web server 532 (or another process) sending a request to one or more hotel servers to retrieve availability dates for a plurality of hotel rooms from each respective hotel. However, the request may not contain any particular date restrictions. In fact, each request sent to a different hotel server may retrieve the following availability date, for example, 6 months. Each hotel server (corresponding to a different hotel) may be accessed periodically, such as once per week or once per day.

The former example may be advantageous over the latter, at least because knowledge of the availability of hotel rooms is not fresh. This is because the room availability for a set of hotel rooms is determined from the source (i.e., the hotel server) at the time of processing a search query targeted to information about the set of hotel rooms.

Searching hotel rooms

There are methods for searching for information about house and rent performance. Com and vrbo com provide features for searching for houses for sale and units for rental, respectively, for example. However, purchasing and renting are very different activities than booking hotel rooms. With respect to houses, apartments and apartments, a specific house, apartment house or apartment building is negotiated from the beginning of the purchase process. For example, the house buyer contacts the house owner directly (or through their respective agents) to negotiate agreements. In contrast, with respect to booking a hotel room, the particular hotel room is unknown to the prospective customer until he/she makes a booking and the (now actual) hotel customer arrives at (or just arrives at) the hotel room. In fact, prospective hotel customers negotiate with a hotel representative (or store using an online service) regarding booking some hotel rooms belonging to a particular room category. Thus, lease negotiations for hotels typically occur at the room category granularity level, while purchase or lease negotiations for houses/apartments occur with respect to particular house units.

Hardware summary

According to one embodiment, the techniques described herein are implemented by one or more special purpose computing devices. A specific-use computing device can be hardwired to perform the techniques, or can include digital electronics such as one or more Application Specific Integrated Circuits (ASICs) or Field Programmable Gate Arrays (FPGAs) permanently programmed to perform the techniques, or can include one or more general-purpose hardware processors programmed to perform the techniques according to program instructions in firmware, memory, other storage, or a combination. Such special purpose computing devices may also incorporate custom hard-wired logic, ASICs, or FPGAs with custom programming to implement the technology. The special purpose computing device may be a desktop computer system, portable computer system, handheld device, network appliance, or any other device that incorporates hard wiring and/or program logic to implement the techniques.

For example, FIG. 8 is a block diagram that illustrates a computer system 800 upon which an embodiment of the invention may be implemented. Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a hardware processor 804 coupled with bus 802 for processing information. The hardware processor 804 may be, for example, a general purpose microprocessor.

Computer system 800 also includes a main memory 806, such as a Random Access Memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instructions to be executed by processor 804. Main memory 806 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Such instructions, when stored in a non-transitory storage medium accessible to processor 804, cause computer system 800 to become a special purpose machine that is customized to perform the operations specified in the instructions.

Computer system 800 further includes a Read Only Memory (ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk or optical disk, for storing information and instructions, is provided and coupled to bus 802.

Computer system 800 may be coupled via bus 802 to a display 812, such as a Cathode Ray Tube (CRT), for displaying information to a computer user. An input device 814, including alphanumeric and other keys, for communicating information and command selections to processor 804 is coupled to bus 802. Another type of user input device is cursor control 816, such as a mouse, a trackball, or a cursor direction keyboard for communicating direction information and command selections to processor 804 and for controlling cursor movement on display 812. The input device typically has two degrees of freedom along two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify positions in a plane.

Computer system 800 may implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and/or program logic combined with the computer system to cause or program computer system 800 to become a special-purpose machine. According to one embodiment, the techniques described herein are performed by computer system 800 in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another storage medium, such as storage device 810. Execution of the sequences of instructions contained in main memory 806 causes processor 804 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.

The term "storage medium" as used herein refers to any non-transitory medium that stores data and/or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 810. Volatile media includes dynamic memory, such as main memory 806. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from, but can be used in combination with, transmission media. The transmission medium participates in transmitting information between the storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared-red data communications.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infrared-red transmitter to convert the data to an infrared-red signal. An ir-red detector can receive the data carried in the ir-red signal and appropriate circuitry can place the data on bus 802. The bus 802 carries the data to main memory 806, from which main memory 806 the processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.

Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides a two-way data communication coupling to a network link 820, which network link 820 couples to a local network 822. For example, communication interface 818 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a Local Area Network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP826 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "internet" 828. Local network 822 and internet 828 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are exemplary forms of transmission media.

Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP826, local network 822 and communication interface 818.

The received code may be executed by processor 804 as it is received, and/or stored in storage device 810, or other non-volatile storage for later execution.

In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.

Claims (34)

1. A method, comprising:

receiving an input representing a boundary of a plurality of individual living units;

receiving input establishing a correlation between the boundaries and a base image of a geographic area in which the plurality of individual dwelling units are located;

receiving a mapping between a point on a base image and a plurality of spatial coordinates;

determining a set of spatial coordinates for each individual living unit of the plurality of individual living units based on the input, the correlation, and the mapping;

wherein the method is performed by one or more computing devices.

2. The method of claim 1, wherein the base image is a satellite image of a geographic area.

3. The method according to claim 1, wherein,

the base image shows some, but not all, boundaries of a plurality of individual living units; and is

The boundary represented in the input represents at least one boundary not shown in the base image.

4. The method of claim 1, further comprising: prior to receiving the input, displaying a floor plan image of a floor plan including boundaries of a plurality of individual living units, wherein the input is received while the floor plan image is displayed.

5. The method of claim 1, further comprising: after determining a set of spatial coordinates for a particular individual living unit of the plurality of individual living units,

receiving visual information showing possible landscapes from windows of a particular living unit; and

data associating the visual information with a particular dwelling unit is stored.

6. The method of claim 5, wherein the visual information is one of a video, a computer rendered image, or a digital photograph.

7. The method of claim 5, further comprising: prior to receiving the visual information, a request is sent to a third party service containing a set of spatial coordinates for a particular individual dwelling unit, wherein the visual information is received from the third party service.

8. A method, comprising:

receiving a first input establishing a first correlation between the floor plan and boundaries of individual living units of the plurality of individual living units while displaying a first image comprising the floor plan of the plurality of individual living units;

receiving a second input establishing a second correlation between the floor plan and the base image reflecting the particular geographic area; and

receiving a third input specifying, for each individual living unit of the plurality of individual living units, one or more values for one or more attributes of the individual living unit; and

storing data in a database associating individual living units of a plurality of individual living units with respective geographic regions and respective one or more values of one or more attributes,

wherein the method is performed by one or more computing devices.

9. The method of claim 8, further comprising generating a second image based on the first input and the floor plan, wherein receiving the second input comprises receiving input that aligns display of the second image relative to display of the base image such that content shown in the second image is displayed in alignment with corresponding content shown in the base image.

10. The method of claim 8, wherein the one or more values include a room number of the individual living unit.

11. The method of claim 8, wherein the one or more values indicate a type of each bed of the one or more beds in the individual living units.

12. The method of claim 8, further comprising:

determining a size of each individual living cell of the plurality of individual living cells based on the boundary of the individual living cell and the base image after receiving the second input,

wherein the one or more attributes comprise a size of the individual human-residing cell.

13. The method according to claim 8, wherein,

the plurality of individual living units includes a first individual living unit and a second individual living unit,

the first individual living unit being of a first type, the second individual living unit being of a second type different from the first type,

the one or more values represent a first category representing a first type for a first individual living unit and a second category representing a second type for a second individual living unit.

14. The method of claim 8, further comprising: after receiving the second input, for each individual living unit of the subset of the plurality of individual living units,

receiving visual information showing possible scenery from windows of the respective human-residing units; and

and storing data associating the visual information with the individual living units.

15. The method of claim 14, wherein the visual information is received from a third party in response to a request for visual information, wherein the request comprises a plurality of geographic coordinates.

16. The method of claim 15, further comprising:

an elevation of a particular individual dwelling unit is determined, wherein the request includes the elevation.

17. The method of claim 14, wherein receiving visual information comprises receiving, for a particular individual living unit of the plurality of individual living units, a plurality of items of visual information each showing a different possible landscape from a window of the particular individual living unit.

18. The method of claim 8, further comprising: after receiving the second input, receiving an image showing an actual view from a window of a particular individual living unit of the plurality of individual living units; and

data associating the image with a particular individual living unit is stored.

19. The method of claim 8, further comprising: after the second image is generated, a fourth input is received to rotate and scale the second image.

20. The method of claim 8 wherein the plurality of individual habitable units includes a first subset managed by a first organization and a second subset managed by a second organization different from the first organization.

21. The method of claim 8, wherein the plurality of living units are hotel rooms.

22. A method, comprising:

receiving a search query relating to one or more search criteria;

in response to receiving the one or more search criteria, analyzing hotel room data containing information about the plurality of hotel rooms to determine whether attributes of a subset of the plurality of hotel rooms satisfy the one or more search criteria; and

in response to determining that an attribute of a subset of the plurality of hotel rooms satisfies one or more search criteria, causing display of information about each hotel room in the subset, wherein the information includes identification data that uniquely identifies each hotel room in the subset relative to each other hotel room in the subset,

wherein the method is performed by one or more computing devices.

23. The method of claim 22, wherein the information comprises, for each hotel room in the subset, an image of a landscape from a window of the each hotel room.

24. The method of claim 23, wherein the image is a computer-rendered image generated by a third party based on geographic coordinates provided to the third party.

25. The method of claim 22 wherein the plurality of individual habitable units include a first subset managed by a first organization and a second subset managed by a second organization different from the first organization.

26. The method of claim 22, wherein the one or more search criteria comprise an indication of one or more floors, a size of a hotel room, a price per unit area, a category of the hotel room, whether the hotel room is connected to another living unit, whether smoking is allowed, accessibility of a disabled person, distance to an elevator, distance to a lobby, distance to a swimming pool, distance to a stairway, distance to a vending machine.

27. The method of claim 22, wherein at least a search criterion of the one or more search criteria is not specified in the search query.

28. The method according to claim 22, wherein,

each hotel room of the plurality of hotel rooms is associated with a plurality of characteristics;

a plurality of living units whose subset includes a plurality of hotel rooms;

for each hotel room of the subset, analyzing the hotel room data comprises:

determining a plurality of normalized values based on a plurality of characteristics of the hotel rooms, wherein each characteristic of the plurality of characteristics is associated with a different value of the plurality of normalized values,

applying a first weight to a first value of the plurality of normalized values to produce a first weighted value,

applying a second weight to a second value of the plurality of normalized values to generate a second weighted value, wherein the second value is different from the first value,

generating a ranking score based on the first weighting value and the second weighting value, an

Associating a ranking score with each living unit;

causing information to be displayed regarding each hotel room in the subset includes causing information to be displayed regarding each hotel room in an order based on a ranking score associated with the each hotel room.

29. The method of claim 28, wherein the plurality of characteristics includes two or more of:

the size of the respective hotel room; the floor of the building where the corresponding hotel room is located; the distance from the respective hotel room to the elevator; the category to which the corresponding hotel room belongs; whether smoking is allowed in the respective hotel room; whether the corresponding hotel room borders another hotel room; whether the corresponding hotel room has a balcony; whether the corresponding hotel room is easily reachable by disabled persons; the distance from the respective hotel room to the stairway; a distance from the respective hotel room to a hotel lobby, a distance from the respective hotel room to a swimming pool, a distance from the respective hotel room to a vending machine; a distance from the respective hotel room to the housekeeping service; distance from the respective hotel room to the nightclub; or the distance from the respective hotel room to the noise source.

30. The method of claim 28, wherein applying the first weight to the first value and the second weight to the second value comprises determining the first weight and the second weight from one or more search criteria.

31. The method of claim 22, further comprising limiting hotel rooms in the subset to hotel rooms indicated in the one or more search criteria that are known to be available on one or more dates.

32. The method according to claim 22, wherein,

causing display of information about each hotel room in the subset includes causing display of reservation information; and

the reservation information contains instructions on how to reserve one or more hotel rooms in the subset for the user.

33. The method of claim 22, further comprising: generating hotel room data prior to receiving the search query, wherein generating hotel room data comprises:

displaying a base image of a geographic area in which a plurality of hotel rooms are located;

receiving input indicative of boundaries of units of a plurality of hotel rooms;

receiving a mapping between a point on a base image and a plurality of spatial coordinates;

based on the input and the mapping, a set of spatial coordinates for units of the plurality of hotel rooms is determined.

34. One or more non-transitory storage media storing instructions which, when executed by one or more processors, cause performance of a method recited in any one of claims 1-33.