KR20060124890A - A method for providing message transmission service among different type messengers and computer-readable medium recorded the program thereof - Google Patents

Abstract

A method for offering a message transmission service among different messengers and a recording medium storing a program thereof are provided to realize communication among the messengers without respect to the number of different messengers, and request chatting and exchange a message even if a counterpart logs in to any messenger program by checking a login/logout status of the counterpart. In case that a login request is received from the messenger of the first user, login to a bridge server is provided by using a unique ID of the first user and an ID of the messenger(S200). A buddy list and presence information for identifying the login/logout status are provided to the messenger of the first user by searching the buddy list of the first user in the bridge server based on the unique ID of the first user(S210). If a chatting request signal for the second user in the login status is detected, the chatting request signal is transmitted to the messenger of the second user by using the unique ID of the second user(S220). A chatting window between the first and second user is provided based on a chatting response signal received from the messenger of the second user.

Description

A method for providing message transmission service among different type messengers and computer-readable medium recorded the program approximately}

1 is a block diagram showing the configuration of a general messenger server.

2 is a schematic diagram showing the configuration of a message transfer system between heterogeneous messengers according to an embodiment of the present invention.

3 is a block diagram showing a detailed configuration of a client system according to an embodiment of the present invention.

4 is a block diagram showing the configuration of a bridge server according to an embodiment of the present invention.

5 is a signal flow diagram illustrating an SM agent installation method according to an embodiment of the present invention.

6 is a signal flow diagram illustrating a login information and a message transmission / reception providing method between heterogeneous messengers according to an exemplary embodiment of the present invention.

7 is a flowchart illustrating an operation of installing and configuring an SM agent according to an embodiment of the present invention.

8 is a view showing a login method of a messenger equipped with an SM agent according to an embodiment of the present invention.

9 is a diagram illustrating a login state of a messenger equipped with an SM agent and a method of adding a buddy according to an embodiment of the present invention.

10 illustrates a scene of requesting a conversation from a buddy using heterogeneous messengers according to an embodiment of the present invention.

11 is a diagram illustrating an SM agent providing a chat window according to an embodiment of the present invention.

12 is a diagram illustrating message transmission and reception using an SM agent according to an embodiment of the present invention.

The present invention relates to a system capable of transmitting a message between heterogeneous messengers and a service method thereof.

More specifically, the present invention relates to a system capable of checking whether a user logs in and transmitting and receiving messages between messenger clients provided by different service providers, and a service method thereof.

With the development of the network, in order to communicate between remote locations, a messenger program for transmitting only a simple text along with e-mail has been in the spotlight. The messenger program can check the log in / off state of the other party, and has a merit of real-time communication, which is widely used in a communication service using the Internet.

Currently, the messenger program provides not only text transmission but also various functions such as URL transmission, group chat, file transmission, and additional information such as stocks, traffic, weather, games, wired / wireless interworking services, voice chat, and video chat. Additional service functions are integrated into one messenger program to provide various functions.

On the other hand, these messenger programs, which are distributed on Internet portal sites or community sites, have been developed and distributed competitively to strengthen communication between members and attract members, providing better value-added services to messenger users.

The distribution of these various upgraded messenger programs has the advantage of meeting various demands of users, but as the messenger programs residing in the RAM of the client's computer increase, the function of the client's computer is affected. There has been a problem that may result in.

In addition, when a friend (hereinafter referred to as a buddy) registered in his or her messenger is present in a plurality of messengers, the messenger user must drive heterogeneous messengers according to the buddy, thus weakening the mutual communication function of the messenger. Causing problems.

In other words, the messenger programs provided by various service companies have different protocols and do not share member information. As a result, the messenger service has a weakened communication function as the messenger program increases.

On the other hand, in Korean Patent Laid-Open No. 2001-10643, in order to provide a communication service between heterogeneous messengers, one messenger server A is registered with a heterogeneous messenger server B as a client, and thus, a client of a heterogeneous messenger server B. Disclosed is a technique for sending a message to a user.

