System for consulting and/or updating DNS servers and/or ldap directories

System for querying and/or updating DNS servers and/or directories

The present invention relates to a query and/or update of a DNS (Domain Name System) server and/or LDAP (Lightweight Directory Access Protocol) directory from a terminal. In particular, the present invention enables users to query and update telecommunication resource records stored in DNS or LDAP servers from any terminal.

DNS (and LDAP) servers are used in data processing to name machines (for example, connecting a network URL with the IP address of the network server that stores the URL). These servers are usually queried through a data processing machine, using a software commonly called RESOLVER, and most terminals or data processing servers have the RESOLVER software. This software makes it possible to extract information from DNS servers in response to customer requests. This information can be obtained directly from the first DNS server that is queried, or from the DNS server pointed to by the first server, and if necessary, the query will be performed in a successive and indirect manner accordingly. The content of the DNS server is updated occasionally by the "management" specialist (updating flat files under the UNIX platform or updating the dedicated application software under the Windows service platform through IHM). The server content and the format of the request are defined in the protocol (called the DNS protocol), described in the RFC 1034 and RFC 1035 documents, and can be found on the IETF website (www.ietf.org).

In addition, DNS servers are now required to assume such a role of ENUM service, whose purpose is to provide users with universal portability of phone numbers. The ENUM service uses the international telephone dialing system defined by the ITU, among which E.164 is recommended. More precisely, the ENUM service enables any user with the single E.164 phone number (the phone number is +3329053859) to be connected through various devices according to their preference for files stored in the network through the server. For example, a single E.164 phone number of an ENUM user can be associated with a mobile phone number (+33686166924), a fixed phone number (+33296916404), an e-mail address (bertrand.Dupont@rd.francetelecom.com), and a website address. URL (http://www.bertrand.dupont.com), a VoIP phone number, a fax number, etc. are connected.

All this information can be stored in a standard DNS server and accessed according to the hierarchical dispatch mode described in Figure 1.

Access is through a root server (E164.ARPA). Each country has a single telephone code (33 for France), and each country uses a primary DNS server (3.3.E164.ARRA for France). Finally, telecom operators or ENUM service providers use DNS servers (such as DNS1 to DNS6 in Figure 1) based on the telephone resources allocated to them (share of E.164 telephone numbers). The model used is divided by shares: fixed STN phone numbers have 5 shares, prefixed from 1 to 5, and mobile phone numbers have one share, prefixed by 6.

A path of the DNS server tree is related to the telephone number in E.164 format. More precisely, each phone number is reversed after it is converted into E.164 international format, the "+" code is omitted, and a dot is added between each number, and the result obtained is combined with the e164.arpa field to convert the phone The number is converted into a single network domain name. For example, the telephone number +33686166924 gets the network domain name 4.2.9.6.6.1.6.8.3.3.e164.arpa after conversion.

In addition, for each telephone number converted into E.164 format, it is related to the record stored in the corresponding secondary server that contains one or more resource records (resource records or RR), and each resource record can contain one Or multiple fields. For example, for a telephone number converted into E.164 format, it can be related to the NAPTR (Naming Authority PoinTeR) resource record, which is defined in the RFC2915 and RFC1916 documents, which are available on the IETF website. Briefly speaking, a NAPTR resource record represents a telecommunication service (telephone or fax number, e-mail address, website, etc.) related to the priority level. The term ENUM record (or ENUM file) will be used as a set of NAPTR records related to network domain names in the following. For example, the following EUNM file is stored in the secondary DNS server: $ORIGIN9.5.8.3.5.0.6.9.2.3.3.e164.arpa.

IN NAPTR 100 10 "u""tel+E2U""! ^.*$! tel: +33296053859! IN NAPTR 100 11 "u""tel+E2U""! ^.*$! tel: +33296916404! IN NAPTR 100 12 "u" "tel+E2U" "!^.*$! tel: +33686166924!

IN NAPTR 100 13"u" "sip+E2U""!^.*$!sip.bdupont@sip.ftrd.fr!" IN NAPTR 120 10"u" "mailto+E2U""!^.*$!mail2 : Bdupont@rd.ftrd.fr! "IN NAPTR 130 10 "u" "http+E2U" "!^.*$! http://www.Bdupont.fr!" The title line indicates a telephone number with E.164 The corresponding Internet domain name. RESOLVER software makes it possible to access records from domain names. In the above example, a telecommunication resource or service corresponds to each NAPTER record. The two numeric fields follow the phrase "NAPTER" and are respectively associated with the service representative's service priority levels: "Order" and "Preference". The lower the value of the "Order" field, the higher the priority of the service. If several services have the same "order" level, the lower the relevant preference value, the higher the priority of the service. Therefore, the priority of the above-mentioned list of records is lowered from top to bottom.

The first line is the fixed telephone service 0296053859 with the order of 100 and the priority of 10.

The second line is the fixed telephone service 0296916404 with the order of 100 and the priority of 11.

The third line is the mobile phone service 0686166924 with the order of 100 and the priority of 12.

The fourth line is the IP phone service with order of 100 and priority of 13 (connected to SIP address bdupont@sip.ftrd.fr via SIP.

The fifth line is the e-mail service with order of 120 and priority of 10, and its destination address is bdupont@rd.ftrd.fr.

Finally, the sixth line is the web service whose order is 130 and priority is 10, and its access URL is http://www.bdupont.fr.

The meaning of this record is as follows. If you find that you want to connect to the E.164 phone number (+33296053859), the RESOLVER software sends a request with the corresponding Internet domain name (9.5.8.3.5.0.6.9.2.3.3.E164.arpa) to the secondary DNS server . In response, the secondary DNS server (DNS2) returns a list of telecommunication records (hereinafter also referred to as services) related to the telephone number +33296053859, which is provided in the form of records. RESOLVER software and ENUM service can be in order (the system will try to connect to the highest priority service, if there is no response or the line is busy, the system will try to connect to the lower priority service, and so on), or in broadcast mode (ENUM service will try Connect all services at the same time) use all or part of these resources.

The change to the ENUM file in the DNS server is not suitable for the administrator to make, as known from the prior art, the update method is well adapted. This is because, unlike Internet domain names, ordinary telecommunication services such as telephone or fax frequently change. In addition, it is sometimes necessary to automatically program these changes daily or even hourly. Considering the effectiveness and flexibility, it is extremely difficult to change the settings of the ENUM file supported by its telecom operator or its ENUM service provider.

A special starting point of the present invention is to enable users to query and/or modify their ENUM files stored in the DNS server or LDAP directory simply and quickly.

In more commonly used terms, the starting point of the present invention is to enable users to easily and quickly query and/or change one or more resource records stored in a DNS or LDAP server from any common terminal.

The starting point of the present invention is solved by a system for querying and/or updating records stored in a first database, the records containing one or several resource records, and the database is stored in a domain name server (called a DNS server), or It is stored in a directory server (called an LDAP server) and can be accessed indirectly through a DNS server. The system includes:-a communication device to ensure that the system receives a request from a telecommunication terminal to query and/or update the record, or a program for such a request;-a control device, which is suitable for transmission to the system according to Or the query and/or change request programmed in the system in advance to determine the domain name and the operation to be performed on the record;-a protocol management device, which is suitable for searching and storing the first The IP address of the server of the database, and according to the operation, a request to read or update the record is transmitted to the server.

Advantageously, the system includes a verification device adapted to perform identity verification on the sender of the request at the application level based on verification information stored in a second local or remote database.

When the sender of the request has been verified, the protocol management device can transmit a query request according to the DNS protocol (DNS query) to the DNS server, the request with the domain name as its parameter, and A first response is received from the server.

According to an embodiment, the control device is adapted to determine the domain name based on the user identifier, which may be the user's E.164 telephone number.

The control device then extracts the information, and according to the request, determines the operation to be performed on the NAPTR resource record.

According to other embodiments, the control device is adapted to extract the information, and according to the request, determine that one or more records (A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS , PTR, HINFO, MINFO, MX, TXT).

The above-mentioned features and other features of the present invention will become clearer after reading the following description of a specific embodiment. The description is given with reference to the accompanying drawings, which are as follows: Dispatch mode used in the service; Figure 2A outlines an example of the system environment according to the present invention; Figure 2B outlines the environment in Figure 2A, with the ENUM service as the background; Figure 3A shows an example of the system environment according to the present invention A schematic block diagram of the query/update system 50; Figure 3B shows an example of the query/update system 50 according to the present invention; Figure 4 outlines the process of querying and manually updating ENUM files accessed in sound mode; 5 The outline shows the process of sending, querying and manually updating ENUM files through SMS; Figure 6 shows the outline of the process of querying and manually updating ENUM files through the Internet; Figure 7 shows the outline of the use of mini-visual terminals, query and manual The process of updating ENUM files; Figure 8 shows the process of querying and manually updating ENUM files through e-mail; Figure 9 shows the process of querying and manually updating ENUM files through the UUI of the ISDN terminal; Figure 10 The outline shows the process of programming the automatic update of ENUM files; Figure 11 outlines the process of automatic updating of ENUM files; Figure 12 outlines the process of querying ENUM files when they are stored in the LDAP directory Process; Figure 13 outlines the process of updating ENUM files when they are stored in the LDAP directory; Figure 2A illustrates an example of the system environment according to the present invention.

The telecom resource management service provider, hereinafter referred to as the service provider, is shown as 301,..., 30N in the form of a chart. Each service provider has a DNS server 31i or LDAP server 34i storing databases, and more generally, has several redundant servers to enhance the reliability of service access. The database contains telecommunication resource records of all relevant users of the service provider.

According to the system 50 of the present invention, on the one hand, it can be connected to a public telephone network through a standard interface of analog or digital (T0 or T2), and on the other hand, it can be connected to an IP network through a standard interface of an Ethernet network.

More precisely, when the present invention can be accessed by any user regardless of whose service provider is, the system 50 is connected to the Internet, and when the present invention is only accessed by users of one service provider, the system 50 is connected to the internal enterprise Internet (Intranet).

The system 50 can be accessed through an ISDN telephone terminal 2, which is connected to the ISDN network 10 directly or through a PABX 3. It should be stated that the ISDN network is natively interconnected to the STN network.

The system 50 can also be accessed through an ordinary telephone terminal 4 or a minitel (Minitel) 5 connected to the STN network 11.

The system 50 can also be accessed through a GSM mobile phone terminal 6 or a UMTS terminal (not shown). The GSM and UTRAN networks are locally interconnected to the STN network.

The system 50 can be accessed through the IP telephone terminal 7 connected to the IP network 13.

Finally, the system 50 can be accessed by connecting to the microcomputer 8 of the IP network through an Ethernet interface (local business network) or a modem (STN/ISDN/ADSL/cable/satellite, etc.).

The user will also be able to receive notifications from the system 50 through one of the aforementioned terminals or the facsimile terminal 9.

Fig. 2B illustrates an example of the system environment according to the present invention, with the ENUM service as the background. The parts with the same reference numbers are equivalent to the parts in FIG. 2A.

The one marked 40 is the root ENUM DNS server. This server contains all IP addresses referencing all level 1 ENUM DNS servers, corresponding to the area codes of different countries (33 for France, 34 for Spain, 44 for the United Kingdom, etc.). For example, 41 is the first-level ENUM DNS server corresponding to France.

Each ENUM operator or service provider has at least one first-level second-level ENUMDNS server 31i (referred to as the first server), and has at least one second-level second-level ENUMDNS server 31i' (referred to as the second server). Redundancy to ensure good reliability of service. The first (or second) server stores a database 33i (or 33i'). In each secondary server, for the E.164 telephone number of each ENUM service user, there are stored: a profile composed of various telecommunication resources of the user, and each resource corresponds to a kind of access device (for example, fixed Office telephones, fixed residential telephones, mobile phones, IP telephones, office e-mail addresses, mobile e-mail addresses, business fax numbers, etc.) and the priority levels (priorities) allocated to each of these access devices. Each telecommunications resource is represented by a NAPTR resource record, as seen above. The priority level of resources is determined by the order and preference field of NAPTR resource records, as defined in the IETF RFC2915 document and exemplified in the preface.

The ENUM service provider A30i can also have an LDAP server that stores an LDAP dynamic directory 36i, as defined in the IETF RFC1959 document. The advantage of this setting is that it can manage ENUM files in the LDAP dynamic directory in an indirect way instead of the secondary ENUM DNS. The advantages obtained include: No more changes to the ENUM customer's files on the secondary ENUM DNS server, but directly in the LDAP directory designed to store dynamic directories. In this case, the secondary ENUM DNS (31i) contains the following files with all E.164 telephone numbers beginning with "+332": $ORIGIN 2.3.3.e164.arpa.

IN NAPTR 100 10 "u" "ldap+E2U" "!^.+332(.*)$! ldap: //ldap.providerA.fr/cn=01!" The LDAP directory 36i can be indirectly from the secondary ENUM DNS server Access, including resource records of different users of provider A.

The ENUM server or channel 80 can query the ENUM service provider 30i to know the telecommunication resource list of each ENUM user. To this end, RESOLVER software converts the users E.164 unique number into the domain name as seen above, and accesses the secondary ENUM DNS server 31i through successive indirections, and where applicable, after an auxiliary indirect method, access The LDAP server 34i. The service provider returns the resource list of the relevant user and the relevant priority level. The ENUM server or channel can then, depending on the situation, add users in a descending order of priority by using resources one by one, or adding them in the form of all users' resources.

FIG. 3A shows a schematic block diagram of the update system 50 according to the present invention.

The system includes a communication device 1150 to ensure that the user has a dialogue with the system, in particular:-transmitting an authentication request to the user;-receiving information from the user so that it can be authenticated;-receiving from the user A request to make a record change (called a manual request), or a request for automatic changes based on time or location (geographical) criteria (called a program request); -Transmit the content of the record before or after the change request; -When the requested change has been If it does, send the update confirmation of the update storage unit (location) to the user, if it fails, the update is invalid;-after the query or check is completed, send to the user a pre-recorded in the system The automatic change request in the;-the history of the changes that have been made is transmitted to the user.

The system also includes an interface device 1160 that connects the communication device to an STN/ISDN network and/or an IP network (Internet or intranet).

The system also includes a verification device 1173 that cooperates with the communication device to verify the sender of the query and/or update request at the application level. Application-level verification has the advantage of ensuring that users can operate on any terminal. The verification device uses information stored in the local or remote database 1170 to perform verification.

In addition to the above information, the database 1170 may specifically include: automatic change procedures related to different users, IP addresses of servers of different telecommunications resource management providers, recorded manual or automatic change history, and update confirmation/invalid notification must The address to be served.

The system 50 also includes a protocol management device 1162 that performs the RESOLVER function. In particular, the protocol management device is suitable for searching the content of the resource record (RR) in the form of a domain name in the case of a successive indirect method. The protocol management device can transmit a query request according to the DNS protocol (DNS query) for this purpose. In addition, the protocol management device can update the resource record according to the update request (DNS update). According to one embodiment, if the resource record is stored in the LDAP directory, the protocol management device also allows to query the record in the LDAP directory (send an LDAP search request) and allow the record to be updated (send an LDAP change request). When the update is completed, the protocol device receives a confirmation from the server of the telecommunication resource management provider.

The control device 1175 cooperates with the above devices and specifically:-command to transmit a verification request from the communication device;-after the verification device 1173 authenticates the user, request the protocol device 1162 to transmit a query request, format the response and send it through the communication device Retransmit it to the user in an understandable form; -According to the user's request to modify the resource record, determine the operation to be performed on the record and determine the user's identifier; -After receiving the update confirmation/invalidation of the protocol device After that, the user is notified of the confirmation/invalidation through the communication device.

Fig. 3B illustrates an exemplary embodiment of the present invention, with the ENUM service as the background.

The parts with the same reference numbers are equivalent to the parts in FIG. 2A. In particular, with one of the aforementioned terminals, the user can connect to the update system 50. 30 is a telecommunications resource management service provider, which includes a secondary DNS server 31 (referred to as the first server), and has a redundancy composed of a second server (not shown). The server 31 includes a database 33 and a DNS protocol storage stack 32 that adopts the DNS protocol described in the RFC1034 and RFC1035 documents. The protocol storage stack also adopted the DNS protocol described in the RFC2136 and RFC2137 documents to allow resource record (RR) update (DNS update). Alternatively, the resource management service provider also includes an LDAP directory server 34 that stores the database 36. The LDAP directory server includes an LDAP protocol storage stack 35.

The communication device of the system 50 is composed of the following modules: A module 52 responsible for handling incoming and outgoing telephone calls. This module manages the establishment and termination of communication (dropping); the user-to-user information (UUI) management module 53 for extracting and transmitting UUI information; and the module 54 for processing DTMF codes. This module is responsible for recovering the DTMF input by the user; sound synthesis module 55; module 56 for broadcasting pre-recorded sound files connected into sentences; visual data server 57; module 58 for receiving and sending SMS; Fax sending module 59; SMTP server 61 for sending and receiving e-mail; Dynamic web server 63.

It should be noted that the system may also include a voice recognition module (not shown) suitable for recognizing user pronunciation information.

The communication device is connected to the outside through the STN and/or ISDN interface 51 and the IP interface 60. The former is based on a multi-interface STN analog card, or based on a T0 (2-channel) or T2 (30-channel) ISDN card. The latter is an Ethernet interface. The path marked 14 indicates that the STN/ISDN network and the IP network are locally interconnected by the VOIP protocol (H323/SIP).

As mentioned above, the system 50 includes an authentication device 73, which enables service users to perform applicative authentication based on authentication information, such as a pseudonym (user name) and password stored in a local or remote database 70. In addition, the database contains identifiers of different ENUM service providers (such as 30), IP addresses or machine names of dual DNS, requests for automatic changes to ENUM files, historical records of manual or automatic changes to ENUM files, and addresses for notification of changes to ENUM files (Fax number, SMS, e-mail).

The system also includes a DNS protocol management module 62, preferably its security mode (DNSSec). In particular, this module performs the role of RESOLVER to read resource records.

When needed, an LDAP protocol management module 64 is installed on it to read and change records in the LDAP directory.

The system also includes a module 72 for setting the address of the secondary DNS server, and a module 71 responsible for updating the ENUM file manually or automatically. When necessary, the module 71 can also produce statistical analysis performed by the system.

The control device first includes a module 74 that is responsible for automatically configuring the ENUM file according to the automatic change request programmed by the user and stored in the database 70, and then includes a module 75 that is responsible for "manually" configuring the ENUM file. The latter manages ENUM scripts, especially ENUM file reading scripts (note that ENUM files are composed of NAPTR resource record lists), and also manages scripts for changing NAPTR resource record fields, especially the order, preference and service fields (e- mail address, phone number, e-mail address, etc.). If you want to have query and/or update functions for DNS resource records other than NAPTR, you must have auxiliary scripts to change them.

Figure 4 schematically illustrates the process of querying and manually changing the ENUM file of the sound mode through a fixed or mobile phone of STN, ISDN, GSM or IP type.

In step 100, the ENUM user sends a free phone call (green number type), or a pay phone call, the pay phone call is paid according to the location or fixed rate of the audio phone or the color number type phone, the audio phone or the color phone The number type phone is: a terminal connected to a public network or a fixed STN 4 or ISDN 2 via PABX 3, or a GSM type mobile phone terminal 6, or an IP terminal 7 of the STN/ISDN interface in the system 50. In step 101, the automatic call processing controller 52 automatically receives an incoming call. In step 102, the ENUM script module 75 sends a command to the voice synthesis module 55 or to the sound file broadcasting module 56 to broadcast to the ENUM user in step 103 a voice inviting the ENUM user to enter his E.164 number and his pen name and password . In step 104, the ENUM user enters this information from the keyboard, and the information is in the form of DTMF band (in the band) is transmitted and intercepted by the DTMF processing module 54. In step 105, this information is provided to the verification module 73, which queries the local or remote database (for example, through an ODBC interface, that is, a public database connection interface), and searches for the E.164ENUM number. In step 107, the corresponding verification information is provided to the verification module 73. The latter compares the pseudonym and password entered by the ENUM customer with the verification information contained in the database 70. If they are the same, in step 108, the verification module 73 instructs the voice synthesis module 55 or the sound file broadcast module to broadcast a notice to the ENUM user in step 109: "Press 1 to query your ENUM file, press 2 to change the attributes of your ENUM file, Press 3 to automatically configure your file, press 4 to change your pen name/password, press 5 to access the record of your file changes," and so on. If the ENUM user presses the key 1 on his telephone keypad in step 110, the corresponding DTMF code is intercepted by the DTMF processing module 54 and retransmitted to the ENUM script module 75 in step 111. The ENUM script 75 detects that this is a read command for an ENUM file. So in step 112, the ENUM script 75 sends a query request to the DNS protocol module 62, the request with the E.164 address of the ENUM user converted into a domain as a parameter (E.164 phone number 332960533859 is converted to 9.5.8.3. 5.0.6.9.2.3.3.e164. arpa). The DNS management module 62 that performs the traditional role of RESOLVER first checks whether the information exists in its cache memory using the aforementioned query or query method (in step 113), and then according to the DNS standard protocol (DNS query request), The zero-level DNS server, the first-level DNS server, and the second-level DNS server through the DNS protocol storage stack 32 are checked sequentially. In order to obtain effectively, the data recorded by the NAPTR is installed in the random access memory of the DNS server 21. If the ENUM user is indeed recorded in the DNS server 31 of the ENUM service provider 30, the DNS protocol storage stack 32 returns the corresponding NAPTR record list to the DNS protocol module 62 in step 114. The DNS protocol module 62 is responsible for retransmitting it to the ENUM script module 75 in step 115. Module 75 analyzes and understands the NAPTR records and generates a text that can be understood by ENUM users, namely "Service 1: Phone 0296053859, Service 2: Phone 0686166924, Service 3: e-mailbertrand.dupont@rd.francetelecom.com" and so on . In step 116, this text is sent to the voice synthesis module 55, which is responsible for broadcasting this information to the ENUM user in step 117. When the sound file broadcasting module 56 is used, the module 75 generates a link of the sound file to be played.

After broadcasting this information, in step 118, the sound synthesis module 55 or the sound file broadcasting module 56 broadcasts the list of operations that can be performed on the ENUM file again: "Press 1 to query your ENUM file, and press 2 to change the attributes of your ENUM file. , Press 3 to automatically configure your file, press 4 to change your pen name/password, press 5 to access the record of your file changes," and so on.

If in step 150, the ENUM user chooses to change his ENUM file, then in step 151, after the DTMF processing module 54 detects the DTMF code, this command is intercepted by the ENUM script module 75. Then the system 50 enters the repeated language state for broadcasting voice information to ENUM users, the voice information comes from the ENUM script module 75 (at step 152), according to the voice synthesis module 55 or the module 56 that broadcasts the linked voice file. (context) and notices (in step 153), and the generated text. The user uses his DTMF keyboard to confirm the provided selection in step 154, and in step 155, the command is transmitted to the ENUM script 75. For example, the sound language can be: °Press 1 to change the order/preferential selection of your services, press 2 to change service attributes, press 3 to add services, press 4 to cancel services, and so on.

°4°Press 1 to cancel the phone number 0296053859, press 2 to cancel the phone number 0686166924, press 3 to cancel the e-mail address bertrand.dupont@rd.francetelecom.com, etc.

°2°press 1 to confirm your choice, otherwise press 2°1°press 1 to cancel the service, press 2 to record your changes, press 0 to return to the main menu °2 when the ENUM user requests to record the ENUM performed When the file is changed, in step 156, the ENUM script module 75 sends a change command request to the DNS protocol module 62. In step 157, the latter sends a "DNS UPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30. The IP address of the latter is stored in the database 70 and can be found based on the E.164 number of the ENUM user. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS can re-download the change at a predetermined time interval. In step 159, the database 33 confirms the update, which generates a response to the command request in step 160. In step 116, the ENUM script 75 intercepts the return code of this response, and then in step 162, it generates a confirmation/invalid message about the recorded change. In step 163, the voice synthesis module 55 or the voice file broadcast module broadcasts this information to the ENUM user. The latter can stop communication.

When the ENUM user requests to record the modification of the ENUM file, in step 156, the ENUM script module 75 sends a modification command request to the DNS protocol module 62. In step 157, the latter sends a "DNS UPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30. The IP address of the latter is stored in the database 70 and can be found based on the E.164 number of the ENUM user. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS can re-download the change at a predetermined time interval. In step 159, the database 33 confirms the update, which generates a response to the command request in step 160. In step 116, the ENUM script 75 intercepts the return code of this response, and then in step 162, it generates a confirmation/invalid message about the recorded change. In step 163, the voice synthesis module 55 or the voice file broadcast module broadcasts this information to the ENUM user. The latter can stop communication.

According to a change in this process, in response to a voice message, the user can directly verbally respond. Therefore, a voice recognition module that determines the choice or the information contained in the response is needed.

Figure 5 schematically illustrates the process of sending, querying and manually changing ENUM files through short messages sent by GSM, STN, ISDN, or IP type mobile phones or fixed telephone terminals.

In step 200, the ENUM user sends a formatted short message (ie: E.164 number + pseudonym + password + request) as specified by the ENUM service provider 30 to the short message module 58 of the present invention. The short message is from a public A terminal connected to the network, or a fixed STN 4 or ISDN 2 via PABX 3, or from an IP terminal 7. In step 201, the short message module 58 transmits the short message to the ENUM script module 75. In step 202, this information is provided to the verification module 73, which in step 203 queries the local or remote database (for example, through an ODBC interface), to the E.164 ENUM number to search. In step 204, the corresponding information is provided to the verification module 73, which is responsible for comparing the pseudonym and password entered by the ENUM customer in the short message with the verification information contained in the database. If they are consistent, then in step 205, the verification module 73 instructs the ENUM script 75 to process the request contained in the short message. When the ENUM script 75 detects that this is a command to read an ENUM file. Then in step 206, the ENUM script 75 sends a query request to the DNS protocol management module 62, the request takes the E.164 address of the ENUM user converted into a domain as a parameter (the E.164 phone number 332960533859 is converted to 9.5.8.3. 5.0.6.9.2.3.3.e164.arpa). The DNS management module 62, which performs the traditional role of RESOLVER, inquires (at step 207) the zero-level DNS server and then the first-level DNS server through a request (DNS request), unless the above-mentioned way of querying these servers has been queried. The information is already in its cache memory. In order to obtain effectively, the data of the DNS server is installed in the random access memory of the server 21. If the ENUM user is indeed recorded in the DNS server 31 of the ENUM service provider 30, the DNS protocol module 32 returns the corresponding NAPTR record in step 208. The DNS protocol management module 62 is responsible for retransmitting it to the ENUM script module 75 in step 209. The latter analyzes and understands the NAPTR records and generates a relatively composite text that can be understood by ENUM users, namely "P1: phone = 0296053859, P2: phone = 0686166924, Pe: e-mail = bertrand.dupont@rd.francetelecom.com, P4: url=www.bertranddupont.fr, etc.". In step 210, this text is sent to the short message sending module 58, and in step 211, it sends the short message to the phone terminal that originally made the request (using the caller's number).

In step 250, the ENUM user sends a formatted short message as specified by the ENUM service provider 30 (ie: E.164 number + pseudonym + password + request type = ECR: P1: phone = 0686166924, P2: bertrand. dupont@rd.francetelecom.com) to the short message module 58 of the present invention. The short message comes from a terminal connected to a public network, or from a fixed STN 4 or ISDN 2 via PABX 3, or from a GSM-type mobile phone terminal 6, Or from the IP terminal 7. In step 251, the short message module 58 transmits the short message to the ENUM script module 75. In step 252, this information is provided to the verification module 73, which in step 253 queries the local or remote database (for example, through an ODBC interface), and the E.164 ENUM number to search. In step 254, the corresponding information is provided to the verification module 73, which is responsible for comparing the pseudonym and password entered by the ENUM customer in the short message with the verification information contained in the database. If they are consistent, the verification module 73 notifies this to the ENUM script module 75, which then processes the request contained in the short message. When the ENUM script 75 detects that this is a command to update an ENUM file with parameters. The ENUM script 75 checks the grammar of the command, and if it is correct, it sends an update request to the DNS protocol management module 62 in step 256. In step 257, the latter sends a "DNS UPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30. The IP address of the latter is stored in the database 70 and can be found according to the E.164 number of the ENUM user. The DNS protocol module 32 updates the server 31 at random Access the information in the memory and request the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download this file at a predetermined time interval. Change. In step 259, the server 31 confirms the update, which generates a response to the update command request in step 260. In step 261, the ENUM script 75 intercepts the return code of this response, and then in step 262, it sends it to Before the short message sending module 58 generates a confirmation/invalid message related to recording the change, the module 58 is responsible for sending the short message to the phone terminal that originally made the request (using the caller's number) in step 263.

Figure 6 schematically illustrates the process of querying and manually changing ENUM files by using a network with a web browser terminal.

In step 300, the ENUM user requests to download the web homepage of the ENUM file management service. In step 301, the web homepage is returned to the user from the web server 63 of the present invention. The home page displays a verification form to ENUM users. The latter enters his E.164 number and his pen name and password. In step 302, the information is transmitted to the network server 63, and in step 303, it transmits the information to the verification module 73 by itself. In step 304, the verification module 73 inquires the local or remote database (for example, through an ODBC interface) for the E.164 ENUM number to search. In step 305, the corresponding information is provided to the verification module 73, which is responsible for comparing the pseudonym and password entered by the ENUM client in the form of the network with the verification information contained in the database. If they are consistent, in step 306, the verification module 73 notifies the web server module 63 that the verification is passed. In step 307, it sends a request to read the ENUM script to the ENUM script module 75. Subsequently, in step 308, the ENUM script 75 sends a query request to the DNS protocol module 62, the request takes the E.164 address of the ENUM user converted into a domain as a parameter (the E.164 phone number 332960533859 is converted into 9.5.8.3. 5.0.6.9.2.3.3.e164.arpa). The DNS protocol module 62 performing the traditional role of RESOLVER, in step 309, uses the aforementioned query method to check whether the information exists in its cache memory, and then uses the DNS standard protocol to query the zero-level DNS server and the first-level DNS in turn Server and secondary DNS server. In order to obtain effectively, the DNS data is installed in the random access memory of the DNS server 31. If the ENUM user is indeed recorded in the DNS server 31 of the ENUM service provider 30, the DNS protocol module 32 returns the NAPTR record corresponding to the DNS protocol module 62 in step 310. The DNS protocol management module 62 retransmits it to the ENUM script module 75 in step 311. The ENUM script module 75 understands the NAPTR record and generates a relatively synthetic text that can be understood by ENUM users, namely: priority level 1 service call: 0296053859 Priority Level 2 Service Phone: 0686166924 Priority Level 3 Service Mail: b.dupont@rd.ft.com Priority Level 4 Service Web Page: www.bertranddupont.fr In step 312, this script is sent to the web server module 63, in step 313. The module 63 downloads a webpage that provides this information to the webpage terminal 8 of the ENUM user.

The web page presented to ENUM users makes it possible to make usual changes to ENUM files through a suitable graphical interface: change priority levels, add services, change service attributes, and so on. In step 350, the change request is sent to the web server 63. The latter transmits the request to the ENUM script module 75 in step 351, and the ENUM script module 75 is responsible for formatting the request according to the NAPTR input described by the ENUM protocol. Then in step 352, the ENUM script module 75 sends an update request to the DNS protocol module 62. The latter sends a "DNS UPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30. The IP address of the latter is stored in the database 70 and can be found according to the E.164 number of the ENUM user. The DNS protocol module 32 updates the server 31 at random Access the information in the memory and request the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download this file at a predetermined time interval. Change. In step 355, the database 33 confirms the update, which generates a response to the update command request in step 356. In step 357, the ENUM script 75 intercepts the return code of this response, and then in step 358, it sends it to Before the web server 63 generates a confirmation/validation method for recording the change, the web server 63 is responsible for formatting the generated web page before downloading it to the web terminal 8 in step 359.

Figure 7 schematically illustrates the process of querying and manually changing ENUM files through a Minitel. ENUM users use the PAVI (Vidio Point of Access) function of the France Telecom network (for example, call ENUM-FT code 3615) to connect to the small telex terminal service. Then, in step 400, the small teletype terminal 5 enters into a dialogue with the small teletype terminal server 57. In step 401, the latter activates the ENUM script module 75 of the present invention, and then the ENUM script module 75 generates a service homepage in step 402, and the service homepage is downloaded to the small telex terminal 5 of the ENUM user in step 403. This small telex terminal page displays an authentication format to ENUM users. The latter enters his E.164 number, his pen name and password. In step 404, the information is transmitted to the small telex terminal server 57, and in step 405, it transmits the information to the ENUM script module 75 by itself. In step 406, the latter forwards the request to the verification module 73. In step 407, the verification module 73 inquires the local or remote database (for example, through an ODBC interface) for the E.164 ENUM number to search. In step 408, the verification information of the database is transmitted to the verification module 73, which compares the verification information with the pseudonym and password in the form of a small telex terminal. If they are consistent, in step 409, the verification module 73 notifies the ENUM script module 75 that the verification is passed. The ENUM script module 75 then sends a query request to the DNS protocol module 62 in step 410, the request with the E.164 address of the ENUM user converted into a domain as a parameter (E.164 phone number 332960533859 is converted into 9.5.8.3. 5.0.6.9.2.3.3.e164.arpa). The DNS protocol module 62 performing the traditional role of RESOLVER, in step 411, uses the aforementioned query method to check whether the information exists in its cache memory, and then uses the DNS standard protocol (DNS query request) to query the zero-level DNS in turn Server, primary DNS server and secondary DNS server. Preferably, in order to obtain effectively, the data of the DNS is installed in the random access memory of the DNS server 31. If the ENUM user is indeed registered in the DNS server 31 of the ENUM service provider 30, the DNS protocol module 32 returns the corresponding NAPTR record in step 412. The DNS protocol module 62 is responsible for retransmitting the NAPTR record to the ENUM script module 75 in step 413. The latter analyzes and understands the NAPTR record, and generates a relatively composite text that can be understood by ENUM users, namely: priority 1 service phone: 0296053859 priority 2 service phone: 0686166924 priority 3 service Mail: b.dupont@rd. ft.com priority level 4 service webpage: www.bertranddupont. fr In step 414, this script is sent to the videotext server module 57, which is responsible for downloading it to the small teletext terminal 5 of the ENUM user in step 415. The visual text page presented to ENUM users makes it possible to make changes to the usual ENUM files through a suitable interface: change priority, add service, cancel service, change service attributes, etc. In step 450, the request to modify the ENUM file is sent to the videotext server 57. The latter transmits the request to the ENUM script module 75 in step 451, and the ENUM script module 75 is responsible for formatting the request according to the NAPTR input described by the ENUM protocol. Then in step 452, the ENUM script 75 sends an update request to the DNS protocol module 62. The latter sends a "DNSUPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30 in step 453. The IP address of the latter is stored in the database 70 and can be found based on the E.164 number of the ENUM user. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download the change at a predetermined time interval. In step 455, the database 33 confirms the update, which in step 456 generates a response to the update command request. In step 457, the ENUM script 75 intercepts the return code of this response, and then in step 458, before sending it to the videotext server 57, it generates a confirmation/invalid message about recording the change. The server 57 is responsible for formatting the generated videotext page before downloading it to the small telex terminal 5 in step 459. 164 number found. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download the change at a predetermined time interval. In step 455, the database 33 confirms the update, which in step 456 generates a response to the update command request. In step 457, the ENUM script 75 intercepts the return code of this response, and then in step 458, before sending it to the videotext server 57, it generates a confirmation/invalid message about recording the change. The server 57 is responsible for formatting the generated videotext page before downloading it to the small telex terminal 5 in step 459. 164 number found. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download the change at a predetermined time interval. In step 455, the database 33 confirms the update, which in step 456 generates a response to the update command request. In step 457, the ENUM script 75 intercepts the return code of this response, and then in step 458, before sending it to the videotext server 57, it generates a confirmation/invalid message about recording the change. The server 57 is responsible for formatting the generated videotext page before downloading it to the small telex terminal 5 in step 459.

Fig. 8 schematically illustrates the process of querying and manually changing ENUM files through e-mail or a terminal 8 with an e-mail client.

In step 500, the ENUM user sends a formatted e-mail to the e-mail server 61. For example, the ENUM command can be in the destination e-mail address: e164-33296053859-login-dupont-password-1234-requestlire@gestion.enum francetelecom.com The ENUM script module 75 has a client that checks the e-mail server 61 regularly. When the ENUM script module 75 receives an e-mail as described above in step 501, it restores the parameters in the header or body of the e-mai, and then transmits it to the verification module 73 in step 502 . In step 503, the verification module 73 inquires the local or remote database (for example, through an ODBC interface) for the E.164 ENUM number to search. In step 504, the local or remote database provides corresponding verification information to the verification module 73, which is responsible for comparing the corresponding verification information with the pseudonym (user name) and password provided by the ENUM customer in the e-mail. If they are consistent, in step 505, the verification module 73 notifies the ENUM script module 75 of this. In step 506, the ENUM script 25 sends a query request to the DNS protocol management module 62, the request takes the E.164 address of the ENUM user converted into the domain name as a parameter (the E.164 phone number 332960533859 is converted into 9.5.8.3.5.0 .6.9.2.3.3.e164.arpa). The DNS protocol module 62 performing the traditional role of RESOLVER, in step 507, in the aforementioned query method, if the information is checked not yet in its cache memory, according to the DNS standard protocol (DNS query request), it inquires the zero-level DNS in turn The server, the primary DNS server, and the secondary DNS server are inquired through the DNS protocol storage stack. Preferably, in order to obtain effectively, the data of the DNS is installed in the random access memory of the DNS server 31. If the ENUM user is indeed recorded in the DNS of the ENUM service provider 30 In step 31, the DNS protocol management module 32 returns the corresponding NAPTR record in step 508. The DNS protocol management module 62 is responsible for retransmitting it to the ENUM script module 75 in step 509. The latter analyzes and understands the NAPTR records and produces a relatively composite text that can be understood by ENUM users, namely: priority level 1 service phone: 0296053859 priority level 2 service phone: 0686166924 priority level 3 service Mail: b.dupont@rd.ft. Com priority level 4 service page: www.bertranddupont.fr In step 510, this text is sent to the e-mail server module 61 in the form of e-mail through the e-mail client software integrated in the ENUM script module, which is responsible for Send the general fax to ENUM users.

The ENUM user who wants to change his ENUM file sends a formatted e-mail to the e-mail server 61 in step 550. For example, the ENUM command can be in the destination e-mail address: E164-33296053859-login-dupont-password-1234-request-write-P1-tel-0296053859-P2-tel-0686166924-P3-fax-0296050242@gestion.enum .francetelecom.com.

The e-mail client of the ENUM script module checks the e-mail server 61. When the ENUM script module receives an e-mail as described above in step 551, it restores the parameters in the header or body of the e-mai, and then transmits it to the verification module 73 in step 552. In step 553, the verification module 73 queries the local or remote database (for example, through an ODBC interface) to search for the E.164 ENUM number. In step 554, corresponding verification information is provided, and then the verification module 73 compares the corresponding verification information with the pseudonym and password provided in the e-mail. If they are consistent, in step 555, the verification module 73 notifies the ENUM script module 75 of this. The latter format the request according to the NAPTR input described by the ENUM protocol. Then in step 556, the ENUM script 75 transmits an update request to the DNS protocol management module 62, which in step 557 sends a "DNS UPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30. The IP address of the latter is stored in the database 70 and can be found according to the E.164 number of the ENUM user. The DNS protocol module 32 updates the server 31 at random Access the information in the memory, and request the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file, so that the second DNS server can re-download the change at a predetermined time interval. In step 559, the database 33 confirms the update, and in step 560 it generates a response to the update command request. In step 561, the ENUM script module 75 intercepts the return code of this response, and then generates a confirmation/relevant to record the change. Invalid message. In step 562, the message is sent to the e-mail server 61 in the form of e-mail through the client software integrated in the ENUM script module. The latter sends the e-mail to the ENUM user in step 563, The ENUM user can check the e-mail at his terminal 8.

Fig. 9 schematically illustrates the process of querying and manually changing the ENUM file through the UUI (User-to-User Information) of the ISDN terminal.

In step 500, the ENUM user sends a telephone call containing UUI information elements from his ISDN terminal 2 to the ISDN interface 51. It should be noted that the size of the UUI field is currently limited to 32 words. The ENUM command located in the UUI field can therefore only execute one ENUM service at a time. For example: GetP1-33296053859*dupont#123456: This request can restore the attributes of the priority level 1 ENUM service.

In step 601, the call automation controller 52 transmits a message requesting call establishment to the UUI module 53, and the UUI module 53 extracts the UUI command. In step 652, the call automation controller 52 sends an alert (Alert) message to the ENUM user, giving a minimum time (according to the ISDN protocol, a time delay before sending the offline message). In step 603, the UUI module 53 transmits the ENUM command to the ENUM script module 75. The latter restores the carried ENUM parameter, and then transmits it to the verification module 73 in step 604. In step 605, the verification module 73 inquires the local or remote database (for example, through an ODBC interface) for the E.164 ENUM number to search. In step 606, the corresponding verification information is provided to the verification module 73, which compares the verification information with the pseudonym and password in the UUI provided by the ENUM customer. If they are consistent, in step 607, the verification module 73 notifies the ENUM script module 75 of this. Next, the ENUM script module 75 sends a query request to the DNS protocol management module 62 in step 608, the request takes the E.164 address of the ENUM user converted into a domain as a parameter (E.164 phone number 332960533859 is converted to 9.5. 8.3.5.0.6.9.2.3.3.e164.arpa). The DNS protocol module 62, which performs the traditional role of RESOLVER, uses the aforementioned query method in step 609 to use the DNS standard protocol (DNS query request) without checking whether the information already exists in its cache memory. Inquire the zero-level DNS server, the first-level DNS, and the second-level DNS server through the DNS protocol module 32. Preferably, in order to obtain effectively, the data of the DNS server is installed in the random access memory of the server 31. If the ENUM user is indeed recorded in the DNS of the ENUM service provider 30 In step 31, the DNS protocol storage stack 32 returns the corresponding NAPTR record to the DNS protocol management module 62 in step 610, which is responsible for retransmitting the corresponding NAPTR record to the ENUM script module 75 in step 611. The latter analyzes and understands the NAPTR record, and generates a relatively composite text that can be understood by ENUM users based on the service requested in the UUI command, namely: Service P1: Tel: 0296053859 In step 612, this text is sent to UUI module 53 The UUI module 53 is responsible for formatting an unconnected message before sending (step 613) to the automatic call control module 52. The call automatic control module 52 generates an offline message, the offline message contains UUI information, and in step 614 is transmitted to the terminal 2 of the ENUM user through the ISDN network. ENUM users can display UUI on the display screen of their ISDN terminal 2.

The ENUM user who wishes to change his ENUM file, in step 650, sends a telephone call containing UUI information elements from his ISDN terminal 2 to the ISDN interface 51. For example: DelP3-33296053859*dupont#123456: This request can cancel the priority level 3 ENUM service.

The call automation controller 52, in step 651, sends a message requesting to establish a call to the UUI module 53, which extracts the UUI command. In step 652, the call automation controller 52 sends an alarm message to the ENUM user, allowing itself a minimum time (a timing based on the ISDN protocol before sending the offline message). The UUI module 53 transmits the ENUM command to the ENUM script module 75 in step 653. The latter restores the carried parameters and transmits them to the verification module 73 in step 654. In step 655, the verification module 73 queries the local or remote database (for example, through an ODBC interface) to search for the E.164ENUM number. In step 656, the corresponding verification information is provided to the verification module 73, and the verification module 73 compares the corresponding verification information with the pseudonym and password provided by the client in the UUI. If they are consistent, in step 657, the verification module 73 notifies the ENUM script module 75 of this. If the change does not involve the entire file, the ENUM script first sends an inquiry request (at step 658) to the DNS protocol management module 62, the request with the ENUM user's E.164 address converted into a domain as a parameter (E. The 164 phone number 332960533859 is converted to 9.5.8.3.5.6.9.2.3.3.e164. arpa). The DNS protocol management module 62 performing the role of RESOLVER checks whether the information exists in its cache memory using the aforementioned query method, and then uses the DNS standard protocol (DNS query request) to query the zero-level DNS server and the first-level DNS server. DNS server and second secondary DNS server (through its DNS protocol module 32). In order to obtain effectively, the DNS data is installed in the random access memory of the server 31. If the ENUM user is indeed recorded in the DNS 31 of the ENUM service provider 30, the DNS protocol module 32 returns the corresponding NAPTR record to the DNS protocol management module 62 in step 660. The latter is responsible for transmitting the corresponding NAPTR record to the ENUM script module 75 in step 661. Then in step 662, the ENUM script 75 sends an update request based on the requested change in the UUI field to the DNS protocol module 62. The latter sends a "DNS UPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30 in step 663. The IP address of the latter is stored in the database 70 and can be found based on the E.164 number of the ENUM user. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download the change at a predetermined time interval. In step 665, the database 33 confirms the update, which in step 666 generates a response to the update command request. In step 667, the ENUM script 75 intercepts the return code of this response, and then in step 668, it generates a confirmation/invalid message about recording the change. This message is sent to the UUI module 53 in step 668, which is responsible for formatting an offline message before sending it (in step 669) to the call automation control module 52. The call automatic control module 52 generates off-line information in step 670, and the off-line information includes UUI information element, and thus is transmitted to the terminal 2 of the ENUM user through the ISDN network. ENUM users can display UUI on the display screen of their ISDN terminal 2. 164 number found. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download the change at a predetermined time interval. In step 665, the database 33 confirms the update, which in step 666 generates a response to the update command request. In step 667, the ENUM script 75 intercepts the return code of this response, and then in step 668, it generates a confirmation/invalid message about recording the change. This message is sent to the UUI module 53 in step 668, which is responsible for formatting an offline message before sending it (in step 669) to the call automation control module 52. The call automatic control module 52 generates off-line information in step 670, and the off-line information includes UUI information element, and thus is transmitted to the terminal 2 of the ENUM user through the ISDN network. ENUM users can display UUI on the display screen of their ISDN terminal 2. 164 number found. The DNS protocol module 32 updates the information in the random access memory of the server 31 and requests the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file so that the second DNS server can re-download the change at a predetermined time interval. In step 665, the database 33 confirms the update, which in step 666 generates a response to the update command request. In step 667, the ENUM script 75 intercepts the return code of this response, and then in step 668, it generates a confirmation/invalid message about recording the change. This message is sent to the UUI module 53 in step 668, which is responsible for formatting an offline message before sending it (in step 669) to the call automation control module 52. The call automatic control module 52 generates off-line information in step 670, and the off-line information includes UUI information element, and thus is transmitted to the terminal 2 of the ENUM user through the ISDN network. ENUM users can display UUI on the display screen of their ISDN terminal 2.

Figure 10 schematically illustrates the process of accessing services to query and manually modify ENUM files through network dialogue. It is difficult and tedious to change ENUM files manually. The automatic controller (referred to as the configuration automatic controller) is then used to make automatic changes to the ENUM file, which is a function of time and/or other parameters. Among these other parameters, if the system 50 knows the location of the user, it can be used.

In step 700, the ENUM user requests to download the web homepage of the ENUM file management service. In step 701, the web homepage is returned to the user from the web server 63 of the present invention. The home page displays a verification form to ENUM users. The latter enters its E.164 number and its user name and password. In step 702, the information is transmitted to the network server 63, and in step 703, it transmits the information to the verification module 73 by itself. In step 704, the verification module 73 queries the local or remote database (for example, through an ODBC interface) to search for the E.164 ENUM number. In step 705, the corresponding verification information is provided to the verification module 73, which is responsible for comparing the corresponding verification information with the pseudonym and password input by the ENUM client in the form of a network. If they are consistent, in step 706, the verification module 73 notifies the web server module 63 that the verification is passed. In step 707, the latter sends a request to read the automatic configuration of this ENUM script to the ENUM script module 75. In step 708, the ENUM script 75 queries the database 70 with the ENUM user's E.164 number as a parameter. The database 70 returns the automatic file management program to the ENUM script module 75 in step 709. The latter formats the information, for example: Monday to Friday: 0830 to 1900P1 Tel 0296053859 P2 Tel 0686166924P3 e-mailbertrand.dupont@rd.francetelecom.com P4 Fax 0296050242 Monday to Friday: 1900 to 0830P1 Tel 0296916404P2 e-mailbertrand.dupont@rd.francetelecom.com Saturday to Sunday: 0000 to 0830P1 Tel 0296916404 P2 Tel 0686166924P3 e- mailb.dupont@wanadoo.fr ENUM script module 75, in step 710, the formatted information is transmitted to the network server 63, which is responsible for downloading the general clear code information containing the configuration program from the ENUM file to the network terminal 8 of the ENUM user .

This web page can make changes to the automatic configuration procedures of ENUM files: change schedules, management of public holidays, service addition/cancellation, service attribute changes, etc. In step 750, the ENUM user confirms the change of the program. In step 751, the web server 63 transmits the information through the ENUM script module 75. The ENUM script module 75 extracts the information and formats it into a prescribed format before writing it into the database 70 (at step 752). This will take the record of the program into account and confirm it to the ENUM script module 75 in step 753. The latter notifies the web server 63 of the registration of the change of the configuration automatic controller of the ENUM file. In step 755, the server downloads the modified webpage to the network terminal 8 of the ENUM user.

Figure 11 outlines the configuration of the automatic controller through the ENUM file, the process of automatic modification, and the alternative process of notifying ENUM users of file changes.

In step 800, the automatic controller 74 is configured to periodically check the database 70 to check whether there are programmed changes (according to current data and time). If there are programmed changes, the configuration parameters are returned in step 801. In step 802, the automatic configuration controller 74 sends a query request to the DNS protocol management module 62, the request with the ENUM user's E.164 address in the file to be changed and converted into a domain name as a parameter (E. The 164 phone number 332960533859 is converted to 9.5.8.3.55.0.6.9.2.3.3.e164.arpa). The DNS protocol management module 62 performing the role of RESOLVER, in step 803, in the aforementioned query method, if the information does not yet exist in its cache memory, it uses the DNS standard protocol (DNS query request) to pass its DNS The protocol module 32 queries the zero-level DNS server, the first-level DNS server and the second-level DNS server (through the DNS protocol storage stack). Preferably, in order to obtain effectively, the data of the DNS is installed in the random access memory of the DNS server 31. If the ENUM user is indeed recorded in the DNS of the ENUM service provider 30 In step 31, the DNS protocol module 32 returns the corresponding NAPTR record to the DNS protocol module 62 in step 804. The latter transmits it to the automatic configuration controller 74, which then queries the database 70 in step 806 to restore the changes made on the ENUM file. In step 807, the database returns the files to be used to the automatic configuration controller 74. If a change is really needed (while the file can be changed manually), the automatic configuration controller determines the change to be made to the NAPTR record, and sends an update request to the DNS protocol management module 62 in step 808. The latter sends a "DNS UPDATE" command to the DNS protocol module 32 of the DNS server 31 of the ENUM service provider 30. The IP address of the latter is stored in the database 70 and can be found according to the E.164 number of the ENUM user. The DNS protocol module 32 updates the server 31 at random Access the information in the memory and request the update of the database 33, which is usually a flat text file. The DNS protocol manages the change number in this file, so that the second DNS server can re-download the change at a predetermined time interval. In step 811, the database 33 confirms the update, and in step 812 it generates a response to the update command request. In step 813, the configuration automatic controller 74 intercepts the return code of this response, and then in step 814, it generates and writes in the database 70 to obtain the log (record) of the change. In step 815, the database 70 determines the writing of the automatic file change event.

If the automatic update service has been configured to notify the automatic changes made to the ENUM file, the automatic configuration controller will notify according to one or more of the following modes:

When the notification is made by voice, the automatic configuration controller 74 informs the call automatic controller 52 in step 820, and the automatic call controller 52 generates a telephone call to the STN4 or ISDN 2 or IP 7 fixed telephone, or to the mobile phone 6. The ENUM user responds to the phone call in step 822, or the call is switched to his voice message. The voice synthesis module 55 or the voice file broadcast module 56 broadcast the ENUM file change notification in step 823, for example: "Hello, your ENUM file 33296653859 has been updated as follows at 1900 today: telephone service 0296053859, telephone service 0686166924, e- mail service Bertrand.Dupont@wanadoo.fr"; when the notification is made by SMS, the automatic configuration controller 74 uses the SMS script to notify the SMS module 58 in step 830, for example: "Your ENUM file 33296653859 changes (3 At 0900 o'clock on the 21st): Tel-0296053859, Tel-0686166924, Fax-0296050242". In step 840, the short message module 58 transmits the short message to the mobile phone or fixed phone terminal, as configured in the database 70.

O When the notification is made by e-mail, the controller 74 is automatically configured in step 850 to include an e-mail with the following script, that is, "change of your ENUM file 33296053859 (at 0900 o'clock on March 21, 2002) : Tel-0296053859, Tel-0686166924, Fax-0296050242", notify the e-mail server 61 of the update. In order to achieve this goal, the automatic configuration controller must have an e-mail client. Then in step 60, the e-mail server 61 transmits the relevant e-mail to the e-mail address stored in the database 70.

O When the notification is made by fax, the automatic configuration controller 74 informs the fax module 59 with a fax script in step 870, which can be as follows: "The change of your ENUM file 33296053859 (at 0900 o'clock on March 21, 2002): phone -0296053859, Tel-0686166924, Fax-0296050242". In step 880, the fax module 59 transmits the fax to the fax terminal 9 configured in the database 70.

Fig. 12 illustrates an example of the process of querying the ENUM file when the ENUM file is an LDAP directory. The example given in FIG. 12 clarifies the query performed through a single computer, but it is obvious that the query can be performed through the aforementioned other types of terminals. This type of service is especially used in companies that wish to provide ENUM services to all or part of the company's employees.

In step 900, the ENUM user requests to download the web homepage of the ENUM file management service. In step 901, the web homepage is returned from the web server 63 of the system 50 to the user. The home page displays a verification form to ENUM users. The latter enters his E.164 number and his pen name and password. In step 902, the information is transmitted to the network server 63, and in step 903, it transmits the information to the verification module 73 by itself. In step 904, the verification module 73 inquires the local or remote database (for example, through an ODBC interface) for the E.164 ENUM number to search. In step 905, the corresponding information is provided to the verification module 73, which is responsible for comparing the corresponding information with the pseudonym and password entered by the ENUM customer. If they are consistent, in step 906, the verification module 73 notifies the web server module 63 that the verification is passed. In step 907, the web server module 63 sends an ENUM file reading request to the ENUM script module 75. In step 908, the ENUM script 75 sends a query request to the DNS protocol management module 62. The request takes the E.164 address of the ENUM user converted into a domain as a parameter (the E.164 phone number 332960533859 is converted into 9.5.8.3.5.0 .6.9.2.3.3.e164.arpa). The DNS protocol management module 62 performing the role of RESOLVER, in step 909, in the aforementioned query method, if the information does not exist in its cache memory, it uses the DNS standard protocol (DNS query request) through its DNS The protocol module 32 queries the zero-level DNS server, the first-level DNS server, and the second-level DNS server. Preferably, in order to obtain effectively, the data of the DNS is installed in the random access memory of the server 31. If the ENUM user is indeed recorded in the DNS server 31 of the ENUM service provider 30, the DNS protocol management module 32 returns the corresponding NAPTR record in step 910. The DNS protocol management module 62 is responsible for retransmitting it to the ENUM script module 75 in step 911. The latter analyzes and understands the NAPTR record, for example: $ORIGIN9.5.8.3.5.0.6.9.2.3.3.e164. arpa.

IN NAPTR 100 10 "u" "ldap+E2U""!...... +33296053859$! ldap: //ldap.providerA.fr/cn=33296053859!" The ENUM script detects that this is an LDAP service. Therefore, in step 912, the ENUM script module 75 sends a request to the LDAP protocol management module 64, the request being an LDAP command connected to the LDAP server specified by the URI "ldap://ldap.providerA.fr". In step 913, the LDAP protocol management module 64 sends a "BIND" request to ENUM On the LDAP protocol module 35 of the LDAP directory server 34 of the A30 provider. In step 914, the LDAP protocol module 35 accepts the connection. The LDAP protocol management module 64 then sends the LDAP "search" request to the LDAP protocol module 35 in step 915, and the "search" request takes the E.164 number of the ENUM user as a parameter. In step 916, the LDAP protocol module 35 queries the LDAP database 36, and then returns (in step 917) all the information about the ENUM user to the LDAP protocol module 35, which itself returns all the information about the ENUM user to the LDAP in step 918 Protocol management module 64. The latter returns the information to the ENUM script 75 in step 919, which is responsible for putting the information in a form that the ENUM user can understand before transmitting (in step 922) to the network server 63. Then the server downloads the web page dynamically generated in step 923 to the network terminal 8 of the ENUM user. At the same time (in parallel), in step 920, the LDAP protocol management module 64 sends an offline request to the LDAP server 34 through an "Unbind" request. In step 921, the LDAP protocol module 35 confirms the disconnection.

Figure 13 describes the process of manually changing the ENUM file when the ENUM file is stored in the LDAP directory. Similarly, it is of course possible to modify the ENUM file through a terminal other than a personal computer.

The ENUM user who inquires about the content of his ENUM file through the above process will decide to change the ENUM file. To do this, it changes the attributes and priority of its ENUM service displayed on the web page of the network terminal 8 on the spot, and adds services or cancels some services. In step 1000, the user confirms his file change, and relevant information is provided to the web server 63. The latter transmits all this information to the ENUM script module 75 in step 1001. The latter sends an inquiry request to the DNS protocol module 62 in step 1002. The request takes the E.164 address of the ENUM user converted into a domain as a parameter (the E.164 phone number 332960533859 is converted into 9.5.8.3.5.0.6.9). .2.3.3.e164.arpa). The DNS protocol management module 62 that performs the role of RESOLVER, in step 1003, in the aforementioned query method, if the information does not yet exist in its cache memory, it can use the DNS standard protocol (DNS query request) through its DNS protocol Module 32, query the zero-level DNS server, the first-level DNS server and then query the second-level DNS server. In order to obtain effectively, the DNS data is installed in the random access memory of the server 31. If the ENUM user is indeed recorded in the DNS of the ENUM service provider 30 In step 31, the DNS protocol module 32 returns the corresponding NAPTR record in step 1004. Then the DNS protocol management module 62 retransmits it to the ENUM script module 75 in step 1005. The latter analyzes and understands the NAPTR record, for example: $ORIGIN9.5.8.3.5.0.6.9.2.3.3.e164. arpa.

IN NAPTR 100 10 "u" "ldap+E2U""!...... +33296053859$! ldap: //ldap.providerA.fr/cn=33296053859!" The ENUM script module 75 detects whether this is an LDAP service. Then in step 1006, the ENUM script module 75 sends an LDAP request to the LDAP protocol module 64, where the LDAP request is a command to connect to the LDAP server specified by the URI "ldap://ldap.providerA.fr". In step 1007, the LDAP protocol module 64 sends a "BIND" request to ENUM On the LDAP protocol module 35 of the LDAP directory server 34 of the A provider 30. In step 1008, the LDAP protocol module 35 accepts the connection. The LDAP protocol module 64 sends the LDAP "search" request to the LDAP protocol module 35 in step 1009, and the "search" request takes the E.164 number of the ENUM user as a parameter. In step 1010, the LDAP protocol module 35 queries the LDAP database 36, and then in step 1011, all information about the ENUM user is returned to the LDAP protocol management module 35. The latter returns all the information about the ENUM user to the LDAP protocol management module 64 in step 1012, and returns the information to the ENUM script module 75 in step 1013. The latter compares the information with the information submitted by the ENUM user through the network, determines the operation to be performed on the LDAP format, and transmits a change request to the LDAP protocol management module 64 in step 1014. The latter sends an LDAP "change" request to the LDAP protocol module 35 in step 1015, and sends a request written on the database 36 in step 1016. The database 36 accepts the update and confirms it to the LDAP protocol module 35 in step 1017. The latter transmits the confirmation/invalidation related to the update to the LDAP protocol management module 54 in step 1018, and returns the confirmation/invalidation related to the update to the ENUM script module 75 in step 1019. Then the latter generates a change confirmation webpage before transmitting it to the web server 63. In step 1023, the server downloads the page to the network terminal 8 of the ENUM user. At the same time, in step 1020, the LDAP protocol module 64 sends an offline request to the LDAP server 34 with an "Unbind request. In step 1021, the LDAP protocol module 35 confirms the disconnection.

Although the process of updating the LDAP directory has been clarified in a manual process, there is no doubt that the automatic update of the LDAP directory by configuring the automatic controller 74 is also feasible.

Although the present invention has been generally described in the context of the application of "ENUM" and the update of ENUM files, it is obvious that for those skilled in the art, the present invention can be extended to one or the other on the DNS (or LDAP) server Various resource records (RR) are updated, as defined in paragraph 3.2.2 of the aforementioned document RFC1035, and listed in the following table:

For a given resource record, the update may involve one or more fields of the record, as defined in the aforementioned RFC file.

It should be noted that if you want to update a non-NAPTR resource record, you must install a module similar to "ENUM script" to process these records.