Hotel Room Availability Search Engine

Palivatkel; Yossi

Patent Application Summary

U.S. patent application number 13/731026 was filed with the patent office on 2014-07-03 for hotel room availability search engine. This patent application is currently assigned to Travel Holdings, Inc.. The applicant listed for this patent is Yossi Palivatkel. Invention is credited to Yossi Palivatkel.

Application Number20140188832 13/731026
Document ID /
Family ID48446106
Filed Date2014-07-03

United States Patent Application 20140188832
Kind Code A1
Palivatkel; Yossi July 3, 2014

HOTEL ROOM AVAILABILITY SEARCH ENGINE

Abstract

A search engine-based system to provide results substantially instantaneously on behalf of a user/customer or a searching enterprise, in response to entering search parameters. The system includes a database and an in memory synchronized database (IMSDB), wherein the search engine is enabled to serve the private user/customers or searching enterprise. The system also includes a notification system to maintain the IMSDB, wherein every change that occurs on the backend system either by a private user/customer, an employee of a searching enterprise or by one of its suppliers, is propagated to the search engine quickly and a presentation layer, wherein the system looks for changes in user/customer search parameters from those initially entered, and immediately performs a new search query, such that the user/customer or searching enterprise is presented with initial results or modified results substantially instantly, once a `Search Now` button is clicked.


Inventors: Palivatkel; Yossi; (Ashdod, IL)
Applicant:
Name City State Country Type

Palivatkel; Yossi

Ashdod

IL
Assignee: Travel Holdings, Inc.
Altamonte Springs
FL

Family ID: 48446106
Appl. No.: 13/731026
Filed: December 30, 2012

Current U.S. Class: 707/706
Current CPC Class: G06F 16/951 20190101; G06Q 50/12 20130101
Class at Publication: 707/706
International Class: G06F 17/30 20060101 G06F017/30

Claims



1. A search engine-based system enabled to provide search results, substantially instantaneously to a user, in response to entering search parameters, said system comprising: a database and/or an in memory synchronized database (IMSDB); a notification system to maintain the IMSDB, wherein every change that occurs on the backend system either by a private user/customer, an employee of the searching enterprise or by one of its suppliers, is propagated to the search engine in less than 5 seconds; and a presentation layer, wherein the system looks for changes in search parameters from those earlier entered, and performs a new search query before the user or searching enterprise issues a search command such that the user or searching enterprise is presented with initial results and modified results immediately after issuing the search command.

2. The system of claim 1, wherein the notification system further comprises an Allegro Machine (application server) comprising at least two sub-machines and an Allegro Network (AN) built around a Notification Coordinator provided and at least one table to manage subscription and data routing on the machine level, wherein one sub-machine can hold multiple applications.

3. The system of claim 2, wherein every change on the at least one table is recorded as an insertion, deletion or update, wherein when both deletion and update occur, the previous state and current state are both recorded, and wherein the notification coordinator checks the recorded change and determines which sub-machines (subscribers) need to be notified, and sends the appropriate data to the subscribers

4. The system of claim 1, wherein the search is to ascertain hotel room availability.

5. The system of claim 4, wherein the search parameters are at least where, when and for how many people and/or how many rooms.

6. The system of claim 1, wherein the IMSDB extends over multiple servers.

7. The system of claim 1, wherein the IMSDB has static information, dynamic information and is scalable.

8. A method for providing search results to a user inputting search parameters that triggers an automatic `search` query by the system of claim 6, the method comprising: receiving search parameters input by a user; performing a search query by the system based on the parameters; pulling the search results and storing them on the user's local browser; receiving notification of modification of the search query by the user/customer; repeating the performing and pulling steps if the user/customer has modified at least one of the `most modified` parameters; and displaying the stored result on the user/customer's browser after clicking of the `Search Now` button by the user/customer.

9. The method of claim 8, further comprising inputting rich user interface (UI) information by or for the user comprising at least photos and video clips, and storing them similarly.

10. The method of claim 8, further comprising synchronizing of notifications in the IMSDB.

11. The method of claim 8, further comprising cancelling the previous operation if still in progress.

12. The method of claim 1, further comprising prioritizing Information according to relevance and forwarded accordingly.

13. The method of claim 12, wherein every server that needs the information is subscribed for the information on a need to know basis, the system knows exactly what information to send to each server and the information goes directly to the relevant subscriber.

