WO2005096550A1 - Procede de creation d'une petite fenetre du cote client dans le reseau intelligent de donnees a large bande - Google Patents

Procede de creation d'une petite fenetre du cote client dans le reseau intelligent de donnees a large bande Download PDF

Info

Publication number
WO2005096550A1
WO2005096550A1 PCT/CN2005/000374 CN2005000374W WO2005096550A1 WO 2005096550 A1 WO2005096550 A1 WO 2005096550A1 CN 2005000374 W CN2005000374 W CN 2005000374W WO 2005096550 A1 WO2005096550 A1 WO 2005096550A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
module
portal server
handshake
message
Prior art date
Application number
PCT/CN2005/000374
Other languages
English (en)
French (fr)
Inventor
Yue Wang
Dongdong Hou
Yang Lou
Huachun Zhai
Chao Zhou
Chengfang Zhu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP05738138A priority Critical patent/EP1732267B1/en
Priority to AT05738138T priority patent/ATE456888T1/de
Priority to DE602005019141T priority patent/DE602005019141D1/de
Publication of WO2005096550A1 publication Critical patent/WO2005096550A1/zh
Priority to US11/510,177 priority patent/US7788320B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2869—Operational details of access network equipments
    • H04L12/2878—Access multiplexer, e.g. DSLAM
    • H04L12/2879—Access multiplexer, e.g. DSLAM characterised by the network type on the uplink side, i.e. towards the service provider network
    • H04L12/2881—IP/Ethernet DSLAM

