ITMI20100061A1 - METHOD OF ESTABLISHING GROUPS OF ANONYMOUS CHAT SMS WITH CERTIFICATION OF PRESENCE IN DIFFERENT NON-COMMUNICATING ENVIRONMENTS, AND RELATIVE SYSTEM. - Google Patents

Description

Method of setting up anonymous SMS chat groups with certification of presence in disjoint non-communicating environments, and related system.

Field of application of the invention

The present invention relates to the field of internet applications on mobile radio telephony networks, and more precisely to a method of setting up anonymous SMS chat groups with certification of presence in disjoint non-communicating environments, and related system.

The term SMS, acronym in English for â € œShort Message Serviceâ €, that is of the service, is also used to indicate the very object of the service, that is a short text message transmitted from one mobile terminal to another .

Review of the known art

Hand in hand with the technological evolution of the cellular telephone network and mobile terminals, the so-called mobile phones, some interesting internet applications, initially feasible only on personal computers, have been extended to the world of mobile radio telephony. Among these applications, the most interesting ones for what will be said later, are those that allow the creation of ad hoc â € œconversationâ € groups, in which the participants converse among themselves by exchanging SMS. In the fixed network, the management of these groups is delegated to a special server for instant messaging, equipped with software to support applications such as Windowsâ „¢ MSN, which allow the individual's PC (personal computer) to exchange SMS in real time with the PCs of all participants in the conversation session. To safeguard privacy, the participants of the session qualify on the net through a convenient name, the so-called nickname, used to disguise their true identity from the other members of the group.

The mobile radio network has made internet technology its own, developing a platform for the interworking between the 3GPP protocols of the mobile radio world and the numerous IETF protocols of the internet world, in particular the IP protocol. After that, some applications developed for the pre-existing Internet network, but which could also be of interest for the mobile radio network, were adapted to the new context. By way of example, instant messaging applications have given rise to the â € œpushâ € technology, so called because, by pressing a button on their mobile phone, the individual affiliate of a conversation group can send a text message to the other participants. session, practically in real time.

The invention that will be described does not specifically concern instant messaging, however it shares with it the main premise of a psychological nature, deriving from the desire of individuals to communicate with other people in a common context. This context can be, for example, the interest in a sport, motors, music, technology, friendship deriving from real life experiences, the desire for a romantic relationship, or more simply the proximity of a home, and it could go on for a long time to come.

As for the fixed network, also for the mobile radio network the formation of thematic communication groups has no geographical restrictions. It should be noted that the use of the IETF protocols in the mobile radio network to provide these native internet services is not strictly binding, the pre-existing 3GPP protocols could in fact be adapted, however the integration of internet technology has proved to be very advantageous . The most modern mobile terminals are in fact equipped with advanced internet applications, capable of supporting all the evolutionary steps ranging from the simplest instant messaging to the most comprehensive social network technology, not to mention all the commercial and financial possibilities offered by navigation. on the Web.

For the purposes of tracing the mobile terminals, the area covered by the mobile radio network has been divided into geographic cells of variable extension, each covered by the radio signal provided by a radio base station of the access network suitable for supporting connections with all terminals present in the cell. The cell change during roaming when a conversation is in progress, the so-called handover, involves nodes of the access network placed at a higher hierarchical level, i.e. the controllers of the radio base stations, which in turn communicate with the centers switching for voice and data of the so-called â € œcore networkâ €, in turn responsible for making the various peripheral elements of the access network communicate with each other throughout the national territory. The core network also provides the platform for interworking with the internet. Thanks to such a network architecture, any mobile terminal can be located anywhere on the territory, maintaining the approximation of the diameter of the cell in which it is currently located, without however the network being able to know its position on the azimuth plane. However, the localization area can be further restricted based on the measurement of the signal strength received by the radio base station, normally monitored in the Power Control procedure. The measurement of the angular position of the terminals on the azimuth plane can be acquired by the network using two different methodologies, the first of which consists in equipping the radio base stations with array antennas controlled by â € œbeamformingâ € algorithms; a second and more expensive methodology instead consists in equipping the individual mobile terminals with a GPS (Global Positioning System) antenna, which in this way will be able to obtain from the GPS signals received the data of geographic latitude and longitude, and height from the ground, and transmit the same data back to the network.

Having sufficiently clarified the architectural aspect of the mobile radio network, valid regardless of the technology used at the physical level, such as those known with the acronyms GSM, GPRS, E-GPRS, HSDPA, UMTS, etc., it is now possible to evaluate some interesting applications of the known art, aimed at overcoming the purely â € œvirtualâ € aspect that afflicts instant messaging groups; virtuality essentially due to the absence of geographical constraints regarding the location of the participants in the conversation group, often together with the lack of knowledge of the real identity of those who participate in the conversation within the group.

Patent application US2003 / 0037110 A1 describes a method and an apparatus for providing an area available to virtual `` rooms '' for conversation, known as a `` chat-room '', where unspecified users each equipped with a portable terminal they can exchange SMS or similar messages in real time while roaming. Users can create chat rooms themselves, or search for pre-existing chat rooms, each associated with a specific geographical location, and show the location information of the participants on their display during the conversation. A special device manages the chat area, it regulates the requests for inclusion and cancellation of chat rooms in the chat area, each associated with a specific location, accepts a request message from a portable terminal including the message current location of the terminal and a short note (SMS), and assign that user to a chat room with a current location. The information is transmitted to all applicants present in the chat room. Each of the terminals draws in the lower part of its display a geographical map of the chat room with the location of all the participants; the short message sent by the last speaker, or the last dialogue sequence, is shown in the upper part of the display.

It is clear from the above that chat rooms are areas defined dynamically by the users themselves on the basis of visual information acquired during roaming. Compared to the previous virtual chat-rooms extended over a vast territory, the chat-rooms made possible by the aforementioned precedence cover a variable area limited by a boundary such that it is still reasonable to be able to focus the attention of those who are by car on the presence of territorial references, such as, for example, shops, supermarkets, restaurants, cinemas, stations, and anything else it is useful to point out or advertise. The virtuality of the chat group, although lower than that of delocalized chat groups, nevertheless continues to persist due to the fact that:

â ’Participants are completely occasional: they interact for a very short time and may no longer interact, being also represented by simple moving circles on a pseudo-cartographic map of the chat-room.

â 'The possibility of having all potential interlocutors in the real field of vision is almost non-existent, both because the chat-room has a territorial extension subject to the possibility of establishing a dialogue of reasonable duration during roaming, and because the participants may never cross paths. For example, a chat room created along a state or provincial road could extend linearly for more than two kilometers, too long to be able to visually locate the participants.

For the above, the life of the chat-rooms is short, their geographical position depends on roaming, and the identity of the participants is random, therefore it is not possible to make the participants loyal to a stable physical location.

Other aspects to be noted consist in the fact that the conversation via SMS is subordinated to the use of sophisticated mobile terminals, that is, compulsorily equipped with a GPS antenna for the acquisition of positional information, and this constitutes a drawback that plays to the disadvantage of dissemination of such a service. Lastly, the dynamic character that distinguishes the creation of chat rooms is due to a partial or total overlap of the same on the same geographical area. The overlapping of chat areas is a criterion that, translated into a context outside of roaming, could create confusion if you want to associate the chat participants with a specific physical place.

Recently some curious commercial initiatives have been advertised on the web aimed at favoring the exchange of SMS in discos or more generally in local areas. One of these initiatives called â € œReality Chatâ € offers three free SMS messages in exchange for a drink to be made within the restaurant; subsequent top-ups will be made with each new drink. The operation is as follows: each person interested in the chat present in the disco is attached to the dress a code corresponding to a "chat number"; after which the applicant must register by sending a message of registration to the chat with the indication of his â € œChat numberâ € to a telephone number of the â € œReality Chatâ € service server; at this point you can use the service by sending a message to the same telephone number as the server whose syntax includes the following: your `` chat number '', space, `` chat number '' of the person with whom you want to communicate, space , short message content. When you leave the club it is still possible to chat via SMS until the credit runs out with the â € œnumbers of chat desiredâ € for a limited period of seven days. From a technological point of view, the salient feature is that of allowing peer-to-peer communication (one to one) with the hiding of one's own telephone number, provided that a simplified telephone number assigned on an individual basis is worn in a clearly visible manner. .