14. The method of claim 13, further comprising differentiating by the system of less relevant information from highly relevant information and forwarding the highly relevant information first.
Description



FIELD OF THE INVENTION

[0001] The present invention generally relates to search engines, and more particularly to a synchronized engine that searches for hotel room availability, and is enabled to provide search results that appear substantially instantly.

BACKGROUND OF THE INVENTION

[0002] Web search engines work by storing information about many web pages, which they retrieve from the HTML file itself. These pages are retrieved by a Web crawler or spider, an automated Web utility, which follows every link on a designated site. The contents of each page are then analyzed to determine how they should be indexed, for example, words can be extracted from the titles, page content, headings, or special fields called meta tags. Data about web pages are stored in an index database for use in later queries.

[0003] A query can be a single word. The purpose of an index is to allow information to be found as quickly as possible. Some search engines, such as Google, store all or part of the source page, referred to as a cache, as well as information about the web pages. When a user enters a query into a search engine, the engine examines its index and provides a listing of best-matching web pages according to its criteria, usually with a short summary containing the document's title and sometimes parts of the text. The index is built from the information stored with the data and the method by which the information is indexed. [Wikipedia, http://en.wikipedia.org/wiki/Web_search_engine, visited Dec. 30, 2012.]

[0004] Anyone searching for a hotel needs to specify where, when and how many people and/or rooms. Without answering these three user inputs it is impossible to determine what is available. So after the user types the date, destination, the number of rooms and presses the search button, the search is initiated. In other words, two steps are involved: 1. Performing the search; AND 2. Bringing the results to the user.

[0005] It would be advantageous to develop a system and methodology to provide search results enormously faster.

SUMMARY OF THE INVENTION

[0006] A search engine-based system enabled to provide search results is disclosed. The results are displayed substantially instantaneously to a user (such as a customer or enterprise) in response to entering search parameters. The system includes a database to hold and store the data and/or an in memory synchronized database (IMSDB), wherein the search engine is enabled to serve users of the searching enterprise. The system also includes a notification system to maintain the IMSDB, wherein every change that occurs on the backend system either by a private user/customer, an employee of a searching enterprise or by its suppliers is propagated to the search engine in less than 5 seconds and a presentation layer, wherein the system looks for every change in user/customer search parameters from those initially entered, and immediately performs a new search query, such that the user/customer is presented with initial results and modified results substantially instantly, once he clicks a `Search Now` button. The Search engine of the present invention is built on several layers. [0007] 1. A Database--to store data. In case of power outage the search engine can revert back to the latest state. [0008] 2. In memory synchronized database (IMSDB) is a search engine, serving millions of queries received daily, with an average response time of less than 20 milliseconds. [0009] 3. Notification System to maintain the IMSDB, every change that occurs on the backend system either by an employee or by the suppliers will be propagated to the search engine quickly. [0010] 4. Presentation layer, which looks for every change in user parameters from the originally entered user parameters, and immediately performs a new search query. The user is presented with instant results once he clicks the `Search Now` button. This technology may be used for selling room nights, cruises, and travel vacations, as non-limiti9ng examples.

[0011] A user searching for a hotel needs to specify where, when and how many people to be accommodated and/or rooms he wants. The engine running in the background is thin and efficient, but without answering these user inputs it is impossible to determine what is available. After the user/customer types the date and the destination, and even before he specifies the number of rooms and presses the search button, the search is initiated. So even before he presses the `Search Now` button (or analogous button) the results are ready, but he doesn't see them (they do not show up on the screen) until he presses the `Search Now` button and then the results appear immediately. The technology uses massive parallel processing and a predictive search. The development started by improving the search in traditional ways: minimizing data and eliminating calls to the server.

[0012] The search process involves two steps: 1. Performing the search; AND 2. Bringing the results to the user. The results are waiting within the user's computer and not at the server administering the search. This differs from auto-complete, where the user sees the results before he presses the `Search Now` button. The system is divided into three levels: the database, the sync system and the In-Memory Synchronized DataBase (IMSDB). In-Memory DataBase (IMDB) is prior art. The invention provides synchronization of the IMDB.

[0013] A search into the system can be initiated by users typing in at a Website using their browsers or by systems connecting to a site by sending XML query requests, either by Internet Protocol (IP) or SOAP (simple object access protocol). SOAP is a protocol for exchanging information in a decentralized, distributed environment.

