Patent Description:
Telephone number research devices are known and disclosed in, for example, Patent Documents <NUM>, <NUM> and <NUM> filed by the applicant and already published. Such a telephone number research device is capable of conducting research on the usage status of telephone numbers across the country.

According to the technologies described in the patent documents, the telephone number research device, a caller, is first connected to a public switched telephone network (PSTN), a mobile communication network, or an Internet protocol (IP) telephone network. The telephone number research device then requests for access to subscriber data using the user network interface (UNI) protocol of an integrated service digital network (ISDN) or the like, thereby researching the usage status of a telephone number as to whether the telephone number is "valid", "invalid", "changed", and the like.

Meanwhile, the migration from PSTN to next-generation network (NGN) is being planned worldwide, and it is expected that the digital communication mode provided by the ISDN service will be discontinued in the future. Because of this, there is a need for a telephone number research tool having session initiation protocol (SIP) based connectivity to the NGN network, instead of ISDN UNI connectivity, to ensure a smooth transition to the new system platform.

In recent years, landline telephones have been gradually replaced by IP phones, which leads to a demand for the realization of an IP telephone number research device that can accurately determine the usage status of telephone numbers.

The basic mechanism of IP telephony is greatly different from traditional landline telephone technology. Therefore, as described in, for example, Patent Document <NUM>, a known telephone number research device verifies the validity of an IP phone number by sending an INVITE request with an incorrect description to the IP telephony network (SIP server).

However, through evaluation tests using the technology described in Patent Document <NUM>, the applicant found that it still failed to establish research that was able to accurately determine the usage status of IP phone numbers. Specifically, in Patent Document <NUM>, the subjects of the research are IP phones that are assigned an <NUM>-digit telephone number starting with <NUM>; the research does not cover IP phones that are assigned the same type of telephone number (0AB-J number) as conventional subscriber telephones such as fiber optic phones. Accordingly, in the course of researching the usage status of telephone numbers of IP phones assigned a 0AB-J number, the validity cannot be verified due to network rejection or the like.

To cope with this, the applicant has established a technology in which a caller terminal (telephone number research device) transmits a specific SIP message that causes call rejection on IP phones via a UNI connection to the IP telephony network to determine the usage status of telephone numbers in the IP telephony network without using a signal that rings an incoming call. This technology was patented as "telephone number research device, telephone number research method, telephone number research program, and a recording medium" on March <NUM>, <NUM> (<CIT>). According to the technology disclosed in the patent, a smooth transition to the new system platform can be achieved with a telephone number research tool having SIP based connectivity to the NGN network.

According to this technology, the telephone number research covers not only IP phones that are assigned an <NUM>-digit telephone number starting with <NUM> but also those assigned a 0AB-J number, such as fiber optic phones, similarly to conventional subscriber telephones. Thus, the research can accurately determine whether telephone numbers are each valid or invalid regardless of the types of IP phones. Reference is made further to Japanese Patent Application No. <CIT> filed by the applicant, which discloses a technology for investigating the usage status of telephone numbers in IMS networks, NGN networks, and IP telephone networks without ringing an incoming call using an IMS interconnection interface or the like for interconnection between carriers.

With the migration from PSTN to NGN, the signaling protocol for the interconnection interface between carriers will also migrate from a common or standard signaling protocol known as signaling system No. <NUM> (SS7) to a session initiation protocol (SIP). As a result, a specific SIP message from a caller terminal (telephone number research device) will reach the IP multimedia subsystem (IMS) network, NGN network, and IP telephony or Voice over Internet Protocol (VoIP) network.

IMS is a standard for realizing multimedia services where services that have been provided through fixed networks, mobile communications, and the like are IP based and integrated. Mobile communication systems and NGNs are the systems that are built according to the standard.

For this reason, there is a need for a SIP-based telephone number research tool that can establish a UNI connection to the NGN network to determine the usage status of telephone numbers in the IMS and IP telephony (VoIP) networks without a signal that rings an incoming call, using an IMS interconnection interface or the like for interconnection between carriers, to achieve a smooth transition to the new system platform.

The present invention has been made to solve the above problems. It is therefore an object of the present invention to provide a device, method, program, and information provision system for telephone number research to determine the usage status of telephone numbers in IMS and IP telephony (VoIP) networks using an IMS interconnection interface or the like for interconnection between carriers, enabling a smooth transition to the new system platform.

In particular, an object of the present invention is to provide a device, method, program, and information provision system for telephone number research capable of determining the usage status of telephone numbers regardless of the type of the destination network.

The above object is achieved by the subject-matter of the independent claims. Further preferred embodiments are set out by the dependent claims. For illustrative purposes only, exemplary aspects of the present invention may be summarized as follows:.

According to one aspect of the present invention, it is possible to provide a device, method, program, and information provision system for telephone number research to determine the usage status of telephone numbers in IMS and IP telephony networks using an IMS interconnection interface or the like for interconnection between carriers, enabling a smooth transition to the new system platform. In particular, it is possible to provide a device, method, program, and information provision system for telephone number research capable of determining the usage status of telephone numbers regardless of the type of the destination network.

In the following, modes (hereinafter, "embodiments") for carrying out the present invention will be described in detail with reference to the accompanying drawings. Note that like parts are designated by like reference numerals or characters throughout the description of the embodiments.

<FIG> is a diagram illustrating the network connection of a telephone number research device <NUM> according to an embodiment. As illustrated in <FIG>, the telephone number research device <NUM> of this embodiment is connected to a plurality of telephone terminals to be researched (IMS terminals 50a, 50b and an IP telephone terminal <NUM>), which are connected to an IMS network <NUM> or a VoIP (IP telephony) network <NUM>, via an NGN network <NUM>.

The IMS network <NUM> is built for each of a mobile network operator/mobile communication carrier (carrier A) and an NGN carrier (carrier B). The IMS terminals 50a and 50b are connected to their respective networks (contract carriers) via SIP servers 30a and 30b managed and operated by the carriers. The IP telephone terminal <NUM> is connected to the IP telephony network <NUM> via a SIP server 30c of a VoIP carrier (carrier C).