However, in the related art, when a messenger server is registered as a client, a compatible heterogeneous messenger program has a problem in that the number is limited. When the messenger server A is registered as a client of another messenger B, the messenger B There is a problem that overloads).

The present invention provides a messenger service method capable of providing data transmission and reception between a plurality of heterogeneous messengers, and a recording medium on which the program is recorded, in order to solve the problems of the prior art described above.

In addition, the present invention can communicate with each other irrespective of the number of heterogeneous messenger, and check the log-in / log-out state of the other party messenger service method and message exchange, even if you are logged in to any messenger program and message exchange and its recording medium To provide.

In order to achieve the above technical problem, a method of providing a messenger service according to an aspect of the present invention includes: a) providing a login to a bridge server using a unique ID for uniquely identifying a first user; b) retrieving the buddy list of the first user from the bridge server based on the unique ID of the first user, and providing presence information identifying the login / out status together with the buddy list to the messenger of the first user; step; c) transmitting a chat request signal to a messenger of the second user through a unique ID of the second user when a chat request signal for a second user who is logged in of the buddy list is detected; And d) providing a chat window between the first user and the second user based on the chat request response signal of the messenger of the second user.

In addition, a program for providing a messenger service stored in a recording medium according to an aspect of the present invention includes: a) a function of accessing a bridge server using a unique ID uniquely identifying a first user; b) downloading the buddy list information of the first user and displaying the buddy list and the login / out status for at least one messenger; c) a function of transmitting a chat request signal for a messenger ID of the buddy to the bridge server when a chat request is made with a buddy in the buddy list and activating a chat window; d) a function of receiving a messenger ID and message information of the buddy transmitted from the bridge server and outputting the message to the chat window.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention.

In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention. Like parts are designated by like reference numerals throughout the specification. (When a part is connected to another part, this includes not only a directly connected part but also an electrically connected part with another element in between.)

A messenger service system and method according to an embodiment of the present invention will now be described in detail with reference to the accompanying drawings.

1 is a block diagram showing the configuration of a general messenger server.

The messenger server 20 includes a gateway server 21, a central message server group 22, an insert message server group 23, an application server group 24, a database 27, a web server 26, an XML server ( 25).

In order to receive a messenger service using the messenger server 20, a messenger client following the protocol of the messenger server 20 must be installed in a PC 10.

The messenger client accesses the gateway server 21 and receives a central message server (CMS) from the central message server group 22 to establish a connection. When a messenger client connects to a central message server assigned by the gateway server 21 from the central message server group 22 and wishes to have a conversation with another messenger client, the central message server is one of the instant message server groups 23. You will assign one instant message server (IMS).

That is, the main body of the messenger client maintains a connection with the central message server, and the chat window of the messenger establishes a connection with the instant message server.

Here, the user of another messenger client who has received a chat request accesses the central message server assigned by the gateway server 21, and the central message server informs the instant message server to which the user messenger client who has applied for chat is connected. You will be connected to the instant message server.

Thus, the central message server group 22 will share in real time a list of all connected users. Here, messenger users send and receive messages through socket connections.

In this case, the application server group 24 performs a function of supporting a central message server and an application program required for instant messaging, and the XML server 25 provides another online supplementary service in a messenger client.

The web server 26 provides a web page to which a messenger user can subscribe and download a messenger client, and the database 27 stores relevant data and user information for providing a messenger function.

The block diagram shown in FIG. 1 may be applied to an embodiment of the present invention as a general architecture for providing a messenger service. In the architecture shown in FIG. It can be obvious.

2 is a schematic diagram showing the configuration of a message transfer system between heterogeneous messengers according to an embodiment of the present invention.

Message transmission system according to an embodiment of the present invention includes a client system (100a, 100b) using a different messenger, a unique ID issuing server 200, a bridge server group 300.

The client system 100a includes a first messenger client 110a and a static messenger agent 120a (hereinafter referred to as an SM agent).

Here, the SM agents 120a and 120b are agents provided by the bridge server group 300 and are plugged into a messenger or used as a client user's request. The SM agents 120a and 120b perform operations for message transmission between heterogeneous messenger clients. . Here, the first messenger client 110a is a different kind of client program from the second messenger client 110b of the client system 110b.

