EA042772B1 - IMPROVED MESSAGING - Google Patents

Description

The invention relates to an improved messaging system, preferably instantaneous.

Currently, the confidentiality and security of messages exchanged through known messaging systems is ensured through end-to-end encryption, and in particular, it is thus ensured that only the sender and recipient can read and view the message sent, and no one else, not even the manager of the exchange system. messages, can't. However, all this happens automatically, i.e. without activating certain settings and without creating special secret chats, and therefore, after gaining access to the device of the sender and / or recipient, the content of individual messages or chats is essentially free to view.

In essence, therefore, at present, access to chats, messages and content provided in the user's messaging system depends solely on the correct passage through the recognition system (by password, passcodes or fingerprint) designed to gain access to all device functions ( and this is both with the power on and in standby mode).

Therefore, in order to allow an unauthorized user who is not the owner of a particular device to freely use the messaging system present on a given device, the owner of the latter must necessarily go through the recognition system in advance to unlock all the functions of the device; however, an unauthorized user would be able to fully and discreetly view all of the content present on the owner's device's messaging system, and in particular, would also be able to view a series of conversations and/or messages that the owner, for various reasons, may want to keep private. In general, there are situations when the owner of the device wants or needs to allow access (both for viewing purposes and for use) to the messaging system to an outside user, but at the same time he wants to prevent the latter from viewing so much content completely and uncontrollably (in in the form of dialogs, messages and elements in general), how much of it is present in the messaging system itself.

In this regard, currently known instant messaging systems do not have the ability to hide certain messages from a chat, and there is also no ability to hide a graphical and/or audio element (e.g. emoji, sticker and/or any multimedia element) inserted in a message, and even more so, there is no way to hide the entire chat, whether it is a chat only between two users or between several users (group).

Therefore, in some situations, the user of the messaging system - both the sender and the recipient - needs to hide within the system itself both the very existence and the content of the entire chat, message and (or) graphic and (or) audio element and, thus, allow them displayed on the device display only after the preliminary unlock and recognition operation has been performed.

US2015/007351 essentially proposes a system for censoring or masking a message that ends up being sent blank or with parts cut out of it. The recipient will receive the message and, by clicking on the corresponding button, will be able to unlock it and get a full display of the message in order to properly understand its content.

US2016/094495 describes a keyboard with various solutions for masking a message, such as anagrams or the elimination of certain words (prepositions, pronouns, conjunctions, etc.). Then, with the help of a button, the function of correctly reconstructing the message can be unlocked, making it possible to understand its content.

US2018/219812 describes a solution in which a message is sent blank or dimmed to then be displayed with a button that activates the fingerprint login to understand its content.

In patents US2015/007351, US2016/094495 and US2018/219812 propose solutions to avoid unwanted situations when an outsider looks at the display of someone else's device, peeking over the shoulder of the owner (manager) of said device in order to be able to see and spy on the content present on the display itself. However, these known solutions are not suitable for ensuring proper privacy in cases where, without the consent of the legal owner (operator) of the device (for example, in the event of theft or loss of this device), or even with his consent, an outsider takes the device at his disposal in order to control it freely and directly, for example, by accessing the unlock buttons, etc.

In addition, US2015/007351, US2016/094495 and US2018/219812 propose solutions for masking the text of a message while the message itself remains visible. In particular, the frame containing the text of the message remains visible even if it is empty inside or its text is darkened, cut or rearranged in various ways. Therefore, in this case, an outsider who has received someone else's device at his disposal will always notice the presence of the message, even if he cannot then understand its content; in other words, in the solutions proposed in patents US2015/007351, US2016/094495 and US2018/219812, despite the fact that an outsider cannot read and understand the message, he will still know about the existence of confidential and secret messages.

- 1 042772

In addition, the solutions proposed in patents US2015/007351, US2016/094495 and US2018/219812 assume that the text of messages exchanged by users will under any circumstances be hidden and, therefore, will be incomprehensible to both the sender and the recipient of these messages. Therefore, they cannot handle the situation where the body of a message, or even the presence of an entire chat, should only be invisible to the sender and not to the recipient(s) or vice versa.

The purpose of the present invention is to provide a messaging system that overcomes the above-mentioned disadvantages of conventional technology.

Another object of the invention is to provide a messaging system capable of hiding both the content and the presence of a chat, a message, or a graphic and/or audio element of a message, thus eliminating the possibility that an unauthorized user will notice their existence.

Yet another object of the invention is to provide a messaging system in which an unauthorized user will not notice the existence of chats, messages and/or graphical and/or audio elements that are hidden.

Yet another object of the invention is to provide a messaging system that allows a chat (i.e., the exchange of messages sent and received on a messaging system) to be hidden so that the corresponding secure chat screen (chat room) is viewable only after a preliminary unlocking and (or) authorization procedure.

Yet another object of the invention is to provide a messaging system capable of hiding a chat (i.e., the exchange of messages sent and received on the messaging system) so that on the preview screen of the corresponding summary, from a plurality of user chats, only the after completing the preliminary unlocking and (or) authorization procedure.

Yet another object of the invention is to propose a messaging system capable of hiding a message, both sent and received via the messaging system, so that the corresponding frame containing the message, as well as the message itself, can only be viewed after a preliminary unlocking procedure and (or) authorization.

Yet another object of the invention is to provide a messaging system that makes it possible to hide a graphical and/or audio element present in a message both sent and received via the messaging system, so that the space occupied by the graphical element and/or audio element in the message, as well as the element itself, could only be viewed after a preliminary unlock and/or authorization procedure had been completed.

Yet another object of the invention is to provide a messaging system that makes it possible to hide a chat between multiple participants (groups).

Yet another object of the invention is to provide a messaging system that allows the creation of a nested chat within a group or even between users of a main chat.

Yet another object of the invention is to provide a messaging system that allows multiple systems to be unlocked in order to access and display content present in said messaging system.

Yet another object of the invention is to provide a messaging system that allows two or more users to share a key to access and display hidden content present in said messaging system.

Yet another object of the invention is to provide a messaging system that allows a key to be exchanged without the need for external means to access and view hidden content present in said messaging system.

Yet another object of the invention is to provide a messaging system that is an improvement and/or alternative to traditional systems.

Yet another object of the invention is to provide a messaging system with alternative characteristics both in terms of functionality and in terms of implementation compared to conventional systems.

Yet another object of the invention is to provide a messaging system that is simple, convenient and intuitive to use.

Yet another object of the invention is to provide a messaging system that provides less resource consumption by the hardware devices involved and less use of the bandwidth occupied by the network.

Yet another object of the invention is to provide a messaging system that can be implemented simply, quickly and at low cost.

All these and other goals that will follow from the following description are achieved according to the invention using a system having the characteristics indicated in paragraph 1 of the claims.

The present invention is further disclosed in the following in its preferred embodiment solely as a non-limiting example with reference to the accompanying drawings, where:

in fig. 1 schematically shows the infrastructure of a messaging system in accordance with the invention, FIG. 2 schematically shows the centralized database on which the infrastructure of the messaging system according to the invention is based, FIG. 3 schematically shows a local subset that is downloaded locally to a device controlled by a particular user and is obtained from the centralized database shown in FIG. 2 in FIG. 4 schematically shows an example of the centralized database shown in FIG. 2 in FIG. 5 schematically shows an example of a local subset loaded onto a device managed by user 0001 and retrieved from the centralized database shown in FIG. 4 in FIG. 6 schematically shows a variant of the centralized database on which the infrastructure of the messaging system according to the invention is based, FIG. 7 schematically shows a variant of a local subset that is downloaded locally to a device controlled by a specific user and is obtained from the centralized database shown in FIG. 6, in FIG. 8 schematically shows part of the database shown in FIG. 6 for managing nested chats and which has been filled in as an example, FIG. 9a shows a screen showing only the list of open type chats while the highlighted type chats are in a hidden state, FIG. 9b shows the screen shown in FIG. 9a, after performing the procedure for unlocking the display of chats of the selected type, which then move from a hidden state to a visible state, in FIG. 10a shows a screen showing a chat with corresponding open type messages while the highlighted type messages are in a hidden state, FIG. 10b shows the screen shown in FIG. 10a after executing the procedure for unlocking the display of messages of the selected type, which then transition from a hidden state to a visible state, in FIG. 11a shows a screen displaying a chat with corresponding messages and open-type graphical elements while highlighted-type graphical elements are in a hidden state, FIG. 11b shows the screen shown in FIG. 11a, after executing the procedure for unlocking the display of graphical elements of the selected type, which in this case transition from a hidden state to a visible state, in FIG. 12a shows a screen in which the keyboard is displayed with open-type graphical elements only, while highlighted-type graphical elements to be inserted are in a hidden state, FIG. 12b shows the screen shown in FIG. 12a, after performing the procedure for unlocking the display of graphic elements of the selected type, which in this case transition from a hidden state to a visible state, in FIG. 13 alternately shows the various screens displayed during execution of the highlighted type chat display unlock procedure, FIG. 14a-c alternately show the various screens displayed during the procedure for accessing a dedicated type of chat, and FIG. 15 shows the screen while entering the passkey.

Preliminarily, it should be noted that in the future, message 60 means a set of all elements, namely: text, graphic (both static and animated), audio and (or) video elements that are presented on the display screen and occupy a certain area (viewing) specified screen. Preferably, said area is bounded by a frame 59, hereinafter referred to as a frame, which may have different graphic characteristics (eg color) relative to the background (and other areas) of the display screen. Conveniently, on the screen, each message 60 containing a frame 59 with textual, graphical, audio and/or video elements is presented separately or graphically unrelated to other chat messages.

In particular, message 60 may contain in its frame 59:

only text 39, or only one or more graphic and (or) audio elements 33, or a combination of text 39 with one or more graphic and (or) audio elements 33.

Conveniently, the message 60 could contain, in addition to the text 39 or as an alternative to it, any digital element transmitted over the Internet. Conveniently, the message 60 could contain, in addition to the text 39 or as an alternative to it, one or more multimedia elements that can be represented in digital form and that can be exchanged via the messaging system 2 in accordance with the invention, for example, graphic elements, audio elements, video elements, text documents, biometric identifiers or other elements, but not limited to the above list.

In particular, graphical elements 33 include symbols, icons, or in general images (both static and animated) that are to be inserted with or in the middle of any text 39, or even without it, within the frame 59 of the message itself. Preferably, but not necessarily, these images 33 express any concept, emotion, or mood that is essentially related to the emoji.