In the configuration of <FIG>, when the telephone number research device <NUM>, a caller, dials the telephone number of a receiver telephone terminal, routing is performed in the following order: a SIP server 20a in the NGN network <NUM>, a caller-side session border controller (SBC) <NUM>, a receiver-side SBC <NUM>, <NUM>, the SIP server 30a, 30b, 30c, and the IMS terminal 50a, 50b or the IP telephone terminal <NUM> as the receiver. At this time, a UNI connection is established between the telephone number research device <NUM> and the NGN network <NUM>. In addition, an IMS interconnection between carriers is secured between the NGN network <NUM> and the IMS network <NUM> via the caller-side SBC <NUM> and the receiver-side SBC <NUM>, and an interconnection is secured between the NGN network <NUM> and the VoIP network <NUM> via the caller-side SBC <NUM> and the receiver-side SBC <NUM>. With this, a specific SIP message (described later) transmitted from the telephone number research device <NUM> reaches the IMS network <NUM>.

Note that although <FIG> illustrates three networks: IMS network, NGN network, and VoIP network as receiver-side networks, the IMS network to which the IMS terminal 50a is connected and the NGN network to which the IMS terminal 50b is connected are identified by the same reference numeral "<NUM>" as they have the same architecture. The common interface for interconnection between IMS carriers via an IP to IP connection is specified in the international standard (TS <NUM>).

According to the SIP protocol, negotiation is necessary between terminals as to a method of encoding packets that contain media information, the destination address of the packets, and the like for real-time communication. This negotiation requires a description format called session description protocol (SDP) defined in RFC <NUM>.

In order to establish a session using SIP, a caller sends a SIP message that contains a description of media information as a request to a receiver, and the receiver replies with a response selecting available media from the media information, thus sharing the media information used for communication. In this manner, sending a SIP message that carries media information to initiate a session is called an offer, and returning information on available media in response is called an answer. This offer/answer model is defined in RFC <NUM>.

As illustrated in <FIG>, the telephone number research device <NUM> of this embodiment sends an SDP offer of the INVITE method (hereinafter, "INVITE request") to the IMS terminal 50a, 50b or the IP telephone terminal <NUM> to be researched via the NGN network <NUM> (the SIP server 20a), the IMS network <NUM> (the SIP server 30a), the NGN network <NUM> (the SIP server 30b), or the VoIP network <NUM> (the SIP server 30c). At this time, the INVITE request contains an SDP parameter that causes call rejection on the receiver, i.e., the IMS terminal 50a, 50b or the IP telephone terminal <NUM> (INVITE (SDP mismatch)).

When the INVITE request arrives, the receiver: the IMS terminal 50a, 50b or the IP telephone terminal <NUM> rejects the INVITE request since its SDP parameter is different from a usable one and sends back a <NUM> error response ("Not Acceptable Here") as a response message. Through the receipt of the <NUM> error response, the telephone number research device <NUM> can accurately determine whether the IMS terminal 50a, 50b or the IP telephone terminal <NUM> is present by the mechanism described below.

Incidentally, there are four cases of SDP mismatch in the SDP negotiation procedure of the INVITE method: network protocol mismatch, media type mismatch, transport protocol mismatch, and codec mismatch. The telephone number research device <NUM> of this embodiment can accurately determine the usage status or validity of a telephone number by combining these cases.

According to RFC <NUM> considered as the SBC standard, when a call is sent from an NGN network (IPv6) to a VoIP network that does not support IPv6, the network protocol is converted to the IPv4 network protocol suitable for the destination network. Specifically, the SBC <NUM> in the NGN network <NUM> has a function to convert the network protocol to the IPv4 network protocol when sending an SDP parameter (first SDP parameter) to the VoIP network <NUM>. The telephone number research device <NUM> determines if the network protocol of an SDP parameter has been converted to determine whether the destination network is the IMS network <NUM> or the VoIP network <NUM>.

<FIG> is a sequence diagram for the operation of the telephone number research device of this embodiment, illustrating an example where a first SDP parameter is sent to a receiver-side VoIP network. <FIG> illustrates an SDP negotiation procedure among the telephone number research device <NUM>, the caller-side NGN network <NUM>, the caller-side SBC <NUM>, the receiver-side SBC <NUM>, the receiver-side VoIP network <NUM>, and the IP telephone terminal <NUM>.

As illustrated in <FIG>, through the receiver-side IP telephony network <NUM> managed by the VoIP carrier that is the contract carrier of the IP telephone terminal <NUM> to be researched, the telephone number research device <NUM> sends an INVITE request to the IP telephone terminal <NUM> via the NGN network <NUM>. At this time, the INVITE request contains an SDP parameter (first SDP parameter) including information that causes call rejection on the receiver IP telephone terminal <NUM> (steps S11 to S12: INVITE + first SDP: IPv6). In this example, the NGN network <NUM> supports IPv6, and the SDP parameter includes the IPv6 network protocol.

The SBC <NUM> on the NGN network <NUM> side performs a mismatch correction function to match the SDP parameter of the INVITE request with the function of the VoIP network <NUM> and rewrites (SDP-converts) the SDP parameter to conform to IPv4. The SBC <NUM> sends the converted INVITE request (INVITE + mod. SDP: IPv4) forward to the VoIP (IPv4) network <NUM> (step S13). The SBC <NUM> in the VoIP network <NUM> sends the converted INVITE request (INVITE + mod. SDP: IPv4) to the receiver terminal <NUM> (steps S14 to S15).

In response, the receiver IP telephone terminal <NUM> sends back a response message (<NUM> OK + SDP: IPv4) (steps S16 to S17). The SBC <NUM> in the VoIP network <NUM> converts the SDP parameter returned from the receiver terminal <NUM> and sends the response message (<NUM> OK + mod. SDP) to the SBC <NUM> on the NGN network <NUM> side (step S18). The SBC <NUM> on the NGN network <NUM> side sends the converted response message (<NUM> OK + mod. SDP) to the telephone number research device <NUM>.

