RU2748177C1 - Method and system for generating notifications about ticket offers - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: invention relates to a method for generating notifications about the appearance of ticket offers. The method for generating notifications about the appearance of ticket offers is performed by at least one computing device and contains the following steps: the server receives from at least one user his or her data and the parameters of at least one ticket offer that he or she requires; at least one data structure is formed in the server data store, the fields of which correspond to the parameters of the required at least one ticket offer for the user received in the previous step; all previously formed data structures are unloaded from the data storage at a predetermined frequency; a request is sent to at least one ticket booking gateway to search for offers based on the data structures obtained in the previous step; a response is received from at least one ticket booking gateway, and if the response from the gateway contains ticket offers that satisfy the values of the fields of at least one data structure, a notification about the appearance of a ticket offer is sent to the user using his contact information from this data structure.

EFFECT: provision of automatic notification of the user about the appearance of ticket offers.

13 cl, 5 dwg

Description

FIELD OF TECHNOLOGY

[001] This technical solution, in General, relates to the field of computing, and in particular, to methods and systems for generating notifications about the appearance of ticket offers.

LEVEL OF TECHNOLOGY

[002] Nowadays, it is common to buy tickets for, for example, rail or airplane tickets, often causing stress for users. As soon as tickets go on sale, tickets are immediately redeemed by various intermediaries or other users and disappear. Any particular person who wants to purchase a ticket on holidays or other dates when users often travel by public transport often have a small chance of getting the tickets they want. If the task becomes more complicated and, for example, it is necessary to buy more than two tickets at a certain place, for a specific date, in a certain class of service, the user often has difficulties with the order.

[003] Prior art patent application JP2005018369A "Seat reservation system for train, seat reservation server, program, and seat reservation method for train" (Applicant: Nec Corp, publication date: 20.01.2005). The present invention relates to a system for booking seats on a train, a server for booking seats, a program and a method for booking seats on a train. In particular, the user can indicate various requests for a designated place, and the system searches for the most comfortable place for him upon request. In this solution, the station window terminal 3 and the travel agency terminal 4 request input of seat conditions and priority, including train designation, vehicle location classification, vehicle position classification, and user contact information for transmission to the seat reservation server and reservation instruction means for display the received information about the free space. The seat reservation server uses the received data and conditions and develops conditions until a seat is found. In this solution, there is a means for initially setting the distribution condition and canceling the prediction of the reservation rate if it exceeds a predetermined value.

[004] The disadvantage of this technical solution is that the system needs a database with all available places for sale. In the claimed solution, the system can work with any provider of data on available seats, both with those that allow you to get all available seats at once in all directions and for all dates, and with those that give the availability of seats for a specific flight on a specific date. ...

[005] An additional disadvantage of the solution is that the system does not allow using this system from any client device (browser, mobile device, etc.), but only from a physical terminal.

[006] In the claimed solution, the system allows you to receive notifications for the appearance of places and thus buy them in any system that the user likes. In the JP2005018369A application system, the client is tied to the system through which he searches for the necessary places for himself.

SUMMARY OF THE INVENTION

[007] The technical problem or the technical problem solved in this technical solution is the implementation of the method and system for generating notifications about the appearance of ticket offers.

[008] The technical result achieved by solving the above technical problem is to increase the likelihood of the user receiving a ticket offer.

[009] An additional technical result is to improve the reliability of generating notifications about the appearance of ticket offers.

[0010] The specified technical result is achieved by implementing a method for generating notifications about the appearance of ticket offers, which is performed by at least one computing device and in which his data and parameters of at least one offer required for him are received on the server from at least one user ticket; form in the data storage of the server at least one data structure, the fields of which correspond to the parameters of the required at least one ticket offer for the user obtained in the previous step; all previously formed data structures are unloaded from the data storage at a predetermined frequency; sending a request to at least one ticket booking gateway to search for offers based on the data structures obtained in the previous step; receive a response from at least one ticket booking gateway, and if the response from the gateway contains ticket offers that satisfy the values of the fields of at least one data structure, send a notification about the appearance of the ticket offer to the user using his contact information from this data structure.