By chat 14 or dialogue is meant the set of all messages 60 exchanged between two users (i.e. sender and recipient) or several users (in so-called group chats) and which are presented in an ordered manner (including by time) on a dedicated page or in a window (also referred to as a chat room) which is presented on the corresponding display screen 57 . Conveniently, when creating a chat 14, the corresponding dedicated page or window can also be cleared of messages.

By nested chat 49 is meant a certain type of chat that depends on or derives from another chat (hereinafter referred to as the parent chat) and in which the participating users are all automatically users of the parent chat or a subset thereof. In particular, a user who is not in the parent chat cannot be present in the sub-chat. A nested chat is displayed within a dedicated page or window and is distinct from the parent chat that is presented on the display screen. Conveniently, when creating a nested chat, the corresponding selected page or window can also be cleared of messages.

By avatar 48, we mean the graphical representation used by each user to identify himself when he communicates with other users, for example, in a chat 14, or when he sends a message 60.

By object we mean one or more chats 14 and/or one or more nested chats 49 and/or one or more messages 60 and/or one or more graphic elements and/or audio and/or ) multimedia 33, and (or) in the general case, digital elements transmitted over the Internet.

An action is an input made by a user that is correctly and unambiguously detected by a computer system. Preferably, the action is a single tap (tap), double tap (double tap), scroll (swipe), or other movements that can be interpreted by a touch screen device. The action may also be a mouse click (single or double), optionally accompanied or replaced by one or more keystrokes on the keyboard if the device is of a desktop type, or it may involve the pronunciation of a sound or sequence of sounds, such as words, in the case when the device has voice commands, another action can be a framing of a facial expression or a specific code structure (QR code or barcode).

Conveniently, the messaging system in accordance with the invention may have one or more of the features proposed in PCT/IB2018/055193, the contents of which are hereinafter expressly and fully incorporated herein by reference.

Accordingly, the messaging system according to the invention may have one or more of the features proposed in PCT/IB2020/050173, the contents of which are hereinafter expressly and fully incorporated herein by reference.

As can be seen from the drawings, the infrastructure of the messaging system according to the invention, indicated as a whole by the reference number 2, contains at least one sending device 4 and at least one receiving device 6, equipped with means of communication with at least one central unit 8 for transmitting and receiving data.

Preferably, the sending device 4 and/or the receiving device 6 may include a client part consisting of a computer or portable device such as a smartphone or tablet.

Preferably, the central unit 8 could contain at least a computer 10, such as a real or virtual remote server and/or cloud system, for example.

The first and second devices 4, 6 are configured to send through the central unit 8, with which both devices interact, messages 60 containing text 39, graphic elements 33 and (or) audio (for example, multimedia content), while sending and receiving are carried out over the network: over the Internet or locally.

Conveniently, the first software module is loaded and/or executed in the first and second devices 4, 6, while the second software module is executed in the central unit 8. Conveniently, in the case of a portable device such as a smartphone or tablet, the first software the module consisted of its own mobile software application, also known as application program (APP). Accordingly, the first program module may also be implemented as a web application or a computer application.

In particular, the first software module is configured to send messages 60 by sending a request to the central unit 8 (server) based on a communication protocol, preferably HTTPS. Preferably this request is made using the POST method in order to send the contents of the messages (particularly in the form of a suitable data structure) to the central unit 8 without displaying them in the search bar (query string), however this request can also be made using the GET method by passing data through the search bar.

Preferably, the data transfer between the devices 4, 6 and the central unit 8 is carried out in accordance with the traditional client-server architecture, which uses, for example, the transfer (communication) protocol HTTP (HyperText Transfer Protocol - hypertext transfer protocol). It is preferable that this transmission (communication) protocol be secure, i.e., for example, be of the HTTPS type and use an encrypted connection, for example, in accordance with the cryptographic protocols TLS (Transport Layer Security - transport layer security) or SSL (Secure Sockets Layer - the level of secure sockets).

The first software module downloaded and executed in the recipient device 6 is configured to download from the central unit 8 the message 60 (in the form of a structured data packet) that was sent by the sending device 4 and prepared by the specified central unit 8. Preferably, downloading the message 60 from the central block 8 by the receiving device 6, or in any case, the transfer of the message 60 from the central block 8 to the receiving device 6 was performed using the REST architecture (REpresentational State Transfer - presentation state transfer) or the GraphQL architecture, which is preferably, but not necessary, used over HTTPS or MQTT as an alternative over WebSocket.

Preferably, the first software module loaded and executed in the device 6 of the recipient provides for the possibility of obtaining periodic access in accordance with a given frequency to the central unit 8 in order to request information from it about the possible presence (availability) of one or more messages 60 intended for it. , i.e., in a client-server dialogue mode called polling, and, if this is the case, the ability to download from the central unit 8 this message 60.

As shown in FIG. 1, it is preferable that the system 2 according to the invention also contains a notification platform 50, such as, for example, a Google cloud messaging service, an Apple toast notification service, or a Firebase cloud messaging service, which act as an intermediary between the devices 4, 6 and the central block 8 and are designed to asynchronously notify the specified devices about when new data will be available for them in the central block, i.e. according to the method called pop-up notification. In particular, for this purpose, the second software module is implemented in such a way that, based on the message 60 sent by the sender device 4, it sends a notification 52 to the notification platform 50, which then transmits this notification to the corresponding recipient device 6. Accordingly, the notification 52 that the central unit 8 sends to the notification platform 50 contains the identification code of the central unit 8 that sent the notification, the identification code of the recipient device 6 to which the notification is to be sent, and the content of this notification 52.

Preferably, the first software module loaded in the sending device 4 and/or the receiving device 6 is configured to be in a first active state, in which a bidirectional connection with the central unit 8 is established and maintained, and in a second rest state, when the sender device 4 and/or receiving device 6 is not connected to the central unit 8. Preferably, the first software module is implemented in such a way that when it is in the specified first active state, the recipient device 6 sends a request to the central unit 8 not periodically ( i.e., in polling mode), but only when it receives a notification, preferably via the notification platform 50 and in accordance with a method called the push notification method. Accordingly, when new data is available in the central unit 8 destined for a particular recipient device 6 on which the first software module is active, the second software module sends a notification to said recipient device 6 to send a request to the central unit 8. Thus, the central unit 8 is polled only when it is required to download new data, which avoids sending periodic and unnecessary requests for this data; this is particularly advantageous in that it makes it possible to reduce data traffic and, above all, not to take up data bandwidth unnecessarily.

Preferably, the message data 60 exchanged in the messaging system 2 between the sending device 4 and the receiving device 6 is encrypted using an end-to-end encryption system.

Central database 12.

- 5 042772

In the central unit 8, at least one database 12 is loaded (or associated with it), which accordingly forms a centralized database containing, in an aggregated and organized form, data on all users of the messaging system 2 and all objects (chats, messages, graphics and (or) audio elements) that can be created or managed and exchanged by these users within the same messaging system 2 .

The database 12 conventionally provides data storage support and a processor for processing a database (database server) and software applications (i.e., a database management system) for creating, processing, managing, and efficiently querying data stored on a storage medium for convenience.

As shown in FIG. 2, it is convenient that the database 12 contains:

a user data set 15 containing data for each user of the messaging system in accordance with the invention;

chat data set 18 containing data from all chats 14 for all messaging system users, message data set 20 containing data from all messages 60 from all messaging chats 14, one or more element data sets 22 containing at least unique identification codes (ID_ELEMENT) all graphic elements 33 (both static and animated), audio and (or) video elements controlled by the messaging system 2; in particular, in the case of a graphical element, this dataset contains for each graphical element at least a unique identification code (ID_ELEMENT) of this element, which preferably defines the primary key of this dataset.

Conveniently, the user data set 15 contains a unique user identification code (ID_USER), preferably defining the primary key of this data set.

Desirably, the user dataset 15 contains a unique user identification code, a username and password, and preferably also a first and last name, a contact link (eg, an email address), and other standard registration data.

Accordingly, the chat dataset 18 contains a unique identification code (ID_CHAT) for each chat 14, preferably defining the primary key of that dataset.

Accordingly, the message data set 20 contains a unique identification code (MESSAGE_ID) of each message 60, preferably defining the primary key of this data set.

Preferably, the element dataset 22 contains, in addition to the unique identification code (ID_ELEMENT) of the graphic and/or audio element 33, an address or location (e.g., a web site URL) of an additional database, including in the cloud, and preferably an accurate the address or location of a corresponding entry in this database in which the data defining the actual graphic and/or audio element 33 is stored in an organized manner. According to the preferred embodiment of the invention, in the dataset 22 of the central database 12, the unique identification code (ID_ELEMENT) of the graphic and/or audio element 33 corresponds to a unique address or location (preferably a web address) that identifies an entry in the additional database 47 (also in the cloud) where the data that defines the actual item 33 is stored.

Conveniently, the database 12 is designed and structured such that the user dataset 15 and the chat dataset 18 are linked to each other via a first link 21 (which is essentially a different dataset), so that each chat data from data set 18 to associate with the data of two (or more) users from the data set 15 participating in it.

Accordingly, the database 12 is designed and structured such that the chat dataset 18 and the message dataset 20 are linked to each other via a second link 23 (which is essentially a different dataset), so that each message data 60 from the dataset Associate 20 messages with chat data 14 from the chat dataset 18 in which these messages were exchanged.

Accordingly, the database 12 is configured and structured such that the message data set 20 and the item data set 22 are linked via a third link 25 (which is essentially an additional data set) in order to link each message data 60 from the message data set 20 with the data of the elements 33 contained in said message.

Accordingly, the database 12 is designed and structured such that the user data set 15 and the item data set 22 are linked via a fourth link 27 (which is essentially a different data set) in order to link each user data or user data set 15 to elements 33 from the data set 22 elements to which each user has access and (or) which can be controlled (used) by each user. Conveniently, in said messaging system 2, each element 33 managed within system 2

- 6 042772 messaging, had a unique identification code ID_ELEMENT and associated with it.

Accordingly, the messaging system 2 is configured such that each object (i.e., each chat 14, message 60 or item 33) created or generally present and exchanged in the messaging system 2 can be of two types:

the first type, hereinafter defined as an open type (i.e. open and free access or display), in which the corresponding object is always visible on the display of the device, and this does not require any unlocking procedure to be performed (preferably by pre-recognition and ( or) entering any access key), or the second type, hereinafter defined as a dedicated type (i.e. with dedicated and secret access or display), in which the display of the corresponding object on the display of the device, on the contrary, requires an unlock procedure (preferably by prior recognition and (or) correct entry of a special access key).