Having received the response message "<NUM> OK + mod. SDP", the telephone number research device <NUM> determines that the destination network is the VoIP network <NUM>. Furthermore, upon receipt of the response message "<NUM> OK + mod. SDP", the telephone number research device <NUM> determines that the telephone number of the IP telephone terminal <NUM> is real and present. When the destination network is the VoIP network <NUM> as a result of the network determination, the telephone number research device <NUM> sends an ACK request as confirmation from a VoIP SIP transmitter to the receiver IP telephone terminal <NUM> (steps S21 to S25).

Next, with reference to <FIG>, an example will be described in which the destination network is a VoIP network and a telephone number is missing. The telephone number research device <NUM> sends an INVITE request via the NGN network <NUM> to the receiver-side VoIP network <NUM> managed by the VoIP carrier that is the contract carrier of the IP telephone terminal <NUM> to be researched. At this time, the INVITE request contains an SDP IPv6 parameter including information that causes call rejection on the receiver (steps S31 to S32: INVITE + first SDP: IPv6).

The SBC <NUM> on the NGN network <NUM> side performs a mismatch correction function to match the SDP parameter of the INVITE request with the function of the VoIP network <NUM> and rewrites the SDP parameter to conform to IPv4. The SBC <NUM> sends the converted INVITE request (INVITE + mod. SDP: IPv4) forward to the VoIP (IPv4) network <NUM> (step S33). The SBC <NUM> in the VoIP network <NUM> sends the converted INVITE request (INVITE + mod. SDP: IPv4) to the destination network, i.e., the VoIP network <NUM> (step S34).

In response, the receiver-side VoIP network <NUM> sends back a response message (error <NUM>/<NUM> + SDP: IPv4) with the SDP parameter and an error code (step S35). The SBC <NUM> in the VoIP network <NUM> converts the SDP parameter of the response message and sends the response message (error <NUM>/<NUM> + mod. SDP) to the SBC <NUM> on the NGN network <NUM> side (step S36). The SBC <NUM> on the NGN network <NUM> side sends the converted response message (error <NUM>/<NUM> + mod. SDP) to the telephone number research device <NUM> (steps S37 to S38).

Having received the response message that is an error response including the error code (<NUM>/<NUM>) (steps S35 to S38), the telephone number research device <NUM> obtains the usage status (missing) of the telephone number of the IP telephone terminal <NUM> and determines that the telephone number is missing. When the destination network is the VoIP network <NUM> as a result of the network determination, the telephone number research device <NUM> sends an ACK request as confirmation from a VoIP SIP transmitter to the receiver IP telephone terminal <NUM> (steps S39 to S42). Incidentally, the error response <NUM> code indicates that the user is not found, and the <NUM> code indicates a guidance response.

<FIG> is a sequence diagram for the operation of the telephone number research device of this embodiment, illustrating an example where a first SDP parameter is sent to a receiver-side IMS network. <FIG> illustrates an SDP negotiation procedure among the telephone number research device <NUM>, the caller-side NGN network <NUM>, the caller-side SBC <NUM>, the receiver-side SBC <NUM>, the receiver-side IMS network <NUM>, and the IMS terminal 50a (50b).

As illustrated in <FIG>, through the receiver-side IMS network <NUM> such as a mobile telephone network managed by the contract carrier of the IMS terminal 50a (50b) to be researched, the telephone number research device <NUM> sends an INVITE request to the IMS terminal 50a (50b) via the NGN network <NUM>. At this time, the INVITE request contains an SDP parameter (first SDP parameter) including information that causes call rejection on the receiver IMS terminal 50a (50b) (steps S51 to S55: INVITE + first SDP: IPv6).

If the destination network is the IMS network <NUM> that supports IPv6, the SBC <NUM> on the NGN network <NUM> does not convert the network protocol. When the INVITE request arrives, the receiver IMS terminal 50a (50b) rejects the INVITE request since its SDP parameter is different from a usable one and sends back a <NUM> error response (steps S56 to S60).

Through the receipt of the <NUM> error response, the telephone number research device <NUM> can accurately obtain the usage status (real/present, available) of the telephone number of the IMS terminal 50a (50b).

Upon receipt of the <NUM> error response through the NGN network <NUM>, the telephone number research device <NUM> sends an ACK request as confirmation to the receiver IMS terminal 50a (50b) via the caller-side SBC, the receiver-side SBC of the contract carrier, and the IMS network <NUM> (steps S61 to S66). As described above, the telephone number research device <NUM> of this embodiment performs a <NUM>-way handshake: INVITE request/<NUM> error response/ACK request for researching the usage status of a telephone number, thereby improving the reliability of communication.

<FIG> illustrates a case where the telephone number of the receiver IMS terminal 50a (50b) is missing. In this case, the telephone number research device <NUM> sends an INVITE request to the receiver IMS terminal 50a (50b) via the NGN network <NUM> and the IMS network <NUM> (steps S71 to S74). As a result, the telephone number research device <NUM> receives a <NUM>/<NUM> error response from the receiver-side IMS network <NUM> (the SIP server 30a (30b)) (steps S75 to S78), thus obtaining the usage status (missing) of the telephone number. Upon receipt of the <NUM> error response, the telephone number research device <NUM> sends an ACK request as confirmation to the IMS network <NUM> via the NGN network <NUM> (steps S81 to S84).

<FIG> is a sequence diagram for the operation of the telephone number research device of this embodiment, illustrating an example where a second SDP parameter is sent to a receiver-side VoIP network.

As illustrated in <FIG>, through the receiver-side IP telephony network <NUM> managed by the VoIP carrier that is the contract carrier of the IP telephone terminal <NUM> to be researched, the telephone number research device <NUM> sends an INVITE request to the IP telephone terminal <NUM> via the NGN network <NUM>. At this time, the INVITE request contains a second SDP parameter including information that causes call rejection on the receiver IP telephone terminal <NUM> (steps S211 to S212: INVITE + second SDP: IPv4). Two of the four parameters that can cause an SDP mismatch: network protocol (IPv4) and media type (audio) are fixed. Therefore, the second SDP parameter includes a description of at least one or a combination of a transport protocol and a codec so that it can cause call rejection on the IP telephone.

