WO2023163611A1 - Service for interaction between parties on the real estate market - Google Patents

Abstract

Claimed is a system for interaction between parties on the real estate market, which is designed to allow the generation of electronic contracts and the signing of electronic contracts by digital signature. The system comprises: a database server for long-term data storage, which contains contract templates for the generation of electronic contracts, information about parties interacting with one another within the system, and information about items of real estate; a server for short-term data storage; a file storage server, in which the stored files are divided into private and public files, wherein the file storage server contains, as private files, the digital signatures of the parties; a server for dynamic content, which supports the operation of an API and an administrative console and provides information to user devices, said server being capable of filtering items of real estate according to set criteria, generating electronic contracts on the basis of information contained on the database server, and enabling parties to sign electronic contracts by digital signature on the basis of information contained on the file storage server; a server for static content for secure access to static files within the system; a chat server for the exchange of messages between users; and a queue server for delivering notifications and launching periodic tasks.

Description

SERVICE FOR INTERACTION OF THE PARTIES IN THE REAL ESTATE MARKET

FIELD OF TECHNOLOGY

The present technical solution relates to the field of computer technology, in particular, to systems for the interaction of parties in the real estate market.

BACKGROUND OF THE INVENTION

The prior art solution, selected as the closest analogue, RU2584345 (C2), publ. 05/20/2016. This solution discloses a system for providing services by a real estate agency, which includes a central server of a real estate agency, made with a device for entering information about a person who intends to sell or buy an apartment, and data on the offer of apartments with prices in the primary and secondary markets, and terminals candidates, made on the basis of computerized agents with the ability to remotely access the central server of real estate agencies, the central server of real estate agencies has a database of standard documents used to conclude contracts and agree on conditions, and has the ability to access databases containing information about persons, information about the proposed sale or purchase of apartments and apartments in the primary and secondary markets. The database of standard documents used to conclude contracts and agree on conditions is a set of contracts filled out on behalf of real estate agencies, a list of service conditions corresponding to each type of contract, and the cost of services corresponding to the terms of each type of contract, candidate terminals have the ability to remotely access to the database of standard documents and the choice of conditions for the provision of services and the corresponding contract for filling in the selected contract with personal identification data.

The proposed technical solution is aimed at eliminating the shortcomings of the state of the art and differs from those previously known in that the proposed solution provides highly effective interaction between the parties in the real estate market. The proposed technical solution is additionally made with the possibility of generating electronic contracts and signing electronic contracts with a digital signature.

SUMMARY OF THE INVENTION

The technical problem to be solved by the claimed solution is the creation of a system for the interaction of the parties in the real estate market. The technical result consists in expanding the functionality of the system for the interaction of parties in the real estate market.

An additional technical result is an increase in the performance of the technical elements of the system when solving the task (i.e., the present technical solution allows processing data to obtain a result (product) in less time), thereby reducing the load on the central processors of computing devices and servers due to reducing the number of requests processed.

The claimed technical results are achieved through the implementation of a system for the interaction of parties in the real estate market, which is configured to generate electronic contracts and sign electronic contracts with a digital signature, containing: at least one database server configured for long-term data storage, moreover, the database server contains at least contract templates for generating electronic contracts, information about the parties that interact with each other in the system, as well as information about real estate objects; at least one short-term storage server configured to short-term store data; at least one file storage server configured to store files, wherein the files stored on the file storage server are divided into private and public, while the file storage server, as private files, contains at least digital signatures of the parties, that interact with each other in the system; at least one dynamic content server that provides API and administrative console operation and provides information to user devices, wherein the dynamic content server is configured to filter real estate objects according to user-specified criteria, and is also configured to generate an electronic contract based on the information, contained on the database server, and signing electronic contracts with a digital signature by the parties based on the information contained on the file storage server; at least one server for static content, providing secure access to the static files of the system; at least one chat server that provides messaging between users within the system; at least one queue server for delivering notifications and running periodic tasks, providing a reduction in the load on the system for the interaction of parties in the real estate market, by sequentially executing tasks from the queue.

In a particular embodiment of the described system, at least two database servers can be used for long-term data storage, which are combined into a single cluster.

In a particular implementation of the described system, the interacting parties are landlords, tenants, real estate sellers, real estate buyers, agencies, service providers in the real estate market.

DESCRIPTION OF THE DRAWINGS

The implementation of the invention will be described hereinafter in accordance with the accompanying drawing, which is presented to explain the essence of the invention and does not limit the scope of the invention in any way. The following drawing is attached to the application:

Fig. 1 illustrates a general structural block diagram of the system.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of the implementation of the invention, numerous implementation details are provided to provide a clear understanding of the present invention. However, one skilled in the art will appreciate how the present invention can be used, both with and without these implementation details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to unnecessarily obscure the features of the present invention.

Furthermore, it will be clear from the foregoing that the invention is not limited to the present implementation. Numerous possible modifications, changes, variations and substitutions that retain the spirit and form of the present invention will be apparent to those skilled in the subject area.

This technical solution is a system of interaction between the parties in the real estate market. To implement this technical solution, the following technical elements can be used:

• database server (it is possible to use several servers united in a cluster); • server of short-term storage;

• file storage server;

• server for dynamic content (provides API, administrative console);

• server for static content (pictures, documents);

• chat server;

• Queue server (for delivering notifications, running periodic tasks).

The database server provides long-term data storage.

When using a database server, it is possible to store information at least:

• about users of the system, which are individuals or legal entities;

• about relations between individuals and/or legal entities (a user may be a family member of another user, an owner, administrator or employee of a legal entity with different levels of privileges in it, a co-owner of real estate);

• on real estate owned by individuals and legal entities;

• about created ads about real estate objects;

• about agreements/contracts concluded and concluded with the help of the system.

The database server contains at least predefined standard contract templates for automatically generating an electronic contract. Additionally, the database server contains information about the parties that interact with each other in the system, as well as information about real estate objects, necessary for generating an electronic (virtual) contract/agreement.

The database server also stores identifiers, with the help of which the system can request a particular file from the file storage server.

A short-term storage server provides short-term storage of data and serves to store at least:

• keys for resetting the user's password;

• mail confirmation codes, user login;

• cache.

A feature of this server is the cleaning of information after the expiration of the storage period or when disconnected, which further improves the performance of the system as a whole. The file storage server provides file storage and is designed to store at least:

• photos from the profiles of individuals or legal entities;

• photographs of real estate objects;

• scanned documents (appendices to contracts, sales receipts, etc.);

• digital/virtual signatures of individuals or legal entities for signing contracts.

The file storage server is capable of storing files, dividing them into private and public. The file storage server as private files may contain at least digital signatures of the parties that interact with each other in the system.

Files on the file storage server are divided into private and public, access to private files is provided only by a complex hash code, which can be temporary. In this case, the client device always receives files through the static content server, but for private files, it first calls the system (service) API to check access rights.

The server for dynamic content provides the API, the administrative console and provides information to user devices. The server for dynamic content based on predetermined criteria is able to automatically generate an electronic (virtual) contract based on the information contained in the database server. Digital signing of virtual contracts generated by the system is also carried out using the server for dynamic content based on the information contained on the file storage server.

At the same time, the server for dynamic content additionally allows you to efficiently and effectively filter real estate objects according to user-defined criteria.

The server for dynamic content additionally manages access to private data in the file storage, and also allows system administrators to perform periodic user administration, service configuration and maintenance tasks through the administrative console.

The static content server provides fast and secure access to the service's static files. Using this server, the file storage is able to provide files to client devices, regardless of whether whether the file was requested via a link (for public files) or via an API method using a complex hash code (for private files). This approach allows you to significantly reduce the load on the dynamic content server, and thus on the entire system as a whole, but at the same time maintains the necessary level of data security.

The queue server ensures the operation of queues, thereby reducing the load on the system and increasing the performance of the system as a whole, by sequentially executing tasks from the queue.

The queue server is designed to at least form queues:

• by sending e-mails;

• task reminders;

• invitations to establish relationships between users;

• notifications about changes in the concluded contract;

• other service notices.

The system may additionally contain a chat server that can provide messaging between users within the service. The chat server is based on web socket technologies and allows users of the service to discuss issues of rent, contracts, etc. online, without resorting to phone calls or e-mail. Chats between users representing both individuals and legal entities are possible. If a legal entity participates in the chat, then any employee with at least administrator rights can send and receive messages on its behalf. The server supports the transfer of files both from the user's computer and those located in his profile on the service. The conclusion of an electronic agreement/contract can automatically start the process of creating a chat between its participants. The server provides for sending service messages to the chat, for example, reminders of the need to perform a one-time or periodic task stipulated by the contract.

The user, interacting with the user device through the interface, causes the client device to send requests to the server that provides the API. Requests are executed by the server (this may involve a database, file storage, temporary storage, requests to external services, etc.), and their results are sent back to the client device.