It is quite clear that the â € œReality Chatâ €; does not preserve anonymity, as those who intend to start a conversation by choosing a `` chat number '' cannot avoid seeing the bearer of the same, indeed, it is more logical to state that the choice of the `` chat number '' is determined by seeing the wearer. Since the received message includes the sender's 'chat number', and the aforementioned number is worn by the sender, the recipient will be able to visually identify the sender and decide whether or not to reply to this message. From the above, the purely commercial nature of the â € œReality Chatâ € service appears clear, the declared purposes of which are to increase the number of drinks, the creation by the operator of a directory of â € œrealâ € mobile numbers to which it is possible to send promotional messages, and ultimately, gaining greater local loyalty. The â € œReality Chatâ € is just a polite way to play down the shyness of a first approach between people who do not know each other, beyond this the proposed technology does not guarantee anonymity.

Another commercial initiative based on the SMS service is illustrated on the website of the company Pangolino, producer of a program called IMU, acronym for â € œInteractive Messaging Unlimitedâ €. The IMU program allows you to project on a screen individual SMS messages transmitted by mobile phones, or entire chat sessions via SMS. The program more or less automatically filters any offensive or indecent messages, alerting the respective senders and then excluding them in case of repeat offense. The screen can be placed in a public or private room, or relocated to that of the home TV or to a web page on the PC. Among the most varied IMU applications, for example: chat, online voting, marketing, interactive TV, etc., it is necessary to emphasize those relating to entertainment in discos, nightclubs, concerts, and private clubs, where the SMS of individuals users, properly scheduled and filtered, are projected on a screen visible to all present. Those present are given the right to customize their SMS with icon, nickname, and choice of color. In this way it is possible to send personalized broadcast SMS within the room.

From the above it is clear that IMU provides a fun broadcast service of â € œText-on-screenâ €, which can be used by users present in a room, who use their mobile phone to send an SMS to the centralized screen manager to view. broadcast in the venue, for example a request to the DJ to listen to a particular piece of music. A message sent to IMU by an iconized user with a nickname, displayed on the centralized screen, can be followed by the display of a response message from another appropriately scheduled user. In this way, a sort of broadcast-type chat takes place with completely random participants, and this constitutes the intrinsic limitation of the IMU service.

For the sake of completeness in the exposition of the known art, it is necessary to mention the existence on the market of luminous diode displays (LED) in which a cellular telephone receiver is integrated, enabled to receive SMS containing information messages and advertising texts to be displayed. sliding on the display. The management of the visualization on the display also takes place via SMS. The management software of the integrated receiver is configured to show the content of individual SMS messages received on the display. The aforementioned IMU service could benefit from such a display instead of the centralized screen. In this case, the receiver integrated in the display would be tuned to the radio channel of the IMU server to receive the content of the messages to be displayed.

Aims of the invention

The invention aims to overcome the limitations highlighted in the SMS chat systems of the known art. Its purpose is therefore to mitigate the sense of virtuality accused by the participants of the delocalized chats to a greater or lesser extent, with the certainty of the presence of real interlocutors protracted for a sufficiently long period of time, even in the order of a few hours, who, however, remain absolutely anonymous until they spontaneously decide to give rise to real encounters, thus overcoming the shyness of the first meeting. The consequent aim is to establish chat-rooms with certain boundaries, stable over time, and territorially separated, for example discos, restaurants, pubs, etc., where all those present can see each other and chat via SMS without necessarily knowing each other.

Summary of the invention

To achieve these purposes, the present invention relates to a method for implementing a chat service by transmitting and receiving short text messages, hereinafter referred to as SMS, in limited areas, hereinafter referred to as real rooms, included in the ™ coverage area of the radio signal of a mobile radio network, connected to a connection node, hereinafter called gateway, between the mobile radio network and a server that manages the chat service in a network of real rooms, the method including the steps of :

a) connect to the server a plurality of fixed terminals, each located in a real room set up on an area separated from possible further territorial areas on which respective real rooms are set up and not communicating with each other; the server by performing the steps of:

b) receiving the messages requesting registration to the chat service, each message including the telephone number of the applicant's mobile terminal and at least one nickname, hereinafter called nickname, unique in the network of real rooms;

c) generate for each real room a unique and temporary authentication code of the SMS relating to the chat service, and transmit said authentication codes to the fixed terminals located in the respective real rooms for making them available to registered users present in that real room; d) receive the request messages for enabling the chat service sent by registered users, and grant the authorization to those registered users whose request message includes a valid temporary authentication code; e) receive the chat SMS sent by the gateway on behalf of users enabled for the chat service and for each real room:

â ’check if the recipient's nickname included in each authenticated SMS corresponds to a user enabled in that real room, or if the SMS is public,

∠’in case of affirmative verification, retransmit the content of each authenticated SMS to the gateway for forwarding to the telephone number of the mobile terminal corresponding to the recipient nickname, masking the sender's telephone number, or,

- forward the content of each public SMS, after appropriate filtering, to at least one centralized display device, as described in claim 1.

Further characteristics of the present invention considered innovative are described in the dependent claims.

Another object of invention is a system for the implementation of the anonymous SMS chat service, according to the method described above. As a whole, the system is structured as a star geographic network in which peripheral nodes consisting of local terminals located in the real rooms report to a centralized server. More precisely, the system for the implementation of a chat service by transmitting and receiving short text messages, hereinafter called SMS, in limited areas, later called real rooms, included in the coverage area of the radio signal of a mobile radio network, includes:

∠’a connection node, later called gateway, connected to the mobile radio network and to an IP server that manages the chat service in the real rooms,

wherein according to the invention the system further comprises:

â ’a plurality of fixed terminals located within their respective real rooms disjoint and not communicating, connected to the server to form an intranet in star topology;

- a plurality of displays connected to respective said fixed terminals to display in each real room a unique code of defined duration, generated by the server to authenticate anonymous chat SMS, each associated with a unique nickname in the intranet, originating in that real room towards nicknames located in the same real room and enabled for the chat service.

Considering that the chat service according to the present invention requires coverage of real rooms by the mobile radio network, and that moreover sophisticated mobile terminals equipped with a GPS antenna are not required to locate their position with precision, it is clear that the system is not able to detect if a user who had obtained the chat authorization has left the real room during the validity period of the authentication code (presence code). In this case, it is evident that the user in question continues to maintain his status of enabling the chat with users in the real room he has just left, or users with his same status, at least as long as the period of validity of the current authentication code. The authentication code regeneration policy is at the discretion of the service provider. Taking as an example of a real room a disco, where presumably a large exchange of SMS messages of the chat service according to the present invention is in progress, it would not seem at all convenient to change the authentication code before closing the club; instead it would be more reasonable to regenerate the code when the venue is reopened. In any case, the system can detect if a room is closed, either directly because the local terminal has performed a logout procedure, or if it is disconnected from the network for more than a time longer than a temporary interruption of the connection, or indirectly consulting a table of the closing times of the various rooms corresponding to the real rooms. In the light of this information, the server is able to discriminate between all the SMS received, those coming from authorized users who are outside a real room during the time interval in which the authentication code of the SMS that actual room not having been regenerated is still valid. These users are assigned the status of users â € œout room onlineâ € (OUTROOM ONLINE), and the enabling of the chat service with other users who have the same status, with reference to the same real room, continues to apply to a duration time at the discretion of the manager, which cannot in any case extend beyond the time of regeneration of the enabling code, which corresponds to the next logon of the room; after which those users assume the status of â € œout room offlineâ € (OUTROOM OFFLINE) and enabling the chat service immediately ceases.

