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

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

[0001] 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.

[0002] 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 corresponding to the URL). These servers are usually queried through data processing machines, 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, it can be queried sequentially and indirectly. 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).

[0003] In addition, the DNS server is now required to assume such a role of the ENUM service, the purpose of which 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 preferences set in files stored on the network through the server. For example, a single E. 164 phone number of an ENUM user can be combined with a mobile phone number (+33686166924), a fixed phone number (+33296916404), an e-ma subscription address (bertrand. Duuont@rd. francetelecom. com), and a The website URL (httu://www.bertrand. duuont. com), a VoIP phone number, a fax number, etc. are connected.

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

[0005] 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 (the share of E.164 telephone numbers). The model used is divided by share: fixed STN phone number has 5 shares, prefixed from 1 to 5, mobile phone number has one share, prefix is 6o

[0006] One path of the DNS server tree is related to a telephone number in the E.164 format. To be more precise, after each telephone number is converted into E.164 international format, it is reversed, the "+" code is omitted, and a dot is added between each digit, and the result obtained is combined with the el64.arpa field to combine the telephone number The number is converted into a single network domain name. For example, the telephone number +33686166924 will get the network domain name 4. 2. 9. 6. 6. 1. 6. & 3. el64. arpa.

[0007] In addition, for each telephone number converted into E.164 format, it is related to a record stored in a corresponding secondary server that contains one or more resource records (resource records or RR), and each resource record Can contain one or more fields. For example, for a telephone number converted into E.164 format, it can be related to NAPTR (Naming Authority PoinTeR) resource records, which are defined in the RFC2915 and RFC1916 documents, which are available on the IETF website. Briefly, a NAPTR resource record represents a

A telecommunication service related to priority level (telephone or fax number, e-ma subscription address, website, etc.). The term ENUM record (or ENUM file) will be used below as a set of NAPTR records related to network domain names. For example, the following EUNM file is stored in the secondary DNS server:

[0008] S0RIGIN 9. 5. & 3. 5. 0. 6. 9. 2. 3. 3. el64. arpa.

<td>[0009]</td><td colspan="2">IN NAPTR 100 10 "u" "tel+E2U" "!. *$!</td><td>tel :+33296053859! "</td>

<td>[0010]</td><td>IN</td><td>NAPTR 100 11 "u" "tel+E2U" "!'. *$!</td><td>tel :+33296916404! "</td>

<td>[0011]</td><td>IN</td><td>NAPTR 100 12 "u" "tel+E2U" "!'. *$!</td><td>tel :+33686166924!</td>

<td>[0012]</td><td>IN</td><td>NAPTR 100 13 "u"</td><td>"Sip+E2U"</td>

<td>[0013]</td><td>“ !</td><td>*$! sip. bdupont@sip. ftrd. fr!</td><td></td>

<td>[0014]</td><td>IN</td><td>NAPTR 120 10 "u"</td><td>"Ma Order to+E2U"</td>

<td>[0015]</td><td>“ !</td><td>*$! ma order 2 :bdupont@rd. ftrd. fr!</td><td></td>

<td>[0016]</td><td>IN</td><td>NAPTR 130 10 "u"</td><td>"Http+E2U"</td>

<td>[0017]</td><td>“ !</td><td>'.*$! http://www. Bdupont. fr!</td><td></td>

[0018] The title line indicates an Internet domain name corresponding to the E. 164 telephone number. The 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 level of the service. If several services have the same "order" level, the lower the related priority value, the higher the priority level of the service. Therefore, the priority of the above-mentioned list of records is lowered from top to bottom.

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

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

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

[0022] The fourth line is the IP phone service with order of 100 and priority of 13 (via SIP

[0023] Connect to the SIP address bdupont@sip. ftrd. fr.

[0024] The fifth line is an e-ma subscription e-mail service with a sequence of 120 and a priority of 10 whose destination address is bduuont@rd. ftrd. fr.

[0025] Finally, the sixth line is the order of 130, the priority is 10, the access URL is httu: //www. bdupont.

fr's network service.

[0026] The meaning of this record is as follows. If you find that you want to connect to the E. 164 phone number (+33296053859), RESOLVER software will send a corresponding Internet domain name (9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. E164. arpa) request to the secondary DNS server. In response, the secondary DNS server (DNS2) returns a list of telecommunication records related to the telephone number +33296053859 (hereinafter also referred to as service), 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.

[0027] The modification of the ENUM file in the DNS server is not suitable for administrators. 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 set the ENUM file supported by its telecom operator or its ENUM service provider.

CN 1663222 Β

Transform.

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

[0029] 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.

[0030] 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 include one or several resource records, and the database is stored in a domain name server (called a DNS server). ), or stored in a directory server (called an LDAP server), and can be accessed indirectly through a DNS server. The system includes:

[0031]-a communication device to ensure that the system receives a request for querying and/or updating the record from a telecommunication terminal, or a program for such a request;

[0032]-a control device, which is suitable for determining the domain name and the operation to be performed on the record according to the query and/or change request transmitted to the system or programmed in the system in advance;

[0033]-a protocol management device, which is suitable for searching for the IP address of the server storing the first database according to the domain name, and transmitting a request to read or update the record to all according to the operationDescriptionServer.

[0034] Advantageously, the system includes a verification device, which is 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.

[0035] When the sender of the request has been verified, the protocol management device can transmit a query request based on the DNS protocol (DNS query) to the DNS server, the request with the domain name as its Parameters, and a first response received from the server.

[0036] 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.

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

[0038] According to other embodiments, the control device is adapted to extract 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).