In addition, the messaging system 2 is implemented in such a way that each object of the second distinguished type can have two states:

a first state, hereinafter referred to as hidden, when the specified object is not displayed on the display of the device, or a second state, hereinafter referred to as visible, when the specified object is displayed (in full and (or) in preview mode) on the screen played on the display of the device.

In particular, when the specified object of the second selected type is in a visible state, the object itself is displayed - in full and (or) in preview mode - on the corresponding screen played on the display of the device 4 and (or) 6, occupying a certain area (surface) of the screen (see Fig. 9b, 10b, 11b and 12b). When the specified object is in a hidden state, it is not displayed inside the corresponding screen played on the display of the device 4 and (or) 6, and also does not occupy the specified specific area (surface) of the screen that it occupies when it is in a visible state, which allows make its presence or existence imperceptible (see Figs. 9a, 10a, 11a and 12a). In more detail, when the specified object of the second selected type is in a hidden state, the corresponding display area, which after the unlocking procedure should be occupied by the specified object, is not displayed in any way and (or) is not occupied by other (previous or subsequent) objects. the first type.

Conveniently, when the chat 14 is in the first hidden state, on the screen 42, which contains a summary list of the user's various chats, the corresponding portion of the chat preview secure screen is not displayed or played by itself (see FIG. 9b); and when the message 60 is in the first latent state within the respective chat screen 57, its associated frame 59 containing the content of the message is also not displayed or played (see FIG. 10b); and when the graphic and/or audio element 33 is in the first hidden state, the space within the message 60 (see Fig. 11b) or on the keyboard 35 (see Fig. 12b) occupied by said graphic and/or audio element was also not displayed. or was not occupied by adjacent text, graphic and (or) audio elements of the first open type. Accordingly, therefore, when the object (chat, message, graphic and (or) audio element 33) of the second distinguished type is in the first hidden state, there is no feedback or visual indication on the display that will allow one to notice the existence (presence) of the hidden object in the exchange system. messages.

In addition, the messaging system is suitably designed so that the unlocking procedure for transferring objects of the second distinguished type from the first hidden state to the second visible state occurs in such a way that, on each unsuccessful attempt, no visual feedback is provided regarding the failure of this attempt, and preferably the screen remains the same. This, in particular, is expedient so that an outside user who has received a device at his disposal does not even notice the existence of the selected objects of the second type; in fact, even after an accidental or deliberate unlock attempt (for example, an attempt to enter a password) fails, the display screen remains the same and the outside user will not receive any visual feedback (i.e. there will be no message like: Wrong password), and therefore it will not notice if the selected objects of the second type are present.

Accordingly, the first program module and/or the second program module are implemented so that the following objects can be created and exchanged in the messaging system 2:

object of the first open type, including at least one chat 14, message 60 and (or) digital element 33, which is always visible on the corresponding screen played on

- 7 042772 display device 4 and (or) 6, and an object of the second type, including at least one dedicated chat 14, message 60 and (or) digital element 33, which is in one of the following states:

the first hidden state in which said at least one chat 14, message 60 and/or digital element 33 are not reproduced in any way and are not displayed on the corresponding screen played back on the display of the device 4 and/or 6, without occupying any display area, the second visible state, in which the specified at least one chat 14, the message 60 and (or) the digital element 33 is completely and (or) in its preview mode is reproduced and displayed on the corresponding screen played on the display of the device 4 and ( or) 6 while occupying the display area.

Preferably, for this purpose, the database 12 contains a selection dataset 70 associated with a user dataset 15, a chat dataset 18, a message dataset 20, and an item dataset 22.

Preferably, each object of the second distinguished type is in the first hidden state by default.

Preferably, each object of the second selected type is changed from a hidden state to a visible state after performing an unlocking procedure performed on or through the device 4, 6, on the display of which said objects will be viewed.

Preferably, each object of the second selected type automatically switches from a visible state to a hidden state after a predetermined time, and (or) when the user performs a certain action on the specified device 4 and (or) 6.

Preferably, in the messaging system according to the invention, each object of the second dedicated type is not always automatically downloaded from the server, but is preferably downloaded only if the unlock procedure was successful (i.e., with a positive result). This is useful both from the point of view of saving on data usage, and from the point of view of the confidentiality of managing objects that are downloaded locally from the central unit 8 to the device 4 and (or) 6 only after prior authorization. In particular, the selected object data set 70 is configured such that each entry 71 from this data set contains at least the following three fields:

a unique object identification code ID_ITEM from chat data set 18, message data set 20, or item data set 22; in particular, the unique identification code ID_ITEM may be a code for a chat 14, a message 60 or an item 33, a unique identification code for a user ID_USER from a set of user data 15; in particular, for a particular chat 14 or message 60, this identification code corresponds to the code of the user participating in said chat or being the sender or recipient of the message; while for elements 33 this identification code corresponds to the code of the user who has access and (or) is allowed to control (use) the indicated element, the code identifying the access key (ACCESS_KEY) 5, which must be entered (printed) in order to be able to view the corresponding object on the display associated with device 4, 6.

Essentially, the selection dataset 70 is associated with the user dataset 15, the chat dataset 18, the messages dataset 20, and the item dataset 22, to result in populating it with a unique user ID_USER ID_USER from the 15 user dataset and a unique identification code GO_SNAT from chat data set 18, or ID_MESSAGE from message data set 20, or ID_ELEMENT from element data set 22, which is then combined with the code defining access key 5 to display the corresponding chat 18, message 60, or element 33.

Accordingly, the primary key of each record 71 of the selected object data set 70 may be determined by the field (Object type) related to the object type, the unique ID_ITEM code of the corresponding object (obtained from the chat data set 18, messages data set 20, or item data set 22) and a unique user identification code ID_USER (obtained from a data set of 15 users).

Alternatively, all objects (chat 14, messages 60 and elements 33) of the messaging system 2 according to the invention, regardless of their type, are uniquely identified in the database 12 by a unique identification code (i.e. ID_CHAT, ID_MESSAGE and ID_ELEMENT codes). are unique not only within one data set, but also among all data sets 18, 20 and 22). In particular, this means that in the database 12, each chat in the chat data set 18 of the messaging system 2 has its own unique identification code ID_CHAT, which is therefore necessarily different not only from other chats in the chat data set 18, but also from the identifiers ID_MESSAGE of the individual messages present in the message dataset 20 and the ID_ELEMENT of the individual elements from the dataset 22 elements.

- 8 042772

Therefore, the primary key of each entry from the selected object dataset 70 can only be determined by the specified primary key ID_CHAT, ID_MESSAGE, and ID_ELEMENT used in the chat dataset 18, message dataset 20, and element dataset 22, respectively.

Conveniently, if a specific object of a specific user is present in the selected object dataset 70, then only for that specific user will that object be of the selected type; conversely, if a specific object of a specific user is not present in the selected object data set 70, then only for that specific user, this object will be of an open type.

In more detail, the chat data set 18 contains data of all chats 14 exchanged in the messaging system 2 (both open and dedicated type), the message data set 20 contains data of all messages exchanged in the messaging system 2 (both open , and dedicated type), the element data set 22 contains the data of all elements exchanged in the messaging system 2 (both open and dedicated type).

The selected object dataset 70 contains identification data relating only to chats 14, messages 20, or items 33 of the selected type. In more detail, this means that the identification data relating only to chat 14, messages 20 or open type elements 33 will not have a corresponding entry 71 in the data set 70 of the selected objects. As such, not all chat 14, message 20, or element 33 identification codes from the respective datasets 18, 20, and 22 are called up and present in the selected object dataset 70.

It is convenient that in the messaging system 2 each object of the selected type (and therefore having a corresponding entry 71 in the data set 70 of the selected objects) is by default in a hidden state and temporarily switches to a visible state only after a preliminary and correct entry of the code corresponding to the key access 5, which is associated with each object in the data set 70 selected objects.

Conversely, each object of the open type (hence without a corresponding record 71 in the data set 70 of selected objects) was always only in the visible state, i.e. when the specified object (in its entirety and (or) in its preview mode) is always available to view on the screen being played on the display of the device.

Data set of 18 chats.

Preferably, the database 12 is designed and structured such that each chat 14 created and present in the messaging system 2 has or is associated with the following fields:

unique identifier ID_CHAT chat; in particular, this code defines the primary key from the chat data set 18, the unique identification codes of the users participating in the chat;

a code identifying a shared access key 80 (ACCESS_KEY_CHAT) 80 that is the same (i.e., shared) and shared between chat participants, to be entered (printed) to enable each chat participant to view the corresponding chat on the display of the corresponding device associated with it .

Conveniently, in the messaging system 2, each chat 14 could be of two types:

open type 14' for all participating users, in which the corresponding chat is always displayed on the display of all devices controlled by users participating in the chat, without the need for any prior recognition and / or input of any access key, or a dedicated type 14 for all participating users, in which the display of the corresponding chat on the display of devices controlled by all users participating in the chat, on the contrary, depends on the correct entry of this special shared key 80.

In particular, if the ACCESS_KEY_CHAT field is not assigned a value (ie, it is empty) or is assigned a value according to a predefined default value, the chat 14 will be of the open type 14' for all participating users; in contrast, if the ACCESS_KEY_CHAT field is set to a value with a specific shared key 80 (eg, as a string), the chat 14 will be of the dedicated type 14 for all participating users.

In addition, in the messaging system 2, each chat 14 of the selected type 14 can be in two states:

visible state, when the entire chat and/or its preview is displayed on the screen playing on the device display, or hidden state, when the chat is not shown on the device display.

Conveniently, in the messaging system 2, each chat 14 of the dedicated type 14 (and therefore having an ACCESS_KEY_CHAT field set to a value with a specific shared key 80) is by default in a hidden state and temporarily transitions to a visible state only after a preliminary and correct input by the user participating in said chat, the code corresponding to the key 80 of the general access.

Conversely, each chat 14 of the open type 14' has always had a visible status, ie the entire chat and/or its preview has always been displayed on the screen being played on the display of the device.

Preferably, each chat 14 may contain a field relating to the unique identification code of the user who created the chat and/or a field relating to the date the chat was created. Data set 20 messages

Preferably, the database 12 is designed and structured such that each message 60 created in the messaging system 2 exchanged therein has or is associated with the following fields:

the specified unique identification code (ID_MESSAGE) of the message 60; preferably defining the primary key of the message data set 20, the identification code of the chat 14 to which the message 60 relates; in particular, this code is determined by the primary key ID_CHAT from the chat data set 18, the unique identification code of the user who sent the message, the unique identification code of the user or users who received the message, the code identifying the shared access key 80 (ACCESS_KEY_MESSAGE) to be entered (printed) to be able to view a specific message 60 in the chat displayed on the screen played on the display of the device.

Conveniently, in the messaging system 2, each message 60 can be of two types:

open type 60', in which for all participants in a particular chat 14 the corresponding message 60 is always displayed in the specified chat 14, and it does not require any prior recognition and (or) input of a shared key 80, or a dedicated type 60, in which for all participants in a particular chat 14, the display of a message in the specified chat 14 to which it refers depends on the correct entry of the particular public key 80 .

In particular, if the ACCESS_KEY_MESSAGE field is not assigned a value (ie, it is empty) or is assigned a value according to a predefined default value, the message 60 will be of the public type 60' for both sender and recipient(s); conversely, if the ACCESS_KEY_MESSAGE field is set to match a particular public access key 80 (eg, as a string), the message 60 will be of the distinguished type 60 for both the sender and the recipient(s).

In addition, in the messaging system 2, each message 60 of the dedicated type 60 can be in two states:

a visible state, when the entire message and/or a preview of it is shown on the screen being played on the device display; or a hidden state, when the message is not shown on the device display. Conveniently, in the messaging system 2, each message 60 of the allocated type 60 (having an ACCESS_KEY_MESSAGE field set to a value with a specific public access key 80) is by default in a hidden state and temporarily switched to a visible state only after a preliminary and correct entry of a code corresponding to key 80 public access.

Conversely, each message 60 of the open type 60' has always had a visible status, i.e. its content and/or its preview can always be displayed on the screen displayed on the display of the device.

Preferably, each message 60 may also be associated with one or more of the following fields: the date the message was created; the date the ACCESS_KEY_MESSAGE field associated with the public access key 80 was filled; accordingly, this saves the date when the display of a particular message in the chat became dependent on the correct pre-entry of a certain public key 80 (ie, when the message 60 became of a dedicated type).

Dataset 22 items.

Preferably, the database 12 is designed and structured such that each graphic and/or audio element 33 inserted into a message 60 created in the messaging system 2 exchanged therein has the following fields and/or is associated with them:

a unique identification code (ID_ELEMENT) graphic, audio and (or) in General multimedia element 33; preferably, this code defines the primary key of the element data set 22, the unique identification code of the message 60 in which said graphic and/or audio element 33 is inserted; in particular, this code is determined by the primary key from the message data set 20, a code identifying the shared access key 80 (ACCESS_KEY_ELEMENT) that must be entered (printed) in order to be able to view a specific graphic and (or) audio element in the message 60 displayed in the corresponding the chat to which it refers, on

- 10 042772 screen played on the display of the sender's and/or recipient's device.

Conveniently, in a messaging system 2, each element could be of two types:

open type 33', in which for all users of a given message 60 the corresponding element 33 is always visible in the specified message 60 to which it refers, and it does not require any prior recognition and (or) input of a public access key 80, or a dedicated type 33, in which for all users of a particular message 60, the display of element 33 in the message 60 to which it refers depends on the correct entry of the special key 80 of the public access.

In particular, if the ACCESS_KEY_ELEMENT field is not assigned a value (i.e., it is empty) or is assigned according to a predefined default value, element 33 will be of public type 33' for all users (both sender and receiver( to her)); conversely, if the ACCESS_KEY_ELEMENT field is set to a value with a specific shared key 80 (eg, as a string), element 33 will be of distinguished type 33 for all users (both sender and recipient(s)).

In addition, in the messaging system 2, each element 33 of the selected type 33 can be in two states:

a visible state when the specified item is fully displayed and/or in preview mode on the screen displayed on the display of the device, or a hidden state when the item 33 is not displayed on the display of the device.

Conveniently, in the messaging system 2, each element 33 of the dedicated type 33 (having an ACCESS_KEY_ELEMENT field assigned a value with a specific public access key 80) is by default in a hidden state, and only temporarily changes to a visible state after a preliminary and correct entry of a code corresponding to key 80 public access.

Conversely, each element 33 of the open type 33' has always had a visible status, i.e. its content and/or its preview can always be displayed on the screen being played back on the display of the device.

Preferably, each graphic and/or audio element 33 inserted into a message 60 created or exchanged within the messaging system 2 may also have one or more of the following fields associated with it:

a unique identification code of the user who filled in the ACCESS_KEY_ELEMENT field related to the public access key 80; by the way, in this way it is possible to keep track of who created the visualization of a particular element 33 inside the message 60, depending on the correctness of the preliminary input of a certain key 5, the type of a particular element; for example, this may concern a graphic element (eg, emoji® or avatar), an audio or video element, the date that the ACCESS_KEY_ELEMENT field related to the public access key 80 was filled; accordingly, the date is thus stored when the display of a certain element 33 in the message 60 became dependent on the correct pre-entry of the special key 80 of the public access.

Software modules.

Inside the sending device 4 and/or the receiving device 6, the first software module is loaded and/or executed.

Conveniently, the second software module, designed to control communication with the sender 4 and the receiver 6, and therefore to control the sending and receiving of messages and notifications, is loaded and/or executed within the central unit 8.

In the following, the term object will refer to one or more chats 14, one or more messages 60, and/or one or more graphic and/or audio elements 33. In particular, the term object will also refer to an embedded chat, as will be better explained below.

Creating objects of a dedicated type only for a specific user (see Fig. 9)

Accordingly, the first program module, when it is executed in the device, has the ability to create in the database 12 a new entry 71 in the set of selected object data 70, in which one or more objects associated with the user logged into the messaging system 2 are associated with the key 5 individual access, which makes the specified objects of the distinguished type for that user.

In particular, the first program module provides for the possibility of creating a new record 71 for a data set 70 of selected objects containing:

identification code ID_ITEM of a specific object, identification code ID_USER of a user who is logged into the messaging system 2 and associated with the specified object, an access key ACCESS_KEY 5 that the user logged into the messaging system 2 wishes to associate with this particular object.

Accordingly, the identification code ID_ITEM of this object may contain:

identification code ID_CHAT of the chat 14 in which the user logged in to the messaging system 2 participates, or the identification code ID_MESSAGE of the message 20 sent or received by the user logged in to the messaging system 2, or the identification code ID_ELEMENT of the element 33 used in message by the user who is logged into the messaging system 2.

Conveniently, in this case, a particular object will be of a dedicated type only for that user having, in the selected object dataset 70, a corresponding ID_USER associated with the ID_ITEM of that particular object.