In most cases, client devices interact with a server that provides the application interface (Aplication Programming Interface, hereinafter referred to as API), a server for static content, and a chat server. For long-term storage of data in the system, a PostgreSQL, MySQL, MariaDB or similar database with support for SQL syntax, as well as any other database management system, can be used.

The front-end stack is based on React, TypeScript, Redux with many third-party packages for working with data and styling. Also on the frontend side, a mechanism for working with sockets is implemented, which implements communication with the server for notifications and working with chats.

For short-term data storage (password reset keys, confirmation codes, etc.), the system can use Redis or similar temporary storage. On the client side, the keys can be stored in localstorage, where JWT authorization is used.

A secure file storage is used to store user files divided into private and public ones. Private files are accessed using a complex hash code, which can be temporary. The functionality of the system can also be implemented using another stack (languages and file storages) to implement the front-end.

The API is used for client devices to interact with the system, but any other tool for data exchange between the user and the server can be chosen. Client device requests and service responses are formatted in JSON, but XML or another format may be used.

Primary authorization of the user is carried out by transferring the user's login and password to the system. The login can be an email or a unique user ID. During authorization, the system generates two tokens - an authorization token and a refresh token, with which a new authorization token can be requested if the old authorization token expires. Tokens are not stored on the server. The server receives an authorization token with most requests from client devices, decrypts and correlates the request with a specific user of the system. The server receives the refresh token from the client devices as needed to refresh the authorization token. Data exchange with client devices is carried out using a secure protocol.

Users interact with the system through data exchange between the system servers and user devices.

The search for real estate can be carried out according to various criteria through a search engine. The user on their device selects tags for ads (for example, rent and pay, rent with bonuses and penalties, rent for assistance, rent with training, rent with earnings, free rent), as well as sets other parameters of the searched ad. Each tag has its own unique icon, which marks the ad about the property. After setting the selection criteria in the search engine of the service, users send a request from their device to the server that provides the API. The server checks the validity of the received data and filters real estate objects according to the specified criteria by generating an SQL query to the database server. Next, the server generates a response that includes the parameters of real estate objects, their unique identifiers, as well as technical data for obtaining static content, if it is attached to a real estate object. The generated response is then sent by the server to the user's device, where the information is displayed via display devices (eg, monitor, display, etc.). If the response contains static content, the client device receives it in separate requests to the server.

To reduce the load and reduce the execution time, the system, in response to a user request, returns one page with results to the user, while to receive another page, the user, interacting with the interface of the client device / application, selects a specific page or requests the next page.

Based on the selected advertisement, the system can automatically generate a virtual contract/agreement, uploading to it at least a description of the property, its geographical address and co-owners as one of the parties to the contract. If the user who initiated the creation of the contract is not a co/owner of the property from the ad, two parties will be added to the contract at once.

The system, using dynamic content servers and a queue server, sends to all users participating in the contract to their devices:

• virtual rental contract,

• notification letters about their participation in the rental contract to the email specified during registration,

• notification of their participation in the rental contract.

Other users of the service who are not parties to the lease contract do not have access to the contract data.

Users can be able to sign a virtual lease contract using a digital signature created in the system.

After creating a virtual signature and passing verification, the user can sign any document, in particular, virtual/electronic lease agreement using the generated digital signature. A signing request is sent from the user's device to the service API. Upon receiving this request, the dynamic content server downloads the user's signature from the file storage by the signature file identifier from the profiles table and places it in the document in the signature field of the corresponding user.

The system checks the validity of incoming data both on the client side and on the server side. On the user device (for example, in a client application), basic validation is performed to prevent obviously erroneous and malformed requests from being sent. Server-side validation blocks the possibility of executing invalid requests from clients, violating the integrity of the database, and accessing data that the user should not have access to. Validated data is stored in the database by the service. If the user has attached additional files (attachments to the contract), they are stored in the file storage in the private part by separate requests from the client device.

For convenience, when the state of the contract changes, the parties can be automatically informed by e-mail, chat and through the notification system. The terms of the contract can be edited by users of the system in real time.

The parties can make adjustments and new conditions to the virtual contract one by one, while all changes made by one party are agreed by the other party. Without mutual agreement of the electronic contract, it is impossible to sign it and transfer it to the status of the current one.

To organize the possibility of sequential editing of the generated virtual contract, the system saves in the database the identifier of the participant who currently holds it, and the type of the contract party whose participants are granted the right to edit. Also, each party to the contract retains the sign of approval and signing.