Because of not having to match the second SDP parameter of the INVITE request with the function of the VoIP network <NUM>, the SBC <NUM> on the NGN network <NUM> side sends the INVITE request (INVITE + second SDP: IPv4) forward to the VoIP (IPv4) network <NUM> without SDP conversion (step S213). The SBC <NUM> in the VoIP network <NUM> sends the received INVITE request (INVITE + second SDP: IPv4) to the receiver terminal <NUM> (steps S214 to S215).

When the INVITE request arrives, the receiver IP telephone terminal <NUM> rejects the INVITE request since its SDP parameter is different from a usable one and sends back a <NUM> error response (steps S216 to S217). The SBC <NUM> in the VoIP network <NUM> sends the <NUM> error response from the receiver terminal <NUM> to the SBC <NUM> on the NGN network <NUM> side (step S218). The SBC <NUM> on the NGN network <NUM> side sends the <NUM> error response to the telephone number research device <NUM>.

Through the receipt of the <NUM> error response, the telephone number research device <NUM> can accurately obtain the usage status (real/present, available) of the telephone number of the receiver terminal <NUM>. The telephone number research device <NUM> then sends an ACK request as confirmation from a VoIP SIP transmitter to the receiver IP telephone terminal <NUM> (steps S221 to S225).

<FIG> illustrates a case where the destination network is a VoIP network and a telephone number is missing. In this case, the telephone number research device <NUM> sends an INVITE request to the receiver IP telephone terminal <NUM> via the NGN network <NUM> and the VoIP network <NUM> (steps S231 to S234). As a result, the telephone number research device <NUM> receives an error response including an error code (<NUM>) as a response message (steps S235 to S238), thus obtaining the usage status (missing) of the telephone number of the IP telephone terminal <NUM>. With this, the telephone number research device <NUM> determines that the telephone number is missing. The telephone number research device <NUM> then sends an ACK request as confirmation from a VoIP SIP transmitter to the receiver IP telephone terminal <NUM> (steps S239 to S242). Incidentally, the <NUM> code in the error response indicates a guidance response.

<FIG> is a block diagram illustrating the configuration of the telephone number research device <NUM> according to the embodiment. As illustrated in <FIG>, the telephone number research device <NUM> of this embodiment includes a network interface unit <NUM>, a message exchange controller <NUM>, a telephone number research determination unit <NUM>, a telephone number history generator <NUM>, and a telephone number history database (DB) <NUM>.

The network interface unit <NUM> provides a communication interface that allows the telephone number research device <NUM> to perform communication conforming to the SIP protocol. The message exchange controller <NUM> sends an INVITE request that causes an SDP mismatch to the IMS terminal 50a, 50b or the IP telephone terminal <NUM>, and receives a message (error response) from the SIP server 30a, 30b of the receiver-side IMS network <NUM> or the SIP server 30c of the VoIP network <NUM>. Note that the SDP parameter added to cause an SDP mismatch may be any one of "network protocol", "media type", "transport protocol", and "codec", or a combination thereof, which are not available to the receiver: the IMS terminal 50a, 50b or the IP telephone terminal <NUM>.

The message exchange controller <NUM> sends a message with an SDP parameter that contains at least one of a network protocol, a media type, a transport protocol, and a codec, or a combination thereof, which are not available to the receiver: the IMS terminal 50a, 50b or the IP telephone terminal <NUM>.

The telephone number research determination unit <NUM> determines the validity of a telephone number, such as whether the receiver: the IMS terminal 50a, 50b or the IP telephone terminal <NUM> is present or not, based on an error response received through the message exchange controller <NUM>. When a response message indicates call rejection, the telephone number research determination unit <NUM> determines that the telephone number of the IMS terminal 50a, 50b or the IP telephone terminal <NUM> is real and present.

Having received, for example, an error code <NUM> (first error code) through the message exchange controller <NUM>, the telephone number research determination unit <NUM> determines that the telephone number of the receiver researched: the IMS terminal 50a, 50b or the IP telephone terminal <NUM> is real and present. Upon receipt of, for example, an error code <NUM> (second error code) or an error code <NUM> (third error code), the telephone number research determination unit <NUM> determines that the telephone number is missing.

When receiving an error code <NUM> (first error code) as a response message from the IMS network <NUM> (the SIP server 30a, 30b) through the message exchange controller <NUM>, the telephone number research determination unit <NUM> may determine that the telephone number of the receiver IMS terminal 50a, 50b researched is "present in an available state". On the other hand, when receiving, for example, an error code <NUM> (fourth error code) through the message exchange controller <NUM>, the telephone number research determination unit <NUM> may determine that the telephone number of the receiver IMS terminal 50a, 50b researched is "present in a busy state".

When receiving an error code <NUM> (second error code) as a response message from the IMS network <NUM> (the SIP server 30a, 30b) through the message exchange controller <NUM>, the telephone number research determination unit <NUM> may determine that the telephone number of the receiver IMS terminal 50a, 50b researched is "missing in a cancelled state and no user found".

When receiving an error code <NUM> (first error code) as a response message from the VoIP network <NUM> (the SIP server 30c) through the message exchange controller <NUM>, the telephone number research determination unit <NUM> may determine that the telephone number of the receiver IP telephone terminal <NUM> researched is "present in an available state".

When receiving an error code <NUM> (third error code) as a response message from the VoIP network <NUM> (the SIP server 30c) through the message exchange controller <NUM>, the telephone number research determination unit <NUM> may determine that the telephone number of the receiver IP telephone terminal <NUM> researched is "missing".

The telephone number history generator <NUM> assigns a timestamp indicating the determination date and time to each of the determination results of the telephone number research determination unit <NUM> and records them in chronological order on a recording medium, thereby constructing the telephone number history DB <NUM>.

<FIG> illustrates an example of the data structure of the telephone number history DB <NUM>. The telephone number history DB <NUM> stores telephone number history information. The telephone number history information includes, as indicated in the telephone number history information layout, "telephone number" researched, "new subscriber number" which is a new or contact telephone number found during the research, "error code" returned from the destination network, "research date" (timestamp), and "other layer information" regarding a layer used for response from the destination network, which are stored and registered for each research.