Definitions

  • the present invention relates to a broadband data intelligent network technology, and in particular, to a method for implementing a small client window in a broadband data intelligent network.
  • broadband data intelligent networks can provide users with rich services, such as broadband Internet access services, portal services, and so on.
  • FIG. 1 shows the basic structure of the existing broadband data intelligent network.
  • the broadband data intelligent network includes an integrated service control center (ISCC), a broadband service access device (BRAS) s portal server, a database, and so on.
  • the BRAS is connected to both the ISCC and the portal server, and the portal server is connected to the database.
  • the BRAS is used to establish a data link between the user client and the portal server.
  • the ISCC is equivalent to a service control point in the intelligent network, which is used to control user authentication, accounting, and authorization operations.
  • the database is used to store the portal server. The data needed.
  • a small window is set on the human-computer interaction interface of the user, for example, a small window is set on the computer display screen.
  • the user's access information is displayed in a small window, such as the user's online time and access user name.
  • operation buttons for users to access the broadband data network or disconnect the broadband data network that is, operation buttons such as login or offline.
  • the user can control the use of their own data services by operating the buttons in the small window.
  • the timing handshake between the portal server and the small window is generally used.
  • Mechanism to proceed When the user cannot use the data service due to the abnormal network interruption, because the browser timing window cannot send a handshake message, the portal server can set the user's online status to offline and send a offline message to the BRAS after detecting the handshake timeout. This can avoid the problem that the network side still charges the user due to the network interruption that prevents the user from using the data service.
  • the handshake mechanism between the small window and the portal server is also implemented through the heartbeat function of the browser.
  • the small window of the client is often closed on the display or replaced by another page due to the abnormal operation of the browser.
  • the user cannot see the small window, and therefore cannot take the initiative to go offline. If the user wants to go offline actively, he must log in to the portal server again and be authenticated, so that a small window will appear again on the client, and then the user can click the offline button to actively disconnect from the broadband network. Obviously, this will cause great inconvenience to users.
  • the existing portal server uses some inherent mechanisms of the browser. This process is complicated and the function is unstable. In addition, when there are many browser versions, the processing of the portal server is also prone to errors.
  • the main object of the present invention is to provide an implementation in a broadband data intelligent network.
  • a method of a small window on a client side which can solve the problem of inconvenience of a user in using data services in the prior art.
  • a method for implementing a small window of a client in a broadband data intelligent network includes: a. Setting a first module and a second module in a client in advance;
  • the first module obtains the IP address of the client, and sends it to the portal server along with the authentication information entered by the user;
  • the first module After receiving the authentication pass message from the portal server, the first module starts the operation of the second module;
  • the second module generates a small window for displaying user access information and providing user operation buttons.
  • the method further includes establishing a shared memory on the client side where both the first module and the second module can perform read and write operations.
  • the first module writes information related to the user's use of data services into the shared memory
  • the second module retrieves the information related to the user's use of data services from the shared memory.
  • the user access information is read from the information, and the user access information is displayed in a small window.
  • step b further includes the first module sending the obtained local IP address to the integrated service control center ISCC through the portal server to request user information. If the ISCC judges that the user has not been successfully authenticated, the portal server generates a user name and password for the user to enter Authentication page, otherwise the first module directly starts the operation of the second module.
  • step d a step of using a small window to control the user's use of data services is further included.
  • This step includes:
  • the second module periodically sends a handshake message to the portal server
  • the portal server checks whether the user logout reason in the user record in the database is null, and if so, returns a handshake response message indicating success to the second module; otherwise returns a handshake response message indicating failure to the second module; After receiving the handshake response message, the second module continues to periodically send a handshake message to the portal server for the handshake response message indicating success; for the handshake response message indicating failure, the second module stops the user from using the data service, and in a small window Displays the reason why the user is offline.
  • the method further comprises, after receiving the forced offline from the ISCC or receiving a message from the client that the user has taken the initiative to offline, setting the user offline reason in the user record in the database to a non-null value.
  • the method further includes re-sending the handshake message after the second module does not receive a handshake response message from the portal server within a preset time, if the handshake message is not received after resending the handshake message a predetermined number of times In response to the message, the second module displays a network connection exception in a small window.
  • the method further includes that the portal server looks up the user record in the online user linked list after receiving the handshake message from the client, and if the user record is found, further checking whether the reason why the user of the user record in the database is offline is If no user record is found, a message to create user information is returned to the second module. After receiving the message, the second module sends a handshake message to create the user information to the current portal server.
  • the method further comprises: before sending the handshake message, determining whether the data service is accessed through web authentication, and if so, performing the step of sending the handshake message, otherwise displaying the information directly in a small window.
  • the method further comprises: the portal server scans the online user data linked list at a fixed time, and if the handshake message from the client is not received, the user information is put into the special delete queue; then the queue to be deleted is traversed to the user Send an offline request, and then delete the current user data from the online user data list.
  • the method may further include setting the number of handshake failures in advance, and further changing the number of handshake failures if no handshake message is received from the client.
  • the number of handshake failures is equal to a preset maximum value, the user information is placed in a queue to be deleted. And sending to the user Before the offline request can be further judged whether it is necessary to send a offline request to the user, if yes, perform the step of sending the offline request; otherwise, the current user data is directly deleted from the online user data list.
  • the judgment of whether the offline request is required to be sent to the user is to compare whether the IP address of the portal server of the user information in the database is the same as its own IP address.
  • the present invention first provides a first module and a second module.
  • the first module After the IP address successfully authenticates the user, the first module starts the operation of the second module, and then the second module generates a small window, and displays the user access information and provides the user operation button in the small window.
  • the present invention implements a small client window by means of the first module and the second module working in a cooperative manner. This implementation is independent of the operating system and the existing browser software, thus avoiding the use of a browser in the prior art. It is easy to generate a small window. The small window is closed or covered abnormally, which avoids causing trouble to the user.
  • a shared memory that can be read and written by the first module and the second module is set on the client, and all information related to the user's access to the data intelligent network is written into the shared memory. Since the information in the shared memory does not exist in the form of a file, it can avoid staff loss caused by user's misoperation, and effectively prevent attacks by network hackers, etc., and greatly improve the security of data use.
  • the first module of the present invention After the first module of the present invention obtains the local IP address, it sends the obtained IP address to the ISCC through the portal server to request user information. If the ISCC judges that the user has not been successfully authenticated, the portal server generates an authentication page for the user to enter a username and password Otherwise, the first module directly starts the operation of the second module. This can effectively ensure that only one user can log in to the portal server at a time, and the implementation method is simple and stable.
  • the present invention adds a processing flow for the cluster service in a fine-grained manner to the processing flow of the client and the portal server, for example, when traversing the queue to be deleted, the portal server can compare the portal server IP address of the user information in the database Is it the same The IP address is the same to determine whether to send offline messages.
  • the portal server finds that it has not received a handshake message from the client, it is found in the database shared by multiple portal servers that the client is sending a handshake message to another portal server.
  • Send a offline message to the BRAS but directly delete the user information in its own queue to be deleted. In this way, since no offline message is received from the portal server, the user client can normally use the data service through another portal server.
  • these special processing procedures ensure that the present invention can well support cluster services.
  • Figure 1 is the basic structure diagram of the existing broadband data intelligent network.
  • Fig. 2 is an overall flowchart of the present invention.
  • FIG. 3 is a flowchart of controlling a user to use a data service through a small window.
  • FIG. 4 is the processing flow of the portal server when the network connection is abnormal.
  • a first module and a second module are set on the client, where the first module is configured to obtain a local IP address when a user accesses the portal server, and start the second module after the portal server is successfully authenticated. Operation of the module; the second module is used to pop up a small window on the client and display the user's access information in the small window, such as the user's access status, Internet time, access type and access user name, etc.
  • a user operation button is provided in a small window, which can specifically include "login to the portal server with an access user name", "login to the portal server with another account", and "offline” .
  • a first module and a second module are first set on a user client.
  • the first module is configured to obtain a local IP address when a user accesses the portal server, and start the second module after the portal server is successfully authenticated.
  • Module operation The second module is used to pop up a small window on the client, and display the user's access information in the small window, while providing user operation buttons in the small window.
  • step 202 when the monthly household wants to access the broadband data intelligent network, it accesses the corresponding address of the portal server, starts the first module, and obtains the IP address of the client by the first module. After obtaining the IP address correctly, the portal monthly server is on the client Push an authentication page. The user enters the user name and password on the authentication page, and then clicks Connect to the network to request that the user be a legitimate user.
  • the username and password here can be collectively referred to as-eyelid identification information.
  • the portal server sends an authentication request to the BRAS, which contains the user name and password information of the user and the IP address information of the client.
  • BRAS then reports the authentication request to ISCC.
  • step 204 the ISCC verifies whether the user is a legal user according to the user name, password, and IP address, and if it is a legal user, sends an authentication success response to the BRAS. BRAS then sends a successful authentication response to the portal server. The portal server sends a message indicating that the user authentication is successful to the first module of the user client.
  • step 205 after receiving the authentication success response from the portal server, the first module starts the operation of the second module, and sends a message that the user has successfully logged in to the second module.
  • the second module In step 206, the second module generates a small window and displays it on the display screen of the client. At the same time, the user access information is displayed in a small window, and a user operation button is provided in the small window. So far, the present invention successfully implements a small window on the user client, and this implementation manner is implemented through the cooperative work of the first module and the second module. Since the implementation manner of the present invention is independent of the operating system and the existing browser software, it avoids the situation that the small window that is easily generated by the browser in the prior art is prone to be closed or covered abnormally. Users go online to cause trouble.
  • the first module and the second module in the present invention may be implemented in the form of a circuit, or may be implemented in the form of software.
  • the first module can be a control, such as an ActiveX control
  • the second module can be a client application.
  • the software implementing the first module may be stored on the portal server, and the user downloads and runs the software from the portal server when the user accesses the broadband data network for the first time.
  • the small client window can have the function of automatically checking for the updated version, for example, writing the corresponding version information in a configuration file of the portal server, obtaining the version information as a control of the first module, and comparing the version with the client. If the version of the client is not the latest version, go to the portal server to download the latest program again.
  • a shared memory for information related to the use of the data service by the user may be further set in the memory of the user client.
  • the first module and the second module of the present invention may both Shared memory for read and write operations.
  • the relevant information here includes information such as user name, local IP address, Internet time, and access method.
  • the authentication page may not be displayed directly when the user logs in to the portal server.
  • the first module sends the obtained local IP address to the ISCC through the portal server.
  • the ISCC judges that the J3 ⁇ 4 user has been successfully authenticated
  • the user can log in to the portal server directly; if the ISCC judges that the user is not authenticated If successful, then an authentication page is generated as described in step 202.
  • the client will not generate an authenticated page, and in particular, the user will not be authenticated again, thereby ensuring that only one user at the same time can successfully authenticate.
  • the second module determines whether the user accesses the Internet through web authentication.
  • the message indicating that the user authentication succeeds is sent by the portal server to the first module, and includes information about a user's Internet access mode. This information is stored in the shared memory by the first module, so the second module can determine the user's Internet access mode by reading the information in the shared memory.
  • the small window will display basic information about Internet access, such as the length of time spent on the Internet, but will not provide a "Login to the portal server with an access user name” button, and it will display "Offline” that is different from web authentication. "Button” to exit, button.
  • step 316 display the information corresponding to the access method in a small window, and then follow the steps The existing processing flow corresponding to the access method is processed.
  • the second module sends a handshake message. If it is started for the first time, a message to create user information is sent. It is not the first time to start. If the return code of the ordinary handshake message is a message that needs to send user information, it will also send a message that creates user information.
  • the handshake message contains information of the message type, and the message type can indicate that the handshake message is a normal handshake message, a message to create user information, or an offline message.
  • step 303 after receiving the handshake message, the portal server determines whether the handshake message is a message indicating creation of user information. If so, in step 304, the database Add the record of the user to the user, and add the record of the user to the online user list of the portal server, and then execute step 309. If it is a normal handshake message, in step 305, the user is looked up in the online user list, and it is determined whether the user is found. If the user is not found, a message requiring creation of user information is returned to the second module of the user client in step 306. If the user is found, go to step 307.
  • step 307 the portal server determines whether the reason why the user is offline is empty. If so, step 308 is performed, otherwise step 309 is performed. The reason why the user is offline is recorded in the corresponding record of the user in the online user list. If the portal server receives a message from the BRAS that the user has been forcibly offline, set the reason for the user to be offline forcibly, otherwise leave the initial null value.
  • step 308 the portal server clears the user record in the data bank and sends a handshake response message indicating the failure to the user to the second module.
  • the portal server clears the number of user handshake failures to zero, and then returns a successful handshake response message to the second module.
  • the number of handshake failures is recorded in the portal server's memory, and its initial value is zero. If the portal server does not receive a turbulent handshake message from the user client when it arrives at a specified time, the handshake failure times are incremented by one.
  • step 310 the second module determines whether a handshake response message is received from the portal server within a predetermined time, and if so, executes step 311, otherwise executes step 314.
  • the second module clears the failure times.
  • the number of failures here is used to indicate the number of times that the second module has not received the handshake response message within a specified time, and its initial value is zero. As will be explained in detail later, each time it is judged that no handshake response message is received, the number of failures will increase by one.
  • step 312 the second module determines whether the handshake response message indicates success, and if so, executes step 302 again after a predetermined time interval, that is, re-sends to the portal server.
  • a handshake message If the handshake response message is a message requiring user information creation, a special handshake message indicating the creation of user information is sent again in step 302. If the second module judges that the handshake response message indicates success, but there is a reason to go offline (indicating that the user has been forced to go offline), or the second module does not receive a handshake response message from the portal server within a preset time, the second The module stops sending the handshake message in step 313, displays the reason for the user offline in a small window, and closes the small window after the user determines.
  • the handshake response message contains a response result value, such as a value indicating success or failure, and when it indicates failure, it may further include the reason for the failure.
  • step 314 if it is determined that the handshake response message is not received within a predetermined time, the second module sets a waiting day t for sending the next handshake message.
  • the waiting time here is longer than the interval between sending handshake messages under normal circumstances. short.
  • the second module increments the number of handshake failures by one.
  • step 315 the second module determines whether the number of failures is greater than a preset maximum number of failures. If so, step 313 is performed, that is, the user stops using the data service and informs the user of the reason for offline in a small window. If the maximum number of failures has not been reached, step 302 is performed again, and a handshake message is sent to the portal server again after a short waiting time.
  • the above process includes processing when the network terminates the user's use of the data service, processing when the user is actively offline, and processing when the network is interrupted and the user is offline.
  • the ISCC on the network side finds that the user cannot continue to use the data service for some reason, the ISCC sends a message to the BRAS, and then the BRAS sends a message to the portal server, and the portal server takes the user in the user record offline.
  • the reason is set to a non-null value, so that when the next handshake message arrives, the portal server returns a response message indicating failure to the client after detecting the non-null value, and carries the reason for offline, so that the client application side receives After the handshake response message, it is determined that the response is a failure in step 312, so that the user uses the data service in step 313 and closes the small window.
  • the second module sends a special handshake message, that is, the message type is set to indicate a "online message”
  • the portal server interacts with the BRAS, and returns the offline success message.
  • the client application determines that the user does not continue to access the Internet in step 312, and then terminates the user's use of the data service in step 313 and closes the small window.
  • the second module determines in step 310 that the handshake response message from the portal server is not received within a predetermined time, it indicates that the network connection is faulty, and the second module may perform step 313 at this time. This will take the user offline and close the small window. Of course, it is also possible to set the maximum number of failures and resend the handshake message as shown in the figure. In actual situations, this process can be added to delete as needed.
  • FIG. 4 shows the processing flow of the portal server when the network connection is abnormal.
  • the portal server scans the online user data linked list in the memory every other time interval;
  • step 402 the portal server determines whether the number of handshake failures of the user is less than the maximum. If yes, go to step 403; otherwise, go to step 404. As mentioned before, if the portal server normally receives the user's handshake message, it will clear the number of handshake failures, so step 403 will not be performed in this case. In other words, the purpose of this judgment is to check whether there is an abnormal network connection.
  • step 403 increase the number of handshake failures of the user by one.
  • step 404 the user information is placed in a queue to be deleted.
  • step 405 it is determined whether the scan is completed, that is, whether the entire online user data link list is traversed. If so, step 406 is performed, otherwise step 401 is performed again, that is, the next user information is searched.
  • step 406 the portal server traverses the queue to be deleted.
  • the portal server determines whether an offline message needs to be sent. This step is In order to support the cluster business, in the cluster business, multiple portal servers can provide data services to the same user, so it is possible that the current portal server judges that it has not received the user's handshake message for a long time, but the user may pass another Portal server to connect data services. In this way, the current portal server determines whether there is another portal server providing services to users by searching for records in the database. If so, step 408 is not performed, that is, no offline request is sent to the user, and step 409 is directly performed, that is, The current user data is deleted from the online user list.
  • step 408 is performed, that is, a offline request is sent to the BRAS, and then step 409 is performed.
  • it is specifically determined whether another portal server provides services to the user by comparing whether the IP address of the portal server of the user information in the database is the same as its own IP address. If they are the same, it is considered that there is no other portal server providing services to the user, and if they are not the same, it is considered that there is another portal server providing services to the user.
  • step 410 it is determined whether the traversal of the queue to be deleted is completed. If yes, end this process. Otherwise, step 406 is performed again, that is, it is determined whether the next user information needs to send an offline message.
  • the portal server in FIG. 3 returns a message that needs to create user information and a small window sends a message to the portal server to create user information that can well support cluster services .
  • the portal server in FIG. 3 returns a message that needs to create user information and a small window sends a message to the portal server to create user information that can well support cluster services .
  • the second portal server will find its own memory There is no record of the user in the online user linked list saved in, so a message to the client that needs to create user information is returned.
  • the small window of the client After receiving the message, the small window of the client sends a create user information message to the second portal server. In this way, the second portal server can continue to provide data access services to users.