After making the necessary adjustments to the contract, the participant releases it with transfer to the opposite party for approval. In this case, in the database of the contract, the side type will be changed automatically. If there is more than one participant on its side, then the type of the side will not be changed, and the contract will be available for editing by other participants of this side only. Other participants of this party can both edit the contract and immediately agree on it. The user starts the process of negotiating the contract from his device. As a result, the dynamic content server, by sending a SQL query to the database, changes the sign of the participant's agreement. The contract, agreed by all participants of one party, is transferred to the opposite party for editing or approval.

Discussion of the details of the contract, its basis and changes is available through chats on the service with the involvement of all parties. The chat server for the contract creates a group chat, to which all participants are automatically added.

The system additionally provides the ability to download the generated contract as a PDF file for viewing or signing manually. To do this, it generates a document and sends a link to the client device, by which this file will be temporarily available for download.

After the conclusion and signing of the lease contract, the property is transferred from the owner to the tenant under the act of transfer. The dynamic content server processes the received information and generates a transfer act document. After preparing the transfer act, the server sends: the document to the devices of users - participants in the transfer act; notification letters about their participation in the act of transfer to the email specified during registration and in the "Notifications" section in the user's personal account.

Other users of the system who are not parties to the act of transfer do not have access to the document.

After agreement by all parties, users participating in the transfer act can also sign the virtual transfer act using their digital signature. To sign a document, they send a corresponding request to the system API. Having received this request, the dynamic content server downloads the user's signature from the file storage by the signature file identifier from the profile table and places it as a graphic image in the document in the signature field of the corresponding user.

The system also provides the ability to download the act as a PDF file for viewing or signing manually. To do this, it generates a file and sends a link to the client device, by which this file will be temporarily available for download.

Thus, the system additionally allows the parties to effectively interact with each other in the real estate market. When implementing the system, the arsenal of its functionality increases due to the wide customization of generated contracts and the possibility of signing them with a digital/electronic signature.

An example of the implementation of this technical solution, in which one participant from each side interacts with each other in the system. Contract #Rent and payment. Pre-loading of information and (manual/automatic) creation of a property card.

Each user at the first interaction with the system registers and creates an informative profile. The information entered by the user (email, name and password) from his device is sent to the API on the dynamic content server (API). The server checks the database (DB) for the presence of email and either returns an error message to the user device, or enters this data into the database (namely, it generates a user account in the database, while the password is not explicitly stored in the system, only its hash). Also, an error will be returned if the user enters incorrect data (note: validation rules are applied to all data entered by users, for example, the password cannot be shorter than 6 characters, etc.). The server also generates and saves a unique digital user identifier in the database. In the future, email (or user ID) and password will be used for authorization.

After adding data to the database, an email with an authorization confirmation link is sent to the user via the queue server via the queue server. The link contains a temporary confirmation token, which will be checked by the corresponding API method upon transition, and if the token is correct (valid), then the account will be marked in the database as confirmed.

In the future, to use the functionality of the system, the user is authorized. Authorization is carried out by entering an email (or user ID) and a password. The email or identifier, as well as the password hash, are compared with those stored in the database, and either an error is returned to the user device, or the API generates a pair of temporary tokens - an access token and a refresh token. Both tokens are returned to the user's device and are not stored on the server. In the future, the access token is used to sign requests to the service API from the user device, since the user identifier is encoded in it. The second token is used to issue a new access token if it has expired.

When a user logs out (logs out), the tokens are blacklisted and cannot be reused. User (1) - the landlord, using a template pre-installed in the system database, creates a card for his property. When filling in the "Owners" section, the dynamic content server contacts the database server and automatically uploads data from the informative profile to the real estate card. A database server is used to store real estate cards. Photos and documents used in the property card are stored in a long-term storage in a private section.

User (1) in the template automatically creates a rental ad based on a previously created property card and publishes it. Initially created ad has the status "Draft". Publication means that in the database the status of the announcement changes to "Published", and from that moment it becomes available to other users of the system, even if they are not registered in the system. The owner of the ad can remove the ad from publication at any time by transferring it to the "Archived" status. In addition, the automatic archiving of old ads can work in the system.

It should be noted that the User (1) can create an advertisement manually by entering information about the property in the template if the property card has not been created in advance. In this case, a real estate card is created automatically when filling in the "Parameters" section of the ad. A database server is used to store real estate cards. Photos and documents used in the property card are stored in a long-term storage in a private section.

While searching for real estate, tenants or roommates, users send a request from their device to the server that provides the API. The server checks the validity of the received data and filters ads based on their classification by tags and specified criteria through the formation of an SQL query to the database server.