As another way to create telephone number history information, for example, when research is conducted on the usage status of a telephone number "<NUM>-<NUM>-<NUM>", research information is stored in the above layout for each determination of the telephone number research determination unit <NUM> and sequentially accumulated as history information. Further to the above data items, the telephone number history DB <NUM> may also additionally store the name of the corporation or individual that owns the phone number, attribute information such as an address, age, and the like, map link information, and credit information for evaluating creditworthiness.

Referring back to <FIG>, the network interface unit <NUM>, the message exchange controller <NUM>, the telephone number research determination unit <NUM>, and the telephone number history generator <NUM> can be each realized by a microprocessor with a built-in or external memory that stores a program and large scale integration (LSI) circuitry for peripheral control including communication. The microprocessor sequentially fetches instructions of the program from the memory and executes them, thereby implementing the functions of the telephone number research device <NUM>.

Specifically, the program implements the following functions: adding an SDP parameter that causes call rejection on the IMS terminal 50a (50b) to the SDP parameter of an INVITE request, sending the INVITE request through the NGN network <NUM> to the IMS terminal 50a (50b) via the IMS network <NUM>, which is the destination network selected by the NGN network <NUM> for each contract carrier of the IMS terminal 50a (50b); and determining the telephone number usage status of the IMS terminal 50a (50b) based on a response message from the IMS network <NUM> (the IMS terminal 50a (50b)), which is the destination network selected by the NGN network <NUM>.

The telephone number history DB <NUM> is stored in a large-capacity recording medium including a semiconductor memory and an optical memory such as a hard disk or a digital versatile disc (DVD).

In the following, with reference to the flowchart of <FIG> illustrating an SDP negotiation procedure in the IMS network <NUM>, a description will be given of a procedure for establishing a communication session based on an SDP description in the telephone number research device <NUM> of the embodiment illustrated in <FIG>.

As illustrated in <FIG>, the telephone number research device <NUM> (the message exchange controller <NUM>) negotiates with the IMS terminal 50a, 50b, the subject of telephone number research, to establish a communication session based on the description of SDP parameters in the following order: check the network protocol (step S91), check the media type (step S93), check the transport protocol of the media (step S95), and check the codec (step S97).

This example assumes that in the negotiation procedure for establishing communication in the NGN network <NUM>, an offer is made with SDP parameters describing, for example, network protocol: IPv6, media type: terminal compatible with all media types (m = audio + m = video + m = application), transport protocol: RTP/AVPF, and video codec: H.

First, in the check of the network protocol (step S91), when the receiver IMS terminal 50a, 50b is implemented with an IPv4 terminal that does not support IPv6 (step S91: NO), the IPv4 terminal replies to the message exchange controller <NUM> with an error code <NUM> (warning code <NUM>/<NUM>) indicating a network protocol mismatch (step S92). On the other hand, when the receiver IMS terminal 50a, 50b is implemented with an IPv6 terminal (step S91: YES), the process proceeds to the check of the media type (step S93). In this step, if the SDP description contains even one media type (m) that the IPv6 terminal does not support (step S93: NO), the receiver IMS terminal 50a, 50b replies with an error code <NUM> (warning code <NUM>) indicating a media type mismatch (step S94).

Incidentally, examples of the IPv6 terminal incompatible with the media include a telephone that supports only audio (m = audio), a TV phone that does not support an application (m = application), and an IP-FAX that does not support video (m = video).

When the receiver IMS terminal 50a, 50b is implemented with a terminal compatible with all media types (step S93: YES), the process then proceeds to the check of the transport protocol (step S95). In this step, even when compatible with all media types as per the SDP description, if the receiver IMS terminal 50a, 50b or IP telephone terminal <NUM> is an AVP terminal that does not support the transport protocol (RTP/AVPF) set forth in the SDP description (step S95: NO), it replies with an error code <NUM> (warning code <NUM>) (step S96).

On the other hand, when the terminal supports the transport protocol set forth in the SDP description (step S95: YES), the process then proceeds to the check of the codec (step S97). In this step, when the terminal does not support the codec set forth in the SDP description (step S97: NO), specifically, if the receiver IMS terminal 50a, 50b is implemented by a terminal that uses a video codec with a lower quality and compression ratio than H. <NUM> such as MPEG-<NUM>, the terminal that uses a codec other than H. <NUM> sends back an error code <NUM> (warning code <NUM>) to the telephone number research device <NUM> (the message exchange controller <NUM>) (step S98).

If all the four SDP parameters are met, communication is established, and the telephone number research device <NUM> can accurately determine the validity of the telephone number of the receiver IMS terminal 50a, 50b. If any of the four SDP parameters is not met, the terminal sends an error code <NUM>, and the call is rejected.

In the NGN network <NUM>, it is possible to set the four parameters that cause call rejection in the above communication establishment procedure. With all the four SDP parameters of network protocol, media type, transport protocol, and codec, the validity of the telephone number can be accurately determined without using a signal that rings an incoming call.

Differently from the SDP negotiation procedure in an IMS network illustrated in <FIG>, two parameters of transport protocol and codec that cause call rejection are used in a VoIP network where the network protocol (IPv4) and media type (audio) are fixed. In this case also, the validity of the telephone number can be accurately determined without using a signal that rings an incoming call.

Next, a telephone number research method according to the embodiment will be described with reference to the flowchart of <FIG> illustrating an algorithm for researching the usage status of a telephone number. The telephone number research method can be realized by causing a computer to perform each of the steps described below.

The message exchange controller <NUM> sends an INVITE request to the IMS terminal 50a, 50b or the IP telephone terminal <NUM> to be researched via the IMS network <NUM> or the VoIP network <NUM>, which is the destination network selected by the NGN network <NUM> for each contract carrier. At this time, the telephone number research device <NUM> adds an SDP parameter that causes call rejection on the IMS terminal 50a, 50b or the IP telephone terminal <NUM> to the SDP parameter of the INVITE request.

If the contract carrier of the IMS terminal 50a, 50b or the IP telephone terminal <NUM> to be researched is a mobile communication carrier A (step S101: carrier A), the telephone number research determination unit <NUM> receives a response to the INVITE request that has caused an SDP mismatch from the receiver IMS terminal 50a via the IMS network <NUM> of the contract carrier A and interprets it, thereby determining whether the telephone number is present or missing (step S102).