Specific functions of the SM agents 120a and 120b will be described later.

The unique ID issuing server 200 provides a unique ID capable of authenticating the user of the client system in all services on the Internet in response to a unique ID request from the user of the client system. The unique ID may authenticate a user by a public key authentication method or a private key grant method. Hereinafter, a unique identifier that can authenticate the identity of a user of a client system on the Internet is referred to as a "unique ID". Here, the "unique ID" includes an identifier in the form of a certificate that cannot be identified externally.

Here, the SM agent 120a manages a messenger client based on the unique ID and controls message transmission and reception with the bridge server group 300. Here, the SM agents 120a and 120b store IDs of a plurality of messenger clients based on the unique IDs, and transmit and store a buddy list of client systems to the bridge server group. The SM agent 120a is automatically activated when the client computer is started in the form of a RAM resident program, and is activated only when the authentication is performed by accessing a bridge server or by inputting a secret key corresponding to a unique ID. It can be driven in one of the forms.

The bridge server group 300 includes a plurality of bridge servers, matches and stores the IDs of the messengers subscribed by the unique IDs transmitted from the SM agent, and also takes a buddy list for each messenger and reconfigures it into an integrated list. Save it.

When a messenger service request is received from the SM agent 120a, a unique ID of the receiver is retrieved based on the reconfigured buddy list to provide a messenger service with a client system on which another SM agent 120b is installed.

The bridge server group 300 stores information on a unique ID, a buddy ID list, and a messenger client in the databases 310, 311, and 312 in order to perform the above-described operation.

By the above-described configuration, the user of the client system (100a) is a bridge server that collects a buddy list according to the unique ID information in the state that the SM agent 120a is activated by resetting the buddy relationship between the heterogeneous messenger, the SM The agent 120a is provided with a login / off state. That is, by collecting the other party's messenger type and messenger ID information and tracking the other party's unique ID, the type of the messenger currently logged in and the messenger ID can be known, and the bridge server transfers the login status information back to the SM agent. And providing the login status information so that the user of the client system 100a uses the messenger ID of the heterogeneous messenger as the target ID, even when the other party logs in to a messenger different from the messenger used by the client system 100a. To attempt a conversation.

According to the above-described configuration of the present invention, even if the messenger used is different, when the messenger type and the messenger ID are reset based on a unique ID capable of identifying a user as a single ID, login status information and a message can be transmitted and received between heterogeneous messengers. I was focused on that.

3 is a block diagram showing a detailed configuration of a client system according to an embodiment of the present invention.

The messenger client 110a may include a plurality of messenger client programs 111a, 112a, and 113a different from each other. Here, the messenger ID used in each messenger client program may be different from ID A, ID B, and ID C, respectively. However, the plurality of messenger IDs all match a single unique ID.

The SM agent 120a includes a messenger ID table 121a, a buddy list collecting module 122a, and an active control module 123a.

Here, the messenger ID table 121a stores a unique ID of the user of the client system and a plurality of messenger IDs of the user. The plurality of messenger IDs may be directly input by the user after activating the SM agent. The information stored in the messenger ID table 121a is transmitted to the bridge server group 300 to share the information with the bridge server.

The buddy list collection module 122a collects and stores buddy IDs set by a plurality of messenger programs installed in the client system. Here, each messenger client program list can be obtained by using an API of an OS such as Windows.

The collected buddy list information matches and stores the buddy ID of the messenger client program corresponding to each messenger client program identifier. For example, in the table showing the information stored in the buddy list collecting module in FIG. 3, the buddy IDs of the messenger client program 111a are ID A1, ID A2, and ID A3, and the buddy ID of the messenger client program 112a is ID. B1, ID B2, and ID B3.

The unique ID, the messenger ID or the messenger client program, and the buddy list may sequentially form a tree structure diagram. The ID information and the diagram information are transmitted to and stored in the bridge server.

Meanwhile, a separate user interface of the SM agent may be provided so that a user may directly register a buddy ID and register it with the bridge server.