Description

一种在宽带数据智能网中实现客户端小窗口的方法
技术领域
本发明涉及宽带数据智能网技术， 具体涉及一种在宽带数据智能网 中实现客户端小窗口的方法。 发明背景
随着智能网技术和宽带技术的发展， 目前已经出现了宽带数据智能 网。 宽带数据智能网能够向用户提供丰富的业务， 例如宽带上网业务、 门户 （Portal )业务等等。
图 1示出了现有的宽带数据智能网的基本结构。 从图 1可以看出， 宽带数据智能网包括集成业务控制中心 （ISCC )、 宽带业务接入设备 ( BRAS )s 门户服务器、 数据库等等。 其中 BRAS同时连接到 ISCC和 门户服务器， 而门户服务器连接到数据库。 这里 BRAS用于建立用户客 户端和门户服务器之间的数据链路， ISCC相当于智能网中的业务控制 点， 用于控制用户的认证、 计费、 授权等操作， 数据库则用于保存门户 服务器所需要使用的数据。
在现有的用户客户端中， 都在用户人机交互界面上设置有一个小窗 口， 例如在计算机显示屏上设置有一个小窗口。 在小窗口中显示用户的 接入信息， 例如用户的上网时间和接入用户名等信息。 同时具有用户接 入宽带数据网络或者断开宽带数据网络的操作按钮， 也就是登录或者下 线等操作按钮， 用户可以通过操作小窗口中的按钮来控制自己的数据业 务使用。
为了使门户服务器可以及时地知道用户的在线状态， 也就是用户当 前是在线还是离线， 目前一般通过门户服务器和小窗口之间的定时握手 机制来进行。 当由于网络异常中断导致用户不能使用数据业务时， 由于 浏览器计时小窗口不能发送握手消息， 门户服务器在检测到握手超时 后， 可以设置用户在线状态为下线并向 BRAS发送下线消息， 这样可以 避免由于网络中断使得用户不能使用数据业务而网络侧依然对用户进 行计费的问题。
但是， 由于现有的小窗口都是基于浏览器来实现的， 小窗口和门户 服务器之间的握手机制也是通过浏览器的心跳功能实现的。 而客户端的 小窗口经常因为浏览器的异常操作而在显示屏上被关闭或者被其它页 面替换掉， 这时用户无法看到小窗口， 因而就无法主动下线。 用户如果 希望主动下线， 必须重新登录门户服务器并经过认证， 这样客户端才会 再次出现小窗口， 用户才可以点击下线按钮从而主动断开和宽带网络的 连接。 艮显然， 这会给用户带来极大的不便。
另外， 现有的客户端为了保存客户信息和用于和服务器交互信息， 使用 cookie来保存数据。 而我们知道用户可以毫无困难地访问到 cookie 文件， 这样用户有可能误删除这些重要的数据， 或者这些数据被网络黑 客等删除或者篡改， 从而极大地影响了用户使用数据业务的安全性。
再有， 现有的门户服务器为了保证每个客户机同时只能有一个用户 登录门户服务器， 使用了浏览器的一些固有机制， 这样处理复杂而且功 能不稳定。 而且在浏览器版本众多的情况下, 门户服务器的处理也容易 出错。
并且， 现有的宽带数据智能网的显示小窗口的方法不能支持集群业 务。 而随着集群业务的逐渐普及， 这也限制了现有方法的应用。 发明内容
有鉴于此， 本发明的主要目的是提供一种在宽带数据智能网中实现 客户端小窗口的方法， 该方法能解决现有技术中用户使用数据业务不方 便的问题。
根据本发明的在宽带数据智能网中实现客户端小窗口的方法包括： a. 预先在客户端中设置第一模块和第二模块；
b. 在用户需要使用数据业务时， 第一模块获取客户端的 IP地址， 然后连同用户输入的验证信息发送到门户服务器；
c 在接收到来自门户服务器的验证通过消息后， 第一模块启动第二 模块的操作；
d. 第二模块生成用于显示用户接入信息和提供用户操作按钮的小 窗口。
较佳地， 该方法进一步包括在客户端建立第一模块和第二模块均能 进行读写操作的共享内存。 在步骤 c中第一模块在接收到来自门户服务 器的验证通过消息后， 将和用户使用数据业务相关的信息写入共享内 存， 步骤 d中第二模块从共享内存的和用户使用数据业务相关的信息中 读取用户接入信息， 并将该用户接入信息显示在小窗口中。
较佳地，步骤 b进一步包括第一模块将获取的本机 IP地址通过门户 服务器发送给集成业务控制中心 ISCC请求用户信息 ,如果 ISCC判断此 用户尚未认证成功， 门户服务器生成供用户输入用户名和密码的认证页 面， 否则第一模块直接启动第二模块的操作。
在本发明中， 在步骤 d之后进一步包括使用小窗口控制用户使用数 据业务的步骤。 该步骤包括：
第二模块定时向门户服务器发送握手消息；
门户服务器检查数据库中的用户纪录的用户下线原因是否为空， 如 果是， 向第二模块返回表示成功的握手响应消息； 否则向第二模块返回 表示失败的握手响应消息； 第二模块在接收到该握手响应消息后， 对于表示成功的握手响应消 息继续定时向门户服务器发送握手消息； 对于表示失败的握手响应消 息， 第二模块停止用户使用数据业务，并在小窗口中显示用户下线原因。
较佳地， 该方法进一步包括门户服务器在接收到来自 ISCC的强制 下线或者在接收到来自客户端的用户主动下线的消息后， 设置数据库中 的用户纪录的用户下线原因为非空值。
较佳地， 该方法进一步包括第二模块在预先设置的时间内没有接收 到来自门户服务器的握手响应消息后， 重新发送握手消息， 如果在重新 发送了预定次数的握手消息后依然没有接收到握手响应消息， 第二模块 在小窗口中显示网络连接异常。
较佳地， 该方法进一步包括门户服务器在接收到来自客户端的握手 消息后在在线用户链表中查找该用户纪录， 如果查找到用户纪录， 则进 一步检查数据库中的用户纪录的用户下线原因是否为空； 如果没有查找 到用户纪录， 则向第二模块返回需要创建用户信息的消息； 第二模块在 接收到该消息后， 向当前门户服务器发送创建用户信息的握手消息。
较佳地， 该方法进一步包括： 在发送握手消息之前判断是否是通过 web认证方式接入数据业务， 如果是， 执行发送握手消息的步骤， 否则 直接在小窗口中显示信息。
较佳地， 该方法进一步包括： 门户服务器在固定时间扫描在线用户 数据链表， 如果没有接收到来自客户端的握手消息， 则将此用户信息放 入特删除队列； 然后对待删除队列进行遍历， 向用户发送下线请求， 然 后^ ^当前用户数据从在线用户数据链表中删除。
该方法可以进一步包括预先设置握手失败次数， 如果没有接到来自 客户端握手消息， 进一步改变握手失败次数， 当握手失败次数等于预先 设置的最大值后， 将此用户信息放入待删除队列。 并且， 在向用户发送 下线请求之前可以进一步判断是否需要向用户发送下线请求， 如果是， 执行发送下线请求的步骤； 否则直接将当前用户数据从在线用户数据链 表中删除。 这里判断是否需要向用户发送下线请求是比较数据库中该用 户信息的门户服务器 IP地址是否同自己的 IP地址相同。
从本发明的上述技术方案可以看出， 本发明首先设置第一模块和第 二模块。 在用户希望接入宽带数据智能网时， 在第一模块获取了正确的'
IP地址并成功实现了用户的认证后， 第一模块启动第二模块的操作， 然 后第二模块生成小窗口， 并在小窗口中显示用户接入信息和提供用户操 作按钮。 本发明通过第一模块和第二模块协同工作的方式实现了客户端 小窗口， 这种实现方式独立于操作系统和现有的浏览器软件， 因此避免 了现有技术中通过浏览器的形式来生成小窗口容易出现的小窗口被异 常关闭或者覆盖的情况， 避免了给用户上网造成麻烦。
在本发明中在客户端设置了第一模块和第二模块均可以进行读写操 作的共享内存， 所有和用户接入数据智能网相关的信息均写入该共享内 存。 由于共享内存中的信息不是以文件形式存在， 因此避免了用户的误 操作带来的 员失， 也有效地防止了网络黑客等的攻击， 极大地提高了数 据使用的安全性。
本发明中第一模块在获取本机 IP地址后， 将获取的 IP地址通过门 户服务器发送给 ISCC请求用户信息，如果 ISCC判断此用户尚未认证成 功， 门户服务器生成供用户输入用户名和密码的认证页面， 否则第一模 块直接启动第二模块的操作。 这样可以有效地保证每个客户机同时只能 有一个用户登录门户服务器， 而且实现方式筒单稳定。
并且， 本发明通过在客户端和门户服务器端的处理流程中增加了对 于集群业务精况下的处理流程， 例如在遍历待删除队列时， 门户服务器 可以通过比較数据库中该用户信息的门户服务器 IP地址是否同自己的 IP地址相同来确定是否发送下线消息。 这样在集群业务的情况下， 虽然 门户服务器发现自己没有收到来自客户端的握手消息， 但是通过检查多 个门户服务器共享的数据库中发现客户端在向另一个门户服务器发送 握手消息， 那么就不再向 BRAS发送下线消息， 而是直接在自己的待删 除队列里删除该用户信息。 这样由于不会收到来自门户服务器的下线消 息， 用户客户端可以正常地通过另一个门户服务器来使用数据业务。 和 现有技术才目比， 这些特殊的处理流程保证了本发明能很好地支持集群业 务。 附图简要说明
图 1是现有的宽带数据智能网的基本结构图。
图 2是本发明的总体流程图。
图 3是通过小窗口控制用户使用数据业务的流程图。
图 4是门户服务器在网絡连接出现异常时的处理流程。 实施本发明的方式
下面结合附图和具体实施例对本发明进行详细说明。
在本发明中， 摒弃了现有技术中使用浏笕器来实现客户端小窗口的 方法， 而改用两个模块的协同工作的方式来实现。 具体地说， 在本发明 中， 在客户端设置了第一模块和第二模块， 其中第一模块用于在用户访 问门户服务器时获取本机 IP地址，并在门户服务器认证成功后启动第二 模块的操作； 第二模块用于在客户端上弹出小窗口， 并且在小窗口中显 示用户的接入信息， 例如用户的接入状态、 上网时间、 接入类型和接入 用户名等信息， 同时在小窗口中提供用户操作按钮，具体可以包括 "使用 接入用户名登录门户服务器"、 "使用其它帐号登录门户服务器 "和"离线" 。
下面结合图 2具体说明本发明是如何通过第一模块和第二模块的协 同工作来实现客户端小窗口的。
在步骤 201 , 首先在用户客户端设置第一模块和第二模块， 如前所 述， 第一模块用于在用户访问门户服务器时获取本机 IP地址， 并在门户 服务器认证成功后启动第二模块的操作； 第二模块用于在客户端上弹出 小窗口， 并且在小窗口中显示用户的接入信息， 同时在小窗口中提供用 户操作按钮。
在步骤 202, 当月户希望接入宽带数据智能网时， 访问门户服务器 对应的地址， 启动第一模块， 由第一模块获取客户端的 IP地址， 正确获 取 IP地址后， 门户月 务器在客户端推送一个认证页面。用户在该认证页 面输入用户名和密码， 然后点击连接网絡， 请求验证用户是否是一个合 法用户。 这里的用户名和密码可以统称为-睑证信息。
在步骤 203, 门户服务器向 BRAS发送一个认证倩求， 其中包含用 户的用户名和密码信息以及客户端的 IP地址信息。 BRAS然后将该认证 请求上报给 ISCC。
在步骤 204, ISCC根据用户名、 密码和 IP地址验证用户是否是一 个合法用户，如果是一个合法用户， 向 BRAS下发认证成功响应。 BRAS 随后向门户服务器发送认证成功响应。 门户服务器向用户客户端的第一 模块发送表示用户认证成功的消息。
在步骤 205, 第一模块在接收到来自门户服务器的认证成功响应后， 启动第二模块的操作， 并向第二模块发送用户登录成功的消息。
在步骤 206, 第二模块生成小窗口， 并显示在客户端的显示屏上。 同时， 将用户接入信息显示在小窗口中， 并在小窗口中提供用户操作按 钮。 至此， 本发明成功地在用户客户端实现了小窗口， 而且这种实现方 式是通过第一模块和第二模块的协同工作来实现的。 由于本发明的实现 方式独立于操作系统和现有的浏览器软件， 因此避免了现有技术中通过 浏览器的形式来生成小窗口容易出现的小窗口被异常关闭或者覆盖的 情况， 避免了给用户上网造成麻烦。
本发明中的第一模块和第二模块可以通过电路的形式来实现， 也可 以通过软件的形式来实现。 在通过软件实现的情况下， 第一模块可以是 一个控件， 例如是一个 ActiveX控件， 而第二模块可以是一个客户端应 用程序。 至于具体如何构造电路和编制软件， 对于本领域技术人员来说 根据本发明的精神是完全可以实现的， 因此这里不再详细说明。
在通过软件实现第一模块和第二模块的情况下， 可以将实现第一模 块的软件存放在门户服务器上， 用户在第一次接入宽带数据网絡时从门 户服务器下载并运行该软件。 并且客户端小窗口可以具有自动检查更新 版本的功能， 例如在门户服务器的一个配置文件中写入相应的版本信 息，作为第一模块的控件获取该版本信息，并和客户端的版本进行比较， 如果发现客户端的版本不是最新版本， 则重新到门户服务器上下载最新 的程序。
为了保证用户数据的安全性， 在本发明中可以进一步在用户客户端 的内存中设置一个用于和用户使用数据业务相关的信息的共享内存， 本 发明的第一模块和第二模块均可对该共享内存进行读写操作。 这里的相 关的信息包括用户名、本机 IP地址、上网时间、接入方式等信息。这样， 通过将数据存放在共享内存的方式， 避免了用户的误操作而删除的情 况， 也防止了恶意用户对文件的攻击， 因此提高了数据的安全性， 使得 用户可以更放心地使用数据业务。
在步骤 202中， 也可以在用户登录门户服务器时不直接弹出认证页 面， 而是由第一模块将获取的本机 IP地址通过门户服务器发送给 ISCC . 请求用户信息， 如果 ISCC判断 J¾用户已经认证成功， 则用户可以直接 登录门户服务器； 如果 ISCC判断此用户没有认证成功， 则如步骤 202 所述生成认证页面。 这样， 在 IP地址已经有用户认证上网的情况下， 在 客户端不会生成认证的页面， 也尤是不会再让用户认证， 从而保证了同 一台客户机同时只能有一个用户认证成功。
在本发明中， 在启动了小窗口之后， 可以进一步通过小窗口来控制 用户的数据业务使用。 如图 3所示， 在步驟 301 , 第二模块确定用户是 否是通过 web认证的方式上网。 这里， 在门户服务器发送给第一模块的 表示用户认证成功的消息中包含了用户的上网方式信息。 该信息由第一 模块保存在共享内存中， 因此第二模块可以通过读取共享内存中的该信 息确定用户的上网方式。 这里的上网方式除了 web认证上网之外， 还有 PPPoE拨号方式和窄带接入方式。 对于后两种来说， 小窗口会显示上网 的基本信息，例如上网时长等，但不会提供"使用接入用户名登录门户服 务器"的按钮， 而且会显示不同于 web认证方式上网的"离线"按钮的 "退 出，，按钮。 在这一步骤中， 如果确定是通过 web认证方式上网， 则进入 到步骤 302, 否则在步骤 316在小窗口中显示该接入方式对应的信息， 然后按照该接入方式对应的现有处理流程进行处理。
在步骤 302, 第二模块发送握手消息。 如果是首次启动则会发送创 建用户信息的消息。 不是首次启动如果普通握手消息的返回码是需要发 送创建用户信息的消息， 也会发送创建用户信息的消息。 在握手消息中 包含消息类型的信息， 该消息类型可以表示此握手消息是一个普通的握 手消息， 还是一个创建用户信息的消息， 或者是一个下线消息。
在步骤 303, 门户服务器在接收到该握手消息后， 判断该握手消息 是否是表示创建用户信息的消息， 如果是， 则在步骤 304中， 在数据库 中添加该用户的纪录， 并在门户服务器的在线用户链表中添加该用户的 纪录， 然后执行步骤 309。 如果是普通握手消息， 则在步骤 305中， 在 线用户链表中查找该用户， 并判断是否查找到该用户。 如果没有查找到 该用户， 则在步骤 306向用户客户端的第二模块返回一个需要创建用户 信息的消息。 如果查找到该用户， 则机行步骤 307。
在步骤 307, 门户服务器判断用户下线原因是否为空， 如果是， 执 行步驟 308, 否则执行步骤 309。 这至的用户下线原因是记录在在线用 户链表中该用户对应的记录中。 如果门户服务器接收到来自 BRAS的用 户已经被强制下线的消息， 将用户下幾原因设置强制下线， 否则保留为 初始的空值。
在步骤 308， 门户服务器清除数梧库中的用户记录， 并将包含用户 下线原因的表示失败的握手响应消息发送给第二模块。
在步骤 309, 门户服务器将用户^握手失败次数清零， 然后向第二 模块返回一个表示成功的握手响应消息、。 这里的握手失败次数是记录在 门户服务器的内存中的， 其初始值为零。 如果门户服务器在一个规定的 时间到达时没有接收到来自用户客户湍的握手消息， 则将该握手失败次 数加 1。
在步骤 310, 第二模块判断是否在预定时间内接收到来自门户服务 器的握手响应消息， 如果是， 执行步 311 , 否则执行步骤 314。
在步驟 311 , 第二模块将失败次軚清零。 这里的失败次数用于表示 第二模块没有在规定时间内接收到握寻响应消息的次数， 其初始值为 零。 如后面要详细说明的那样， 每次判断没有接收到握手响应消息后， 失败次数将加 1。
在步骤 312， 第二模块判断握手 应消息是否表示成功， 如果是， 则在间隔预定时间后重新执行步骤 302, 也就是重新向门户服务器发送 握手消息，如果握手响应消息是需要创建用户信息的消息，则在步骤 302 再次发出一个特殊的表示创建用户信息的握手消息。 如果第二模块判断 握手响应消息表示成功， 但是有下线原因 （表明用户已经被强制下线）， 或者第二模块在一个预先设置的时间内没有收到来自门户服务器的握 手响应消息， 第二模块在步骤 313停止握手消息的发送， 在小窗口中向 用户显示用户下线原因， 并在用户确定后关闭小窗口。
这里， 握手响应消息包含一个响应结果值， 例如表示成功或者失败 的值， 并且当表示失败时， 还可以进一步包含失败的原因。
在步骤 314, 如果判断没有在预定时间内收到握手响应消息， 第二 模块设置一个发送下次握手消息的等待日 t间， 当然， 这里的等待时间会 比正常情况下发送握手消息的间隔时间短。 然后， 第二模块将握手失败 次数加 1。
在步驟 315， 第二模块判断失败次数是否大于预先设置的最大失败 次数， 如果是， 执行步骤 313， 也就是停止用户使用数据业务并在小窗 口中告知用户下线原因。 如果还没有达到最大失败次数， 则重新执行步 驟 302, 在短的等待时间后再次向门户服务器发送握手消息。
上述流程包括了网络终止用户使用数据业务时的处理、 用户主动下 线时的处理和网络中断导致用户下线时的处理。 对于第一种情况， 当网 络侧的 ISCC发现因为某种原因用户不能继续使用数据业务时， ISCC向 BRAS发送一个消息， 然后 BRAS向门户服务器发送一个消息， 门户服 务器将用户纪录中的用户下线原因设置一个非空值， 这样当下一次握手 消息到来的时候， 门户服务器在检测到该非空值之后向客户端返回一个 表示失败的响应消息， 并携带下线原因， 这样客户应用端在接收到该握 手响应消息后在步骤 312判断出响应为失败， 这样在步骤 313终止用户 使用数据业务， 并关闭小窗口。 对于第二种情况， 当用户主动下线时， 第二模块发送一个特殊的握 手消息， 也就是在消息类型中设置该消息表示 "线消息， 门户服务器同 BRAS交互， 将下线的成功消息回给第二模块， 这样客户应用端在接收 到该握手响应消息后在步骤 312判断出用户不^ <继续上网， 这样在步骤 313终止用户使用数据业务， 并关闭小窗口。
对于第三种情况， 在步骤 310如果第二模 判断出没有在预定时间 内接收到来自门户服务器的握手响应消息， 那么就表示网络连接有故 障， 此时第二模块可以执行步骤 313。 这样可 将用户下线， 并关闭小 窗口。 当然， 也可以如图所示设置失败最大次数和重新发送握手消息， 在实际情况下这一处理可以根据需要进行增加氣者删除。
图 4示出了门户服务器在网络连接出现异常时的处理流程。 如图 4 所示， 在步骤 401 , 门户服务器每隔一个固定^；时间段扫描内存中的在 线用户数据链表。
在步驟 402， 门户服务器判断用户的握手失败次数是否小于最大值。 如果是， 执行步骤 403 , 否则执行步骤 404。 口前所述， 如果门户服务 器正常地接收到用户的握手消息， 会将此握手^败次数清零， 因此在这 种情况下将不会执行步骤 403。 换句话说， 这一判断的目的即在于检查 是否存在网络连接异常。
在步骤 403 , 将此用户的握手失败次数加 1。
在步骤 404 , 将此用户信息放入待删除队列。
在步骤 405 , 判断扫描是否完成， 也就是是否遍历了整个在线用户 数据链表， 如果是， 执行步骤 406, 否则重新机行步骤 401 , 也就是查 找下一个用户信息。
在步骤 406， 门户服务器对待删除队列进行遍历。
在步驟 407, 门户服务器判断是否需要发 下线消息。 这一步骤是 为了支持集群业务考虑的， 在集群业务中， 多个门户服务器可以向同一 个用户提供数据服务， 因此有可能当前门户服务器判断在长时间内没有 接收到用户的握手消息， 但是用户可能通过另一个门户服务器来连接数 据业务。 这样当前门户服务器通过查找数据库中的 录来确定是否有另 一个门户服务器向用户提供服务， 如果是， 不执行步骤 408, 也就是不 向用户发送下线请求， 而直接执行步驟 409, 也就是将当前用户数据从 在线用户链表中删除。 而如果没有另一个门户服务器向用户提供服务， 则执行步骤 408, 也就是向 BRAS发送下线请求， 然后执行步骤 409。 这里具体判断是否有另一个门户服务器向用户提供服务是比较数据库 中该用户信息的门户服务器 IP地址是否同自己的 IP地址相同。 如果相 同， 则认为没有另一个门户服务器向用户提供服务， 如果不相同， 则认 为有另一个门户服务器向用户提供服务。
在步骤 410, 判断是否完成了对待删除队列的遍历。 如果是， 结束 此流程。 否则重新执行步骤 406, 也就是对下一个用户信息确定是否需 要发送下线消息。
上面通过一个具体实施例对本发明进行了说明。 可以看出， 本发明 可以很好地支持集群业务。 除了图 4中的步驟 407是出于集群业务考虑 的之外， 图 3中的门户服务器返回需要创建用户信息的消息和小窗口向 门户服务器发送创建用户信息的消息都能很好地支持集群业务。 具体地 说， 在有多个门户服务器向用户提供数据业务的情况下， 如果用户从第 一门户服务器转而使用第二门户服务器接入宽带数椐网络， 那么第二门 户服务器将会发现自己内存中保存的在线用户链表中没有该用户的纪 录， 因而向客户端返回一个需要创建用户信息的消息。 客户端的小窗口 在接收到该消息后， 向第二门户服务器发送一个创建用户信息消息。 这 样第二门户服务器可以继续向用户提供数据接入业务。 以上所述仅为本发明的较佳实施例而已， 并不用以 P艮制本发明， 凡 在本发明的精神和原则之内， 所作的任何修改、 等同替擬、 改进等， 均 应包含在本发明的保护范围之内。

