RU2790036C2 - Hardware and software complex for searching for fellow travellers - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: invention relates to the field of information processing systems; it can be used in the implementation of a service for booking transport tickets, in particular in air travels. A hardware and software complex for searching for fellow travelers contains a server and client parts connected by communication channels. The client part is an application module located on at least one user device, and the server part consists of a web server, API server and chat server connected to each other.

EFFECT: increase in the functionality and informativity of the service for searching for fellow travelers.

1 cl, 4 dwg

Description

Technical field

The proposed invention relates to the field of information processing systems and can be used in the implementation of the ticket booking service for transport, in particular for air travel.

State of the art

From the prior art, a service for booking tickets for transport is widely known, which provides the user with the opportunity by visiting the website of a certain company (aeroflot.ru, rzd.ru, etc.) according to specified criteria (date, ticket price, number of free seats in the cabin) select and purchase a ticket for a trip or flight. To ensure greater convenience, carrier companies are developing mobile applications through which the user can carry out the above procedures.

However, a common disadvantage of these systems is low functionality and informativeness due to limited possibilities for choosing search criteria, processing query results and providing additional information and functions.

A system is also known from the prior art for "facilitating" flight planning for several passengers (CA 2988977 A1, 12/15/2016), based on a hardware-software complex, including client and server parts. Based on the request, the system sets the attributes and the scheduler searches for a suitable route and provides it to the user. The attributes in the known solution may include, in particular, the city of departure, the city of destination and the hotel for the first passenger; departure city, destination city, hotel and car booking for the second passenger; and city of departure, city of destination, flight date, hotel and destination city of the return flight for the third passenger.

The system takes into account the preferences of passengers, which include flight attributes, but does not provide the user with information regarding passengers who are potential buyers of tickets for the same flight. The system does not provide users with the ability to communicate with each other and does not provide the ability to create a personalized profile that may be available to other passengers. The known system is aimed at improving logistics, i.e. is more focused not on the user, but on reducing costs in the provision of services. Thus, the known solution is also characterized by low functionality and information content.

As an analogue of the proposed invention, you can specify a well-known solution, which is a device for the automated selection of fellow travelers when buying tickets for transport (RU 2706468 C2, 11/19/2019). The known device, which is essentially a system, is made on the basis of a hardware-software complex and contains an interface for the interaction of the buyer with the reservation system and a processing center. The system is capable of receiving a travel request, wherein the travel request is associated with a plurality of passengers. Based on the request, the system sets a plurality of attributes, performs a search, and based on the search result, provides a route for each of the plurality of passengers. In addition, taking into account the given preferences of the user, the system determines the seat in the cabin for the passenger that best suits his preferences. This determination is made on the basis of preferences specified by other users.

However, the known system also does not provide users with the ability to communicate with each other and create a personalized profile that can be accessed by other passengers. In addition, seat selection is carried out automatically and the user does not have the ability to send or receive any additional information from other users who are potential buyers of tickets for this flight. However, with this information, the passenger could refuse to book tickets, choose a more suitable place for a joint trip, or be able to plan in advance their actions after the trip.

The proposed invention is aimed at overcoming the known shortcomings of the prior art and makes it possible to achieve technical results, which consist in increasing the functionality and information content of the service for finding fellow travelers.

Disclosure of invention