[0014] The user/customer browser communicates with the Web layer of the present invention and the Web layer communicates with the IMSDB, which is very scalable and very robust. It can extend over many servers. Everything is kept in memory and results can be sent in milliseconds. There are many fast test systems in existence, but their problem is their data is aged.

[0015] After a couple of hours the data loses relevance. The search system performs a mirroring. For example, if one of the enterprise users/customers, such as Hot Wire or Price Line books hotel rooms, a notification is created that Hot Wire or Price Line booked the rooms in the particular hotel and that the hotel is left with Y rooms available for sell.

[0016] Databases are not as scalable or as fast as application servers. So the present invention stores the updated information on the application server as well as the data base.

[0017] The IMSDB has static information, dynamic information, is scalable and performs testing. The database is maintained for backup in case the system should go down. The user interface is not as fast as the search itself. So if the user were to click `Search Now,` and only then was the search initiated, it would take time to go to the Internet, to get the results and display them.

[0018] The stored information is URL's for Photo and Video. The present invention uses CDN service to serve media. One CDN is AKAMAI.

[0019] The IMSDB has two subsystems: the data notification subsystem and the server itself. The system can differentiate less relevant information from highly relevant information and forwards the highly relevant information first. Information is prioritized according to relevance and forwarded accordingly. Every server that needs the information is subscribed for the information on a need to know basis. The system knows exactly what information to send to each server. The information goes directly to the relevant subscriber. So the main idea is a smart, efficient rules based information system. Any query is sent to the Application Programming Interfaces (API's). The API's comprise the platform used by a program to access different services on the computer system.

[0020] There has thus been outlined, rather broadly, the more important features of the invention in order that the detailed description thereof that follows hereinafter may be better understood. Additional details and advantages of the invention will be set forth in the detailed description, and in part will be appreciated from the description, or may be learned by practice of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of a non-limiting example only, with reference to the accompanying drawings, in the drawings:

[0022] FIG. 1 is a high level system diagram, constructed according to the principles of the present invention;

[0023] FIG. 2 is a screen shot of the Presentation Layer, constructed according to the principles of the present invention; and

[0024] FIG. 3 is a flow diagram illustrating the Sync Cache Layer, including the notification system of FIG. 1, constructed according to the principles of the present invention.

[0025] All the above and other characteristics and advantages of the invention will be further understood through the following illustrative and non-limitative description of preferred embodiments thereof.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0026] The principles and operation of a method and an apparatus according to the present invention may be better understood with reference to the drawings and the accompanying description, it being understood that these drawings are given for illustrative purposes only and are not meant to be limiting.

[0027] FIG. 1 is a high level system diagram, constructed according to the principles of the present invention. The Search engine of the present invention is built on several layers: [0028] A Database 110 is provided to hold and store the data. In case of a power outage the search engine can revert back to the latest configuration. [0029] The in-memory synchronized database (IMSDB) 130 is a search engine, capable of serving millions of queries received daily, with an average response time of less than 20 milliseconds. The IMSDB may have multiple modules. [0030] A Notification System 120 maintains the IMSDB, providing notification for every change that occurs on the backend system either by an employee or by the suppliers. The notification is forwarded to the search engine in less than 5 seconds. Notification System 120 provides synchronization of IMSDB 130. Back end systems run a company by managing orders, inventory and supply processing. Back end systems operate automatically in the background by collecting input from users or other systems for processing. [0031] The presentation layer 140 is an integral set of software modules, which looks for every change in user/customer 105 parameters from the originally entered user/customer parameters, and immediately performs a new search query even before the user gives the command perceived by him to start the search (for example, by selecting a button labeled "Search Now"). A search into the system can be initiated by a user/customer 105 typing in at the exemplary Website 115 of the embodiment on their browser or by other systems connecting into the system by sending XML query requests, either by Internet Protocol (IP) or SOAP. User/customer 105 is presented with instant results on presentation layer 140 once he clicks the `Search Now` button 141.

[0032] FIG. 2 is a screen shot of the Presentation Layer, constructed according to the principles of the present invention. A user searching for hotel rooms 200 needs to specify where 210, when 221, 222 and how many people or rooms 231. Optionally, the number of children 233, aside from the number of adults 232 is entered.