The telephone number research determination unit <NUM> determines that the telephone number is missing (step S102: missing) upon receipt of an error code <NUM> from the receiver-side IMS network <NUM> as described with reference to the sequence diagrams of <FIG>. In other words, the telephone number research determination unit <NUM> interprets a response (error code <NUM> or <NUM>) to the INVITE request received due to an SDP mismatch from the IMS network <NUM>, which is the destination network selected, to make the determination (steps S103 and S107).

If the IMS terminal 50a researched is present (step S102: present), the telephone number research determination unit <NUM> determines whether the IMS terminal 50a is available or busy (step S104). As described with reference to the sequence diagrams of <FIG>, when receiving, for example, an error code <NUM> as a response to the INVITE request due to an SDP mismatch from the IMS network <NUM>, which is the destination network selected, the telephone number research determination unit <NUM> determines that the receiver IMS terminal 50a is busy (step S104: busy) by interpreting the response (steps S105 and S107). On the other hand, when receiving a response (error code <NUM>) to the INVITE request due to an SDP mismatch, the telephone number research determination unit <NUM> determines that the receiver IMS terminal 50a is available (step S104: available) by interpreting the response (steps S106 and S107).

Regarding the usage status of the telephone number of the receiver IMS terminal 50a determined in step S107, the telephone number history generator <NUM> generates telephone number history information as in, for example, the telephone number history information layout illustrated in <FIG> based on the determination result of the telephone number research determination unit <NUM>. The telephone number history information is stored in the telephone number history DB <NUM> each time generated.

Here, the error code can be used to determine whether the destination network is an IMS or VoIP network and the usage status of the telephone number. By creating a database of information on the network determination, the information can be used for future telephone number research. The telephone number history information in the telephone number history DB <NUM> is edited in an appropriate format when accumulated for a certain period of time and is distributed for search to those who are interested as a telephone number usage status research recording medium.

If the contract carrier of the IMS terminal 50a, 50b or the IP telephone terminal <NUM> to be researched is an NGN carrier B (step S101: carrier B), the telephone number research determination unit <NUM> receives a response to the INVITE request that has caused an SDP mismatch from the receiver IMS terminal 50b via the NGN network <NUM> of the contract carrier B and interprets it, thereby determining whether the telephone number is present or missing (step S108).

The telephone number research determination unit <NUM> determines that the telephone number is missing (step S108: missing) by interpreting a response (error code <NUM> or <NUM>) to the INVITE request received due to an SDP mismatch from the NGN network <NUM>, which is the destination network selected (steps S103 and S109).

If the IMS terminal 50b researched is present (step S108: present), the telephone number research determination unit <NUM> determines whether the IMS terminal 50b is available or busy (step S110). When receiving a response (error code <NUM>) to the INVITE request due to an SDP mismatch from the NGN network <NUM>, which is the destination network selected, the telephone number research determination unit <NUM> determines that the receiver IMS terminal 50b is busy (step S110: busy) by interpreting the response (steps S111 and S113). On the other hand, when receiving a response (error code <NUM>) to the INVITE request due to an SDP mismatch, the telephone number research determination unit <NUM> determines that the receiver IMS terminal 50b is available (step S110: available) by interpreting the response (steps S112 and S113).

Regarding the usage status of the telephone number of the IMS terminal 50b determined in step S113, the telephone number history generator <NUM> generates telephone number history information as in the telephone number history information layout illustrated in <FIG> based on the determination result of the telephone number research determination unit <NUM>. The telephone number history information is stored in the telephone number history DB <NUM> each time generated. The telephone number history information in the telephone number history DB <NUM> is edited in an appropriate format when accumulated for a certain period of time and is distributed for search to those who are interested as a telephone number usage status research recording medium.

If the contract carrier of the IMS terminal 50a, 50b or the IP telephone terminal <NUM> to be researched is a VoIP carrier C (step S101: carrier C), the telephone number research determination unit <NUM> receives a response to the INVITE request that has caused an SDP mismatch from the receiver IP telephone terminal <NUM> via the VoIP network <NUM> of the contract carrier C and interprets it, thereby determining whether the telephone number is present or missing (step S114).

The telephone number research determination unit <NUM> determines that the telephone number is missing (step S114: missing) by interpreting a response (error code <NUM>) to the INVITE request received due to an SDP mismatch from the VoIP network <NUM>, which is the destination network selected (steps S117 and S121).

If the IP telephone terminal <NUM> is present (step S114: present), the telephone number research determination unit <NUM> determines whether the terminal <NUM> is available or busy (step S118). When receiving a response (error code <NUM>) to the INVITE request due to an SDP mismatch from the VoIP network <NUM>, which is the destination network selected, the telephone number research determination unit <NUM> determines that the receiver IP telephone terminal <NUM> is busy (step S118: busy) by interpreting the response (steps S119 and S121). On the other hand, when receiving a response (error code <NUM>) to the INVITE request due to an SDP mismatch, the telephone number research determination unit <NUM> determines that the receiver IP telephone terminal <NUM> is available (step S118: available) by interpreting the response (steps S120 and S121).

Regarding the usage status of the IP telephone number determined in step S121, the telephone number history generator <NUM> generates telephone number history information as in the telephone number history information layout illustrated in <FIG> based on the determination result of the telephone number research determination unit <NUM>. The telephone number history information is stored in the telephone number history DB <NUM> each time generated. The telephone number history information in the telephone number history DB <NUM> is edited in an appropriate format when accumulated for a certain period of time and is distributed for search to those who are interested as a telephone number usage status research recording medium.

Incidentally, in the case of a telephone that is assigned a telephone number in the same format as the conventional subscriber number such as a fiber-optic IP phone, it is not possible to distinguish whether the destination network is an IMS (NGN) network or a VoIP network due to local number portability (LNP). Also, parameters for SDP mismatch are different between the IMS (NGN) network and the VoIP network.

Specifically, while the IMS (NGN) network <NUM> supports both IPv4 and IPv6 network protocols, the VoIP network <NUM> supports only IPv4 and does not support IPv6. In addition, although the IMS (NGN) network <NUM> supports both audio and video media types, the VoIP network <NUM> supports only audio. Therefore, after determining the destination network to which an IP phone is connected, the telephone number research device <NUM> needs to set SDP parameters corresponding to each network.