[0039] The above 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:

[0040] Figure 1 outlines the dispatch mode used in the ENUM service;

[0041] FIG. 2A schematically illustrates an example of the system environment according to the present invention;

[0042] Figure 2B outlines the environment in Figure 2A, with the ENUM service as the background;

[0043] FIG. 3A shows a schematic block diagram of the query/update system 50 according to the present invention;

[0044] FIG. 3B shows an example of the query/update system 50 according to the present invention;

[0045] Figure 4 schematically shows the process of querying and manually updating ENUM files accessed in sound mode;

[0046] Figure 5 shows a summary of the process of sending, querying and manually updating ENUM files via SMS;

[0047] Figure 6 shows a summary of the process of querying and manually updating ENUM files through the Internet;

[0048] Figure 7 shows a summary of the process of using a miniature visual terminal to query and manually update ENUM files;

[0049] Figure 8 shows a summary of the process of querying and manually updating ENUM files through e-mail;

[0050] Figure 9 shows a summary of the process of querying and manually updating ENUM files through the UUI of the ISDN terminal;

[0051] FIG. 10 schematically shows the process of programming the automatic update of the ENUM file;

[0052] FIG. 11 schematically shows the process of automatically updating ENUM files;

[0053] Figure 12 schematically shows the process of querying ENUM files when they are stored in the LDAP directory;

[0054] FIG. 13 schematically shows the process of updating the ENUM file when it is stored in the LDAP directory; [0055] FIG. 2A illustrates an example of the system environment according to the present invention.

[0056] The telecommunications resource management service provider, hereinafter referred to as the service provider, is shown as 30 in the form of a graph. Each service provider has a DNS server 31, or an LDAP server 3 £, which stores databases. More generally, there are several redundant servers to enhance the reliability of service access. The database contains telecommunication resource records of all relevant users of the service provider.

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

[0058] 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 corporate intranet (Intranet).

[0059] The system 50 can be accessed through an ISDN telephone terminal 2, which is directly or through PABX

3 Connect to the ISDN network 10. It should indicate that the ISDN network is natively interconnected to the STN network.

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

[0061] 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.

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

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

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

[0065] 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.

[0066] The 40 is the root ENUM DNS server. This server contains all the IP addresses referencing all the first-level 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.

[0067] Each ENUM operator or service provider has at least one first-level second-level ENUMDNS server 31: (referred to as the first server), and has at least one second second-level ENUMDNS server 31/ (referred to as the second server) ) The redundancy constitutes to ensure the good reliability of the service. The first (or second) server stores a database 33: (or 33/). 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-ma subscription addresses, mobile e-ma subscription addresses, business fax numbers, etc.) and the priority levels (priorities) allocated to each of these access devices_oEach 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.

CN 1663222 Β

[0068] The ENUM service provider A30i may also have an LDAP server storing an LDAP dynamic directory 36:, as defined in the IETF RFC 1959 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 longer making 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 (31J) contains the following files with all E. 164 telephone numbers beginning with "+332":