[0033] After the user/customer types dates 221, 222 and destination 210, and even before he specifies number of rooms 231 and presses the `Search Now` button 270, the search is initiated in the background. Even before he presses `Search Now` button 270 the results are ready internally to be displayed for him. By performing some data analysis the algorithm learns what parameters are usually modified by users/customers. Whenever the user/customer makes a change to one of these parameters a `search` command is triggered and the resultant data is stored on the user/customer's local machine but not immediately displayed. This enables the display of results to the user/customer instantly upon clicking `Search Now` button 270.

[0034] User/customer entries trigger an automatic `search` query as follows: [0035] 1. private user/customer or enterprise customer enters search parameters; [0036] 2. perform a search query; [0037] 3. the system pulls the search results and stores them on the user/customer's local browser; [0038] 4. If a parameter that is changed is one of the `most modified` parameters, steps 2. and 3. are repeated on every such user/customer changed parameter and the previous operation is canceled, if still in progress, if not the search is repeated proportionately less frequently; and [0039] 5. after the 3 minimal parameters are first entered, whenever the customer clicks the `Search Now` the stored results are displayed.

[0040] FIG. 3 is a flow diagram illustrating the Sync Cache Layer 300, including the notification system of FIG. 1, constructed according to the principles of the present invention. There are two flows: A and B, respectively in the diagram: A1 . . . A3 and B1 . . . B9.

A is the subscription flow 310 B is the data notification flow (synchronization) 320

[0041] Allegro is a combination of two main services: 1. Allegro Machine (AM), which is an application server that includes two sub-machines in an exemplary embodiment: Machine A 321 and Machine B 311; and 2. Allegro Network (AN) built around the Notification Coordinator 322, hereinafter referred to as AN 322. AM 311, 321 manages the subscription and data route on the machine level, such that one machine can hold multiple applications. AN 322 does the same for the entire network, for all AM's 311, 321, in this exemplary embodiment.

The flows:

A

[0042] Every application, e.g., Application IV of subscriber type Z 312, starts declaring itself 313 to Allegro Machine (AM) 311, 321; the declaration includes the exact database tables 323, 324 and exact columns on each table that the application wants to subscribe to, i.e., the subscription for changes A1 313. Allegro Network (AN) 322 receives this request and checks if exact request has already been made by another application on the same machine 314. If so nothing happens; if this is the first subscription for the type, AM forwards it 316 to AN 322 (A2)

[0043] AN 322 receives this subscription and store it on its local memory and configuration database storage 340, in order to survive a power outage (A3). Microsoft message queuing (MSMQ) processors 315, 325 are digital signature generators based on a hash of the following message properties: [0044] correlation identifier; [0045] application-specific information; [0046] message body; [0047] message label; [0048] response queue; and [0049] administration queue.

B

[0050] Every change on a table 323, 324, 326 is recorded: Insertion, deletion 328 and update 327. When both deletion 328 and update 327 occur, the previous state and current state are both recorded 329a, 329b (B1-B4). AN 322 checks the recorded change 330 and determines which subscribers (machines) need to be notified, and sends the appropriate data to the subscribers 331.

[0051] For example Sub1 subscribed for Table T on columns C1 and C3; Sub2 subscribed for table T on columns C1 and C4; a change on column C1 will go to both Sub1 and Sub2, a change on column C3 will go only to Sub1, a change on column C4 will go only to Sub2, a change on column C2 will not be sent (B4-B6). AM 321 receives this change message 332 and does the same operation as AN 322 does between the applications on AN machine 321 (B7-B9)

[0052] Having described the present invention with regard to certain specific embodiments thereof, it is to be understood that the description is not meant as a limitation, since further modifications will now suggest themselves to those skilled in the art, and it is intended to cover such modifications as fall within the scope of the appended claims.

* * * * *

References


uspto.report is an independent third-party trademark research tool that is not affiliated, endorsed, or sponsored by the United States Patent and Trademark Office (USPTO) or any other governmental organization. The information provided by uspto.report is based on publicly available data at the time of writing and is intended for informational purposes only.

While we strive to provide accurate and up-to-date information, we do not guarantee the accuracy, completeness, reliability, or suitability of the information displayed on this site. The use of this site is at your own risk. Any reliance you place on such information is therefore strictly at your own risk.

All official trademark data, including owner information, should be verified by visiting the official USPTO website at www.uspto.gov. This site is not intended to replace professional legal advice and should not be used as a substitute for consulting with a legal professional who is knowledgeable about trademark law.

© 2024 USPTO.report | Privacy Policy | Resources | RSS Feed of Trademarks | Trademark Filings Twitter Feed