Advantageously, but not necessarily, the network consisting of the server-side gateway, the server, and the local terminals of the real rooms, adopts the IETF protocols that characterize the Internet network, in particular the IP protocol. The mobile terminals currently in circulation, although they have already been connected to the internet for some time, this connectivity is not required at all for their use in the new chat service, as it is carried out by sending and receiving SMS with appropriate syntax. For this purpose the gateway comprises a telephone subsystem reachable by telephone number, and an IP subsystem towards the chat server. With this, the network of the chat service between the server and the gateway constitutes a first intranet, while the network of the chat service between the server, the local terminals (PC), and the display devices (TV monitors, projectors and screens , LED display, etc.) forms a second intranet.

Before further technical considerations, it is useful to specify that the chat service according to the present invention can be managed either by a single manager or by a manager who interfaces with the final user through an intermediate user level having the burden of managing certain aspects of the chat service in the individual real rooms. It is quite clear that the invention does not concern the methods of economic management of the chat service, nor the agreements between the main operator and intermediate users, but it is also true that end users will perceive intermediate users as the co-managers of the chat service to whom you can contact for all the tasks, such as those concerning the purchase of SMS credits and the recharging of credit for the chat service only according to the invention. The credit on the SIM card of the mobile radio service operator will have to be regulated separately. End users are given the opportunity to subscribe to the direct debit on the residual credit of their telephone SIM card.

The server in step a) of the method in question assigns an identification code to each real room and transmits it to the local terminal. This code is stable and must not be confused with the SMS authentication code, which is instead temporary. The identification code of the real room is useful in transactions between the server and the end user, and in the procedures for querying the status of the individual mobile terminals in relation to any real room.

In an embodiment referred to in step b) the registration request messages are sent by the applicants directly to the network address of the chat service server (website).

In an embodiment referred to step b) the registration request messages formulated by the applicants are forwarded to the server through the local terminal of the real room in which the generic applicant is located.

In an embodiment referred to step b) the registration request messages are SMS formulated with established syntax and sent by the applicants to a telephone number of the gateway, where an algorithm checks the conformity of the syntax and data and automatically forwards the SMS to the SMS chat service server.

As a corollary to step b), the chat service server verifies that the syntax and data contained in the registration request messages comply with pre-established rules, and if so, it transmits a respective notification message of registration to the senders.

In an embodiment referred to step c), the generic local terminal is connected to a display device, addressable on the network, placed in a position such that all those present in the real room can see the temporary authentication code projected by the device . Advantageously, in real rooms of greater extension, several individually addressable displays on the network are placed in different points of the real room, all displays receiving the same temporary authentication code from the local terminal so that it can be seen by all present in the real room.

In an embodiment referred to step c), the generic local terminal is connected to one or more â € œbatchâ € reading stations present in the real room for the reading of cards respectively owned by registered users, the nickname being stored in each card chosen. Each registered user who intends to request the enabling of the chat service in the real room in which he is located, submits his card to a reading station, so that the local terminal can acquire the identification data stored in the card, the temporary authentication code assigned to the real room, and include the associated data in an enabling request message sent to the chat service server on behalf of the applicant.

In an embodiment referred to in step c), the generic local terminal is connected to one or more active RFID (Radio Frequency Identification) devices located at the entrance to the room or at predetermined points. Active RFIDs transmit a radio signal to passive RFIDs respectively worn by registered users, where the chosen nickname is stored in each of them. When the radio interrogation signal transmitted by the active RFIDs hits the passive RFIDs, it induces the transmission of the stored identification data in each of them. The local terminal acquires the aforementioned data, matching for each RFID the temporary authentication code assigned to the real room, and including the matched data in an enabling request message sent to the chat service server on behalf of the applicant.

According to an aspect of the invention, any enabled user can send an SMS with the syntax of disabling (logout) to the server; this allows the physical migration to another real room and the partial re-execution of the method starting from step e) to request the authorization for the service in the new real room. According to an aspect of the invention, any registered user can send to the server some query SMS characterized by different syntax, to which the server replies by sending the requested information. More precisely:

â € ¢ An inquiry SMS requests the list of nicknames registered in any real room identified by its own CIS (Real Room Identification Code).

â € ¢ A query SMS requires that the status of a nickname present in any real room be automatically reported whenever this status changes. The status information being the following:

out of room offline (OUTROOM OFFLINE);

in room on line CIS (INROOM ONLINE);

out of room online (OUTROOM ONLINE).

â € ¢ A â € œmanualâ € variant consists in obtaining the notification of the current status of a nickname with each query SMS sent.

â € ¢ An inquiry SMS requires that the address of a real room corresponding to a given identification code be returned.

â € ¢ An inquiry SMS requests that the remaining credit available to the service be returned.

According to one aspect of the invention, any registered user can send to the server an SMS requesting the inclusion of a nickname in a blacklist of nicknames for which communication must be inhibited. Another SMS will allow you to remove the nickname from the blacklist and restore communication. Advantageously, blacklisting makes it possible to prevent a given nickname from continuing to disturb another nickname with inappropriate SMS.

According to an aspect of the invention, any registered user can send to the server an SMS requesting not to fulfill the queries on his own status towards a specific requesting nickname. Another SMS will allow you to reset the status queries. This precautionary measure is less drastic than the previous one.

According to one aspect of the invention, the server, with each query SMS regarding the status of a nickname, checks whether the applicant's nickname is blacklisted, and if this is not found, it sends the requestor the ™ status information and at the same time notify the requester's nickname to the queried nickname.

According to an aspect of the invention, the server transmits to the local terminals for forwarding to the centralized display device present in each real room, in addition to the temporary SMS authentication code (also called presence code or CPS), also the following service information: gateway telephone number; real room identification code (CIS of unlimited duration).

Advantages of the invention

The proposed invention outlines chat-rooms free from any residual sensation of virtuality, as each group of SMS chat is located in a limited physical place, such that each participant can see the others and interact with them via SMS, despite not knowing them in person due to the precluded traceability of the telephone number. All this arouses in the chat subjects a natural feeling of curiosity that feeds the desire, first to guess who you are chatting with and then to get to know each other in person, but only after a precautionary phase of mutual study, and why not of provocation. As Leopardi said â € œpleasure child of troubleâ €, the longer the interlocutory phase is, the greater the satisfaction in getting to know one could be. However, the interlocutory phase could also involve giving up breaking the ice, probably because incompatibilities have emerged in their respective characters or different points of view. The combination of these emotional factors cannot at all occur in the prior art examples discussed above.

The invention can be used inside public places, such as: discos, pubs, private clubs, etc., or in external environments such as stadiums, sports halls, outdoor concerts, etc. The use in discos is however the most suitable, because they are mostly frequented by boys and girls who want to know each other, and the chat via SMS with only the nickname represents the most intriguing vehicle, also taking into account the fact that the conversation in words is disturbed by the very high volume of the music. Another advantage is that after the closure of the restaurant, the chat via SMS can continue for a certain time before the next reopening; this would allow the ongoing conversations to be prolonged by igniting in the parties the desire to return later to the room to pick up where they left off. This mechanism creates loyalty to the same place by boys and girls, and more generally by users of the chat service to a specific real room.

The advantages also exist for the owners or operators of public places, who can earn profits deriving from being co-managers of the chat service, and indirectly as a result of loyalty to the club that increases the number of users and therefore of consumptions, and further by the centralized display device which gives the possibility to display paid advertising messages.

Brief description of the figures

Further objects and advantages of the present invention will become clear from the detailed description that follows of an example of its embodiment and from the attached drawings given purely for explanatory and non-limiting purposes, in which: ∠'figure 1 shows the network architecture for the realization of the chat service via SMS inside real rooms, according to the present invention;

∠’Figure 2 shows a variant with multiple displays within a real room;

∠Figure 3 shows the temporal evolution of the state of a real room in Figure 1 and the related mobile terminals enabled;

∠’figure 4 is a more synthetic schematization of the network of figure 1;