[0011] In some embodiments of the technical solution, user data includes an email address and / or telephone number and / or name and / or nickname.

[0012] In some embodiments of the technical solution, the parameters of the ticket offer include a departure date or date range and / or class of service and / or number of seats required.

[0013] In some embodiments of the technical solution, the user's data and parameters of the required ticket offer are obtained from a website or a mobile communication device.

[0014] In some implementations of the technical solution, the server data store is persistent and / or non-persistent.

[0015] In some embodiments of the technical solution, the non-persistent store is located in the RAM of the computing device.

[0016] In some embodiments of the technical solution, memcache is used as the persistent storage of MariaDB, rather than the persistent storage.

[0017] In some embodiments of the technical solution, the data structure, the fields of which correspond to the parameters of the required ticket offer for the user, is a row of a database table.

[0018] In some embodiments of the technical solution, the data structure, the fields of which correspond to the parameters of the required ticket offer for the user, further includes a status, next check date, priority.

[0019] In some embodiments of the technical solution, the data structures generated in the data store of the server are combined into groups.

[0020] In some embodiments of the technical solution, the data structures are combined into groups if the fields coincide with the point of departure and arrival, and / or the date of departure, and / or the class of service and the number of passengers.

[0021] In some implementations of the technical solution, the request to the ticket booking gateway to search for offers is an HTTP request (or HTTPS) to the gateway API.

[0022] In some implementations of the technical solution, the response from the ticket booking gateway comes in XML or JSON format.

BRIEF DESCRIPTION OF DRAWINGS

[0023] The features and advantages of the present technical solution will become apparent from the following detailed description and the accompanying drawings, in which:

[0024] FIG. 1 shows an example of the implementation of the method for generating notifications about the appearance of ticket offers, shown in the form of a block diagram.

[0025] FIG. 2 shows an implementation option for a user to form a request for a ticket, send it to the server, and store it in a persistent and non-persistent data store.

[0026] FIG. 3 shows an embodiment of generating a data structure in the server data store, the fields of which correspond to the parameters of the required ticket offer for the user.

[0027] FIG. 4 shows an embodiment of a system for generating notifications about the appearance of ticket offers.

[0028] FIG. 5 shows an embodiment of sending a request to a ticket booking gateway to search for offers based on data structures unloaded from the storage and grouped.

DETAILED DESCRIPTION OF THE INVENTION

[0029] Below will be discussed in detail the terms and their definitions used in the description of the technical solution.

[0030] In this invention, a system means a computer system, a computer (electronic computer), CNC (numerical control), PLC (programmable logic controller), computerized control systems and any other devices capable of performing a given, well-defined sequence of operations. (actions, instructions), centralized and distributed databases, smart contracts.

[0031] An instruction processing device means an electronic unit or an integrated circuit (microprocessor) executing machine instructions (programs), a smart contract, an Ethereum virtual machine (EVM), or the like. A command processor reads and executes machine instructions (programs) from one or more storage devices. The role of data storage devices can be, but are not limited to, hard disks (HDD), flash memory, ROM (read only memory), solid state drives (SSD), optical drives.

[0032] A program is a sequence of instructions for execution by a computer control device or command processing device.

[0033] A method 100 for generating notifications of the appearance of ticket offers, shown in block diagram form in FIG. 1 and below through a series of computational steps.

[0034] Step 110: receive on the server from at least one user his data and parameters of the required for him at least one offer of a ticket.