To achieve these technical results, a hardware-software complex for searching for fellow travelers is proposed, containing server and client parts connected by communication channels, moreover, the client part is an application module located on at least one user device, and the server part consists of connected between a web server, an API server, and a chat server, wherein the web server includes a module manager, a plurality of interface modules, a first authorization module, and a chat module; The API server contains a router, a second authorization module, modules for processing authorized and unauthorized requests, a route processing module, a flight search module and an SMS module, as well as databases corresponding to the route processing module and the module for processing unauthorized requests; the chat server contains a stream request terminator module, a session module, a request processing module, a database module, and a PUSH module; the application module contains a loading module, an authorization/registration module, a flights module, a chat module, an internal data logging module, an API registration module, a favorites module, a personal settings module containing a media loading block, while the module manager loads the required interface module via an https request , the first authorization module manages the user's session, which is provided by using a hash string-session key and update key pair, the session key is used to access service elements that require authorization, and the update key is used when updating the session key, the chat module sends and receives requests from the server using the WSS protocol, which supports the initiation of data transfer not only from the client request, but also from the server in real time; after successful authorization, the chat module establishes a connection with the chat server, while messages are sent via this channel to chat and receive messages from server side, as well as periodic exchange of service messages to determine the activity of the client session, and the chat server connects via the WSS protocol for real-time interaction with clients connected to the system, and also transmits messages between clients, the router is designed to parse the request address and redirects it to the API server request processing module corresponding to the parsing result, and is a procedure that performs a function intended for the HTTP route, the second authorization module checks the validity of the session key and, depending on the result of the check, returns access or data transfer errors to a module for processing authorized requests, which in turn provides data to the user from the flight search module, the SMS module and the database, and the flight search module and the SMS module are an abstraction over the API of the flight search services and SMS mailing, respectively, the route processing module includes the business logic of the server API and interacts with the database, the stream request terminator module determines the type of request, request data and session data accompanying the request via the WSS protocol, the session module determines the validity of the session key and returns the corresponding result to the stream request terminator, and in if the session key is valid, the data and request type are passed to the chat server request processing module, which calls the appropriate handler, the PUSH module is an abstraction over the API service for sending PUSH notifications and uses the chat server to notify the participants in the conversation for messaging, the database module provides work with the chat server database, the loading module displays the loading screen and is designed to initialize the session, and in the case of an authorized request, the loading module loads user data, in case of unauthorized access, redirects to the authorization module/re registration, which is designed to intercept a request and add service data, register, authorize and confirm a phone number, the flights module contains a flight search block and a flight calendar component, the chat module interacts with the chat server via the WSS protocol, the favorites module generates access to the list of friends , while in the RAM of the user's device during the operation of the application module there is a state manager based on Redux, and is used when the application is running, while the software module that controls the loading of code blocks loads the necessary interface module using an https request.

In the following section of the description provides information showing the preferred embodiment of the proposed invention. For a specialist it will be clear that the principle underlying the invention can be used not only in the service related to air travel, but can also be successfully applied in other information systems in which, in the manner described in this application, it is possible to interact between users.

Implementation of the invention

This section shows how the invention can be carried out with the achievement of the above technical results, as well as other results that will clearly follow for a specialist from the information presented, but are not explicitly noted above as technical.

The proposed hardware-software complex for searching for fellow travelers is a set of tools designed for the harmonious and harmonious interaction of the so-called frontend (English Frontend) and backend (English Backend) parts. The frontend refers to the user interface on the client side, while the backend is the firmware of the service itself. Thus, in the proposed invention, the application is physically divided into two main parts: the hardware part, which processes all requests and returns the result, and the client part, which displays the data in a user-friendly form.

In FIG. 1 shows a generalized block diagram of the complex.

For convenience and expansion of functionality, the front-end part is presented in the form of two possible interfaces - provided by a mobile application or by accessing the service through a web interface. As OS for mobile applications, Android and iOS are considered in the preferred embodiment. A web server (not shown) provides a web interface for clients accessing the system via a browser, such as a desktop PC. In FIG. 1 also shows the API server and chat server included in the complex.

It should be noted that the developed complex in the hardware part has minimal hardware requirements.

So, the minimum system requirements under which the service is possible are:

Processor: Intel Xeon E5-2420 or better.

RAM: 64GB DDR4 or more.

A hard drive with hardware support for RAID 6 technology or more reliable and with a capacity of at least 5 TB.

Below are the possible user actions when working with the application.

Before using the service, the user must complete the registration procedure in the system.

The following order of actions for the user and the operation of the mobile application is preferable.

When the application is launched, the loading module displays the loading screen and initializes the session. Further, in case of an authorized request (ie, if the user has already been registered), the upload module loads the user's data.

In case of unauthorized access, the download module redirects the user to the authorization/registration module.

The authorization/registration module consists of a request interceptor that intercepts the request and adds overhead. It also contains an authorization component, a registration component, and a phone number verification component.

To register in the system, the user must:

- specify the e-mail address;

- specify the name;

- specify a password for further entry into the system, and confirm it by re-entering it;

- indicate the cell phone number to which his account will be linked in the future, after which an SMS with a code will be sent to this number;

- confirm the phone number by entering the code from the SMS message.

After completing the registration procedure, the user gets access to his account in the application and can enter the application from any device using the email address as a login and password.

Using the application interface, the user can search for flights by point of departure and arrival, as well as the date of departure, for which the flights module, which includes the flight search block, and the flight calendar component, is responsible.

Using the application, the user can subscribe to a specific flight, thereby becoming visible to other users who are also subscribed to this flight, i.e. such users become fellow travelers.