∠’figure 5 is a functional block representation of the SMS chat server of figure 4;

∠’figure 6 shows the intranet of a real room in figure 4, with particular emphasis on the functional block representation of the local terminal;

∠’figure 7 shows the detail of the ATC block in figure 6;

â ’Figure 8 shows the flow chart of the possible forms of new user registration;

∠’Figure 9 shows the sequence of messages through the various network elements and the processing steps in the nick registration procedure via SMS; ∠’Figure 10 relates to the local terminal logon procedure with renewal of the presence code on the public display;

∠’Figure 11 relates to the nick enabling procedure with presence code;

∠’figure 12 is a flow-chart of the processing performed by block BC 02 of figure 11;

∠’figure 13 (and 13A) relates to the SMS transmission procedure from nick to nick;

∠’figure 14 (and 14A) relates to the procedure of transmission from nick to public display;

∠’Figure 15 relates to the local terminal logout procedure with maintenance of the time attendance code;

â ’Figure 16 relates to the query procedure for the list of enabled nicknames;

∠’figure 17 (and 17A) relates to the nick status query procedure; ∠’figure 18 (and 18A) relates to the query procedure for real room address â € œABCDâ €;

â ’Figure 19 relates to the residual credit query procedure;

∠’figure 20 (and 20A) relates to the blacklist on request procedure for a nick;

∠’figure 21 (and 21A) relates to the blacklist off request procedure for a nick;

∠’figure 22 (and 22A) relates to the procedure for requesting the status off of a nick;

∠’Figure 23 (and 23A) relates to the procedure for requesting the status on of a nick.

Detailed description of some preferred embodiments of the invention

In the following description, identical elements appearing in different figures may be indicated with the same symbols. In the illustration of a figure it is possible to refer to elements not expressly indicated in that figure but in previous figures.

Figure 1 shows a mixed type telecommunications network, comprising a mobile radio network (PLMN) and a fixed telecommunications network (PSTN). In both networks it is possible to route the information to be transmitted, be it voice or data, through â € œcircuitâ € auto-switches for voice and â € œpacketâ € for data. The mobile radio network also makes it possible to send and receive short text messages, known as SMS, which more recently can also be transmitted from fixed terminals to mobile terminals. The mobile radio network (PLMN) is the current cellular network with national coverage, with branches to neighboring countries. The transmissions exploit the most diverse transmission technologies on the physical layer: FDMA, TDMA, HSDPA, CDMA, etc. The services provided by the mobile radio network are the prerogative of the most diverse private operators, the so-called providers: TIM, Vodafone, Tre, H3G, Wind, Poste Mobile, etc. The fixed network is the current public telephone network (PSTN), where the X.25 protocol originally used for packet data transmission, and now outdated, has been almost completely supplanted by the Internet Protocol (IP). The IP network has the versatility we all know, and is exploited in the most diverse applications, which include e-mail, WEB browsing, streaming, VoIP telephony, and many others. The mobile radio network accesses the IP network via a hardware and software platform located in the core network.

With reference to Figure 1, a radio base station 1 can be seen comprising transceivers connected to a sectorial antenna 2, the radiation pattern of which determines a territorial cell for coverage of the radiated signal relating to a predetermined number of radio channels. Antenna 2 is also used to receive the radio signals radiated by the antenna incorporated in the mobile terminals, the so-called cell phones, of the users who are in that cell. The radio base station 1 exemplifies all similar stations distributed on the territory of radio coverage 3 pertaining to the mobile radio network, this territory is divided into coverage cells adjacent to each other. The radio base station 1 is connected to a controller 4 of the radio base stations 1, interfaced to several radio base stations to supervise the connectivity of the respective cluster of cells to the core network 5. As a whole, the radio base stations 1 and 2, and the controllers 4 constitute the access network to the core network 5. The latter is connected to a mobile network side port of a node 6, which has an IP network side port connected to a server 7 specialized in providing a particular service chat via SMS, the peculiarities of which will be illustrated later. Node 6 acts as a gateway between the 3GPP protocols typical of the mobile radio network and the IETF protocols typical of the IP network. As such, the port on the mobile network side can be reached at an address corresponding to a predetermined NUM.TEL.M telephone number, while an Internet address IP.ADD.M is assigned to the port on the IP network side. Server 7 exploits the connectivity of the IP network to communicate with fixed terminals 8, 9, and 10, typically personal computers (PCs), physically located in respective areas STR1, STR2, and STR3 covered by the radio signal 3 of the mobile radio network. The STR1, STR2, and STR3 areas, hereinafter referred to as real rooms, are territorially separated and mutually isolated, in this specific case they are discos. The chat service via SMS in the real rooms is managed by server 7 through local terminals 8, 9, and 10, each of which is assigned its own IP address, respectively IP ADD.1, IP ADD.2 , and IP ADD.3, being! P ADD.0 the IP address of the server 7. Inside the real rooms the respective local terminals 8, 9, and 10 are connected to their monitors 8a, 9a, and 10a visible only to local operators. Each local terminal is also connected to its own display device, respectively 8b, 9b, and 10b, positioned so as to be visible to all present in the real room. This centralized device is an active or passive (projection) screen or an LED display. The users present in the real rooms STR1, STR2, and STR3 all covered by the radio signal of the mobile radio network are equipped with mobile terminals, respectively and collectively indicated with 11, 12, and 13, and therefore they can use all the services made available by the mobile radio operator. The mobile terminals 11, 12, and 13 are the usual mobile phones, therefore capable of transmitting and receiving SMS through the mobile radio network.

In operation, each display device is used by the local PC to display the most diverse information, such as codes relating to the chat service, individual SMS, or advertisements. In figure 1 each display shows a code assigned by server 7 and transmitted to the local terminal of the real room. The code displayed in the real room STR1 by display 8b is different from the code displayed in the other real rooms STR3 and STR4 by displays 9b and 10b, and this continues to apply to all the codes displayed in all the real rooms of the network managed by the server 7 The code displayed is a temporary authentication code of all the SMS transmitted in the real room where the aforementioned code is displayed. In other words, the authentication code certifies the physical presence of the sender of the SMS in that real room. The authentication code has a time-based validity, after which it is regenerated, so that users registered for the chat service provided through server 7 will have to request the enabling of the service by indicating the new presence code before being able to use it again. The SMS that do not concern the chat service managed by the server 7 are transmitted and received by the mobile phones 11, 12, and 13 as usually happens, instead the SMS that concern the chat service managed by the server 7 must be subject to a specific syntax and not will show on their display the sender's telephone number, instead of which a respective nickname will be displayed, unique in the network managed by the server 7. Such SMS to be correctly delivered must be sent to nicknames physically present in the same real room where the senders are present. of SMS, the situation is schematized by the circle of arrows between the various mobile phones all inside the real room.

Figure 2 shows a real room STR4 in which a local terminal 20 is connected to a switch 21, in turn connected to three display devices 22, 23, and 24 variously located in the real room STR4 so that all present can see them. The local terminal 20 has an internet address IP.ADD.4 and each display device 22, 23, and 24 has its own internet address, respectively IP.ADD.5, IP.ADD.6, and IP.ADD.7. Each display device shows the same presence code. The STR4 real room is a very large room where a single display may not be enough. The different IP address of the displays 22, 23, and 24 allows each of them to be sent different information for public viewing, except for the presence code which is the same.

Figure 3 shows the temporal evolution of the state of the real room STR1 of figure 1 and of the mobile terminals 11a, 11b, and 11c, initially present in that room and enabled to transmit and receive SMS from the chat service managed by the server 7 . The initial situation is that of INROOM ONLINE in which the users with their respective mobile terminals, after having requested the server 7 to enable the chat service by including in the request message the presence code shown on the display 8b, and have once the consent is obtained, anonymous SMS messages are exchanged with the indication of the sender's nickname. This situation may persist until server 7 decides to change the presence code shown on display 8b. The situation just proposed is that in which the status of the real room STR1 is LOGOUT TIME ON and OUTROOM ONLINE the status of the mobile terminals 11a, 11b, and 11c, which continue to exchange chat SMS of the service managed by the server 7 in the vicinity of the closed room, where coverage of the mobile radio network also exists. At the end of the enabling period, the status of the real room STR1 switches to LOGOUT TIME OFF and the status of the mobile terminals 11a, 11b, and 11c switches to OUTROOM OFFLINE ceasing to use the chat service.