The activation control module 123a activates the SM agent 120a to control interworking with each messenger program. When the SM agent 120a is activated, communication using each messenger communicates through the mode bridge server group 300 and informs the login / off state of the counterpart in which the SM agent is installed.

4 is a block diagram showing the configuration of a bridge server according to an embodiment of the present invention.

Bridge server 300 according to an embodiment of the present invention is the interface unit 301, unique ID authentication unit 302, SM agent providing unit 303, unique ID search unit 304, ID information collection unit 305 , ID information mapping unit 306, login processing unit 307, message analysis unit 308, message processing unit 309, unique ID database 310, buddy ID database 311, and messenger information database 312. do.

The interface unit 301 provides a communication interface for authentication, connection request, conversation request, message transmission and reception, etc. from the client systems 100a and 100b.

The unique ID authentication unit 302 authenticates the user with respect to the client system attempting to connect using the SM agent or the client system requesting to provide the SM agent. The authentication may be performed using a public key or a private key corresponding to the issued unique ID.

The SM agent providing unit 303 performs a function of providing a SM agent program to the client system when requesting to download the SM agent from the client system.

The ID information collecting unit 305 collects information regarding IDs, such as a unique ID, a messenger ID, and a buddy ID, which are transmitted from a client system having an SM agent installed.

The ID information mapping unit 306 maps the unique ID, the messenger ID, and the buddy ID to each other so as to enable data communication between heterogeneous messengers, and stores them in a database. That is, a plurality of messenger IDs for one unique ID are stored, and messenger information and a buddy list are stored in correspondence with one unique ID, and in the future, a buddy corresponding to a messenger ID existing in the buddy list is stored. Map each user's unique ID.

The login processing unit 307 establishes a socket connection with the client system logged into the bridge server using the SM agent, and stores login status information. The login status information is provided to other messenger users as buddy connection status information.

In this case, the unique ID search unit 304 searches for a unique ID corresponding to the messenger ID or the buddy ID stored in the unique ID database 310 or the buddy ID database 311 or performs a reverse function thereof. Accordingly, the login processing unit 307 retrieves a messenger ID for the unique ID of the user of the client system which has logged in, and notifies the messenger of another client system which has designated the retrieved messenger ID as a buddy.

The message analyzer 308 analyzes a user ID such as a unique ID or a messenger ID attached to a message received from a client system, and adds a unique ID or a messenger ID to enable data transmission and reception between heterogeneous messengers. A detailed processing method of the user identifier will be described later.

The message processing unit 309 processes message transmission / reception so that a conversation function of a messenger can be performed between two or more messenger client clients. The detailed configuration of the message processing unit 309 is not significantly different from the general messenger configuration shown in FIG.

Meanwhile, the bridge server group 300 includes a unique ID database 310 storing unique ID information of users who provided an SM agent, a buddy ID database 311 storing buddy IDs for each user, and information on a messenger program. A stored messenger information database 312 is included, and as described above, the mapping relationship between the unique ID, the messenger ID, the messenger program, and the buddy list is used.

According to the above-described configuration, even when each of the client systems using the SM agent is logged in using heterogeneous messengers, the login status can be checked using a matching relationship between the user's unique ID, the messenger ID, and the buddy list. Even when selecting a messenger ID of a heterogeneous messenger and requesting a conversation, the conversation window can be provided with a unique ID.

5 is a signal flow diagram illustrating a method for installing an SM agent according to an embodiment of the present invention.

The client system 100a having the messenger client requests the unique ID issuing server 200 to issue a unique ID, and the unique ID issuing server 200 issues a unique ID to the client system 100a in response to the request. (S100, S110).

Here, the unique ID is an identifier for authenticating the user of the client system, and includes not only an identifier of a number-letter combination but also a public certificate that can be installed on the client system. That is, when the public certificate is issued as a unique ID, transmitting the unique ID may be interpreted as an authentication using the public certificate.

Meanwhile, the client system granted the unique ID transmits the unique ID to the bridge server 300 and requests an SM agent (S120). When the user authentication is completed through the unique ID, the bridge server 300 stores the unique ID information and provides a corresponding SM agent to the client system.