[0069] $0RIGIN 2. 3. 3. el64. arpa.

[0070] IN NAPTR 100 10 "u" "ldap+E2U"

[0071]!'.+332(.*)$! Ldap ://ldap. providerA. fr/cn = 01!

[0072] LDAP directory 36: can be accessed indirectly from the secondary ENUM DNS server, and contains resource records of different users of provider A.

[0073] 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, the RESOLVER software converts the users E. 164 unique number into the domain name as seen above, and accesses the secondary ENUM DNS server 31" through successive indirections and, where applicable, after an auxiliary indirect method, access LDAP server 3. The service provider returns the resource list of the relevant user and the relevant priority level. The ENUM server or channel can then, according to the situation, add users by using resources one by one, in descending order of priority, or based on all the resources of the user Way to add it.

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

[0075] The system includes a communication device 1150 to ensure that the user has a dialogue with the system, in particular:

[0076]-Send an authentication request to the user;

[0077]-receive information from the user so that it can be verified;

[0078]-Receive a request for record changes from the user (called a manual request), or a request for automatic changes based on time or location (geographical) criteria (called a program request);

[0079]-Transfer the recorded content before or after the change request;

[0080]-When the requested change has indeed been made, the update confirmation of the update storage unit (location) is transmitted to the user, and when it fails to be made, the transmission update is invalid;

[0081]-After the query or check is completed, send to the user an automatic change request recorded in the system in advance;

[0082]-Delivering a history of the changes that have been made to the user.

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

[0084] 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.

[0085] In addition to the above information, the database 1170 may specifically include: automatic modification procedures related to different users, IP addresses of servers of different telecommunication resource management providers, recorded manual or automatic modification history, and update confirmation/ The address where invalid notices must be delivered.

[0086] 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. protocol

For this purpose, the management device can transmit a query request according to the DNS protocol (DNS query). 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 querying the record in the LDAP directory (sending an LDAP search request) and allowing the record to be updated (sending an LDAP change request). When the update is completed, the protocol device receives a confirmation from the server of the telecommunication resource management provider.

[0087] The control device 1175 cooperates with the above-mentioned devices and specifically:

[0088] command to transmit a verification request from the communication device;

[0089]-After the verification device 1173 verifies the user, the protocol device 1162 is requested to transmit a query request, format the response and retransmit it to the user in an understandable form through the communication device;

[0090]-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;

[0091] After receiving the update confirmation/invalidation of the protocol device, the user is notified of the confirmation/invalidation through the communication device.

[0092] FIG. 3B illustrates an exemplary embodiment of the present invention, with the ENUM service as the background.

[0093] Components with the same reference numbers are equivalent to those 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, including 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 (stack) that adopts the DNS protocol described in the RFC1034 and RFC1035 documents. The protocol storage stack has 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.

[0094] The communication device of the system 50 is composed of the following modules:

[0095] Module 52 responsible for handling incoming and outgoing phone calls. This module manages the establishment and termination of communication (dropping);

[0096] User-to-user information (UUI) management module 53 that extracts and transmits UUI information;

[0097] Module 54 for processing DTMF codes. This module is responsible for recovering the DTMF input by the user;

[0098] Voice synthesis module 55;

[0099] A module 56 for broadcasting pre-recorded sound files connected into sentences;

[0100] Visual data server 57;

[0101] Module 58 for receiving and sending SMS;

[0102] Fax sending module 59;

[0103] An SMTP server 61 that sends and receives e-ma subscriptions;

[0104] Dynamic web server 63.

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

[0106] 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).

[0107] As mentioned above, the system 50 includes a verification device 73 so that users of the service can apply according to the verification information.

CN 1663222 Β

(Applicative) verification, the verification information, for example, a pseudonym (user name) and a 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).

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

[0109] When necessary, an LDAP protocol management module 64 is installed on it to read and modify records in the LDAP directory.

[0110] 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.

[0111] The control device first includes a module 74 responsible for automatic configuration of the ENUM file according to the automatic modification request programmed by the user and stored in the database 70, and then includes a module 75 responsible for "manual" configuration of 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- Ma subscribed address, telephone number, e-ma subscribed 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.

[0112] FIG. 4 outlines the process of inquiring and manually changing the ENUM file of the sound mode through a fixed or mobile phone of STN, ISDN, GSM or IP type.