The detailed description of the network structure and subsequently of its operation is made by redefining the symbology of figure 1 in the most synthetic way of figure 4, in which the symbols indicated have the following meanings:

â € “D is the mobile telephone operator;

â € “P is a network node set up by the SMS chat service provider in real rooms to interface both operator D and server B of the aforementioned service in the real room network;

- C is the gateway of P associated with the telephone number NUM.TEL.M to the mobile radio operator for the SMS chat service in question; â € “BIP is the gateway of P associated with the first level IP address www.yyy.yy; - B is the server that manages the SMS chat service in the network of real rooms; â € “BIB is B's gateway associated with the first level IP address www.xxx.xx; â € “A01, A02, A03 are the names of the real rooms corresponding to the identification codes associated with their physical addresses;

â € “BIL is the A01 internet gateway to which the http: // IP address is associated;

- TR 01 and TR 02 are the mobile terminals present in the real room A01;

â € “AT is the local terminal of the real room A01 associated with the http: // IP address; â € “AD is the display connected to the local AT terminal and reached by it via an IP address.

Inside node P the telephone gateway C communicates with the internet gateway BIP via an IP connection. What is shown for the real room A01 also applies to the real rooms A02 and A03.

Figure 5 shows the functional block structure of the SMS chat server B of figure 4, containing the blocks highlighted with BA, BI, BH, BD, BE (01â € ¦06), BF (01, 02, 03), BL , BG (01, 02, 03), and BC (01, 02), the meaning of which is as follows: BA - SMS TX / RX MANAGEMENT - PROCESSING REQUESTS FORWARDING SMS:

BA 01) FROM NICK TO ANOTHER NICK,

BA 02) FROM NICK TO PUBLIC DISPLAY.

BIB - INTERNET GATEWAY www.xxx.xx.

BH - WEB GRAPHIC INTERFACE - DATA ENTRY MANAGEMENT.

BD - LOGON AND LOGOFF MANAGEMENT REAL ROOM AND RELEASE PRESENCE CODE.

BE - SYSTEM QUERY MANAGEMENT:

BE 01 - NICK 0N / OFF BLACKLIST REQUEST,

BE 02 - NICK STATUS REQUEST,

BE 03 - REQUEST FOR REAL ROOM ADDRESS,

BE 04 - NICK CREDIT STATUS REQUEST,

BE 05 - REQUEST FOR ENABLED NICK LISTS,

BE 06 - REQUEST STATUS NICK ON / OFF.

BF - SMS SYNTAX CHECK:

BF 01.a - SYNTAX CHECK REGISTRATION / ENABLING, BF 01.b - SMS FROM NICK to NICK / SMS FROM NICK TO DISPLAY,

BF 01.c - BLACK LIST NICK on / off - STATUS NICK on / off - NICK LIST

- REAL ROOM ADDRESS - CREDIT STATUS - STATUS

NICK,

BF 02.a - SMS SYNTAX ERROR,

BF 02.b - USER NOT ENABLED,

BF 03 - SMS SYNTAX CHECK.

BL - SMS SENDING MANAGEMENT - SMS SENDING SECTION A (GA-TEWAY SMS NUMBER).

BG - SYSTEM DATABASE.

BG 01 - ADMIN LEVEL DATABASE - REGISTRY / CREDIT.

BG 02 - USER LEVEL DATABASE - PERSONAL DATA / CREDIT / STA-TUS.

BG 03 - CUSTOMER LEVEL DATABASE <(NOTE 1)> - DATA / CREDIT /

/ STATUS.

BC - USER STATUS MANAGEMENT:

BC 01 - NEW USER REGISTRATION PROCEDURE,

BC 02 - PRE-ENABLING AND RECOGNITION PROCEDURE

WITHOUT.

NOTE 1 - From the point of view of the manager of the chat service via SMS in the real rooms object of invention, both the individual users with mobile terminals who request the service, both the managers of the real rooms and for them are customers convenience they equip it with a local terminal and a display, however to avoid confusion the term customer, where provided, will only be used to indicate the co-managers of the service in the real rooms. The blocks of figure 5 use memory areas accessible in reading and writing to the processing unit of server B (not indicated) by means of a bus 30. The interactions between the individual blocks of the server, and between them and the remaining parts of the system will be explained shortly. Figure 6 shows the display AD and the functional block structure of the local terminal AT of figure 4. The display AD comprises three displays each having an internet connection with the switch 21 and its own IP address. The local terminal AT includes the blocks marked with ATA, ATC, ATB, and BI, the meaning of which is as follows:

ATA - REAL ROOM ENABLING AND PRESENCE CODE REQUIRED. ATB - SMS DISPLAY MANAGEMENT.

ATC - GRAPHIC DISPLAY INTERFACE.

BIL - INTERNET GATEWAY http: // IP.

The ATB and ATA blocks send the information they process to the ATC graphic interface and are also connected to the BIL internet gateway.

Figure 7 shows the functional block structure of the GRAFI-CA DISPLAY ATC INTERFACE contained in the local AT terminal of figure 6. This structure contains two functional blocks called ATC 01 and ATC 02. The ATB block receives the SMS to be displayed by means of the SMS RECEPTION function, and reads the information for their correct display by means of the READING DISPLAY SETTING function. The setting information is sent to the ATC 02 block which assumes two different types of displays: LED (Light Emitting Diode) and VIDEO. Specific parameters are set for each type, such as: the quality of the representation, the number of lines or inches of the screen, and the assignment of the IP address. The final display setting information is transferred to the MESSAGE FORMATTING block included in ATC 02, which formats the message according to the setting information and sends the correctly formatted message to the AD display using the SEND function.

The various operating procedures of the SMS chat server B connected to the local terminals TR in the real rooms will now be illustrated, starting with the registration procedure for the service carried out in the various ways provided in figure 8, exhaustive in itself in the descriptive part, to which we refer. Of the three registration methods illustrated: 1) via the server's website, 2) via local terminal, 3) via SMS, only the second implies the presence of the potential user within the real room. In all three cases, the syntax of the registration message must contain the following information: telephone number of the mobile terminal, chosen nickname (6 characters), age, proper-sex, sex-sought. By way of example, for the registration procedure via SMS only, figure 9 illustrates the temporal sequence of messages through the network, and between the various functional blocks inside server B and node P. The sequence is originated by an SMS of Request for registration to the SMS chat service transmitted by the mobile terminal TR 01 (but it could be a generic mobile terminal TR wherever positioned) to the telephone number NUM.TEL.M of Gateway C, and ends with a confirmation SMS of successful registration delivered to the user in possession of the mobile terminal TR 01. Inside the node P, the telephone gateway C sends the contents of the SMS to the IP address www.yyy.yy of the BIP internet gateway. The syntax of the SMS requesting registration to the chat service in the real rooms is â € œinfoâ € dispatch, in which info represents the following information: telephone number of the mobile terminal, nickname, age, gender-specific, sex-searched , also reported in the final block of figure 8. The Gateway BIP sends the content of the request SMS to the Gateway BIB of server B, where block BF checks the syntax, and in case of error it issues an error notification to block BL, while in the presence of a correct syntax the content of the SMS reaches block BC 01 with registration syntax. This last checks if by chance the user has not already been registered. If this is not the case, block BC 01 registers and sends a notification request (Notification R) to block BL, which in turn sends an SMS notification of successful registration to gateway BI for forwarding to gateway C and from here to the TR 01 terminal of the registered user. The SMS confirming the registration has the syntax: Nick registration done. In the event of a syntax error, block BL sends an error notification SMS to terminal TR 01, along the reverse path indicated in the figure.