In the following, a procedure for determining the destination network of a call to a telephone will be described in detail with reference to the flowchart of <FIG> illustrating a destination network determination procedure, assuming that the telephone is the IMS terminal 50b connected to the IMS (NGN) network <NUM> or the IP telephone terminal <NUM> connected to the VoIP network <NUM>.

In <FIG>, in the telephone number research device <NUM>, first, the message exchange controller <NUM> makes an offer or sends an INVITE request to an IP phone (the IMS terminal 50b or the IP telephone terminal <NUM>) to be researched with a first SDP parameter that conforms to an IMS (NGN) network in which, for example, IPv6 is set as the network protocol, or audio, video, and application (audio + video + application) are set as the media type (step S201). It will be assumed in this example that IPv6 is set as the network protocol.

Next, when receiving a response message (<NUM> OK + mod. SDP) as an answer to the INVITE request that contains the first SDP parameter from the destination network (step S202: YES), the message exchange controller <NUM> determines that the IP telephone terminal <NUM> is the IP phone to be researched. The message exchange controller <NUM> then transmits an INVITE request from a VoIP SIP transmitter with a second SDP parameter that conforms to a VoIP network, in which IPv4 is set as the network protocol (the media type is audio only) (step S204).

As an answer to the INVITE request sent as an offer in step S204, the telephone number research determination unit <NUM> acquires a response message through the message exchange controller <NUM>. The telephone number research determination unit <NUM> determines that the telephone number assigned to the IP telephone terminal <NUM> researched is present if the response message includes an error code <NUM>, and determines that the telephone number is missing if the response message includes an error code <NUM> (step S205).

When receiving a response message that accepts IPv6, in which the network protocol of the SDP parameter has not been converted, as an answer from the destination network (step S202: NO), the telephone number research determination unit <NUM> determines that the IMS terminal 50b is the IP phone to be researched. The telephone number research determination unit <NUM> also determines that the telephone number is present if the response message includes an error code <NUM> or <NUM>, and determines that the telephone number is missing if the response message includes an error code <NUM> (step S203).

As described above, according to the embodiment, the telephone number research device <NUM> can research the usage status of a telephone number in the IMS network <NUM> using an IMS interconnection interface or the like for interconnection between carriers. Therefore, with a SIP-based telephone number research tool having connectivity to the NGN network <NUM>, a smooth transition to the new system platform can be achieved.

Furthermore, according to the embodiment, since the IMS network <NUM> for each carrier, the destination network, is selected on the NGN network <NUM> side, the telephone number research device <NUM> can handle the mobile number portability (MNP), which allows a mobile telephone user to change from one carrier to another and keep the same phone number. As a result, unlike the case of UNI connection, connecting to a wrong network (a telephone terminal having a telephone number to be researched is connected to another network) does not occur. Thereby, the procedure of telephone number research is simplified, which reduces the load on the telephone number research device <NUM> to make a determination. In addition, the cost of capital investment can be reduced as it is sufficient to install the telephone number research device <NUM> and the line only in the NGN network <NUM>.

In the above embodiment, the telephone number research device <NUM> is described using mobile telephones such as the IMS terminals 50a, 50b and the IP telephone terminal <NUM> as examples of telephone terminals to be researched. Examples of the IP telephone terminal <NUM> include IP phones that are assigned a telephone number in the same format as conventional subscriber telephones such as metal IP phones and fiber optic phones. The telephone number research device <NUM> can accurately determine whether a telephone number is valid or invalid in research regardless of the type of IP phone and the destination network.

These telephone terminals check network protocol, media type, transport protocol of media, and codec in this order based on the description of SDP parameters in a negotiation to establish a communication session. In the NGN network, four parameters that cause call rejection can be set in this negotiation procedure as in the IMS network. By using all of the four parameters, it is possible to make an accurate determination. On the other hand, for the IP telephone terminal <NUM>, two of the parameters that cause call rejection: network protocol (IPv4) and media type (audio) are fixed, and therefore the other two: transport protocol and codec are used. In this case also, the validity can be accurately determined without using a signal that rings an incoming call on the receiver IP telephone terminal <NUM>.

There may be a case where it is not possible to distinguish whether the destination network is an IMS (NGN) network or a VoIP network due to LNP, and parameters for SDP mismatch that are sent to a telephone (the IMS terminal 50b, the IP telephone terminal <NUM>) vary depending on the destination network. In such case, the message exchange controller <NUM> adds a first SDP parameter that conforms to the NGN network <NUM>, in which IPv6 is set as the network protocol, to an INVITE request when sending the INVITE request to an IP phone to be researched, and sends the request to the IMS network <NUM> or the VoIP network <NUM>, which is the destination network for each contract carrier selected through the NGN network <NUM>. Then, the destination network to which the IP phone to be researched is connected is determined based on a response message received from the destination network. If the response message is "<NUM> OK" or the first SDP parameter has been converted, it is determined that the destination network is a VoIP network. With this, the telephone number research determination unit <NUM> determines the telephone number usage status of the IP phone based on the response message received through the message exchange controller <NUM>. Thus, according to the embodiment, the telephone number research device <NUM> can perform accurate verification regardless of the destination network.

As described above, according to the embodiment, the telephone number research device <NUM> can accurately determine whether the telephone numbers of the IMS terminals 50a, 50b and the IP telephone terminal <NUM> are in service (valid (present)), not in service (invalid (missing)), or has been changed. Also, if a call does not reach the destination, it is possible to completely stop some billing that may have occurred so far. In addition, a tool is provided that can store the determination result together with the determination date and time in a recording medium (the telephone number history DB <NUM>). For example, as in the example data structure illustrated in <FIG>, the recording medium may store the determination result, information on a new telephone number linked to the old one, and the determination date and time for each telephone number researched.

According to an embodiment, for example, a program can realize the telephone number research device <NUM> that, as illustrated in <FIG>, establishes a connection to a telephone (the IMS terminal 50b, the IP telephone terminal <NUM>) connected to the IMS (NGN) network <NUM> or the VoIP network <NUM> via the NGN network <NUM>.