User (2) - the tenant selects the required ad and sends a request to the User (1) for interaction. The request can be a message to discuss the terms and conditions and conclude a lease contract. The message goes to the chat server and then from the server to the User's device (1). Thus, remote joint interaction of all parties to the transaction in the discussion of the electronic contract and the act of transfer is implemented. Using the group chat functionality, users can send each other attached documents (photos, contracts, acts, reports). Attached documents are stored in the private part of the long-term storage. When chat participants enter the service in their personal profile, their device connects to the server and receives chat information stored on the chat server, with the ability to download documents to their devices.

The formation of the lease contract takes place in the template (constructor) both on the device of the User (1) and the User (2). When creating a virtual lease contract, when a previously created real estate card is taken as the basis, the parameters of the object from the database storage server are automatically uploaded to the electronic contract. The data of contract participants is also automatically copied from their profiles created in the system and stored on the database server. User (1) and User (2) negotiate the contract generated by the system on their devices, while the system marks the contract as agreed. The parties to the contract can then sign the agreed upon contract using their digital signature created earlier. At the same time, the system identifies the user, unloads his signature from the private part of the long-term storage and inserts it in the contract into the field specially designated for the signature. Once a contract is signed by both parties, the system marks it as signed by both parties and displays the contract on each member's profile under "My Contracts". Contract participants can download the signed contract in PDF format and print it.

In the process of forming, agreeing and signing a contract, the system sends notifications to contract participants about the actions performed by each party with the contract. In addition, when creating a virtual contract in a template (constructor), the user specifies the period for notification of the expiration of the lease period, when the system sends a corresponding message from the server to the users participating in the contract.

Similarly, the formation of an act of transfer of a real estate object is carried out in a template (constructor) both on the User's device (1) and on the User's device (2). Data about the property and participants in the act of transfer is uploaded by the system from the concluded lease contract. User (1) and User (2) approve the document generated by the system, while the system marks the act as approved. The parties to the contract can then sign the act using their digital signature. At the same time, the system identifies the user, unloads his signature from the signature database and inserts it into the field specially designated for the signature in the transfer act. After the act is signed by both parties, the system marks the act as signed by both parties and displays the act in the profile each participant in the "My Contracts" section as an Appendix to the rental contract. Participants can download the signed act in PDF format and print it.

The “House book” section is generated by the system automatically when the User (1) creates a card of his real estate and is attached to this card. In the "House book" section, the User (1) keeps a record of all expenses for his facility, including repair and construction work. The house book of the object is available for viewing and editing for each user added to the property card as a co-owner. Access to the "House book" of the object can be opened by the owner to a third user. Other users of the system do not have free access to the information of the House Book. "House Book" is located in the database and is structured in folders, in which the user adds sections, and in sections - paragraphs with descriptions. The user uploads documents, photos, checks to the sections of the "House Book". When adding checks, the system automatically converts the currency of the check. The system summarizes all the costs entered by the object.

An example of the implementation of this technical solution, in which several participants from each side interact with each other (for example, 2 participants from each side, but the maximum number can be up to 5). Contract #Rent with bonuses and penalties. The formation of a virtual rental contract occurs automatically in a template (constructor) on the device of any user from each side, when a pre-created real estate card (or an ad with automatic generation of a real estate card by the system) is taken as a basis.

From the side of the landlord 2 participants: User (1), who creates a real estate card and adds User (2) to it as a co-owner. To the user (2), the system, using the queue server, sends an invitation to the real estate card, which he can accept or reject. The co-owner who accepted the invitation is displayed in the property card with a % share of the object's ownership. A database server is used to store real estate cards. Photos and documents used in the property card are stored in a long-term storage in a private section.

User (3) - the tenant selects the desired advertisement and writes a message to the User (1) to discuss the terms and conclude a lease contract. The message goes to the chat server and then from the server to the User's device (1). User (3) - the tenant can add the User (4) co-tenant to the chat, due to which the remote joint participation of all parties to the transaction in the discussion of the terms of the contract and the act of transfer will be realized. Nested Documents are stored in the private part of the long-term storage. When chat participants enter the system in their personal profile, their device is connected to the server and receives information in the chat stored on the server, with the ability to download documents to their devices.

The rental contract is formed in the template (constructor) both on the device of Users (1) or (2) and Users (3) or (4). When creating a virtual lease contract, when a real estate card (or advertisement) previously created in the system is taken as the basis, the parameters of the property are automatically uploaded from the database server, where the real estate card data is stored, into an electronic contract. A similar algorithm is used when creating a lease that is based on an advertisement.