[0113] In step 100, the ENUM user sends a toll-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, and the audio The telephone or color number type telephone 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 broadcast 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 inputs this information through the keyboard, and the information is transmitted in the form of DTMF band 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), to the E. 164ENUM number to search. 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 consistent, 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. ENUM script 75 detects that this is a read command for an ENUM file. Then in step 112, the ENUM script 75 sends an inquiry 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 telephone number 332960533859 is transformed into 9.5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. 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), Check zero in turn

CN 1663222 Β

The secondary DNS server, the primary DNS server, and the secondary DNS server are checked by the DNS protocol storage stack 32. 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 record, and generates a text that can be understood by ENUM users, namely "Service 1: Phone 0296053859, Service 2: Phone 0686166924, Service 3: e-ma order bertrand. duuont@rd. francetelecom. com and many more. 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.

[0114] 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 your ENUM file. The attributes of the 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.

[0115] 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 sound information to ENUM users, the sound information comes from the ENUM script module 75 (at step 152), according to the sound synthesis module 55 or the module 56 for broadcasting the sound file. (Context) and notices (in step 153), and the resulting 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:

[0116] °-Press 1 to change the order/priority of your services, press 2 to change service attributes, press 3 to add services, press 4 to cancel services, and so on.

[0117]° — 4

[0118] °-Press 1 to cancel the phone number 0296653859, press 2 to cancel the phone number 0686166924, press 3 to cancel the e-mail address bertrand. duuont@rd. francetelecom. com, etc.

[0119] ° —2

[0120] °-Press 1 to confirm your choice, otherwise press 2

[0121] ° —1

[0122] °-Press 1 to cancel the service, press 2 to record your changes, press 0 to return to the main menu

[0123] ° —2

[0124] 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 according to the ENUM users E.164 number The DNS protocol module 32 updates the server 31 to randomly access the information in the memory 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 itself This change is re-downloaded 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 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 the communication.

CN 1663222 Β

[0125] 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 according to the ENUM users E.164 number The DNS protocol module 32 updates the server 31 to randomly access the information in the memory 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 itself This change is re-downloaded 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 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 the communication.

[0126] 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.

[0127] FIG. 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.

[0128] In step 200, the ENUM user sends a formatted short message (ie: E.164 number + pen name + password + request) as specified by the ENUM service provider 30 to the short message module 58 of the present invention. The short message From a terminal connected to a public network, or from 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 queries the local or remote database (for example, through an ODBC interface) in step 203 to search for the E.164 ENUM number. 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, and 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 transformed into 9.5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. 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). 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 synthetic text that can be understood by ENUM users, namely "P1: phone = 0296053859, P2: phone = 0686166924, Pe: e-ma order = 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 callers number ).

[0129] 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. duuont@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 a fixed STN 4 or ISDN 2 via PABX 3, or from a GSM type mobile phone Terminal 6, or from IP terminal 7. In step 251, the short message module 58 transmits the short message to the ENUM script module 75. At 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) to search for the E.164 ENUM number. 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, which can be based on the ENUM user's E. 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 259, the server 31 confirms the update, and in step 260 it generates a response to the update command request. In step 261, the ENUM script 75 intercepts the return code of this response, and then in step 262, before sending it to the short message sending module 58, it generates a confirmation/invalid message about recording the change. The module 58 is responsible for the step 263 Send the SMS to the phone terminal that originally made the request (using the caller's number). [0130] FIG. 6 schematically illustrates the process of querying and manually changing ENUM files by using a network with a web browser terminal.

[0131] 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 queries the local or remote database (for example, through an ODBC interface) to search for the E.164 ENUM number. 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, and the request takes the E.164 address of the ENUM user converted into a domain as a parameter (E.164 telephone number 332960533859 is converted into 9.5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. arpa). The DNS protocol module 62 that performs 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:

[0132] Priority level 1 service call=0296053859

[0133] Priority level 2 service call=0686166924

[0134] Priority level 3 service Ma subscription: b. duuont@rd. ft. com

[0135] Priority level 4 service webpage: www. bertrandduuont. fr

[0136] In step 312, this script is sent to the web server module 63, and in step 313, the module 63 downloads a web page provided with this information to the web terminal 8 of the ENUM user.