Claims

权利要求书
1、一种在宽带数据智能网中实现客户端小窗口的方法，所述宽带数 据智能网包括客户端和门户服务器， 该方法包括：
a. 预先在客户端中设置第一模块和第二模块；
b. 在用户需要使用数据业务时， 第一模块获取客户端的 IP 地址， 然后连同用户输入的验证信息发送到门户服务器；
c 在接收到来自门户服务器的验证通过消息后， 第一模块启动第二 模块的操作；
d. 第二模块生成用于显示用户接入信息和提供用户操作按钮的小 窗口。
2、根据权利要求 1所述的方法， 其特征是， 该方法进一步包括在客 户端建立第一模块和第二模块均能进行读写操作的共享内存。
3、根据权利要求 2所述的方法， 其特征是， 在步骤 c中第一模块在 接收到来自门户服务器的验证通过消息后， 将和用户使用数椐业务相关 的信息写入共享内存， 步骤 d中第二模块从共享内存的和用户使用数据 业务相关的信息中读取用户接入信息， 并将该用户接入信息显示在小窗 口中。
4、根据权利要求 1所述的方法， 其特征是， 步骤 b进一步包括第一 模块将获取的本机 IP 地址通过门户服务器发送给集成业务控制中心 ISCC请求用户信息， 如果 ISCC判断此用户尚未认证成功， 门户服务器 生成供用户输入用户名和密码的认证页面， 否则第一模块直接启动第二 模块的操作。
5、根据权利要求 1所述的方法， 其特征是， 在步骤 d之后进一步包 括使用小窗口控制用户使用数据业务的步骤。
6、根据权利要求 5所述的方法， 其特征是， 所述使用小窗口控制用 户使用数据业务的步骤包括：
第二模块定时向门户服务器发送握手消息；
门户服务器检查数据库中的用户纪录的用户下线原因是否为空， 如 果是， 向第二模块返回表示成功的握手响应消息； 否则向第二模 返回 表示失败的握手响应消息；
第二模块在接收到该握手响应消息后， 对于表示成功的握手 应消 息继续定时向门户服务器发送握手消息； 对于表示失败的握手 ^应消 息，第二模块停止用户使用数据业务，并在小窗口中显示用户下线 ^因。
7、根据权利要求 6所述的方法， 其特征是， 该方法进一步包括门户 服务器在接收到来自 ISCC的强制下线或者在接收到来自客户端的用户 主动下线的消息后， 设置数据库中的用户纪录的用户下线原因为非空 值。
8、根据权利要求 6所述的方法， 其特征是， 该方法进一步包括第二 模块在预先设置的时间内没有接收到来自门户服务器的握手响应消息 后， 重新发送握手消息， 如果在重新发送了预定次数的握手消息后依然 没有接收到握手响应消息， 第二模块在小窗口中显示网络连接异常。
9、根据权利要求 6所述的方法， 其特征是， 该方法进一步包括门户 服务器在接收到来自客户端的握手消息后在在线用户链表中查找该用 户纪录， 如果查找到用户纪录， 则进一步检查数据库中的用户纪录的用 户下线原因是否为空； 如果没有查找到用户纪录， 则向第二模块返回需 要创建用户信息的消息； 第二模块在接收到该消息后， 向当前门户服务 器发送创建用户信息的握手消息。
10、 根据权利要求 6所述的方法， 其特征是， 该方法进一步包括： 在发送握手消息之前判断是否是通过 web认证方式接入数据业务， 如果 是， 执行发送握手消息的步骤， 否则 _接在小窗口中显示信息。
11、 根据权利要求 6所述的方法， 其特征是， 该方法进一步包括： 门户服务器在固定时间扫描在线用户 t据链表， 如果没有接收到来自客 户端的握手消息， 则将此用户信息放 待删除队列； 然后对待删除队列 进行遍历， 向用户发送下线请求， 然后将当前用户数据从在线用户数据 表中删除。
12、根据权利要求 11所述的方法， 其特征是， 该方法进一步包括预 先设置握手失败次数， 如果没有接到 自客户端握手消息， 进一步改变 ¾手失败次数， 当握手失败次数等于 先设置的最大值后， 将此用户信 息放入待删除队列。
13、 根据权利要求 11所述的方法， 其特征是， 该方法进一步包括： 在向用户发送下线请求之前进一步判 ¾f是否需要向用户发送下线请求， 如果是， 执行发送下线请求的步骤； 否则直接将当前用户数据从在线用 卢数据链表中删除。
14、根据权利要求 13所述的方法， 其特征是， 所述判断是否需要向 用户发送下线请求是比较数据库中该用户信息的门户服务器 IP 地址是 否同自己的 IP地址相同。
PCT/CN2005/000374 2004-03-24 2005-03-24 Procede de creation d'une petite fenetre du cote client dans le reseau intelligent de donnees a large bande WO2005096550A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP05738138A EP1732267B1 (en) 2004-03-24 2005-03-24 Method and system for achieving a small window at a client-side in a broadband intelligent network
AT05738138T ATE456888T1 (de) 2004-03-24 2005-03-24 Verfahren und system zur erlangung eines kleinen fensters auf kundenseite in einem intelligenten breitbanddatennetz
DE602005019141T DE602005019141D1 (de) 2004-03-24 2005-03-24 Verfahren und System zur Erlangung eines kleinen Fensters auf Kundenseite in einem intelligenten Breitbanddatennetz
US11/510,177 US7788320B2 (en) 2004-03-24 2006-08-25 Method, device and system for producing small window at client in broadband data intelligent network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB2004100303941A CN100344099C (zh) 2004-03-24 2004-03-24 一种在宽带数据智能网中实现客户端小窗口的方法
CN200410030394.1 2004-03-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/510,177 Continuation US7788320B2 (en) 2004-03-24 2006-08-25 Method, device and system for producing small window at client in broadband data intelligent network