When User (1)/(2)/(3)/(4) creates a contract, the system sends notifications to other users added to the contract that they have been added to the contract as a participant. Users added to the contract can accept or decline the invitation to the contract. The data of the contract participants who accepted the invitation to the contract are also automatically loaded from their profiles created in the system and stored on the database server. Using condition templates in the contract constructor, participants fix one-time and regular conditions, upon fulfillment/failure of which the system will automatically accrue bonuses/penalties. The summation of the bonuses/penalties entered into the rental contract also occurs automatically in the contract template.

Users (1), (2), (3), (4) negotiate the contract generated by the system on their device. In this case, the system marks the contract as agreed for each of the parties. The parties to the contract can then sign it using their digital signature created earlier in the system. At the same time, the system identifies the user, unloads his signature from the signature database and inserts it into the field specially designated for the signature in the contract. Once a contract is signed by all participants from both parties, the system marks it as signed by both parties and displays the contract on each participant's profile in the My Contracts section. Contract participants can download the signed contract in PDF format and print it.

In the process of forming, agreeing and signing the contract, the system sends notifications to the contract participants about the actions performed with the contract by each participant from each side. In addition, when creating an electronic contract in the template (constructor), the user specifies the notice period for the end of the lease term, when the system from the server sends a corresponding message to the users - participants in the contract.

Similarly, the formation of the act of transfer of the property in the template (constructor) is carried out both on the device of the Users (1), (2) and on the device of the Users (3), (4). Data about the property and participants in the act of transfer is unloaded by the system from the concluded lease contract automatically. Users (1), (2), (3), (4) approve the document generated by the system, while the system marks the act as approved. The parties to the contract can then sign the act using their digital signature. At the same time, the system identifies the user, unloads his signature from the signature database and inserts it into the field specially designated for the signature in the transfer act. After the act is signed by both parties, the system marks the act as signed by both parties and displays the act in the profile of each participant in the "My Contracts" section as an Annex to the rental contract. Participants can download the signed act in PDF format and print it.

Automatic accrual of bonuses or penalties occurs in the system within the time specified in the contract, depending on the acceptance or rejection by the lessor of reports on the fulfillment by the lessee of the regular or one-time conditions agreed upon and fixed in the contract.

The “House book” section is generated by the system automatically when the User (1) creates a card of his real estate and is attached to this card. In the "House Book" section, the User (1) keeps a record of all expenses for his facility, including repair and construction work. The house book of the object is available for viewing and editing for each user added to the property card as a co-owner. Access to the "House book" of the object can be opened by the owner to a third user. Other users of the system do not have free access to the information of the House Book. "House book" is located in the database and is structured in folders, in which the user adds sections, and in sections - paragraphs with descriptions. The user uploads documents, photos, checks to the sections of the “House Book”. When adding checks, the system automatically converts the currency of the check. The system summarizes all the costs entered by the object.

In these application materials, a preferred disclosure of the implementation of the claimed technical solution was presented, which should not be used as limiting other, private embodiments of its implementation, which do not go beyond the claimed scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims

Formula 1. A system for interaction between parties in the real estate market, configured to generate electronic contracts and sign electronic contracts with a digital signature, comprising: at least one database server configured for long-term data storage, the database server containing at least contract templates to generate electronic contracts, information about the parties that interact with each other in the system, as well as information about real estate objects; at least one short-term storage server configured to short-term store data; at least one file storage server configured to store files, wherein the files stored on the file storage server are divided into private and public ones, while the file storage server contains at least digital signatures of the parties that interact with each other as private files in system; at least one dynamic content server that provides API and administrative console operation and provides information to user devices, wherein the dynamic content server is configured to filter real estate objects according to user-specified criteria, and is also configured to generate an electronic contract based on the information, contained on the database server, and signing electronic contracts with a digital signature by the parties based on the information contained on the file storage server; at least one server for static content, providing secure access to the static files of the system; at least one chat server that provides messaging between users within the system; at least one queue server for delivering notifications and running periodic tasks, providing a reduction in the load on the system for the interaction of parties in the real estate market by sequentially executing tasks from the queue. 2. The system according to claim 1, in which at least two database servers can be used for long-term data storage, which are combined into a single cluster. 3. The system according to claim 1, in which the interacting parties are landlords, tenants, real estate sellers, real estate buyers, agencies, service providers in the real estate market.