On the other hand, the SM agent is installed in the client system, and collects the messenger ID information and buddy information of the installed client system (S140, S150). The SM agent may be installed as a separate program, resident in RAM when the client system is driven, or installed in a plurality of messenger programs in a plug-in state to be driven together.

The messenger ID information of the client system activates the SM agent, the user directly inputs the messenger ID in correspondence with the type of the messenger, and the buddy information may be collected using the Windows API.

In step S160, the SM agent transmits the collected messenger ID and buddy list information to the bridge server. The source of the messenger ID and the buddy list information may be identified based on the unique ID described above.

When the messenger ID buddy list is transmitted, the bridge server 300 maps the messenger ID and the buddy information stored for each unique ID (S170). For example, a relationship between a unique ID and a messenger ID and a buddy list is set, where a relationship between a buddy list and a buddy's messenger ID and a buddy's unique ID is mapped. Therefore, when the bridge server 300 knows the end of the messenger and the messenger ID, the bridge server 300 performs matching between users of the client system using a mapping relationship with the unique ID.

6 is a signal flow diagram illustrating a login information and a message transmission / reception providing method between heterogeneous messengers according to an exemplary embodiment of the present invention.

In the state where mapping between the messenger ID and the unique ID is completed by the method illustrated in FIG. 5, the client system 100a activates the SM agent and attempts to log in (S200). At this time, the authorized user identifier of the client system 100a is a unique ID, and the first messenger type and the user identifier of the first messenger who attempted to log in are defined as ID A and transmitted to the bridge server. The above-described unique ID is transmitted through an authentication procedure with the bridge server, and the ID A can be known when attempting to log in using a specific messenger. Here, the specific messenger and the messenger ID are registered in advance by the SM agent.

The bridge server 300 searches for a related buddy list by using the unique ID of the transmitted client system 300 (S210). Here, the buddy list includes all buddy IDs associated with the unique IDs regardless of the type of the first messenger.

If the client system 100a searches for a second messenger ID 2 different from the first messenger logged in and ID B1, which is a second messenger ID, as a buddy, the bridge server 300 may identify a unique ID for the ID B2 (here, for convenience). Unique ID B1). Then, ID A information is transmitted with the unique ID B2 as a target (S220).

Here, the SM agent of the client system 100b receives the login notification signal and provides the second messenger with login information indicating that the client system 100a is logging in to the first messenger using the first messenger ID through the ID A. Done.

Through the above-described process, the client system 100b on which the second messenger and the SM agent are installed registers the client system 100a as a buddy logged in on the second messenger (S230). Here, the first messenger ID of the user of the client system 100a is activated as a target ID to which the client system 100b requests a conversation.

When the user of the client system 100b requests message transmission with the user of the client system 100a, the ID as a target ID together with the unique ID B1 and the second messenger ID (ID B1) information of the user of the client system 100b. A and the message information are transmitted together to the bridge server (S240).

In response to the message transmission request, the bridge server 300 retrieves the unique ID of the client system 100a based on the ID A, and retrieves the messenger ID B1, the messenger ID A, and the message using the unique ID of the receiver. Transmission to the SM agent (S260).

The SM agent, the client system (100a) checks the unique ID of the receiver, and identifies the message sender through ID B1. In addition, the message is output on the first messenger through the messenger ID A transmitted.

The establishment of a chat room and a socket connection for transmitting the above-described message may be made through the configuration of the general messenger server illustrated in FIG.

7 is a flowchart illustrating a method for setting an SM agent according to an embodiment of the present invention.

As described above, the user of the client system receives a unique ID and stores it in the form of a certificate in the client system, and downloads and installs the SM agent using the unique ID in the client system (S300 and S310).

On the other hand, the SM agent may be set for driving at installation (S320). The configuration for the SM agent is to select whether or not to automatically run the SM agent upon startup to the client system, and whether to register the ID of the type of the messenger to be linked with the SM agent.

In step S330, it is set whether to use a secret key (or private key) for use of a certificate corresponding to the unique ID. If the user selects to input the secret key, the SM agent is driven only when authentication is completed by inputting the secret key (S331). In this case, when omitting the secret key, the SM agent is automatically started when the client system is started to connect to the bridge server.