For example, as illustrated in <FIG> and <FIG>, the program may cause a computer (the telephone number research device <NUM>) to perform at least the following steps: adding a first SDP parameter to an INVITE request for a telephone to be researched and sending it to the destination network selected by the NGN network (step S201), receiving a first response message that contains the first SDP parameter from the destination network (step S202), determining the usage status of the telephone number of the telephone based on the first response message (steps S203 to S205), wherein the first SDP parameter includes at least an IPv6 network protocol, and it is determined that the destination network is a VoIP network when the first response message is "<NUM> OK" or the network protocol of the first SDP parameter has been converted, while it is determined that the destination network is an IMS network when the first SDP parameter of the first response message has not been converted and the response message includes a first error code (error <NUM>) (step S202).

According to the embodiment, the program, which includes instructions that are fetched sequentially from a memory (not illustrated) and executed on the telephone number research device <NUM>, enables research on the usage status of a telephone number in the IMS network <NUM> using an IMS interconnection interface or the like for interconnection between carriers. Therefore, with a SIP-based telephone number research tool having connectivity to the NGN network <NUM>, a smooth transition to the new system platform can be achieved. In particular, the telephone number usage status of a telephone (the IMS terminal 50b or the IP telephone terminal <NUM>) can be determined regardless of the type of the destination network (the IMS (NGN) network <NUM>, the VoIP network <NUM>).

<FIG> is a diagram illustrating the configuration of a telephone number research information provision system <NUM> according to an embodiment. As illustrated in <FIG>, the telephone number research information provision system <NUM> of the embodiment includes one or more user terminals <NUM> and a telephone number research server (the telephone number research device <NUM> in <FIG>) that is connected to the user terminals <NUM> via an IP network <NUM>. The server is also connected to another network (not illustrated).

Upon receipt of a request for information on telephone number research based on a target telephone number from the user terminal <NUM> via the IP network <NUM>, the telephone number research server <NUM> adds a first SDP parameter to an INVITE request for a telephone to be researched (the IMS terminal 50b, the IP telephone terminal <NUM>) and sends the INVITE request to the IMS network <NUM> or the VoIP network <NUM>, which is the destination network for each contract carrier of the telephone selected through the NGN network <NUM>. Having received a response message from the destination network, the telephone number research server <NUM> determines that the destination network is a VoIP network when the response message is "<NUM> OK" or the first SDP parameter has been converted. On the other hand, if the first SDP parameter of the response message has not been converted and the response message includes a first error code (error <NUM>), the telephone number research server <NUM> determines that the destination network is an IMS network. Then, the telephone number research server <NUM> determines the telephone number usage status of the telephone based on the received response message, and sends the determination result to the user terminal <NUM> that has requested the telephone number research information via the IP network <NUM>. For this purpose, the telephone number research server <NUM> has a function of providing the user terminal <NUM> with information on the telephone number usage status of a telephone terminal determined by the telephone number research determination unit <NUM> in response to a telephone number research information request for the telephone terminal received from the user terminal <NUM> through the network interface unit <NUM> illustrated in <FIG>.

At this time, in response to a request for information on telephone number research based on a target telephone number from the user terminal <NUM> via the IP network <NUM>, the telephone number research server <NUM> refers to a recording medium (the telephone number history DB <NUM>) that stores telephone number research information consisting of determination results that are each assigned a timestamp indicating the determination date and time and recorded in chronological order. Thereby, the telephone number research server <NUM> sends the telephone number research information to the user terminal <NUM> that has requested the information via the IP network <NUM>.

The telephone number research information recording medium (the telephone number history DB <NUM>) may be distributed independently to users who need it. The recording medium (the telephone number history DB <NUM>) is created by the telephone number research device <NUM> that is connected to a telecommunications carrier network via a dedicated line to record information on the presence or absence of target telephone numbers. The recording medium may be used for search on a system where it is distributed.

The telephone number research information recording medium (the telephone number history DB <NUM>) stores a collection of determination results as to the usage status or validity of telephone numbers of telephone terminals on the receiver side. For example, the recording medium has a data structure as illustrated in <FIG>, in which determination results are each assigned a timestamp indicating the determination date and time and recorded in chronological order. The database need not necessarily be distributed on a recording medium such as DVD and hard disk, it may also be distributed via a communication line.

According to the embodiment, the telephone number research device <NUM> determines whether a telephone number is in service (valid (present)), not in service (invalid (missing)), or has been changed (in a state where voicemail announces a new phone number), and the telephone number research information provision system <NUM> can provide the information to a user who needs it. In addition, the telephone number research information recording medium (the telephone number history DB <NUM>) may be distributed to users who need it so that they can utilize it for, for example, evaluating creditworthiness or the like.

Claim 1:
A telephone number research device (<NUM>) configured to be connected via a next-generation network, NGN, (<NUM>) to a telephone (50a, 50b, <NUM>) connected to at least a destination network that is an IP multimedia subsystem, IMS, network (<NUM>) that supports IPv6 or a voice over IP, VoIP, network (<NUM>) that does not support IPv6, the device (<NUM>) comprising:
a message exchange controller (<NUM>) configured to add a first session description protocol, SDP, parameter to an INVITE request for the telephone (50a, 50b, <NUM>) to be researched, send the INVITE request to the destination network selected by the NGN (<NUM>), and receive a first response message from the destination network; and
a telephone number research determination unit (<NUM>) configured to determine a usage status of a telephone number of the telephone (50a, 50b, <NUM>) based on the first response message,
wherein
the first SDP parameter includes at least an IPv6 network protocol,
a session border controller, SBC, (<NUM>) has a function to convert the IPv6 network protocol to an IPv4 network protocol suitable for the destination network when the first SDP parameter is sent from the NGN (<NUM>) to the destination network,
characterized in that the message exchange controller (<NUM>) is further configured to:
determine whether the first SDP parameter has been converted based on a description of the first SDP parameter,
determine that the destination network is the VoIP network (<NUM>) when the first response message is "<NUM> OK" and the first SDP parameter has been converted, and
determine that the destination network is the IMS network (<NUM>) when the first SDP parameter has not been converted and the first response message includes a first error code, wherein the first error code is error code <NUM>.