[0035] The functionality of this technical solution allows the user 200 to subscribe to receive notifications when tickets are on sale, as shown in FIG. 2. To do this, the user leaves his contact information (for example, an email address or phone number, or a nickname or ID in the messenger, etc., not limited to) and subscribes to the transport he needs (for example, railway or air) or a whole direction , and also selects a specific date or range of dates, class of service, number of seats required and other necessary requirements for seats for the trip. The user leaves his data on the user's website or mobile application, and also selects the notification parameters (for which train, date, etc. he wants to receive a ticket). After he clicks on the "subscribe" button (this implementation is exemplary, which is obvious), the parameters of the request 210 he has generated for notifications of emerging ticket offers are sent to the server 220 (for example, in an exemplary implementation this may be an AJAX request from a web browser). In some implementations, this can be any communication device capable of transmitting data to the server 220. For example, it can be a mobile application installed on the user's phone. It can also be terminals for travel by bus, which are installed at train stations. Server 220 receives requests 210 with notification parameters on its side. Based on these query parameters 210, a record is created in persistent storage 230 (for example, in a database), which is a row of a database table (for example, in a MySQL database) as well as an entry in a non-persistent storage 240 (for example, in a database located in the operational memory, without writing to disk), because fetching from it will be faster than from persistent store 230, after which processing is finished. Non-persistent storage 240 resides in the RAM of the computing device, so if server 220 is turned off and on, all data is lost. However, accessing data in RAM is faster than in the case of a regular persistent database such as MySQL. Two data stores are used in a particular implementation so that if the non-persistent store 240 is zeroed (i.e., the data is lost), it is possible to load data from the persistent store 330. The non-persistent store 240 in a particular implementation uses memcache, and the persistent store 230 is MariaDB. After the appearance of places that are tracked according to the algorithm below, the user 200 is notified of the opportunity to buy tickets through the contact information left earlier on any data transmission channel, as shown in FIG. 2.

[0036] The user through the graphical user interface is given the opportunity to issue an application for notification of the appearance of ticket offers for the previously selected transport on sale. To do this, the user, through the graphical interface, selects the parameters of the application from the drop-down list or enters himself. The parameters of the application can be, but are not limited to, the mode of transport of interest, date of departure or date range of direction, point of departure, point of arrival, number of tickets or number of passengers, class of service (can be presented as "economy / economy + / business" or for railway transport in Russia as "seated / reserved seat / shared / compartment, luxury / sleeping car"), flight number is optional, contact information for notification: SMS / e-mail or other types.

[0037] After that, the user through the interface confirms his agreement with the provided application parameters and these parameters are sent to the server via the Internet communication channel via the HTTP or HTTPS data transfer protocol. Other protocols from the TCP / IP protocol stack may be used without being limited to HTTP.

[0038] Step 120: at least one data structure is generated in the server data store, the fields of which correspond to the parameters of the required at least one ticket offer for the user obtained in the previous step.

[0039] After receiving the parameters of the application on the server 220, a structure 310 is created in the data store, the fields of which correspond to the parameters of the application, as shown in FIG. 3. After that, the parameters of the request 210 are automatically entered into this structure 310 (a class object in programming). Also in this structure 310 there are additional fields that do not correspond in any way with the notification parameters received from the user, but are filled on the server side 220. These additional the fields of structure 310 may include the status of the application (created, verified, completed, canceled), next verification date, priority. In some implementations, the priority may depend on the strategy for searching for ticket offers. For example, trains will leave soon or this is the beginning of sales, so it is better to process them first.

[0040] The field "application status" is initially set to the value "created" - this means that the application has just been created and nothing has happened to it. The status "verified" means that at least one attempt was made to "verify" the application (more on this below). "Completed" means that a notification has been triggered for the user and nothing else needs to be done with this request. "Canceled" - for some reason this application was canceled, for example, at the request of the user himself or if they could not find offers for tickets upon request (for example, the train had already left).

[0041] The "next check date" field means what date and time the application will be "checked", as detailed below. To fill this date, the closest date is selected from as many dates as the next poll date selection strategies are used. Strategies are algorithms that, based on input parameters, output the date and time of the ticket offer. Below, as an example of implementation, there are strategies for searching for ticket offers for railway transport.

[0042] In the first embodiment, a set is obtained from the number of hours before departure (this set may differ for different directions, ticket booking systems, type of transport, but in a specific implementation example for railway transport, this set is as follows: "24 hours before departure", "in 6 hours", "in 4", "in 2", "in 0 hours"). Using this set, a set of dates with time is compiled by subtracting from the date and time of departure of the train the number of hours from the set with added, for example, five minutes (this is the time for issuing a ticket on the site). In fact, this should be the average time it takes for a user to issue a ticket on the website or in a mobile application. This time is chosen empirically. This set of dates is further filtered by removing all dates that have already occurred. Filtering can be implemented as follows. For example, at the moment the time is 19:00, and the train leaves tomorrow at 18:00. If you take the time "24 hours before departure", you get the date "today at 18:00". But it has already arrived, because it is now 19:00. Therefore, this date is removed from the sample and proposals are considered further. For example, take for "6 hours", etc. As a result, only those dates will remain that have not yet arrived. From the remaining dates, the closest to the current date and time is selected. For example, the set of dates remained as follows: "today at 21:00", "today at 23:00". And now it is 19:00. The closest date means "today at 21:00".