In fact, a situation is possible when, for example, a specific message of a dedicated type was created for the sender (i.e., in the data set 70 of selected objects, there is a corresponding record 71 in which the ID_MESSAGE message identification code is combined with the ID_USER sender identification code and the KEY_ACCESS access key ), while it remains an open type for the recipient (i.e., there is no corresponding entry in the allocated object dataset 70 in which the ID_MESSAGE of the above message is combined with the recipient's ID_USER).

Displaying objects of the selected type only for a specific user (see Fig. 10).

Accordingly, the first software module, when it is executed in the device, provides that objects belonging to the selected type (that is, they have a corresponding entry in the data set 70 of the selected objects) for this particular user logged into the messaging system 2, temporarily move from a hidden state to a visible state after a preliminary and correct entry of the ACCESS_KEY code corresponding to the access key 5, which in the corresponding record 71 from the data set 70 of the selected objects is associated with the identification code ID_ITEM of the specified object and the identification code ID_USER of the given user logged into the messaging system 2 .

Conveniently, the first software module running on the device provides for the possibility of performing a display unlocking procedure designed to transfer objects that for a given user are of a selected type from a hidden state to a visible state. Preferably, this procedure includes the following operations:

receive the access code entered by the user by acting on the device in which the first program module is executed, preferably by acting on the keyboard 35 provided in the device or displayed on the touch screen of the device, check whether there is an object in the data set 70 of selected objects (i.e. e. chat 14, message 60 and/or graphic and/or audio element 33), whose access key code ACCESS_KEY 5 corresponds to the code entered by the user, and which, in addition, the unique user identification code ID_USER corresponds to the code of the user logged into messaging system, only in case of a positive result of the check, the corresponding object or objects (in full and (or) in the preview mode, even partial) are displayed on the display of the device associated with the user who is logged into the system and whose set value of the access key 5 matches the code entered by the user; and vice versa, in the case of a negative test result, the corresponding object or objects are not displayed on the display of the device.

It is preferable that objects of the selected type, which by default are in a hidden state and, after the unlocking procedure, go into a visible state, retain this visible state only temporarily (for a predetermined time, and (or) until the user performs a certain action on the device and/or until a certain event occurs) and then returned to a hidden state until a subsequent display unlock procedure is performed.

Accordingly, the first software module executable in the device is implemented with the possibility of temporarily displaying on the display of the device objects belonging to the selected type for a particular user (ie, those that have the corresponding entry 71 in the data set 70 of the selected objects).

Preferably, the first software module executing in the device is configured to automatically interrupt the display of said objects of the selected type on the display of the device (and, as a result, transfer them from a visible state to a hidden state) after a predetermined time interval, which preferably can be set by the user.

Preferably, the first software module executable in the device is configured to automatically interrupt the display of the indicated objects of the selected type on the device display (and, as a result, transfer them from a visible state to a hidden state) after a certain action that the user performs on the device ( for example, double-tapping a certain area of the touch screen and/or long pressing a certain button). Preferably, the first software module executing in the device is configured to automatically interrupt the display of said selected objects on the device display.

- 12 042772 types (and, as a result, their transition from a visible state to a hidden state) after an event caused by one or more of the following actions:

act on a special button (for example, touch) that is displayed on the screen displayed on the touch screen of the device, act to close or put a special messaging application into the background, act to lock the screen of the device, act to put the device into standby mode, or turning it off, the action taken to start a new chat 14 in the messaging system, the action to return to the previous screen, or to change the screen displayed.

Local personal subset.

Preferably, each device functioning as a sender and/or receiver in the messaging system 2 contains a local memory 90 into which a personal subset 75 can be loaded and stored, obtained from the central database 12 of the central unit 8 and containing all object data ( chats 14, messages 60 and/or items 33) of a particular user logged into the messaging system 2 using that particular device.

Conveniently, the local memory 90 is mass storage, main memory, or RAM, and may also be of the cache type.

Accordingly, the personal subset 75 is generated from the central database 12, loaded and stored in the local memory 90 of the respective device controlled by the user who has logged into the messaging system 2 using this device.

Conveniently, the personal subset 75 has a structure essentially corresponding to that of the central database 12, but without the user dataset 15. In particular, the personal subset 75 contains a chat dataset 18', a message dataset 20', an item dataset 22', and a selection dataset 70', however, each of these datasets contains only the respective objects associated with a user who, in specifically, is the user logged into the messaging system 2 from that particular device.

According to the invention, it is preferable that the first program module executable in the device of the sender and (or) the recipient, and the second program module loaded into the central unit 8, be implemented in such a way that after the first login to the system and (or) after each access to system 2 messaging on this device:

the first software module of the sending device 4 and the receiving device 6 sent to the central unit 8 data (username and password) that the user enters by influencing his device 4 and (or) 6 when he enters the messaging system 2, the second software module the central unit 8 checked the login data thus obtained (i.e. checked, preferably by querying the information contained in the user data set 15 in the central database 12, whether they together correspond to a user already registered in the messaging system), retrieved the identification code ID_USER of the respective user and, using the code thus retrieved, always identified in the central database 12 all objects in the selected object dataset 70 and preferably also in the chat dataset 18, in the messages dataset 20 and in the item dataset 22, which are associated with the identification code ID_USER of this user, the first program module of the sending device 4 and (or) the receiving device 6, respectively, loaded into the local memory 90 of the devices 4 and (or) 6 the objects thus identified, which respectively define the personal subset 75.

Conveniently, in this case, when objects of the selected type, which by default have a hidden status, are loaded into the local memory 90 of devices 4 and (or) 6 (and thus locally form a personal subset 75 of the data set 70 of the selected objects), they still have a hidden status and become visible only after the display unlock procedure is performed, while preferably the verification step is performed in the specified personal subset 75 present in the local memory 90. Conveniently, due to this, a faster data access speed is achieved , as well as the speed of passing the verification stage.

Alternatively, when objects of the selected type, defaulting to the status of hidden, are not loaded into the local memory 90 of the device, the step of checking the unlock procedure is performed in the data set 70 of the selected objects present in the database 12 loaded into the central unit 8. Conveniently, This ensures greater data security.

Conveniently, the synchronization step between the database 12 of the central unit 8 and the personal subset 75 in the local memory 90 of the device is performed each time a user accesses and/or logs into the messaging system 2 via the devices 4 and/or 6. Further, it is preferable so that the central unit 8 can send objects 4 and (or) 6 to each of the devices,

- 13 042772 which are managed and/or exchanged in the messaging system 2 as soon as they become available in the central unit, preferably notifying them via a push notification system.

Accordingly, the first program module and the second program module are implemented in such a way that each new entry 71 related to an object of the selected type is automatically added both to the data set 70 of the selected objects of the database 12 located in the central unit 8, and to the data set 70 ' selected objects of the personal subset 75 located in the local memory 90 of the sending and (or) receiving device.

Preferably, the first program unit and the second program unit are configured such that each new entry that can be associated with an object of a public or dedicated type is automatically added:

in the data set 18 chats, in the data set 20 messages and (or) in the data set 22 of the elements of the database 12 located in the central unit 8, as well as in the data set 18' chats, in the data set 20' messages and (or) in a set of data 22' of elements of a personal subset 75 present in the local memory 90 of the sending and/or receiving device.

Accordingly, the first program module and the second program module are configured to search for open type and dedicated type objects to be displayed on the corresponding screen of the device only in the personal subset 75 present in the local memory 90 of said device.

Accordingly, the first program module and the second program module are implemented with the ability to search for objects of open type and dedicated type, which will then be displayed on the corresponding screen of the device, both in the personal subset 75 present in the local memory 90 of the device, and in the central database 12 located in the central unit 8, and preferably first in the personal subset 75 and then in the central database 12.

Embedded chat.

Preferably, the above also applies to nested chat 49, which is essentially another chat that:

belongs to a distinguished type, and is created on the basis of the main chat (hereinafter referred to as the parent chat) and, in particular, actually functions in parallel with the latter.

Accordingly, nested chat 49 is formed in such a way that all participants in the parent chat or their subgroup are participants in it.

Therefore, it is convenient that the nested chat 49 contains a series of messages that are sequentially exchanged between the sender and at least one recipient (or several recipients in the case of a group chat) who are also participating in the parent chat. Conveniently, each nested chat could contain a number of participants equal to or less than the number of participants in the parent chat, and in particular, the set of participants in the nested chat would be a subset of the participants in the parent chat.

Therefore, preferably, only users of the parent chat can be members of a sub-chat generated from the parent chat, and accordingly, the sub-chat can be accessed using the key associated with said sub-chat. In addition, participants in a sub-chat will only be aware of the existence of this sub-chat after the user of the parent chat creates said sub-chat and appropriately shares this information with other users of the parent chat that he has chosen.

Accordingly, the display (playback) of the nested chat 49 may take place on an additional dedicated screen different from the screen of the parent chat 14 to which the messages refer; this additional screen is preferably played automatically as soon as the shared key 80 is correctly entered, and may occupy the entire display of the device (thus completely covering the previous screens) or part of it (preferably, the parent chat 14 remains in the background).

Preferably, in order to manage nested chats, the database 12 is designed and structured so that the chat 18 from the data set is provided with an additional PARENT_CHAT field, which can:

not assigned a value (i.e. it will be empty - null) or assigned a value according to a predefined default value, and this means that the corresponding chat 14 of record 76 is a parent chat and does not depend on other chats or is not derived from them (i.e. it is not a nested chat) is assigned a value with the unique identification code of a specific chat 14, and this means that the corresponding chat of record 76 is a nested chat 49 that depends on or derives from the parent chat 14 042772.

Moreover, conveniently, in the data set of 18 chats of record 76, in which the PARENT_CHAT field is set to a value with a unique identification code for this chat 14, the ACCESS_KEY_CHAT field is also set to a value with a code that identifies the shared access key 80 to allow participants in the nested chat 49 ( whose identification codes are assigned a value in the USERS field of the 18 chats dataset) switch the same nested chat from a hidden state to a visible state. Conveniently, as a result of this, nested chat 49 always refers only to the selected type.

In essence, if a particular record 76 of the 18 chats dataset has the PARENT_CHAT and ACCESS_KEY_CHAT fields set to (non-default) values, then the corresponding chat is a nested chat 49; conversely, if in a given record 76 of the chat data set 18 the PARENT_CHAT and ACCESS_KEY_CHAT fields are not assigned a value (or have a default value assigned to them), then the corresponding chat is the parent chat 14 of the nested chat or a simple chat that does not have a nested chat.

In addition, the chat data set 18 is configured such that the USERS field of the nested chat 49 includes all or part of the unique identification codes of users participating in the corresponding parent chat 14.

Preferably, the database 12 is configured and structured such that each message 60 of the message dataset 20 exchanged within (and therefore associated with) the nested chat 49 is automatically assigned a dedicated type.

Preferably, the database 12 is configured and structured such that each element 33 of the message 60 that is exchanged within (and therefore associated with) the nested chat 49 is automatically of a dedicated type. Preferably, all messages 60 and/or all elements 33 of nested chat 49 are of a dedicated type, since the corresponding screen containing them, and in particular the screen of the corresponding nested chat 49, is of a dedicated type.

Preferably, the first program module is configured to load, at least temporarily, into the local memory 90 of the device (on which said module is running) a dedicated type nested chat 49 only after the download unlock procedure has been successfully executed and completed, as described in more detail below. Furthermore, it is preferable that the nested chat 49 of the dedicated type, once downloaded to the local memory 90 of the device (after performing the download unlock procedure) and once temporarily displayed on the device display (without or after performing the display unlock procedure), is then automatically deleted from the device. device local memory. Therefore, in this case, in order to be able to view the nested chat 49 again (that is, to switch it from a hidden state to a visible state), it is necessary to perform an additional download unlock procedure in advance.

Performing Local Loading of Public and Dedicated Objects Conveniently, in the first embodiment of the invention, the first software module is configured to load into the local memory 90 of the device running said module a personal subset 75 of all objects (i.e., both open type objects and and objects of a dedicated type) associated with a user logged into the messaging system 2 on that device.

Accordingly, in this case, the first program module also provides the following:

personal subset 75 objects of an open type (i.e., those that do not have a corresponding entry 71' in the dedicated object dataset 70' and have a corresponding public access key code 80 from the chat dataset 18', dataset 20' messages or data set 22' element not assigned a value or assigned a predefined value) can always be automatically displayed on the display of the device in which the specified first module is running (i.e. without the need to first enter an individual 5 or general 80 access key in order to have the ability to view them), objects of the personal subset 75 belonging to the selected type (i.e. those that have a corresponding entry 71' in the data set 70' of the selected objects and in which the corresponding key code 80 of the public access from the data set 18' chats, or the message data set 20' or the element data set 22' has been assigned a value not predetermined) can only be viewed on the display of the device after the code corresponding to the individual access key 5 or the public access key 80 has been previously and correctly entered.

Conveniently, the first software module executing on the device is capable of executing a display unlocking procedure to change objects of the second type (ie, the selected type) from a hidden state to a visible state. Preferably, this procedure includes the following operations:

receive the access code entered by the user by acting on the device in which the first program module is executed, preferably by acting on the keyboard 35 provided in the device or displayed on the display of the device,

- 15 042772 reload the corresponding screen, storing in memory the access code entered by the user, and check whether among the objects associated with this screen (and in particular the chat played on this screen) in the personal subset 75 present in the local memory 90 of the device, an object with an individual access key 5 or a public access key 80 that corresponds to the entered code, only in the case of a positive test result on the corresponding screen of the device 4 display the corresponding object (in full and (or) in preview mode, even partial), the value of the individual access code 5 or the public access key 80 of which matches the code entered by the user; and vice versa, in the case of a negative test result, the specified object is not displayed on the display of the device.

It is preferable that objects of the selected type, which by default have the status of hidden and, after the unlocking procedure, go into the visible state, retain this visible state only temporarily (for a predetermined time, and (or) until the user performs a certain action on the device, and/or until a certain event occurs), and then returned to a hidden state until a subsequent display unlock procedure is performed.

Accordingly, the first program module executable in the device is implemented in such a way that objects of the second type are temporarily displayed on the display of the device itself.

Preferably, the first software module executing in the device is configured to automatically remove the display of said objects of the selected type from the display of the device (and consequently change them from a visible state to a hidden state) after a predetermined time interval, which preferably can be set by the user.

Preferably, the first software module executing in the device is configured to automatically remove the display of the specified objects of the selected type from the display of the device (and, as a result, transfer them from a visible state to a hidden state) after a certain action that the user performs on the device ( for example, double-tapping a certain area of the touch screen and/or long pressing a certain button).

Preferably, the first software module executing in the device is configured to automatically remove the display of said objects of the selected type from the display of the device (and, as a result, change them from a visible state to a hidden state) after an event triggered by one or more of the following: :

act on a special button (for example, touch) that is displayed on the screen being played on the touch screen of the device, act to put the special messaging system application in the background or close it, act to set the lock screen of the device, act to put the device into idle or off, the action taken to start a new chat 14 in the messaging system, the action to return to the previous screen or change the screen displayed.

Preload locally only open objects

In the second embodiment of the invention, the first program module is also configured to preload into the local memory 90 of the device in which the specified module is executed, only those public type objects that are associated with a user logged into the messaging system 2 on this device.

Conveniently, as a result, only public type objects are loaded into the local memory 90 of the device, and therefore they are always automatically displayed on the display of the device, without requiring the preliminary entry of the individual access key 5 or the public access key 80. In this case, it is convenient that the first program module also provides that the objects loaded in this way are always automatically viewed on the display of the device in which said first module is running (i.e. without requiring any prior input of the individual access key 5 or the public key 80 access to be able to view them).

Preferably, in this second embodiment of the invention, the first program module is also configured to load, at least temporarily, into the local memory 90 of the device (in which said module is executing) objects of a dedicated type, and only after the user has previously and correctly entered a code corresponding to said key 5 individual access or key 80 general access.

In particular, the first program module executing in the device and the second program module executing in the central unit 8 are configured to cooperate with each other to perform a download unlock procedure for locally downloading objects of a dedicated type. Preferably, this procedure includes the following steps:

the first software module of the device sends to the second software module of the central

- 16 042772 block 8 the code that the user enters by acting on his device, preferably on the keyboard 35 provided in the device or displayed on the display of the device, the second program module of the central unit 8 checks the received data and, in particular, checks whether there is in the central database 12 for this particular user logged into the messaging system, an object that has an individual 5 or general 80 access key corresponding to the code entered by the user, only in the case of a positive check result, the first software module loads from the central unit 8 into the local memory of the device ( in which the specified module is executed) the corresponding object (in full and (or) in preview mode, even partial), the value of the private access key 5 or the public access key 80 of which matches the code entered by the user; conversely, in the case of a negative test result, the first program module does not perform any download.

Therefore, it is preferable that, once loaded into the device's local memory, these objects of a dedicated type can also be viewed directly on the device's display (without the need to perform any procedure to unlock the display). It is convenient that in this case, when objects of the selected type, which by default have a status of hidden, are loaded into the local memory of the device after the download unlock procedure is performed, they also automatically switch to a visible state and save it only temporarily (for a predetermined time, and (or) until the user performs a certain action on the device, and (or) until a certain event occurs), and then returned to a hidden state and maintained it until a subsequent boot unlock procedure was performed.

Alternatively, after loading into the local memory of the device running the first software module, these objects are displayed on the display of said device only after subsequent preliminary and correct entry by the user of the code corresponding to the specified individual access key 5 or public access key 80 (t i.e. after performing the display unlock procedure as described above). Conveniently, in this case, when objects of the selected type, defaulting to hidden status, are loaded into the local memory 90 of the device after the download unlock procedure is performed, they still have the hidden status and become visible only after the display unlock procedure is performed. In addition, these objects retain their visible state only temporarily (for a predetermined amount of time, and/or until the user performs a certain action on the device, and/or until a certain event occurs), and then return to a hidden state. and keep it until an additional boot unlock procedure is performed.

Preferably, objects of a dedicated type, once loaded into the local memory 90 of the device (after performing the download unlock procedure) and once temporarily displayed on the device display (without or after performing the display unlock procedure), are then automatically deleted from the local memory of the device. Therefore, in this case, in order to be able to view them again (that is, to switch them from a hidden state to a visible state), it is necessary to perform an additional download unlock procedure in advance.

Key of individual or joint (general) access.

Code that assigns a value to an individual access key 5 field (i.e., the ACCESS_KEY field in the allocated object dataset 70 or 70') or a shared (shared) access key 80 field (i.e., the ACCESS_KEY_CHAT field in the chat dataset 18 or 18') to display objects of the selected type, may contain:

a sequence of alphanumeric characters, special characters, punctuation marks, and/or a sequence of graphical elements 33 related to the type of elements that are sent in the messaging system within the screen area occupied by the message (preferably within the frame 59); Preferably, these graphical elements contain symbols, icons or, in general, images to be inserted (selected) using the input keyboard 35 displayed on the display of the device, and preferably these images express some concept, emotion or mood. emoji, the sequence of media available in the device's memory, answers to open-ended questions, biometric codes (for example, fingerprints, retina, iris, face or voice recognition, etc.).

Preferably, the field for entering an individual 5 or shared (common) 80 access key (which is essentially a password) can be filled with a sequence of graphic elements of the type that can be inserted into the message area, separately and (or) between words on the same line with the text of the message itself.

Accordingly, the first program module provides that the code corresponding to the individual 5 or shared (shared) 80 access key that the user enters and inserts, acting on the device in which the specified program module is executed, in order to translate the object of the selected type from a hidden state to a visible state, is displayed during input on the display of the device itself, possibly in a mode in which individual code components are hidden in the traditional way using appropriate symbols (for example, asterisks or dots).

Alternatively, the first program module may be configured such that the code corresponding to the individual 5 or shared (shared) 80 access key that the user enters and inserts, influencing the device on which the specified program module is executed, in order to translate the object selected type from a hidden state to a visible state, is not displayed in any way on the display of the device itself, and in particular, even the individual components of the specified code are not obscured. In other words, when the user operates the keyboard 35 to enter the aforementioned code, the screen displayed on the display of the device (or at least the portion of the screen not occupied by the keyboard 35) remains essentially the same.

Preferably, the first program module is implemented in such a way that the method of entering the code corresponding to the individual 5 or joint (general) 80 access key, in order to transfer the selected type object from the hidden state to the visible state, is automatically activated after entering using the keyboard 35 for typing a certain sequence (marker) of pre-coded characters, symbols, graphic elements 61 before and (or) after the specified access key 5 (see Fig. 5) or after a certain action performed by the user on the device (for example, double-tapping a certain touch screen area and/or a long press on a specific button).

Accordingly, a sequence of pre-coded characters, symbols or graphic elements, which essentially acts as a marker, is entered before or after the access key 5 . In essence, therefore, when the first program module receives a certain sequence of characters, symbols, or pre-coded graphic elements, or when it captures a certain action, said module is activated and automatically goes into data transmission standby mode, so that subsequent inserted characters entered using the keyboard 35 for typing, are considered as components of the code that defines the key of individual 5 or shared (general) 80 access.

Modes of operation in the messaging system.

Preferably, the first program module provides for the following:

the object belonged to the distinguished type from the moment of its creation (initialization), and (or) the open type object, already created and initialized, was converted to the specified distinguished type or vice versa.

Accordingly, for this purpose, the first software module is implemented in such a way as to enable the user to operate in a first mode (referred to as secret), in which all new objects created (i.e., one or more chats 14 and (or) one or more messages 60 ) or new objects used (i.e., one or more elements 33 inserted in the message) are automatically of the distinguished type. In particular, in this case, the first program module is implemented in such a way that the activation of the first (secret) mode is associated or dependent on the insertion (input) of the individual access key 5, so that the latter is automatically associated with all objects that are created or used when working in this first mode.

Accordingly, the first software module may be configured to allow the user to operate in a second mode (referred to as public), in which all created objects (i.e., one or more chats 14 and/or one or more messages 60) or the objects used (ie, one or more graphic and/or audio elements 33 inserted into the message) are of an open type. Preferably, in this case, the first program module is implemented in such a way as to allow the user to select one or more objects, and after entering (printing) the corresponding individual access key (which is thus automatically associated with the indicated objects, creating the corresponding entry 71 there are 70 selected objects in the dataset) they become elements of the selected type.

Preferably, the screens displayed on the display of the device are provided with a special icon (hereinafter referred to as the secret icon), which is selected, for example, by touching or clicking with the pointer to activate or go to the first mode (called secret) and / or convert the selected objects from an open type to a dedicated type.

Screens.

Accordingly, the first program module is also configured to display on the screen of the device 4,6 a plurality of screens relating to various functions implemented in the messaging system 2 in accordance with the invention.

Preferably, the first program module is implemented in such a way that the keyboard 35 for typing is displayed on the display of the device, and in it, on one or more pages, alphanumeric characters, special characters, punctuation marks, graphics and ( or) audio elements 33. Preferably, the typing keyboard 35 is configured to occupy the lower part of the display of the device.

Preferably, the first program module is configured to display on the screens displayed on the display of the device, the respective selectable areas 47 (preferably marked with special icons 47' and / or appropriately highlighted graphically) which, if selected, after an external activation event (for example, a short touch in the case of a touch-type display or a click, for example, with a pointer) issue an activation command for one or more corresponding special functions. Accordingly, said selectable areas 47 are identified by an icon 47' or a special inscription that represents the respective function or is associated with a function that can be activated.

Displaying objects of the selected type.

Preferably, the first program module is designed such that the objects of the dedicated type, when they are in a visible state (and therefore displayed on a screen played on the display of the device), are displayed together with the objects of the open type. Preferably, but not necessarily, in this case, the first software module can be implemented in such a way that objects of the selected type, when they are in a visible state, have a graphical appearance (for example, due to color, shadows and (or) frames) that differs from objects of open type.

Preferably, the first software module is designed such that the objects of the dedicated type, when they are in a visible state (and therefore displayed on a screen played on the display of the device), are displayed separately, i.e. without objects of the open type.

Functioning.

The operation of the messaging system 2 according to the invention is clear from what has been described above, and accordingly, only some specific functions are disclosed and presented below for illustrative and non-limiting purposes only.

It should be recalled that, as previously indicated, the term object will hereinafter be understood as one or more chats 14, one or more messages 60 and (or) one or more graphic and (or) audio elements 33.

Creating a key 5 individual access.

Conveniently, the first software module is implemented with the ability to create and bind a private access key 5 to one or more objects as soon as a particular user has logged into the messaging system 2 .

For example, it is convenient for the user to select, by a predetermined action, such as touching, a special icon (eg, indicated by a button symbol) displayed on the screen of the messaging system 2 related to the user's profile.

Accordingly, this selection leads to the opening of a page that presents various operations that can be performed.

The user can easily select, through a certain action, the operation associated with the creation of the individual access key 5 .

The user then, using the insert keypad 35 provided in the device, enters the access code of their choice and completes this operation by selecting the confirmation icon. Accordingly, the impact on the confirmation icon automatically ensures that the code entered by the user is stored appropriately in the database 12 (ie, for each object in the data set 70 of selected objects, a corresponding entry is created). In this case, therefore, the code entered by the user and stored in the database 12 can subsequently be used as an access key to display one or more objects of a selected type associated with a user logged into the messaging system 2 on this device.

Deleting a private key.

It is convenient that the first software module provides for the possibility of deleting the previously created individual access key 5 from the local memory of the device.

Accordingly, the first program module is implemented in such a way that when the previously created individual access key 5 is deleted, the selected objects associated with it are also automatically deleted. As an alternative, the first software module can be implemented in such a way that when the previously created private key 5 is deleted, the objects of the dedicated type associated with it become objects of the open type and, therefore, will always be visible (namely, the corresponding entry 71 of data set of 70 selected objects).

Creating an object of a dedicated type for a particular user.

To create an object of a dedicated type for a specific user, the following steps of the flowchart are respectively provided:

- 19 042772

User Ui selects inside the screen Si an object (chat, message, element) Ci to make it an object of a dedicated type for himself only

I , '---------g

User Ui enters an individual key SKi for the selected object Ci ¹ I

In the data set of selected objects, a record is created both in the central database 12 and in the personal subset

The object becomes of the second ("allocated") type, and by default it is assumed that it is in a closed state

The screen Si is updated and the object display Ci disappears from the screen Si. '—' 1 ¹

Creating a chat of a selected type.

To create a chat 14 of the selected type, the user can perform the following operations:

open the 42 Conversations screen, which displays a list (preferably with a partial preview) of the various chats in which the user is the sender or recipient, click on the privacy icon in the Conversations 42 screen, open a special screen with various functions designed to for the first mode of operation (secret), click on the icon to create a new chat, enter the private access key 5, select the recipient's contacts.

Alternatively, to create a chat 14 of a dedicated type 14, the user 16 can perform the following operations:

create a new chat 14, select the recipient user to communicate with, click on the privacy icon present on the newly created chat screen 14 (blank), enter the private access key 5, confirm that chat 14 is of the selected type 14, enter the first message 60 to the chat created in this way 14.

Accordingly, it is understood that in a chat of a dedicated type 14, all messages exchanged in it, as well as all graphic and (or) audio elements in messages, automatically belong to the dedicated type.

Convert chat from public to dedicated type.

To convert an already created chat 14 from open 14' to dedicated 14, the user can perform the following operations:

open the 42 Conversations screen, which displays a list (preferably with a partial preview) of the various chats in which this user is the sender or recipient, long press (tap and hold) or side-drag (swipe to scroll) on the list bar chats of the first (public) type 14' displayed on the Conversations screen, to select a specific chat, open a new menu with various options, click on the privacy icon in the menu, enter the private access key 5, confirm that the chat has become the second (highlighted ) of type 14.

Accordingly, it is understood that in the chat 14 of the dedicated type 14, all messages exchanged in it, as well as all graphic and (or) audio elements in the messages, automatically belong to the dedicated type.

Creation of one or more messages of a dedicated type inside a chat of an open type.

To create one or more messages 60 of a dedicated type 60 in an open type chat, the user can perform the following operations:

open a specific chat 14 open type 14' on screen 57, click on the privacy icon on the screen related to that particular chat,

- 20 042772 enter the private access key 5, print the message 60, which then from the moment of its creation (insertion) will belong to the selected type 60.

Converting one or more open type messages to a dedicated type within an open type chat.

To convert within an open type chat one or more open type messages 60 60' to a second dedicated type 60, the user can perform the following operations:

open a specific open type chat 14' on the screen 57, long press (press and hold) on the screen area occupied by the message 60 displayed on the specific chat screen to select that specific message, tap on the privacy icon on the screen related to that specific chat, enter the private access key 5, confirm that the thus selected message 60 has become of the selected type 60, and preferably, the display of this message has disappeared from the corresponding chat screen 57.

Converting an element of a dedicated type inside a chat and a message of an open type.

To convert one or more graphic and/or audio elements 33 contained in chat message 60 14, if they are both of open type, from open type 33' to dedicated type 33, the user can perform the following operations:

open a specific open type chat 14 14' on screen 57, long press (press and hold) on the display area that in the message 60 (displayed on that particular chat screen) is occupied by a specific graphic and/or audio element 33 to thereby select that particular element, click on the privacy icon on the screen related to that particular chat, enter the private key 5, confirm that the graphic and/or audio element 33 thus selected is now of the selected type 33, and preferably that the visualization this item has disappeared from the corresponding chat screen 57.

Display unlock procedure (see Figs. 14a-14d).

Preferably, in order to perform the procedure for unlocking the display in order to transfer an object (chat, one or more messages, one or more graphic and (or) audio elements) of the second (selected) type from a hidden state to a visible state, the user could perform the following operations:

open the 42 Conversations screen, which displays a list (preferably with a partial preview) of the various public-only chats 14' in which the user is the sender or recipient, click on the selection icon 43 in the Conversations screen, open the menu 44 , where various functions are displayed, click on the menu function 45 related to the display of objects of the selected type, open an additional screen 46, on which you can enter, preferably using the keyboard 35 for typing, reproduced on the touch screen of the device, the components of the code that determines the access key, enter the key 5 individual access, open the screen 47, which displays (reproduces) objects of the selected type, which, in turn, moved from a hidden state to a visible state; as shown in FIG. 9b or 13d, it is preferable that the objects, in particular chats, of the dedicated type 14 differ graphically from the objects of the open type 14', for example, by the presence of the symbol 51.

Displaying objects of the selected type for a specific user.

To view an object of a selected type by a specific user, the following steps of the flowchart are provided:

- 21 042772

The user Ui decides to display the selected object using the key SKi

I

User Ui enters key SKi

I'

The first program module sends a request to the selection content data set to find in the personal subset 75 or in the central database 12 the selection content of the user Ui hidden with the key SKi

I-

The Ui object fetched by the request is switched from hidden state to visible state and hence displayed on the device screen

Create an access key that is shared between two or more users to gain access to an embedded chat.

It is convenient that the first software module provides for the following features:

create a shared key 80 that will be associated with a sub-chat 49 derived from the parent chat 14 and will be used to move the specified sub-chat (which is always of the highlighted type by default) from a hidden state to a visible state, and share a public (shared) key 80 created for all or part of the users participating in the parent chat 14 so that the corresponding nested chat objects 49 (which are therefore of a dedicated type) can be viewed on the displays of the respective devices of the users participating in a nested chat, after correctly entering the same key 80 general (shared) access.

Preferably, but not required, that once the key is generated by the first user in the sub-chat, its sharing with other users in the sub-chat is by sending in an appropriately secure mode, which is done by and within the messaging system 2 in accordance with the invention.

Creating a nested chat of a selected type inside an open chat (see Fig. 11).

To create a sub-chat 49 of a dedicated type in an open-type chat 14' (which will become the parent chat 14 respectively), a user participating in the parent chat can perform the following operations:

open the 42 Conversations screen, which displays a list (preferably with a partial preview) of the various first type chats 14' (potential parent chats) in which the user is the sender or recipient, long press (tap and hold), side drag (swipe to scroll) or touch in the list bar of chats (potential parent chats) of the first (public) type displayed on the Conversations screen, to select a specific chat, click on the privacy icon 47 on screen 42, open additional screen 46, on which to print, preferably using the keyboard 35 for typing, reproduced on the touch screen of the device, the components of the code that determines the key 89 of the shared (shared) access, enter the key 80 of the shared (shared) access, open an additional screen 53, on which, respectively, inside the parent chat 14 (and, therefore, for its own participants or for some of them) a nested chat 49 of the selected type is displayed; accordingly, nested chat 49 will initially contain no messages.

Preferably, the following two additional operations are also provided:

sending to the devices of all or part of the users participating in the parent chat 14, invitations to participate in the nested chat 49, which for them will also automatically be of the selected type, sending to the devices of all or part of the users participating in the parent chat of the same key 80 shared (general) access, so that the nested chat 49 of the selected type is transferred from a hidden state to a visible state, i.e., to display messages and (or) graphic elements present in the nested chat 49.

- 22 042772

Preferably, to create a dedicated type nested chat for participating users, the following flowchart steps are provided:

Gaining access within an open type chat to a dedicated type nested chat (see FIGS. 12 and 14a-14c).

To access a sub-chat 49 of a dedicated type within a parent open-type chat 14', the user can perform the following operations:

open the 42 Conversations screen, which displays a list (preferably with a partial preview) of the various first type 14' chats in which this user is the sender or recipient, long press (press and hold), side drag (swipe to scroll ) or touch in the chat list bar of the first public type 14' displayed on the Conversations screen to select a specific parent chat, click on the privacy icon 47 on the screen, enter the sharing (general) key 80, open the screen 53, in which a nested chat 49 (and hence the messages 60 and/or the graphic and/or audio elements 33 present therein) of a dedicated type is displayed, associated with said shared key 80; in particular, said nested chat 49 transitions from a hidden state to a visible state.

Preferably, the following flowchart steps are provided for participating users to view a dedicated type of nested chat:

User Ui enters chat Ci and enters the shared key SKi । v

The first software module sends a query to the chat data set present in the personal subset 75 or the central database 12 to find the nested chat SCi hidden with the public key SKi

I

Embedded SCi Chat found by query goes from hidden state to visible state to then be shown on the display of the device controlled by the user U2

Deleting a shared (general) access key.

Conveniently, the first software module is implemented to remove the previously created shared (shared) key 80, preferably without requiring the consent of other users participating in the embedded chat.

Accordingly, the first software module is implemented in such a way that when the previously created shared (general) access key 80 is deleted, the nested chat of the selected type associated with it is also automatically deleted. Alternatively, the first software module can be implemented such that when the previously generated shared access key 80 is deleted, the dedicated type nested chat associated with it becomes public and therefore always visible.

Conclusions.

From the foregoing, it is clear that the messaging system in accordance with the invention is particularly

Claims (21)

is useful in that it allows the user to selectively hide certain chats, messages and (or) graphic and (or) audio elements within the system itself. Therefore, as a result, even an unauthorized person who has gained access to the device and the messaging system will not be able to freely and automatically display all the objects that are present, exchanged and (or) used in the messaging system with their respective contents. In particular, in the messaging system according to the invention, any unauthorized person who has gained access to or taken possession of the device will not only never be able to view and understand the contents of the selected objects without successfully performing the unlock procedure, but, above all, he will not be able to notice and learn about the presence of selected objects. In other words, in the messaging system according to the invention, it will not be possible for any outsider to know or recognize whether the highlighted content (ie, second type content) is present or not. In addition, the specific configuration of the database and the set of allocated object data implies that the same object exchanged in the messaging system can be of different types (i.e., dedicated or public) for the sender and/or the recipient, and may be of a different type, even for multiple recipients. For example, this makes it possible for the same chat, message, or item to be of the second type (highlighted) for the sender while remaining of the first type (i.e., open) for the recipient, or vice versa. In addition, the specific database configuration implies that the user can determine that the same object exchanged in the messaging system is of the same type (i.e., dedicated or public) for both the sender and the same object. or multiple recipients. CLAIM 1. System (2) messaging, preferably instantaneous, characterized in that it contains at least one sending device (4) and at least one receiving device (6) designed to send and/or receive messages (60) through at least one central unit (8), with which both devices communicate, while the specified system (2) contains the first software module loaded and/or executed in the sending device (4) and/or receiving device (6), and a second software module loaded and/or executed in the central unit (8), wherein the first software module and/or the second software module are implemented in such a way that the messaging system (2) creates, manages and/or exchanges: objects of the first open type (14', 60', 33'), including at least one chat (14) and/or message (60) and/or digital element (33), which are always visible on the corresponding screen (42, 57) played on the display of the device (4, 6) and objects of the second selected type (14, 60, 33), including at least one chat (14) and/or message (60), and /or a digital element (33), providing the possibility of switching between two states: visible state, in which at least one chat (14) and/or message (60) and/or digital element (33) is displayed in full and/or in its preview mode on the corresponding screen (42, 57) being played on the display of the device (4, 6) and occupying a certain area of the specified screen, a hidden state in which at least one chat (14) and/or message (60) and/or digital element (33) is not displayed inside the corresponding screen (42, 57) played on the display of the device (4, 6), while the first program module and/or the second program module are implemented in such a way that the object (14, 60, 33) of the second selected type (14, 60, 33) transitions from a hidden state to a visible state after a successful unlocking procedure performed on the device (4, 6), on the display of which these objects will be viewed, as well as the first program module and/or the second program module are implemented in such a way that when at least one chat (14) and/or message (60) and/or digital element (33) of said hidden state do not occupy said defined area of the corresponding screen (42, 57), which is occupied when they are in visible state, on the display there is no feedback or visual indication; said unlocking procedure ensures the correct entry of the access code associated with one or more objects (14, 60, 33) of the second selected type (14, 60, 33), using the keyboard (35) of the device (4, 6), on the display of which to view them, which will allow you to notice the existence of a hidden object in the messaging system, said unblocking procedure is implemented in such a way that for each attempt that has a negative result, no visual feedback regarding the success or failure of such an attempt may be provided. - 24 042772 2. The messaging system according to claim 1, characterized in that it is designed in such a way that when objects of the selected type (14, 60, 33) are in a visible state, they are displayed on the corresponding screen (42, 57) together and / or among objects of the first public type, if any. 3. The messaging system according to one or more of the previous claims, characterized in that the first software module is implemented in such a way that: the object is of the distinguished type (14, 60, 33) from the moment of its creation, and/or the object of the open type (14', 60', 33'), already created and initialized, is converted to the distinguished type or vice versa. 4. The messaging system according to one or more of the preceding claims, characterized in that the first program module and/or the second program module are implemented in such a way that objects (14, 60, 33) of the second dedicated type (14, 60, 33) are loaded locally for each device (4, 6) only if the unlocking procedure performed on the device (4, 6) on the display of which these objects will be viewed was successful. 5. The messaging system according to one or more of the previous claims, characterized in that the first program module and/or the second program module are implemented in such a way that the object (14, 60, 33) of the second allocated type (14, 60, 33) by default is in a hidden state and switches from a visible state to a hidden state automatically after a specified time and/or when the user performs a certain action on the device (4, 6). 6. The messaging system according to one or more of the previous claims, characterized in that the first software module and/or the second software module are implemented in such a way that said unlocking access code (5, 80) used for the unlocking procedure contains alphanumeric characters, and/or special characters and/or punctuation marks. 7. The messaging system according to one or more of the previous claims, characterized in that the first software module and/or the second software module are implemented in such a way that the code (5, 80) of the unlock procedure access key contains graphic elements (33) related to that the type of elements that are sent in the messaging system (2) within the screen area occupied by the message. 8. The messaging system according to one or more of the previous claims, characterized in that the first software module is implemented in such a way that the input mode corresponding to the code (5, 80) of the access key is automatically activated after entering using the keyboard (35) for typing a certain sequence of pre-coded characters, symbols, graphic elements (61) before and/or after the code (5, 80) of the access key. 9. The messaging system according to one or more of the previous claims, characterized in that the first software module executed in the device (4, 6) is implemented with the ability to perform a display unlock procedure designed to translate objects (14, 60, 33) of a selected type (14, 60, 33) associated with a specific user, from a hidden state to a visible state. 10. The messaging system according to one or more of the previous claims, characterized in that the first software module executed in the device (4, 6) and the second software module executed in the central unit (8) are configured to interact with each other in such a way so as to perform the download unlock procedure before downloading objects (14, 60, 33) of the selected type (14, 60, 33) into the device's local memory (4, 6). 11. The messaging system according to one or more of the previous paragraphs, characterized in that it is implemented in such a way that objects (14, 60, 33) belonging to the selected type (14, 60, 33) for a particular user are all loaded into local memory (90) the device (4, 6) from which the specified user logged in, and they switch to a visible state only after the display unlock procedure is performed. 12. The messaging system according to one or more of the previous paragraphs, characterized in that as soon as the objects (14, 60, 33) belonging to the selected type (14, 60, 33) have been loaded into the local memory (90) of the device (4 , 6), they are displayed directly on the display of the same device. 13. The messaging system according to one or more of the previous claims, characterized in that the central unit (8) contains at least one database (12), in which a data set (15) of users containing at least one unique identification code of each the user of the messaging system (2), has a connection (27) with at least one data set (22) of elements containing at least unique identification codes of all digital elements (33) that can be controlled through the messaging system (2), in order thus to establish that these digital elements (33) are available to each user from the data set (15) of users. 14. The messaging system according to one or more of the previous paragraphs, characterized in that at least one database (12) contains a data set (18) of chats containing - 25 042772 at least one unique identification code of each chat (14, 49) of the messaging system (2), which is associated with a data set (20) of messages containing at least unique identification codes of all messages (60) exchanged in the system (2) messaging, where: a dataset (18) of chats is associated with a dataset (15) of users to define the users participating in each chat (14, 49), a dataset (20) of messages is associated with a dataset of elements (22) to be associated with each message ( 60) at least one possible digital element (33) contained in each message. 15. The messaging system according to one or more of the previous claims, characterized in that at least one database (12) contains a data set (70) of selected objects associated with a data set (15) of users, and with a data set (18) chats, and/or with a data set (20) of messages, and/or with a data set (22) of elements. 16. The messaging system according to the previous paragraph, characterized in that the specified data set (70) of selected objects is implemented in such a way that each of its records (71) contains: the first field assigned a value or associated with the identification code of the chat (14), message (20) or element (33), the second field assigned a value or associated with the unique code of the user identifier associated with the specified chat (14), or with the specified message (20), or with the specified element (33), the third field, which is assigned a value with a code that defines the access key (5) associated with the chat (14), or the message (20), or the element (33) records (71). 17. The messaging system according to the previous paragraph, characterized in that the first program module and / or the second program module are implemented in such a way that if a specific record (71) with an identification code of a particular chat (14) is present in the data set (70) of the selected objects ), and/or messages (60), and/or element (33), then this chat (14), and/or message (60), and/or element (33) belong to the second distinguished type only for a user having a unique identification code corresponding to the second field of said particular record (71). 18. The messaging system according to one or more of the previous claims, characterized in that the first program module and/or the second program module and/or the central database (12) are implemented in such a way that if in the data set (70) selected objects there is a certain record (71) with an identification code of a particular chat (14), and/or message (60), and/or element (33), then for their display on the display of a device controlled by a user having a unique identification code corresponding to the second field of the specified specific record (71), the user is required to correctly enter the code corresponding to the access key (5) indicated in the third field of the specific record (71). 19. The messaging system according to one or more of the previous claims, characterized in that the first program module and/or the second program module are implemented in such a way that the messaging system (2) contains: at least one chat (14) of the first open type (14'), which is always visible on the display of devices (4, 6) managed by all users participating in the specified chat, and at least one chat (14) of the second selected type ( 14), which, as a result of the execution of the procedure, switches between the following states: the first hidden state, when the specified at least one chat (14) is not displayed on the displays of devices (4, 6) controlled by all users participating in the specified chat, the second visible state, when the specified at least one chat (14) is complete and /or in preview mode is displayed on the screen played on the displays of devices (4, 6) controlled by all users participating in the specified chat. 20. The messaging system according to one or more of the previous claims, characterized in that the chat data set (18) contains at least one field with a code identifying a public key that is the same for all chat participants, which must be entered in order to enable everyone the chat participant to view the corresponding chat on the display of the corresponding device or on the display associated with this device. 21. The messaging system according to one or more of the preceding paragraphs, characterized in that: each device (4,6) functioning as a sender and/or receiver in the messaging system (2) contains a local memory (90) into which a personal subset (75) obtained from the central database (12) of the central block (8) and containing all data of objects (14, 60, 33) of a specific user logged into the messaging system (2) using this specific device, the first program module and the second program module are searchable -