In step S340, it is selected whether to manually register the IDs of the plurality of messengers to be used by the client user. If manual registration is selected here, the user can directly input the ID of the messenger to be used for the messenger service using the bridge server and register it with the bridge server (S341).

On the other hand, if the manual registration of the messenger ID is omitted, the bridge server does not perform the process of checking whether the unique ID and the messenger ID transmitted in the messenger login process are registered in advance.

When the above-described setting process of the SM agent is completed, a login is performed by using the first messenger of one of the plurality of messengers (S350). In this case, the SM agent is already running in the form of a RAM resident and is executing a connection to the bridge server. When the login of the first messenger is attempted, the SM agent monitors the messenger login request packet, extracts the first messenger included in the login request packet, and transmits the first messenger to the bridge server in pairs with a unique ID (S360).

The bridge server performs login processing using the received unique ID and the messenger ID. If the manually registered messenger ID performed in step S341 and the first messenger ID transmitted do not match, the bridge server may reject the login process and transmit a notification message to the SM agent.

8 is a view illustrating a login scene of a messenger equipped with an SM agent according to an embodiment of the present invention.

FIG. 8 illustrates a configuration in which the SM agent logs the messenger into the bridge server even when the ID "Naverkim" 513 of the first messenger is input into the normal login window 512.

Although FIG. 8 follows the normal messenger login method, since the SM agent is already driven and the connection with the bridge server is already established, the login to the bridge server is performed through the SM agent as the login of the general messenger. Here, the "integrated connection" menu shown in FIG. 7 is not necessarily displayed externally.

As described above, since the SM agent is plugged into the messenger program or resides in RAM, the SM agent detects a login process of a normal messenger program and can connect to the bridge server without inputting a unique ID.

In the scheme illustrated in FIG. 8, a certificate associated with a unique ID may be installed in the user client system to automatically perform authentication with the bridge server.

As described above, the SM agent may be performed by the SM agent auditing the messenger login packet and transmitting the unique ID to the bridge server together with the first messenger ID (NaverKim) included in the messenger login packet.

When the authentication is completed, the SM agent and the first messenger 500 log in with the bridge server, and receive the login state (hereinafter referred to as presence) information of the buddy from the bridge server.

9 is a diagram illustrating a login state of a messenger equipped with an SM agent according to an embodiment of the present invention.

When the login is completed, the presence information regarding the buddy connected to the heterogeneous messenger is transmitted from the bridge server as described above. The SM agent of the present invention shows the type of messenger to which each user is connected and the login status based on a unique ID uniquely identifying the user.

That is, even if the messenger used is different, even if the same user is connected to the messenger, the SM agent provides the presence information along with the messenger information used and enables the conversation.

As described above, when the buddy and the presence information are added by the heterogeneous messenger, the SM agent may collect and map them, but may also add the SM agent in the activated state.

When adding a buddy, the SM agent provides a buddy add window 520 having fields for inputting a messenger type and a messenger ID. In the embodiment of the present invention, it is possible to select a messenger that can be supported through the messenger type field. However, since a typical messenger ID includes information on the messenger and the ID to be used, such as an E-mail address, the messenger ID is inputted at the same time. The method is also applicable.

In FIG. 9, when the messenger type is selected as "nate" and the messenger ID as "Mirae", the SM agent transmits the buddy information to the bridge server and the bridge server searches for a unique ID based on the messenger ID. Then, the presence information of the desired buddy is retrieved and provided to the messenger 500.

As described above, since the SM agent can collect a buddy list using the API of the operating system as described above, a buddy can be added by using a normal messenger in addition to adding a buddy while performing an integrated connection as shown in FIG. .

10 illustrates a scene of requesting a conversation from a buddy using heterogeneous messengers according to an embodiment of the present invention.

When the target ID "Mirae (@ nate.com)" of the partner connected online is clicked through the above-described process, the messenger ID information is transmitted to the bridge server, and the bridge server transmits the "Mirae (@nate. com) "to retrieve the unique ID.