Figure 10 illustrates the logon procedure of the local AT terminal to server B carried out by the operator in the real room A01 when it is opened to the public. The purpose of the procedure is to obtain the generation of a new CPS presence code to be displayed on the AD centralized display. Through the local AT terminal, the operator makes a logon request to the SMS chat service addressed to server B, including a verification password. The ATA functionality of the local AT terminal, before sending this request, checks if there is software registered on server B, and this happens only if the manager of the real room is also a customer of the SMS chat service. If so, the ATA functionality of the AT terminal sends the logon request to Server B via its BIL gateway. This request through the BIB gateway reaches the BH 02 functionality of server B, where the password is checked to verify the authenticity of the message. In case of correspondence, the real room A01 is declared in the LOGON state, otherwise a LOG authentication error notification is sent to the ATA block that originated the request. The information on enabling room A01 is transferred to the BD module, which disables from the SMS chat service all the nicknames still enabled with the last CPS assigned to the real room A01, and finally generates a new presence code CPS. The new CPS is sent back to the ATB block of the AT terminal, which reads it and forwards it to the ATC graphic interface, and from there to the AD display for viewing by all present in the real room A01. At this point, those present who intend to use the SMS chat service in the real room A01 will be able to request authorization with the new CPS.

Figure 11 illustrates the procedure for requesting enabling the SMS chat service in the real room A01, carried out by the user in possession of the TR 01 mobile phone and physically present in that real room, so he can see the presence code illuminated on the display public AD. The same procedure is valid for other real rooms and for other users present there. The user in question with his TR 01 mobile phone sends an SMS to the gateway number NUM.TEL.M whose syntax is as follows: â € œpresence codeâ € send. The SMS follows the path indicated in the figure and reaches block BF for checking the syntax and, if correct, reaches block BC 02 with the syntax of `` enabling '', where it undergoes the processing illustrated in figure 12, while in the event of a syntax error, block BF issues an error notification to block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 12, block BC 02 checks whether the ™ user is registered, and if so if not already enabled. If, as it should be, the user is not already enabled, block BC 02 checks if the CPS presence code is valid. If the user is not registered, a notification a) of a NICK registration request is sent to the BL block. If the user is already enabled, do not proceed further. If the user has entered an incorrect presence code, a notification c) of an incorrect presence code is sent to block BL. If the user is registered but not enabled and has entered a valid presence code, then he is enabled with the chosen NICK and a notification b) of NICK enabling is sent to block BL. The BL block, according to the notification received, prepares the content of an SMS which it forwards to the mobile terminal TR 01 following the route indicated in figure 11. The notification a) gives rise to the SMS 2) â € œNick not registeredâ €; the notification b) gives rise to the SMS 1) â € œNick enabledâ €; and finally the notification c) gives rise to the SMS 3) â € œIncorrect presence codeâ €. The status reached by the nicknames who received the SMS 1) is that of â € œINROOM ONLINEâ € in figure 3).

Figure 13 illustrates the transmission procedure from NICK TR 01 enabled to NICK TR 02 enabled, both inside the real room A01. The procedure is also valid in the OUTROOM ONLINE state. The syntax of the SMS sent is that indicated in round brackets and includes the recipient's nickname. The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œnick to nickâ € syntax reaches block BA 01 where it undergoes the processing illustrated in figure 13A, while in the event of a syntax error the block BF issues an error notification to the BL block, which in turn generates a syntax error notification SMS directed to the TR 01 terminal. With reference to figure 13A, the BA 01 block checks whether the remaining credit of the sender NICK TR 01 Ã It is sufficient to send the new SMS, and if insufficient it sends to block BL a notification d) of insufficient credit, otherwise it proceeds to format the chat SMS for the recipient NICK TR 02, which it sends to block BL. In both cases, the relative SMS reaches the recipient NICK following the route indicated in the figure.

Figure 14 illustrates the transmission procedure from the NICK TR 01 enabled to the public display AD, both inside the real room A01. The syntax of the SMS sent includes the text of the message sent, and differs from the previous one due to the fact that it does not include the recipient NICK. The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œnick to PUBâ € syntax reaches block BA 02, where it undergoes the processing illustrated in figure 14A, while in the event of a syntax error the block BF issues a syntax error notification to block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 14A, block BA 02 checks whether the local AT terminal of the room real A01 is still in the Logon state, and if this is not the case, it sends the notification e) of the Logout state to block BL, otherwise (Logon) proceeds to format the SMS for the public display AD which send to block BL. In case of Logout, block BL prepares a notification SMS e) which it sends to terminal TR 01 by the indicated route. In case of logon, block BL prepares an SMS with the message content for the public display AD and sends it to block ATB by the indicated route. The ATB block transfers the content to the ATC block, and from there to the AD public display.

Figure 15 illustrates the procedure for logging out of the local AT terminal from server B. The procedure is requested by the operator (co-manager of the SMS chat service) in the real room A01 in the imminence of its closure. The CPS presence code is kept valid for an optional period of time, which in any case does not exceed the instant of the subsequent reopening to the public. The operator formulates through the local AT terminal a logout request from the SMS chat service addressed to server B, including a verification password. The ATA functionality of the local AT terminal sends this request through its BIL gateway. The logout request through the BIB gateway reaches the BH 02 functionality of server B, which checks the password to verify the authenticity of the message. If the password matches, the real room A01 is declared in the â € œLOGOUT TIME ONâ € status (figure 3).

The information is transferred to the BD module, which switches all the nicknames enabled with the current CPS to the â € œOUTROOM ONLINEâ € status, after which it sends a â € œReal room closedâ € message addressed to the AD display. The message is sent back to the ATA block of the AT terminal, which reads the message and forwards it to the ATB function, and from this to the ATC graphical interface for sending to the AD display which displays it to all users again present in room A01. Once the optional duration of validity of the current CPS in the â € œLOGOUT TIME ONâ € status of the real room A01 has expired, the BH 02 function of the server B switches the status of â € œLOGOUT TIME OFFâ € (figure 3). The information is transferred to the BD module, which switches all the nicknames enabled with the current CPS to the status of â € œOutroom offlineâ €, which therefore loses its validity.

Figure 16 illustrates the procedure for interrogating the list of NICKs enabled in any real room, for example that of the applicant's A01 code. To carry out this procedure, the user must be registered but not necessarily enabled for the SMS chat service in a particular real room. Obviously, such a query is of greater interest as soon as the user has obtained the authorization for the SMS chat service and needs to know the nicknames available in that room, so as to be able to start conversing anonymously. Later, when he deems the potential of the SMS conversation exhausted, he may want to look elsewhere for new partners with whom to talk. In this case he should choose another real room nearby, and even before leaving the real room he is currently in, carry out a query on the list of enabled NICKs to discover potentially interesting ones, otherwise try again with a ™ other location. The syntax â € œlist? Â € sending the SMS requesting the NICK list does not specify the code of the real room, and this means that it coincides with the one (A01) for which the NICK TR 01 has obtained the ™ enabling the service in association with the presence code shown on the local display. The syntax â € œlist A03? Â € would give rise to a query of the NICKs present in room A03. The response provided by server B is an SMS containing 10 nicknames randomly chosen from those enabled in the interrogated room; if they are not enough, it is sufficient to repeat the query to obtain another 10. The random choice criterion is advantageous because it avoids a tedious query in alphabetical order and increases the surprise effect already in itself characterizing the whole service. For the supply in random mode of each group of 10 nicks subsequent to the first, it is possible to follow two criteria, of which, the first consists in making the choice on all the nicknames enabled in the real room, including those already previously provided ; while a second criterion consists in removing the nicknames already provided from the search. The first criterion is more advantageous for the manager, while the second for the users. As already said for the previous â € œmessage sequence chartâ €, the SMS requesting the nick list reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œLISTâ € syntax reaches block BE 05, while in the event of a syntax error, block BF issues an error notification to block BL. Block BE 05 performs the random reading of 10 nicks among all those enabled in room A01, forms the list of the nicknames read, and notifies this list with a notification SMS to block BL. The latter sends the notification SMS with the 10 nicks read to the mobile terminal TR 01 02 following the route indicated in the figure.

