The above and other aspects of the present invention will become more apparent from the following description of exemplary embodiments thereof with reference to the accompanying drawings, in which:
Certain exemplary embodiments of the present invention will now be described more fully with reference to the accompanying drawings.
According to an exemplary embodiment of the present invention, messages to be used to implement a protocol are passed in the form of packets having a predefined structure when the messages are transmitted through a network, but in the present specification, an example of each message structure will be suggested by describing only fields to be included in the payload of a packet.
The process begins when a client that desires to use the service of the server sets information on the client itself and the type of service in a “service registration” message (ServiceRegistrationReq), and transmits the message to the server in operation S101. If the server provides the same service type specified by ServiceRegistrationReq, the server registers the client, and by using the ServiceRegistrationReq information, the server can manage clients by group. For example, clients are divided into groups; rights for each group are set; and contents can be provided only to clients belonging to a group having a right to receive contents. By doing so, rights management by group is enabled.
Meanwhile, the ServiceRegistrationReq can be transmitted through a socket for controlling service start and end and for controlling multimedia service. This uses TCP mode separately from a data transmission channel.
ServiceRegistrationReq Packet payload={MAC address, service type, group name, client name}
Here, the “MAC address” is a unique identification number of a network card and is used as an identifier to distinguish each client. The “service type” is a unique identifier (ID) to distinguish a variety of services provided by the server. The “group name” is a name used when clients are divided into a plurality of groups and managed. The “client name” is used to distinguish each client and as a user-friendly alias. The purposes of fields to be explained in the present specification are applied identically throughout the specification.
As shown in
The exemplary structures of messages used to provide the pull mode service as described above are as follows:
ContentsPullListReq Packet payload={service type, group name, client name, medium type, list sort information, list request information}
ContentsPullList Packet payload={service type, server name, medium type, contents list information, server service network information}
ContentsPullReq Packet payload={service type, group name, client name, contents information}
ContentsPullEnd Packet payload={service type, group name, client name, medium type}
Here, the “medium type” is used to distinguish a variety of media and includes, for example, movie, music, photo, document, and the like. The “list sort information” is to specify how the contents list is sorted and received, and includes, for example, file name, date, size, genre, etc. The “list request information” is a field to specify the number of lists per page, the position of a page, etc. The “contents list information” is the list of contents corresponding to the “medium type” requested by the client among the contents provided by the sever. Also, the “server service network information” is access information of a network through which the server provides services and includes an IP address and port number, and when multicast is required depending on the type of services, may also include a multicast IP address and port number. The “contents information” is information on respective contents, and a file name, size, generated date, play time, and thumbnail can be specified.
When a server transmits data in a push mode in the conventional push and pull mode service, the service begins by a one-sided compulsory transmission of a contents list to a client by the server. However, in an exemplary embodiment of the present invention, when the server begins a push mode service, a priority is requested in order to determine which mode of service the client wants to receive preferentially in operation S301. The client, receiving a priority question, transmits a response message including a desired priority in operation S302. Though the priority information of the client is requested and received when the push mode service begins in the shown exemplary embodiment, the client may actively transmit priority information whenever the status of the client changes, and the server may use the information in order to determine whether or not to provide a push mode service. Meanwhile, in the present embodiment, “pull-mode-first,” “push-mode-first,” and “user-selection-first” are suggested as priorities that the client can select, but the priorities are not limited to these.
It is determined whether the priority received from the client is “pull-mode-first” mode, “push-mode-first” mode or “user-selection-first” mode in operation S303. If it is the “pull-mode-first” mode, the push mode service is terminated and switched to a pull mode in operation S304. Meanwhile, if it is the “push-mode-first” mode, the push mode service is continued to provide the data push service in operation S305. At this time, if the client is using the pull mode service, the pull mode service will be terminated.
Meanwhile, if the priority is the “user-selection-first” mode, the client needs to receive priority information from the user in operation S306. This can be implemented in a variety of ways. Examples of the implementation include direct input by the user or user's selection in a set file.
Whether or not to continue the push mode service is determined by the user selection in operation S307. If the user selects the “pull mode,” the push mode service is terminated and switched to the pull mode in operation S308. Meanwhile, if the user selects the “push mode,” the push mode service is continued in operation S309.
Hereinafter, an exemplary embodiment to provide the data push service will be explained in more detail with reference to message transmission and reception protocols shown in
If the priority of the client is the “pull-mode-first (PULL_MODE_FIRST)” mode as in
In this case, the server transmits a “contents push list” message (ContentsPushList) in operation S423. The ContentsPushList includes “contents list information” which is a list of contents that the server desires to push, and by referring to this list, the client transmits a “contents push request” message (ContentsPushReq) to request the server to push the contents in operation S424. In response to this request, the server confirms the “service type” and the right of the client and then provides the push service for the requested contents in operation S425. That is, by transmitting the ContentsPushReq, the client sequentially requests the contents in the contents list, and receives contents from the server, and this process is repeated to the end of the contents list.
If the push service for all contents is finished, the server transmits a “contents push end” message (ContentsPushEnd) to end the push mode service in operation S426.
If the response of the user is the “pull mode” as in
If the response of the user is the “push mode” as in
Examples of the structures of messages used in the present embodiment of the present invention described above with reference to
ContentsPushPriorityReq Packet payload={service type, server name, server service network information}
ContentsPushPriorityRes Packet payload={service type, group name, client name, priority information}
ContentsPushList Packet payload={service type, server name, medium type, contents list information, server service network information}
ContentsPushReq Packet payload={service type, group name, client name, contents information}
ContentsPushStop Packet payload={service type, group name, client name, error information}
ContentsPushEnd Packet payload={service type, server name, medium type}
As described above, the “priority information” of the ContentsPushPriorityRes is set to “PUSH_MODE_FIRST,” “PULL_MODE_FIRST,” or “USER_SELECTION_FIRST.”
When a push mode service for the remote control service begins, a server asks the priority of a client in operations S501 and S502, and according to the priority, determines whether to continue the remote control service in operation S503. Depending on an application system, it can be determined whether to begin the remote control service by using priority information provided in advance by the client.
If the priority information from the client is a “pull-mode-first” mode, the remote control service is terminated in operation S504, otherwise, a remote control command from the server is transmitted to the client in operations S505 and S507. If the priority information is the “pull-mode-first” mode, the pull mode service can be continuously used without interference from the remote control service, and if it is the “push-mode-first” mode, the transmitted remote control command is executed and then the result is reported to the server in operation S506.
Meanwhile, if the priority information is a “user-selection-first” mode, the client receives an input of a priority from the user in operation S508. If the user's selection is the “pull mode,” the remote control service is terminated in operations S509 and S510, and if it is the “push mode,” the received remote control command is executed and the result is reported in operations S509 and S511.
Hereinafter, the embodiment for the remote control service will be explained in more detail with reference to message transmission and reception protocols shown in
First, the server transmits ContentsPushPriorityReq to confirm the priority of a client desired to be remote controlled in operations S611 and S621, and in response, the client transmits ContentsPushPrioirtyRes in operations S612 and S622.
If the “priority information” of the ContentsPushPriorityRes is “PULL_MODE_FIRST” as shown in
Meanwhile, if the priority information is “PUSH_MODE_FIRST” as shown in
If the response of the user is “PULL_MODE” as shown in
The examples of the structures of messages used in the embodiment of the present invention described above with reference to
RemoteControl Packet payload={service type, server name, remote control command, remote control command parameter}
ClientStatus Packet payload={service type, server name, client status information}
RemoteControlStop Packet payload={service type, server name, client status information, error information}
Here, the “remote control command” is a command which is desired to be executed in the client through remote control by the server, and can include a variety of commands, such as changing power status to off, WOL, adjustment of brightness, color, illumination, volume, screen mode, and sound. The “remote control command parameter” is parameter information required for executing the “remote control command.”
Meanwhile, the “client status information” and “error information” are fields to report the result of executing the remote control command. The “client status information” can include status information in relation to the brightness, color, illumination, volume, screen mode, sound mode, corresponding to the executed remote control command.
The examples of the structures of messages used in the termination of services are as follows:
ClientServiceEnd Packet payload={MAC address, service type, group name, client name}
ServerServiceEnd Packet payload={service type, server name}
Meanwhile, a server or a client can sense an abnormal termination by the other side by periodically transmitting a “connection confirmation” message (ConnectionConfirm).
ConnectionConfirm Packet payload={MAC address, service type, group name, client name}
While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the following claims. The exemplary embodiments should be considered in a descriptive sense only and not for purposes of limitation. Therefore, the scope of the invention is defined not by the detailed description of the invention but by the appended claims and their equivalents, and all differences within the scope will be construed as being included in the present invention.
According to the structure of an exemplary embodiment of the present invention as described above, while a service is used in a pull mode, according to the priority selected by the client, reception of a push mode service is refused or the pull mode service is stopped and switched to a push mode so that important information can be received. Also, according to an exemplary embodiment of the present invention, a service mode can be selected according to the response of the user, and therefore according to the decision of the user, an important service between the pull mode service and push mode service may be received.
Number | Date | Country | Kind |
---|---|---|---|
10-2005-0075252 | Aug 2005 | KR | national |