10 is a diagram illustrating an SM agent providing a chat window according to an embodiment of the present invention.

For example, if the unique ID mapped to "Mirae (@ nate.com)" is "UniqueMirae", a chat request is sent to the user corresponding to the UniqueMirae, and the instant server provides the chat window 600.

In this case, a user of UniqueMirae uses a dialog request window 710 in a popup form, for example, information regarding the ID of the first messenger, for example, "A chat request from Naverkim of Naver messenger." Is provided.

By clicking the chat request window 710, the chat window 700 of the second messenger of the other party is generated. The chat windows 600 and 700 may provide information of a messenger to which the other party is connected during the chat.

11 is a diagram illustrating message transmission and reception using an SM agent according to an embodiment of the present invention.

In the case of inputting a message by inputting a message using the chat window 700 of the second messenger, the message is provided to the chat window 600 through the bridge server.

The message transmits the target ID along with the message ID of the counterpart's messenger ID information and the sender's messenger information and the unique ID. The bridge server searches for the unique ID corresponding to the target ID and transmits the message data together with the sender's messenger information.

Through the above-described process, the chat message can be exchanged between the chat window 600 and the chat window 700.

Although the preferred embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

By the above-described configuration, the present invention can provide a messenger service capable of transmitting and receiving messages even between heterogeneous messengers.

Also, by checking the login status among different messengers, there is an effect that a conversation can be performed immediately by selecting a target ID as if one messenger is used without any manipulation between different messengers.

Accordingly, the present invention can overcome the limitation of communication due to the increase in the type of messenger, and has a remarkable effect of reducing the memory resources of the user client and providing activation of the communication.

Claims (10)

In the messenger service providing method between heterogeneous messengers, a) providing a login to a bridge server using a unique ID uniquely identifying the first user and an ID of the messenger when a first user's login request is requested; b) retrieving the buddy list of the first user from the bridge server based on the unique ID of the first user, and providing presence information identifying the login / out status together with the buddy list to the messenger of the first user; step; c) transmitting a chat request signal to a messenger of the second user through a unique ID of the second user when a chat request signal for a second user who is logged in of the buddy list is detected; d) providing a chat window between the first user and the second user based on the chat request response signal of the messenger of the second user; Messenger service providing method comprising a. The method of claim 1, And in the step a), when logging in, inputting a first user messenger ID and a password, detecting the first user messenger ID and providing the first messenger ID to the bridge server together with the unique ID. The method of claim 1, Step b), The presence information is a messenger service providing method for displaying the ID and nickname information on the messenger of the first user for each messenger used by the buddy. The method of claim 1, Step c) is The conversation request signal is a messenger service providing method of providing a messenger information of a first user and a messenger ID thereof in a pop-up form to a client system of a second user. The method of claim 1, Step d) is, A method for providing a messenger service, which displays information on a messenger program currently used by a counterpart along with a message in a first user dialog and a second user dialog. A computer-readable recording medium having recorded thereon a program providing a messenger service between heterogeneous messengers, a) accessing the bridge server using a unique ID that uniquely identifies the first user; b) downloading the buddy list information of the first user and displaying the buddy list and the login / out status for at least one messenger; c) a function of transmitting a chat request signal for a messenger ID of the buddy to the bridge server when a chat request is made with a buddy in the buddy list and activating a chat window; d) a function of receiving a messenger ID and message information of the buddy transmitted from the bridge server and outputting the message to the chat window; The computer-readable recording medium having the program recorded thereon. The method of claim 6, The program is a computer-readable recording medium installed in the form of a RAM-resident program. The method of claim 6, The program is a computer-readable recording medium that is installed as a plug-in to any messenger program. The method according to claim 7 or 8, The function a) is a computer-readable recording medium triggered when a messenger login is attempted by inputting a messenger ID and password. The method according to claim 7 or 8, e) a function of outputting messenger information and ID information included in data transmitted from the unique ID to a target; And f) outputting a message included in the transmission data together with the messenger information and ID information; The computer-readable recording medium further comprising a.

Images