Figure 17 illustrates the procedure for manual interrogation of server B by the user in possession of the mobile terminal TR 01 in order to have a reply SMS with the indication of the connection status (relating to the SMS chat service) of a target NICK indicated as TR 02. Both TR 01 and TR 02 can be positioned anywhere on the network, as long as they are registered. The reply SMS contains one of the following three possible states of the target nick: 1) Nick TR 02 out room; 2) Nick TR 02 in room (ABCD); 3) Nick TR 02 logoff. The state 1) means that the Nick TR 02 is in the vicinity of a real room in its turn in the LOGOUT TIME ON state, and therefore he is in the temporary state of OUTRO-OM ONLINE; in this case the code of the real room is not rightly indicated as it is now closed and the service is about to expire. Status 2) means that Nick TR 02 is enabled inside the real room whose identification code is ABCD, in which case he is reachable. From a purely commercial point of view, the ABCD code also identifies the customer of the SMS chat service manager who sponsors this service in their own premises. The ABCD code must absolutely not be confused with the presence code temporarily assigned to the room for the purpose of enabling the nicknames present, and thereby the authentication of their SMS in relation to the chat service. If in the in-room status (ABCD) the ABCD code is that of the same room in which the Nick TR 01 is located, then the conversation via SMS with the Nick TR 02 can take place immediately. If the ABCD code instead indicates another real room, and the Nick TR 01 still decides to look for the Nick TR 02 because he is particularly interested in that nick, he could start a disconnection procedure from the room A01, interrogate the server B to have the address of the real room corresponding to the ABCD code, physically move into that real room, request the enabling with the CPS read on the display in that room, and finally get in touch via anonymous SMS with the Nick TR 02. For simplicity, the disconnection procedure is not indicated as it is dual of the enabling request procedure already described in figure 11, by varying only the syntax of the request SMS and the confirmation SMS which become respectively: â € œCPS logoffâ € sending and â € œNICK disabling doneâ €. In state 3) the Nick TR 02 is not reachable.

The procedure for manual interrogation of the status of Nick TR 02 is started by Nick TR 01 which sends a request SMS to the telephone gateway number NUM.TEL.M with the following syntax: â € œnick TR 02? Â € send . The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œS.NICKâ € syntax reaches block BE 02, where it undergoes the processing illustrated in figure 17A, while in the event of a syntax error the block BF issues an error notification to block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 17A, block BE 02 checks if nick TR 02 is registered, and if this is not the case, it sends the notification f) of Nick not found to block BL; otherwise (registered nick) it reads the status of the Nick TR 02 from the BG 02 database and formats an SMS with the indicated status, which it sends to block BL as notification g). In both cases, the notification SMS reaches nick TR 01 following the route indicated in figure 17.

The procedure for the automatic query of the status of a nick differs from the manual query for a different syntax of the query message, for example: â € œnick TR 02 ??? â € send, and for the fact that every time the nick initially interrogated (TR 02) changes status, a notification of the new status is sent to the applicant, corresponding to one of the three indicated above.

Server B notifies with an SMS to the queried nick all requests for information on its status. The nick interrogated in turn can initiate a status obscuring procedure, such that whenever other nicknames interrogate his status, the server B will reply with an SMS of â € œnick status not availableâ €. The redaction procedures will be seen in reference to the blacklists.

Figure 18 illustrates the procedure for querying server B by a registered user, for example, TR 01, anywhere on the network as long as it is registered, for example in room A01, to have a reply SMS with the indication of the name and geographical address of a real room whose identification code is ABCD. This type of query requires knowledge of the individual codes of the main real rooms (for example clubs or discos) in a specific area. The global information can be retrieved from the local terminal, or displayed in rotation in an area of the centralized display, and being coded it takes up little memory in your mobile phone. The procedure for querying the local ABCD address is started by Nick TR 01 which sends a request SMS to the telephone gateway number NUM.TEL.M with the following syntax: â € œABCD? Â € send. The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œIND.LOCâ € syntax reaches block BE 03, where it undergoes the processing illustrated in figure 18A, while in the event of an error block BF issues an error notification to block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 18A, block BE 03 checks whether the ABCD code corresponds to that of identification of a real room (or of a customer), and if it does not turn out to be so, it sends notification h) of address not found to block BL; otherwise (valid code) it reads the BG 03 database to obtain the name and address of the real room which it sends to block BL as notification i). In both cases the BL block formats the received data and prepares a respective notification SMS, which it sends to the requesting nick TR 01 through the way indicated in the figure.

Figure 19 illustrates the procedure for querying the residual credit of server B by a registered user, for example, TR 01, anywhere on the network as long as registered, for example in room A01, to receive an SMS from server B reply with the indication of the remaining credit expressed as a number of SMS still available. It is necessary to distinguish between the usual telephone credit on the TR 01 SIM card, accrued against a payment made in favor of the mobile radio service provider: TIM, Vodafone, etc., from the credit for the anonymous SMS chat service in real rooms , accrued against a payment made in favor of the operator of this service, and in the various forms envisaged. It is obvious that in order to use the anonymous SMS chat service in the real rooms, it is necessary to have both credits. Therefore, the residual credit query procedure is started by Nick TR 01 which sends a request SMS to the telephone gateway number NUM.TEL.M with the following syntax: â € œcredit? Â € sending. The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the SMS content with â € œCREDITâ € syntax reaches block BE 04 which reads the (residual) credit of NICK YR 01, while in the event of a syntax error the block BF issues an error notification to block BL. The information on the remaining credit is transferred to block BL which prepares a notification SMS that reaches nick TR 01 following the route indicated in the figure.

Figures 20 and 21 illustrate the procedures for requesting blacklist on and blacklist off respectively for a registered nick, for example the nick TR 02, anywhere on the network, for example in the same real room A01 as the requesting nick TR 01. The blacklist It is a black list of nicknames that have become unwelcome to which any communication is forbidden, probably following the receipt of SMS of inappropriate content. Blacklist on for a specific nick means the inclusion in the blacklist of the nick indicated in the request SMS. Blacklist off means the cancellation from the blacklist of the nick indicated in the request SMS. Referring to figure 20, the blacklist on nickxxx request procedure is started by Nick TR 01 which sends a request SMS to the telephone gateway number NUM.TEL.M with the following syntax: â € œblacklist on nick TR 02â € send . The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œB.LISTâ € syntax reaches block BE 01 / A, where it undergoes the processing illustrated in figure 20A, while in the event of an error syntax block BF issues an error notification to block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 20A, block BE 01 / A checks if nick TR 02 It is registered, and if this is not the case, it sends the notification j) of Nick not found to block BL; otherwise (registered nick) proceeds with the insertion of Nick TR 02 in the blacklist and sends the information to block BL as notification k). In both cases, the notification SMS reaches nick TR 01 following the route indicated in figure 20. The notification SMS k) is the following: blacklist on (ok) nick TR 02 .

Referring to figure 21, the blacklist off nickxxx request procedure is started by Nick TR 01 which sends a request SMS to the telephone gateway number NUM.TEL.M with the following syntax: â € œblacklist off nick TR 02â € send . The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œB.LISTâ € syntax reaches block BE 01 / A, where it undergoes the processing illustrated in figure 20A, while in the event of an error syntax block BF issues an error notification to block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 21A, block BE 01 / A checks if nick TR 02 It is registered, and if this is not the case, it sends the notification l) of Nick not found to block BL; otherwise (registered nick) it deletes the Nick TR 02 in the blacklist and sends the information to block BL as notification m). In both cases the notification SMS reaches nick TR 01 following the path indicated in figure 20. The notification SMS k) is the following: blacklist off (ok) nick TR 02 .