Publications (1)

Publication Number Publication Date
WO2005096550A1 true WO2005096550A1 (fr) 2005-10-13

Family

ID=35046804

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/000374 WO2005096550A1 (fr) 2004-03-24 2005-03-24 Procede de creation d'une petite fenetre du cote client dans le reseau intelligent de donnees a large bande

Country Status (6)

Country Link
US (1) US7788320B2 (zh)
EP (1) EP1732267B1 (zh)
CN (1) CN100344099C (zh)
AT (1) ATE456888T1 (zh)
DE (1) DE602005019141D1 (zh)
WO (1) WO2005096550A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0420675D0 (en) * 2004-09-17 2004-10-20 Ibm Method and software tool for installation of portlets into a client platform
KR101079592B1 (ko) * 2006-11-03 2011-11-04 삼성전자주식회사 디스플레이장치 및 그 정보갱신방법
US20080177869A1 (en) * 2007-01-24 2008-07-24 Christopher Jensen Read System and method for configuring consumer electronics device for home network using the internet
US20080229370A1 (en) * 2007-03-13 2008-09-18 Zustak Frederick J TV-centric system
US20090055534A1 (en) * 2007-08-22 2009-02-26 Sony Corporation Tiered network structure for large ce device populations
CN107517236B (zh) 2016-06-17 2021-06-15 斑马智行网络(香港)有限公司 一种用于物联网的事件处理方法、装置和设备
CN107517238A (zh) * 2016-06-17 2017-12-26 阿里巴巴集团控股有限公司 一种用于物联网的智能设备控制方法、装置和设备
CN107147643A (zh) * 2017-05-10 2017-09-08 武汉票据交易中心有限公司 一种客户端登录方法
CN112714123A (zh) * 2020-12-27 2021-04-27 杭州迪普科技股份有限公司 上网方法、装置及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6240091B1 (en) 1997-07-14 2001-05-29 Nokia Telecommunications Oy Implementation of access service
US20020152242A1 (en) * 2001-04-12 2002-10-17 Meyer Kristin S. System for monitoring the usage of intranet portal modules
KR20030043055A (ko) * 2001-11-26 2003-06-02 삼성전자주식회사 디지털 가입자 회선 망에서 공지사항 안내 서비스 시스템
JP2003219197A (ja) * 2002-01-18 2003-07-31 Sega Toys:Kk 画像生成装置、画像生成方法及びプログラム
EP1349062A2 (en) * 2002-03-28 2003-10-01 Seiko Epson Corporation Download management system

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE9900710L (sv) * 1999-02-25 2000-08-26 Ericsson Telefon Ab L M Metod och anordning som avser kommunikationsnätverk för mobiltelefoner
US7111060B2 (en) * 2000-03-14 2006-09-19 Aep Networks, Inc. Apparatus and accompanying methods for providing, through a centralized server site, a secure, cost-effective, web-enabled, integrated virtual office environment remotely accessible through a network-connected web browser
US20020129096A1 (en) * 2001-02-14 2002-09-12 Mansour Peter M. Platform-independent distributed user interface client architecture
CN1180594C (zh) * 2001-09-29 2004-12-15 华为技术有限公司 互联网个人号码业务中的认证与计费方法
CN1152333C (zh) * 2002-07-31 2004-06-02 华为技术有限公司 基于认证、计费、授权协议的门户认证实现方法
US8321584B2 (en) * 2003-04-04 2012-11-27 Ellacoya Networks, Inc. Method and apparatus for offering preferred transport within a broadband subscriber network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6240091B1 (en) 1997-07-14 2001-05-29 Nokia Telecommunications Oy Implementation of access service
US20020152242A1 (en) * 2001-04-12 2002-10-17 Meyer Kristin S. System for monitoring the usage of intranet portal modules
KR20030043055A (ko) * 2001-11-26 2003-06-02 삼성전자주식회사 디지털 가입자 회선 망에서 공지사항 안내 서비스 시스템
JP2003219197A (ja) * 2002-01-18 2003-07-31 Sega Toys:Kk 画像生成装置、画像生成方法及びプログラム
EP1349062A2 (en) * 2002-03-28 2003-10-01 Seiko Epson Corporation Download management system