[0043] In the second embodiment, a scenario similar to the first is used, but uses not the departure date, but the arrival date of the train. For example, the train must arrive at the station on 03/21/2020 at 15:00. The following set of dates is selected: "24 hours in advance", "6 hours before", etc. Then they subtract and get the dates: "03/20/2020 at 15:00", "03/21/2020 at 9:00", "03/21/2020 at 11:00", etc. Further, only the actual ones are left, suppose that everything. Since today, for example, is 18.03, then the nearest date is taken, i.e. "03/20/2020 at 15:00".

[0044] In another embodiment, a set of dates (date + time) is generated by subtracting the following segments from the departure date and time: "40 days" "35 days" "25 days" "20 days" "15 days" "10 days" "7 days" "5 days" "3 days". Further, from the obtained set of dates with time, only those that have not yet come are left and then the nearest date with time is taken from them

[0045] In yet another implementation, a set of dates with time is returned based on the date and time of opening sales for a particular direction. Thus, the date and time of opening sales for a specific direction are taken. Further, by adding to this date with time 5, 10, 15, 25, 45, 105 and 145 minutes, we get a set of 7 dates with time, of which we leave only those that have not yet come and from them we take the closest date with time.

[0046] The Priority field specifies the priority for the bid, i. E. how much more priority this application is than another. By default, we set the "normal" priority.

[0047] After filling the structure 310, store it in two stores, persistent 230 and non-persistent 240, since the latter is much faster. Persistent store 230 is only used to populate non-persistent 240 in a situation where the latter was reset as a result of clearing RAM, for example, in a server 220 reboot situation or in abnormal situations.

[0048] The following describes in detail the process of checking the application by the system in the booking gateway.

[0049] Step 130: all previously generated data structures are unloaded from the data store at a predetermined frequency.

[0050] Server 220 runs a daemon process 500 (ie, a computer program on UNIX-class systems that is launched by the system itself and runs in the background without direct user interaction) as shown in FIG. 5, which, for example, every minute or several seconds, but not limited to, unloads from non-persistent storage 240 (because it is much faster than persistent) all previously saved structures 310, which have the content of the "next check date" field less than the current date and time, those. it's time to check. In some embodiments, the daemon process 500 may be disabled during non-running hours of the booking gateway 530 if known in advance. For example, it is known that gateways 530 do not work from 3 to 4 am and there is no point in interrogating them. These structures are formed into groups (510, 520, etc.) as shown in FIG. 5. In order for the structures to be in the same group, they must have the same fields with the point of departure and arrival (overlap), as well as the dates of departure, class of service and the number of passengers must intersect. In other implementations, grouping options are possible that will reduce the number of requests to gateways 530 and process similar requests at once.

[0051] Step 140: a request is sent to at least one ticket reservation gateway to search for offers based on the data structures obtained in the previous step.

[0052] Thereafter, for each group, a request is made by the server 220 to the ticket reservation gateway 530. To do this, based on the value of the field "point of departure", the value of the field "point of arrival", "date of departure", number of passengers, class of service and optionally the flight number, a request is generated in the API gateway 530, which is an HTTP request (or HTTPS) 530 tickets in the booking gateway API.

[0053] The booking gateway 530 tickets is a third-party system that provides information via an API about current ticket offers for direction and date. The grouping of structures 310 previously made can reduce the number of requests to the gateway 530 and make one request per group, instead of a separate request for each structure. For example, one user ordered notifications for the Moscow-St. Petersburg direction for tomorrow - any class of service, 1 passenger, and the second user also ordered Moscow-St. Petersburg for tomorrow, but for a specific train 056A - any class of service. In the group, respectively, there will be both of these requests, since their dates and directions, as well as the class of service, intersect.