Figures 22 and 23 illustrate the procedures for requesting status off and status on respectively for a registered nick, for example the nick TR 02, anywhere on the network, for example in the same real room A01 as the requesting nick TR 01. As mentioned previously, the status off procedure allows the requestor to inhibit the transmission of their status information to a specific requesting nickname. Status on instead cancels the inhibition. Referring to figure 22, the procedure for requesting status off nickxxx is started by Nick TR 01 which sends a request SMS to the telephone gateway number NUM.TEL.M with the following syntax: â € œstatus off nick TR 02â € sending. The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œS.NICKâ € syntax reaches block BE 01, where it undergoes the processing illustrated in figure 22A, while in the event of a syntax error the block BF issues an error notification to block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 22A, block BE 01 / A checks if nick TR 02 is registered, and if this is not the case, it sends notification n) of Nick not found to block BL; otherwise (registered nick) it disables the sending of the status information of the Nick TR 01 to the Nick TR 02, and sends the information to the BL block as notification o). In both cases the notification SMS reaches nick TR 01 following the path indicated in figure 20. The notification SMS o) is the following: status off (ok) nick TR 02 .

Referring to figure 23, the procedure for requesting status on nickxxx is started by Nick TR 01 which sends a request SMS to the telephone gateway number NUM.TEL.M with the following syntax: â € œstatus on nick TR 02â € sending. The SMS reaches server B following the route indicated in the figure. Block BF checks the syntax and, if correct, the content of the SMS with â € œS.NICKâ € syntax reaches block BE 01, where it undergoes the processing illustrated in figure 23A, while in the event of an error, block BF issues an error notification towards block BL, which in turn generates a syntax error notification SMS directed to terminal TR 01. With reference to figure 23A, block BE 01 checks if nick TR 02 is registered, and if if this is not the case, it sends the notification p) of Nick not found to block BL; otherwise (registered nick) it restores the sending of the status information of Nick TR 01 to Nick TR 02, and sends the information to block BL as notification q). In both cases the notification SMS reaches nick TR 01 following the route indicated in figure 20. The notification SMS o) is the following: status on (ok) nick TR 02 .

On the basis of the description provided for a preferred embodiment example, it is obvious that some changes can be introduced by the person skilled in the art without thereby departing from the scope of the invention as shown in the following claims.

Claims (14)

R I V E N D I C A Z I O N I 1. Method for the implementation of a chat service by transmitting and receiving short text messages, hereinafter called SMS, in limited areas, later called real rooms (STR1, STR2, STR3), included in the area coverage (3) of the radio signal of a mobile radio network (1, 2, 4, 5), connected to a connection node (6), hereinafter called gateway, between the mobile radio network and a server (7) that manages the chat service in a network of real rooms, characterized by the fact that it includes the steps of: a) connect to the server (7) a plurality of fixed terminals (8, 9, 10), each located in a real room set up on an area separated from possible further territorial areas on which respective real rooms are set up. communicating; the server by performing the steps of: b) receive the messages requesting registration to the chat service, each message including the telephone number of the mobile terminal (11, 12, 13) of the applicant and at least one nickname, hereinafter called nickname, unique in the network of real rooms ; c) generate for each real room a unique and temporary authentication code of the SMS relating to the chat service, and transmit said authentication codes to the fixed terminals (8, 9, 10) located in the respective real rooms for making them available to users registered present in that real room; d) receive the request messages for enabling the chat service sent by registered users, and grant the authorization to those registered users whose request message includes a valid temporary authentication code; e) receive the chat SMS sent by the gateway (6) on behalf of users enabled for the chat service and for each real room (STR1, STR2, STR3): â ’check if the recipient's nickname included in each authenticated SMS corresponds to a user enabled in that real room, or if the SMS is public, - in the event of an affirmative verification, retransmit the content of each authenticated SMS to the gateway (6) for forwarding to the telephone number of the mobile terminal (11, 12, 13) corresponding to the recipient nickname, masking the sender's telephone number, or , â ’forward the content of each public SMS, after appropriate filtering, to at least one centralized display device (8b, 9b, 10b). 2. The method of claim 1, characterized in that at step b) the registration request messages are sent by the requestors directly to the network address (IP ADD.0) of the server (7). 3. The method of claim 1, characterized in that in step b) the registration request messages formulated by the applicants are forwarded to the server (7) through the fixed terminal (8, 9, 10) of the real room in which the generic requester is located. 4. The method of claim 1, characterized by the fact that in step b) the registration request messages are SMS formulated with established syntax sent by the applicants to a telephone number (TEL.M) assigned to the gateway (6) by the telephone service provider, said SMS being automatically forwarded to the server (7). 5. The method of any one of claims 1 to 4, characterized in that in step a) the server (7) assigns each real room (STR1, STR2, STR3) an identification code (A01, A02, A03) and transmits it to the fixed terminal (8, 9, 10). 6. The method of any one of claims 1 to 5, characterized by the fact that in step b) the server (7) verifies that the syntax and data contained in the registration request messages comply with pre-established rules, and in case affirmative, sends the senders a respective notification message of successful registration. 7. The method of any one of claims 1 to 6, characterized in that in step c) the provision of the temporary authentication code is made by presenting the code by means of the said centralized display device (8b, 9b, 10b). 8. The method of any one of claims 1 to 6, characterized by the fact that in step c) the provision of the temporary authentication code is done automatically by the fixed terminal (8, 9, 10) which includes it in the messages request for enabling forwarded to the server (7) on behalf of registered applicants, matching it to the nickname read from a card owned by registered users through at least one â € œbatchâ € reading station present in the real room (STR1, STR2, STR3). 9. The method of any one of claims 1 to 6, characterized by the fact that in step c) the provision of the temporary authentication code is done automatically by the fixed terminal (8, 9, 10) which includes it in the messages request for enabling forwarded to the server (7) on behalf of registered applicants, matching it to the nickname stored inside passive RFID devices respectively worn by registered users. 10. The method of any one of claims 1 to 9, characterized by the fact that any registered user can send a query SMS to the server (7) characterized by its own syntax to have one of the following return from the server information: ∠’the list of all nicknames enabled for the service in a real room corresponding to the identification code sent by the applicant; â ’the list of all nicknames enabled for the service in the same real room where the requesting nickname is located; â ’the current status of a nickname relative to any real room; ∠’the change in the status of a nickname; ∠’the address of a real room corresponding to a given identification code of the same; â ’the remaining credit available for the service. 11. The method of any one of claims 1 to 9, characterized by the fact that any registered user can send an SMS to the server with the syntax of inserting a nickname in a blacklist of nicknames for which it must be communication inhibited. 12. The method of claim 10, characterized by the fact that any registered user can send to the server (7) an SMS requesting not to fulfill the queries on their status towards a specific requesting nickname. 13. The method of any one of claims 1 to 9, characterized by the fact that an authorized user can send an SMS with disabling syntax to the server (7) in order to be able to transfer to another real room (STR1, STR2, STR3 ) where to request authorization for the service. 14. System for the implementation of a chat service by transmitting and receiving short text messages, hereinafter referred to as SMS, in limited areas, hereinafter referred to as real rooms (STR1, STR2, STR3), included in the area coverage (3) of the radio signal of a mobile radio network (1, 2, 4, 5), comprising: ∠’a connection node (6), later called gateway, connected to the mobile radio network and to an IP server (7) that manages the chat service in the real rooms, the system being characterized by the fact that it also includes: ∠’a plurality of fixed terminals (8, 9, 10) located within their respective real rooms disjoint and not communicating, connected to the server (7) to form an intranet in star topology; - a plurality of displays (8b, 9b, 10b) connected to respective said fixed terminals to display in each real room a unique code of defined duration, generated by the server (7) to authenticate anonymous chat SMS, each associated with a nickname unique in the intranet, originated in that real room to nicknames located in the same real room and enabled for the chat service.