Having found an interesting passenger (fellow traveler) in the system, flying with him on the same flight, the user can send him messages, for example, for the purpose of acquaintance. This function is provided by the chat module interacting with the backend chat server via the WSS protocol (WSS tunnel). The passenger of interest can be found, for example, by viewing his profile with information about him and the photos attached to the profile.

Editing a profile and uploading photos is provided by the personal settings module, which contains a media upload block. For example, a user can attach a photo taken directly with their mobile device to their profile. Also, in his profile, the user can specify and edit information "About himself" in order to simplify communication with other users. Such information may include, but is not limited to: photographs, indication of gender, selection of a photo for a profile picture, interests, and so on.

The user can also send a friend invitation to another user. After accepting the invitation, each of the users can see in his list of favorites (friendlist) those users who accepted such an invitation.

The user has the ability to view the history of flights to which he or another user is subscribed, and also has access to the history of chat messages.

The user has the opportunity to send an appeal to technical support in case of various errors in the operation of the service.

The mobile application also provides an internal data logging module and an API logging module.

Also, when the application is running in the RAM of the user's device, there is a state manager based on Redux.

It should be noted that the term "informativeness" used in this application refers not only to providing the user with additional information not previously presented in such systems, as shown above, but also characterizes information as a measure of the orderliness of the material system. In the proposed invention, the specific informativeness of the source is increased by structuring the information and presenting it in this form to the user.

The proposed invention in a generalized form is represented by the following components:

API server (Backend server), web server, mobile clients (Android, iOS), chat server.

The backend server implements access to the API for processing data, executing user requests and other functions provided for the operation of the complex, which are not included in the subject of this invention.

The web server provides a web interface for clients working with the system through a browser.

The chat server provides a WSS connection for real-time interaction with clients connected to the system, and is also responsible for sending messages between clients.

Mobile clients allow clients to access the system via both Android and IOS mobile phones and also allow sending and receiving messages between system clients.

Further, information about the operation of each of the above components of the hardware-software complex is presented.

Working with the web server is carried out as follows.

In FIG. 2 is an exemplary block diagram.

When working with a web server, as noted above, the user logs into the system using a login/password pair. After that, the program module that controls the loading of code blocks (the first modules) loads the necessary interface module using an https request. Thus, the required functionality is not loaded on the user's device in its entirety, but as the need arises. This solution allows reducing the amount of traffic consumed by the user's device, as well as reducing the load on the network and computing power of the complex due to a decrease in the amount of processing and data transmission.

The web server authorization module (the first authorization module in the terminology of formula features) performs the functions of managing the user session. The user session is secured by using a hash string-session key and refresh key key pair. The session key is used to gain access to elements of the service that require authorization. The refresh key is used when updating the session key. When making an https request to the server, if the session key expires, the refresh key is checked. If the renewal key has not yet expired, the authorization module renews the session key, resulting in a new pair of keys (session and updates) coming from the server. If the update key has expired, the user is taken to an authorization page with an invitation to enter a login and password. The session key and refresh key are stored in the memory of the client's browser.

The chat module of the web server implements the functionality of sending and receiving messages from the chat. The function is activated after a successful session setup. The chat module sends and receives requests from the server using the WSS protocol (URI scheme of the WebSocket protocol, WebSocket over HTTPS), which supports initiating data transfer not only from a client request, but also from the server in real time. Also, a distinctive feature of the WSS protocol is the presence of an encrypted connection, which increases the security of using the chat. Also, if there is an HTTP proxy between the client and the server, the WSS connection is more reliable due to the fact that the HTTP proxy will not truncate the WebSocket headers (which can break the transmission) because the traffic through it will be encrypted.

After successful authorization, the chat module establishes a connection with the chat server, which is maintained throughout the entire session of using the application. This channel sends messages to the chat, receives them from the server, periodically exchanges service messages to determine the activity of the client session. Each message from the client also accompanies the session key. Marked actions can be provided through modules, WSS connector, Chat service with the function of sending to the backend chat server.

The architecture of the web version of the application is built according to the MVC (Model-View-Controller) pattern. Blocks of code, united by the maintenance of functionality, are combined into services that represent interfaces for other blocks and application modules to work with. So, requests to the server are made using an HTTP service that passes through a request interceptor that completes the request with a session key. Requests are made via the HTTPS protocol to the server from there, the response is returned to the HTTP service, which, having processed the request, redirects it to the code block responsible for storing the application state and data (model). The data from the model is reflected in the user interface.

Working with the API-server is carried out as follows.

In FIG. 3 shows an exemplary block diagram of the functioning of the API server.