[0054] Step 150: receive a response from at least one ticket reservation gateway.

[0055] If the response from the gateway 530 contains ticket offers that match the field values of at least one data structure 310, notify the user of the ticket offer appearance by his contact information from this data structure.

[0056] Since the grouping was made by actually matching request parameters, therefore, the response from the ticket booking gateway simultaneously matches each data structure within the group (for example, in XML or JSON format).

[0057] Next, the daemon process matches the response from the gateway to all structures within the group. The fields of the application from the structure (for example, direction, number of passengers, flight, etc.) are compared with the answer whether there is such a ticket there or not. If the response from the gateway contains ticket offers that satisfy the values of the fields of a specific structure from the group (that is, the departure date, arrival date, point of departure and arrival, class of service and optionally a flight are the same), then the structure is given the status "Completed", after whereupon it is saved back to two storages. Next, the client's contact information is taken from the same structure and the client is notified via the appropriate communication channels. Those structures for which none of the offers from the response from the gateway came up are assigned the "verified" status, and the value of the "next verification date" field is filled in anew according to the previously described algorithm. After that, these structures are also saved back to two storages.

[0058] Referring to FIG. 4, this technical solution can be implemented as a computing system 400 for generating notifications about the appearance of ticket offers, which contains one or more of the following components:

- a processing component 401 comprising at least one processor 402,

- memory 403,

- component 405 multimedia,

- component 406 audio,

- interface 407 input / output (I / O),

- sensory component 408,

a data transfer component 409.

[0059] The processing component 401 generally controls all of the operations of the system 400, such as processing data about the user or their ticket search request, and also controls the display, phone call, data communication, camera operation, and recording operation of the mobile communication device. The processing component 401 may include one or more processors 402 that implement instructions to complete all or part of the steps from the above methods. In addition, the processing component 401 may include one or more modules for convenient communication between other processing modules 401 and other modules. For example, the processing component 401 may include a media module for convenient, lightweight interaction between the media component 405 and the processing component 401.

[0060] Memory 403 is configured to store various types of data to support the operation of system 400, such as a user profile database. Examples of such data include instructions from any application or method, contact information, address book data, messages, images, videos, etc., all of which operate on system 400. Memory 403 can be implemented as any type of volatile storage device, nonvolatile memory, or a combination thereof, such as static random access memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (EPROM), Read Only Memory device (ROM), magnetic memory, flash memory, magnetic disk or optical disk and others, but not limited to.

[0061] The multimedia component 405 includes a screen providing an output interface between a system 400 that may be installed on a user's mobile communications device and a user. In some implementations, the screen may be a liquid crystal display (LCD) or a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen for receiving input from a user. The touchpad includes one or more touch sensors in terms of gestures, touching, and sliding across the touchpad. The touch sensor can not only sense the subject's touch boundary or swipe gesture, but also detect the length of time and pressure associated with touch and slide behavior. In some embodiments, the media component 405 includes one front camera and / or one rear camera. When the system 400 is in a mode of operation, such as shooting mode or video mode, the front camera and / or the rear camera can receive media data from the outside. Each front camera and rear camera can be one fixed lens optical system or can have focal length or optical zoom.

[0062] The audio component 406 is configured to output and / or input an audio signal. For example, the audio component 406 includes a single microphone (MIC) that is configured to receive an external audio signal when the system 400 is in a mode of operation, such as a call mode, a recording mode, and a speech recognition mode. The resulting audio signal can be further stored in memory 403 or routed to data transfer component 409. In some embodiments, the audio component 406 also includes one speaker configured to output an audio signal.

[0063] An input / output (I / O) interface 407 provides an interface between the processing component 401 and any peripheral interface module. The above peripheral interface module can be keyboard, steering wheel, button, etc. These buttons may include, but are not limited to, a start button, a volume button, a start button, and a lock button.