CN 1663222 Β

[0137] The web page presented to the ENUM user makes it possible to change the usual ENUM file through a suitable graphical interface: change priority, add service, change service attribute, etc. 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 in step 353. The IP address of the latter is stored in the database 70, which can be based on the ENUM user's E. 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 355, the database 33 confirms the update, which in step 356 generates a response to the update command request. In step 357, the ENUM script 75 intercepts the return code of this response, and then in step 358, before sending it to the web server 63, it generates a confirmation/validation method for recording the change, and the web server 63 is responsible for In step 359, before downloading it to the web terminal 8, format the generated web page first.

[0138] FIG. 7 outlines the process of querying and manually changing ENUM files through a minitel (Minitel). ENUM users use the PAVI (Vidio Point of Access) function of the France Telecom network (for example, call "He Wei-Jie 1'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 its E. 164 number, its 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 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. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. 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 produces a relatively composite text that can be understood by ENUM users, namely:

[0139] Priority level 1 service call=0296053859

[0140] Priority level 2 service call=0686166924

[0141] Priority level 3 service Ma subscription: b. duuont@rd. ft. com

[0142] Priority level 4 service webpage: www. bertrandduuont. fr

[0143] In step 414, this script is sent to the videotext server module 57, and the videotext server module

CN 1663222 Β

Block 57 is responsible for downloading it to the small telex 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, which can be based on the E. 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. [0144] FIG. 8 outlines the process of querying and manually changing ENUM files through e-ma subscription or a terminal 8 with an e-ma subscription client.

[0145] In step 500, the ENUM user sends a formatted e-ma subscription to the e-ma subscription server 61. For example, the ENUM command can be used in the destination e-ma subscription address:

[0146] el64-33296053859-login-dupont-password-1234-request

[0147] lire@Restion. enum francetelecom. com

[0148] The ENUM script module 75 has a client that regularly checks the e-ma subscription server 61. When the ENUM script module 75 receives an e-ma subscription 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 in step 502 73. In step 503, 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 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-ma subscription. 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 an inquiry request to the DNS protocol management module 62, and the request takes the E.164 address of the ENUM user converted into the domain name as a parameter (E.164 telephone number 332960533859 is converted into 9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. arpa). The DNS protocol module 62 that performs the traditional role of RESOLVER, in step 507, in the aforementioned query method, if it is checked that the information has not yet existed 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 31 of the ENUM service provider 30, 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:

[0149] Priority level 1 service call=0296053859

[0150] Priority level 2 service call=0686166924

[0151] Priority level 3 service Ma subscription: b. duuont@rd. ft. com

[0152] Priority level 4 service webpage: www. bertrandduuont. fr

[0153] In step 510, this text is sent to the e-ma subscription server module 61 in the form of e-ma subscription through the e-ma subscription client software integrated in the ENUM script module, which is responsible for sending the approximate fax to ENUM user.

[0154] An ENUM user who wants to change his ENUM file sends a formatted e-ma subscription to the e-ma subscription server 61 in step 550. For example, the ENUM command can be in the destination e-ma subscription address:

[0155] E164-33296053859-1ogin-dupont-password-1234-request-write-Pl-te1-0296

053859-P2~te1-0686166924-P3-fax-0296050242@gestion. enum. francetelecom. com.

[0156] The e-ma subscription client of the ENUM script module checks the e-ma subscription server 61. When the ENUM script module receives an e-ma subscription 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, and in step 557, it 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, which can be based on the E. 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 by itself. In step 559, the database 33 confirms the update, which in step 560 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/invalid message about recording the change. In step 562, the message is sent to the e-ma subscription server 61 in the form of e-ma subscription through the client software integrated in the ENUM script module. The latter sends the e-ma subscription to the ENUM user in step 563, and the ENUM user can query the e-ma subscription at his terminal 8.

[0157] FIG. 9 outlines the process of querying and manually changing the ENUM file through the UUI (User-to-User Information) of the ISDN terminal.

[0158] 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: GetPl-33296053859*dupont#123456: This request can restore the attributes of the priority level 1 ENUM service.

[0159] 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 (a time delay before sending an offline message according to the ISDN protocol). 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 queries the local or remote database (for example, through an ODBC interface) to search for the E.164 ENUM number. 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 an inquiry request to the DNS protocol management module 62 in step 608, and the request is converted to

CN 1663222 Β

The E. 164 address of the ENUM user in the form of a domain is used as a parameter (E. 164 telephone number 332960533859 is converted to 9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. 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 inquire 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 31 of the ENUM service provider 30, 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 storing the corresponding NAPTR record in step 611 Retransmit to ENUM script module 75. The latter analyzes and understands the NAPTR record, and generates a relatively composite text that can be understood by ENUM users according to the service requested in the UUI command, namely:

[0160] Service P1: Tel=0296053859

[0161] In step 612, this text is sent to the UUI module 53, which is responsible for formatting an unconnected message before sending (step 613) to the call automatic control module 52. The call automatic control module 52 generates an offline message, the offline message contains UUI information, and is transmitted to the ENUM user's terminal 2 through the ISDN network in step 614. The ENUM user can display it on the display screen of his ISDN terminal 2. Show UUL·

[0162] An ENUM user who wants 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.

[0163] The call automation controller 52, in step 651, sends a message requesting the establishment of a call to the UUI module 53, which extracts the UUI command. In step 652, the call automation controller 52 sends the 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 (in step 658) to the DNS protocol management module 62, the request takes the ENUM user's E.164 address converted into a domain as a parameter (E. 164 phone number 332960533859 is converted to 9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. arpa). The DNS protocol management module 62, which performs 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 method (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, which can be based on the ENUM user's E. 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 this file at a predetermined time interval.

Changes. 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 automatic control module 52. The call automatic control module 52 generates offline information in step 670, and the offline information contains UUI information element, so it is transmitted to the ENUM user's terminal 2 through the ISDN network. The ENUM user can display it on the screen of its ISDN terminal 2. Shows UUL· [0164] Figure 10 outlines the process of accessing services to query and manually modify ENUM files through network conversations. 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.

[0165] 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 network 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: [0166] Monday to Friday: 0830 to 1900

[0167] P1 phone 0296053859 P2 phone 0686166924

[0168] P3 e-mail bertrand. duuont@rd. francetelecom. com

[0169] P4 Fax 0296050242

[0170] Monday to Friday: 1900 to 0830

[0171] Pl Phone 0296916404

[0172] P2 e-mail bertrand. duuont@rd. francetelecom. com

[0173] Saturday to Sunday: 0000 to 0830

[0174] Pl phone 0296916404 P2 phone 0686166924

[0175] P3 e-mail b. duuont@wanadoo. fr

[0176] The ENUM script module 75, in step 710, transmits the formatted information to the network server 63, which is responsible for downloading the general plain information containing the configuration program from the ENUM file to the network terminal 8 of the ENUM user.

[0177] This web page can make changes to the automatic configuration program 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 web page to the ENUM user's network terminal 8ο

[0178] FIG. 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.

[0179] 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 an inquiry 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. 164 phone number 332960533859 is converted to 9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. 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 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 31 of the ENUM service provider 30, 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 of the ENUM service provider 30 in step 809 On the DNS protocol module 32 of the server 31. 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 811, the database 33 confirms the update, which in step 812 generates a response to the update command request. In step 813, the automatic controller 74 is configured to intercept the return code of this response, and then in step 814, a request written in the database 70 is generated to obtain a log (record) of the change. In step 815, the database 70 determines the writing of the automatic file change event.

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

[0181] When the notification is made by voice, the automatic configuration controller 74 notifies the automatic controller to call in step 820

52. The call automatic 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 telephone call in step 822, or the call is switched to its voice message. The voice synthesis module 55 or the voice file broadcast module 56 broadcasts the ENUM file change notice 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 Yue Gen Service Bertrand. Duuont@wanadoo. fr;

[0182] 0 When the notification is made by short message, the automatic configuration controller 74 uses the short message script to notify the short message module 58 in step 830, for example: "Your ENUM file 33296053859 changes (at 0900 o'clock on March 21, 2002): phone -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.

[0183] When the notification is made in the e-ma subscription mode, the automatic configuration controller 74, in step 850, will include an e-ma subscription with the following script, that is, "change of your ENUM file 33296053859 (March 2002). At 0900 o'clock on the 21st): Tel-0296053859, Tel-0686166924, Fax-0296050242", notify the e-ma subscription server 61 of the update.

CN 1663222 Β

In order to achieve this goal, the automatic configuration controller must have an e-ma customer. Then in step 60, the e-ma subscription server 61 transmits the related e-ma subscription to the e-ma subscription address stored in the database 70.

[0184] 0 When the notification is made by fax, the automatic configuration controller 74 notifies the fax module 59 with a fax script in step 870, which can be as follows: "The changes to your ENUM file 33296653859 (at 0900 hours on March 21, 2002) ): Tel-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.

[0185] 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.

[0186] 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 queries the local or remote database (for example, through an ODBC interface) to search for the E.164 ENUM number. 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, and the request uses 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. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. 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 yet 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 first-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:

[0187] SORIGIN 9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. arpa.

[0188] IN NAPTR 100 10 "u" "ldap+E2U""! .... +33296053859$! Ldap: //ldap.

providerA. fr/cn = 33296053859!

[0189] 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 is to connect to the LDAP command on 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 the LDAP protocol module 35 of the LDAP directory server 34 of the ENUM A30 provider. In step 914, the LDAP protocol module 35 accepts the connection. The LDAP protocol management module 64 then In step 915, the LDAP "search" request is sent to the LDAP protocol module 35, and the "search" request takes the ENUM user's E.164 number as a parameter. In step 916, the LDAP protocol module 35 queries the LDAP database 36, and then asks about the ENUM user All the information of is returned (in step 917) to the LDAP protocol module 35, which itself returns all the information about the ENUM user to the LDAP protocol management module 64 in step 918. The latter returns the information to the ENUM script 75 in step 919 , It is responsible for the information

CN 1663222 Β

Before transmitting (at step 922) to the network server 63, the information is first put in a form that the ENUM user can understand. 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.

[0190] FIG. 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 make changes to the ENUM file through a terminal other than a personal computer.

[0191] An ENUM user who inquires about the content of his ENUM file through the above process will decide to modify 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 telephone number 332960533859 is converted to 9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. arpa). The DNS protocol management module 62 performing the role of RESOLVER, in step 1003, in the aforementioned query method, if the information does not 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 31 of the ENUM service provider 30, 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:

[0192] SORIGIN 9. 5. &amp; 3. 5. 0. 6. 9. 2. 3. 3. el64. arpa.

[0193] IN NAPTR 100 10 "u

[0194] ldap+E2U!... +33296053859$! Ldap ://ldap.providerA. fr/cn =

33296053859 ! ”

[0195] 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, and 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 the LDAP protocol module 35 of the LDAP directory server 34 of the ENUM 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 is the ENUM user's E. The 164 number is used 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 ENUM user's network terminal

8 on. 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.

[0196] Although the process of updating the LDAP directory has been illustrated 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.

[0197] 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 the DNS (or LDAP) server One or more resource records (RR) are updated, as defined in paragraph 3.2.2 of the aforementioned document RFC1035, and listed in the following table:

[0198]

<td>RR type</td><td>Serial number</td><td>meaning</td>

<td>A</td><td>1</td><td>IP address of the machine</td>

<td>NS</td><td>2</td><td>The name of the server managed by the management organization</td>

<td>MD</td><td>3</td><td>Destination mail server</td>

<td>MF</td><td>4</td><td>Re-routing mail server</td>

<td>CNAME</td><td>5</td><td>Username's real name</td>

<td>SOA</td><td>6</td><td>Organization area start mark</td>

<td>MB</td><td>7</td><td>e-ma subscribed mailbox domain name</td>

<td>MG</td><td>8</td><td>Mail group member</td>

<td>MR</td><td>9</td><td>Rename mail domain</td>

<td>NULL</td><td>10</td><td>Resource record NULL</td>

<td>WKS</td><td>11</td><td>Public service description</td>

<td>PTR</td><td>12</td><td>Domain name indicator</td>

<td>HINFO</td><td>13</td><td>Computer information</td>

<td>MINFO</td><td>14</td><td>Email information</td>

<td>MX</td><td>15</td><td>Mail exchange</td>

<td>TXT</td><td>16</td><td>String</td>

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

[0200] It should be noted that if a non-NAPTR resource record is to be updated, it must be installed with the "ENUM pin

This" similar module to process these records.

CN 1663222 Β