When a request is received, it is sent to the program module that parses the request address (router). Further, depending on the address, this request is redirected to the appropriate request handler. The system provides two types of routes - routes that require authorized access and routes that do not require authorized access. Authorization is carried out by the authorization module (the second authorization module in the terminology of formula features) by checking the validity of the session key (not shown). If it is available and validation is successful, the system passes the request to the handler. In case of an error or lack of a key, an access error is returned.

The route handler includes the business logic of the server and interacts with the database.

The flight search module and the SMS module is an abstraction over the API of the flight search and SMS mailing services, respectively. This solution is used to ensure less connectivity between the system and third-party services.

In the case of an authorized request, the data is transmitted to the authorized request processing module, which provides data from the flight search module (proxy) via notion.io, as well as from the database and SMS module. The generated response is passed back to the frontend user through the reverse chain.

The operation of the chat server is provided as follows.

In FIG. 4 shows an exemplary block diagram of the functioning of the chat server.

The chat server interacts via the WSS Tunnel with the stream request terminator, then to the session module and the request processing module.

A stream request terminator is a software module that defines the request type, request data, and session data that accompanies the request.

The session module determines the validity of the session key and returns the corresponding result to the stream request terminator. If the session key is valid, the data and request type are passed to the request processing module, which calls the appropriate handler.

The PUSH notifications module is an abstraction over the API of push notification sending services. This solution is used to ensure less connectivity between the system and third-party services.

The database module, as is obvious to a specialist, provides work with the database.

Thus, the proposed invention can be implemented by means known from the prior art, and as a result of the implementation of a hardware-software complex for searching for fellow travelers, an increase in the functionality and information content of the service for searching for fellow travelers is provided.

Claims (1)

A hardware-software complex for searching for fellow travelers, comprising server and client parts connected by communication channels, wherein the client part is an application module located on at least one user device, and the server part consists of interconnected web servers, an API server and a chat server, the web server comprising a module manager, a plurality of interface modules, a first authorization module, and a chat module; The API server contains a router, a second authorization module, modules for processing authorized and unauthorized requests, a route processing module, a flight search module and an SMS module, as well as databases corresponding to the route processing module and the module for processing unauthorized requests; the chat server contains a stream request terminator module, a session module, a request processing module, a database module, and a PUSH module; the application module contains a loading module, an authorization/registration module, a flights module, a chat module, an internal data logging module, an API registration module, a favorites module, a personal settings module containing a media loading block, while the module manager loads the required interface module via an https request , the first authorization module manages the user's session, which is provided by using a hash string-session key and update key pair, the session key is used to access service elements that require authorization, and the update key is used when updating the session key, the chat module sends and receives requests from the server using the WSS protocol, which supports the initiation of data transfer not only from the client request, but also from the server in real time; after successful authorization, the chat module establishes a connection with the chat server, while messages are sent via this channel to chat and receive messages from server side, as well as periodic exchange of service messages to determine the activity of the client session, and the chat server connects via the WSS protocol for real-time interaction with clients connected to the system, and also transmits messages between clients, the router is designed to parse the request address and redirects it to the API server request processing module corresponding to the parsing result, and is a procedure that performs a function intended for the HTTP route, the second authorization module checks the validity of the session key and, depending on the result of the check, returns access or data transfer errors to a module for processing authorized requests, which in turn provides data to the user from the flight search module, the SMS module and the database, and the flight search module and the SMS module are an abstraction over the API of the flight search services and SMS mailing, respectively, the route processing module includes the business logic of the server API and interacts with the database, the stream request terminator module determines the type of request, request data and session data accompanying the request via the WSS protocol, the session module determines the validity of the session key and returns the corresponding result to the stream request terminator, and in if the session key is valid, the data and request type are passed to the chat server request processing module, which calls the appropriate handler, the PUSH module is an abstraction over the API service for sending PUSH notifications and uses the chat server to notify the participants in the conversation for messaging, the database module provides work with the chat server database, the loading module displays the loading screen and is designed to initialize the session, and in the case of an authorized request, the loading module loads the user data, in case of unauthorized access, it redirects to the authorization module isration, which is designed to intercept the request and add service data, register, authorize and confirm the phone number, the flights module contains a flight search block and a flight calendar component, the chat module interacts with the chat server via the WSS protocol, the favorites module generates access to the list of friends , while in the RAM of the user's device during the operation of the application module there is a state manager based on Redux, and is used when the application is running, while the software module that controls the loading of code blocks loads the necessary interface module using an https request.

Images