Also Published As

Publication number Publication date
DE602005019141D1 (de) 2010-03-18
ATE456888T1 (de) 2010-02-15
US7788320B2 (en) 2010-08-31
EP1732267B1 (en) 2010-01-27
EP1732267A4 (en) 2007-03-14
US20070055750A1 (en) 2007-03-08
CN1674522A (zh) 2005-09-28
EP1732267A1 (en) 2006-12-13
CN100344099C (zh) 2007-10-17

Similar Documents

Publication Publication Date Title
WO2005096550A1 (fr) Procede de creation d&#39;une petite fenetre du cote client dans le reseau intelligent de donnees a large bande
US20030069848A1 (en) A User interface for computer network management
US6081508A (en) Remote computer communication
EP1700230B1 (en) Dynamic timeout in a client-server system
KR101099238B1 (ko) 외부 컴퓨터를 내부 컴퓨터에 원격으로 접속하기 위한 시스템 및 방법
JP4734592B2 (ja) クライアントリダイレクトによるプライベートネットワークへの安全なアクセス提供方法およびシステム
US6799147B1 (en) Enterprise integrated testing and performance monitoring software
US8291268B2 (en) Apparatus, system, and method to provide alert notification with reconcile actions
US7257741B1 (en) Methods and systems for communications device troubleshooting
US20110138446A1 (en) System and method for providing user authentication and identity management
CN101841537A (zh) 一种基于协议代理实现对文件共享访问控制方法及系统
CA2415868A1 (en) Systems and methods for authenticating a user to a web server
US20010042202A1 (en) Dynamically extendible firewall
US20070180126A1 (en) Systems and methods for establishing and validating secure network sessions
US6959392B1 (en) Information providing system and method for providing information
US7281027B2 (en) Distributed processing system and network monitoring system
US7392540B1 (en) Methods and systems for customer premises remote collaboration facility
US7426727B2 (en) Delayed uploading of user registration data
Cisco Release Notes for the PIX Firewall Manager Version 4.3(2)g
Cisco Release Notes for the PIX Firewall Manager Version 4.3(2)f
Cisco Release Notes for the PIX Firewall Manager Version 4.3(2)h
Cisco CiscoSecure ACS 2.2(3) for UNIX Release Notes
Cisco CiscoSecure ACS 2.2(3) for UNIX Release Notes
Cisco PIX Firewall Manager Version 4.2(3) Release Notes
Cisco Release Notes for CiscoSecure ACS 2.2.2 for UNIX

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2005738138

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005738138

Country of ref document: EP