[0064] The sensor component 408 comprises one or more sensors and is configured to provide various aspects of assessing the state of the system 400. For example, the sensor component 408 can detect on / off states of the system 400, the relative position of components, such as a display and a keypad, of a single component. system 400, presence or absence of contact between a subject and system 400, and orientation or acceleration / deceleration and temperature change of system 400. Sensor component 408 comprises a proximity sensor configured to detect the presence of an object in the vicinity when there is no physical contact. Touch component 408 includes an optical sensor (eg, CMOS or CCD image sensor) configured for use in rendering an application. In some embodiments, sensor component 408 includes an acceleration sensor, gyroscope sensor, magnetic sensor, pressure sensor, or temperature sensor.

[0065] The communication component 409 is configured to facilitate wired or wireless communication between the system 400 and other devices. System 400 can access a wireless network based on a communication standard such as WiFi, 2G, 3G, 5G, or a combination of these. In one exemplary embodiment, communication component 409 receives a broadcast signal or broadcast associated information from an external broadcast control system via a broadcast channel. In one embodiment, communication component 409 comprises a Near Field Communication (NFC) module to facilitate near field communication. For example, the NFC module may be based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0066] In an exemplary embodiment, system 400 may be implemented by one or more Application-Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Units (DSPs), Programmable Logic Devices (PLCs), a logic chip programmed into operating conditions (FPGA), controller, microcontroller, microprocessor, or other electronic components, and can be configured to implement the method 500 for generating notifications about the appearance of ticket offers.

[0067] In an exemplary embodiment, the non-volatile computer-readable medium comprises memory 403 that includes instructions where instructions are executed by processor 401 of system 400 to implement the above-described smart flight search methods. For example, non-volatile computer-readable media can be ROM, random access memory (RAM), compact disc, magnetic tape, floppy disks, optical storage devices, and the like.

[0068] Computing system 400 may include a display interface that transmits graphics, text, and other data from a communications infrastructure (or from a framebuffer, not shown) for display on a media component 405. Computing system 400 further includes input devices or peripherals. Peripheral devices may include one or more devices for interacting with a user's mobile communications device, such as a keyboard, microphone, wearable device, camera, one or more audio speakers, and other sensors. Peripheral devices can be external or internal to the user's mobile communications device. A touchscreen can display, typically graphics and text, and also provides a user interface (such as, but not limited to, a graphical user interface (GUI)) through which a subject can interact with a user's mobile communication device, such as access and interact with applications running on the device.

[0069] The elements of the proposed technical solution are in a functional relationship, and their joint use leads to the creation of a new and unique technical solution. Thus, all blocks are functionally linked.

[0070] All blocks used in the system can be implemented with electronic components used to create digital integrated circuits, which is obvious to a person skilled in the art. Not limited to, microcircuits can be used, the logic of which is determined during manufacture, or programmable logic integrated circuits (FPGA), the logic of which is set through programming. For programming, programmers and debugging environments are used that allow you to set the desired structure of a digital device in the form of a circuit diagram or a program in special hardware description languages: Verilog, VHDL, AHDL, etc. An alternative to FPGAs can be programmable logic controllers (PLCs), basic matrix crystals ( BMK) requiring a factory production process for programming; ASICs are specialized custom large integrated circuits (LSIs), which are significantly more expensive for small-scale and single-piece production.

[0071] Typically, the FPGA itself consists of the following components:

- configurable logic blocks that implement the required logic function;

- programmable electronic links between configurable logic blocks;

- programmable input / output blocks providing communication of the external output of the microcircuit with the internal logic.

[0072] Blocks can also be implemented using read-only memory devices.

[0073] Thus, the implementation of all the blocks used is achieved by standard means based on the classical principles of the implementation of the foundations of computing.

[0074] As will be understood by a person skilled in the art, aspects of the present technical solution may be implemented as a system, method, or computer program product. Accordingly, various aspects of the present technical solution may be implemented solely as hardware, as software (including application software, and so on), or as an embodiment combining software and hardware aspects, which may generally be referred to as a "module" , "System" or "architecture". In addition, aspects of the present technical solution may take the form of a computer program product implemented on one or more computer-readable media having computer-readable program code that is implemented thereon.

[0075] Any combination of one or more computer readable media can also be used. The computer-readable storage medium can be, without limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or any suitable combination thereof. More specifically, examples (non-exhaustive list) of computer-readable storage media include: electrical connection using one or more wires, portable computer diskette; hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), fiber optic connection, compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any combination of the above. As used herein, a computer-readable storage medium can be any flexible storage medium that can contain or store a program for use by the system itself, device, apparatus, or in connection therewith.

[0076] Program code embedded in a computer-readable medium can be transmitted using any medium, including, without limitation, wireless, wired, fiber optic, infrared, and any other suitable network or combination of the above.

[0077] Computer program code for performing operations for the steps of this technical solution may be written in any programming language or combinations of programming languages, including an object-oriented programming language such as Python, R, Java, Smalltalk, C ++, and so on, and conventional procedural programming languages such as "C" programming language or similar programming languages. The program code can be executed on the user's computer in whole, in part, or as a separate software package, partially on the user's computer and partially on the remote computer, or completely on the remote computer. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN), a wide area network (WAN), or a connection to an external computer (for example, via the Internet using Internet service providers).

[0078] Aspects of the present technical solution have been described in detail with reference to block diagrams, schematic diagrams, and / or diagrams of methods, devices (systems), and computer program products in accordance with embodiments of the present technical solution. It will be appreciated that each block from the block diagram and / or diagrams, as well as combinations of blocks from the block diagram and / or diagrams, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other data processing device to create a procedure, such that instructions executed by a computer processor or other programmable data processing device create means to implement the functions / actions specified in block or blocks of flowchart and / or diagram.

[0079] These computer program instructions may also be stored on a computer-readable medium that can control a computer other than a programmable data processing device or devices that function in a particular way, such that the instructions stored on the computer-readable medium create a device including instructions that perform the functions / actions specified in the block diagram and / or diagram.

Claims (19)

1. A method of generating notifications about the appearance of ticket offers, performed by at least one computing device, and includes the following steps: - receive on the server from at least one user his data and parameters of the required for him at least one ticket offer; - at least one data structure is formed in the server data storage, the fields of which correspond to the parameters of the required at least one ticket offer for the user obtained in the previous step, and the application parameters are automatically entered into this structure; - all previously formed data structures are unloaded from the data storage with a predetermined frequency by means of a daemon process, in which the content of the "next check date" field is less than the current date and time; - sending a request to at least one program interface of the ticket booking gateway application to search for offers based on the data structures obtained in the previous step; - receive a response from at least one ticket booking gateway, and - if the response from the gateway contains ticket offers that satisfy the values of the fields of at least one data structure, send a notification about the appearance of a ticket offer to the user using his contact information from this data structure. 2. The method according to claim 1, characterized in that the user data includes an e-mail address and / or telephone number and / or name and / or nickname. 3. A method according to claim 1, characterized in that the parameters of the ticket offer include the departure date or date range and / or class of service and / or the number of seats required. 4. The method according to claim 1, characterized in that the user's data and parameters of the ticket offer required for him are obtained from a website or a mobile communication device. 5. The method according to claim 1, characterized in that the server data store is persistent and / or non-persistent. 6. The method according to claim 5, characterized in that the non-persistent storage is located in the RAM of the computing device. 7. The method according to claim 5, characterized in that memcache is used as a non-persistent storage, and MariaDB is used as a persistent storage. 8. The method according to claim 5, characterized in that the data structure, the fields of which correspond to the parameters of the required ticket offer for the user, is a row in the database table. 9. The method according to claim 1, characterized in that the data structure, the fields of which correspond to the parameters of the required ticket offer for the user, additionally includes a status, the next check date, and a priority. 10. The method according to claim 1, characterized in that the data structures generated in the server data store are combined into groups. 11. The method according to claim 10, characterized in that the data structures are combined into groups if the fields coincide with the point of departure and arrival, and / or the date of departure, and / or the class of service and the number of passengers. 12. The method according to claim 1, characterized in that the request to the ticket booking gateway to search for offers is an HTTP request and / or HTTPS request to the gateway API. 13. The method according to claim 1, characterized in that the response from the ticket booking gateway comes in XML or JSON format.

Images