WO2005015429A1 - Authentication method based on ticket - Google Patents

Authentication method based on ticket Download PDF

Info

Publication number
WO2005015429A1
WO2005015429A1 PCT/KR2004/001980 KR2004001980W WO2005015429A1 WO 2005015429 A1 WO2005015429 A1 WO 2005015429A1 KR 2004001980 W KR2004001980 W KR 2004001980W WO 2005015429 A1 WO2005015429 A1 WO 2005015429A1
Authority
WO
WIPO (PCT)
Prior art keywords
contents
ticket
server
user client
information
Prior art date
Application number
PCT/KR2004/001980
Other languages
French (fr)
Inventor
Sang-Hyeon Kim
Original Assignee
Nhn Corporation
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 Nhn Corporation filed Critical Nhn Corporation
Publication of WO2005015429A1 publication Critical patent/WO2005015429A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Definitions

  • the present invention relates to a ticket-based authentication method, and more particularly, to a method of deciding whether a user, who requests contents to a server providing the contents, has paid a corresponding bill using a ticket.
  • a transmission rate of a data network such as Internet has been rapidly sped up.
  • Data transmitted via Internet were mainly a general text or simple image data in the early days.
  • a transmission service of moving picture data needing a wide bandwidth is provided nowadays.
  • a server providing a web page allowing a user to request contents used to transmit the contents as well.
  • a service provider just provides the web page to allowing a user to request contents, whereas a substantial transmission of the contents tends to be mostly carried out by a server operated by a contents transmission provider nowadays.
  • CDN contents delivery network
  • the CDN service is the service for transmitting a great capacity of contents data by minimizing a load put on a server in a manner of being equipped with a plurality of edge servers that are locally distributed as well as a central server.
  • portal sites providing integrated services tend to interoperate with CDN providers. So, the portal site provides a web page allowing a user to request contents only and the transmission of the corresponding contents is mainly carried out via CDN.
  • a contents transmission provider gets to transmit the contents of a plurality of contents providers, e.g., portal site, broadcasting station, professional movie site, etc.
  • FIG. 1 is a block diagram of a general authentication system according to a related art.
  • an authentication system may include a user client 100, a contents server 102, an authentication server 104, a first web server 106, a second web server 108, and a third web server 110.
  • the contents server 102 is a server operated by a contents transmission provider.
  • the first to third web servers 106, 108, and 110 are operated by a contents provider. Although three web servers are shown in FIG. 1, it is apparent that the number of the web servers can be variously varied.
  • a user pays a bill for contents via web server. For instance, in case of intending to view a movie- A provided by the first web server 106, the user pays the bill for the move-A via the first web server 106. In doing so, user's payment information is stored in the first web server 106 and is transmitted to the authentication server 104 linked to the contents server 102. And, the authentication server 104 stores the received payment information therein. Namely, each of the web servers 106, 108, and 110 providing contents transmits payment information to the authentication server 104 each time the user pays the bill for contents.
  • the corresponding web server provides resource ID (identification) information corresponding to the requested contents to the user client 100.
  • the user client 100 requests the contents corresponding to the resource ID to the contents server 102.
  • user's request information includes information such as ID and the like on the web server.
  • the contents server 102 decides whether the user has paid the bill via communication with the authentication server 104 to transmit the corresponding contents to the user client 100.
  • the conventional authentication method as described above has the following problems or disadvantages. First of all, since each of the web servers of the affiliated contents providers transmits the corresponding payment information to the authentication server each time the corresponding bill is paid, load is excessively put on the authentication server. Secondly, since the payment information is transmitted via network, error may occur in transmitting the payment information to lower the reliance of the payment information stored in the authentication server.
  • the present invention is directed to a ticket-based authentication method that substantially obviates one or more of the problems due to limitations and disadvantages of the related art.
  • An object of the present invention is to provide a ticket-based authentication method, by which a user can be authenticated without a separate authentication server.
  • Another object of the present invention is to provide a ticket-based authentication method, by which a user can be authenticated without a separate commumcation between a contents transmission service provider's server and a contents provider's server.
  • a further object of the present invention is to provide a ticket-based authentication method, by which a user is authenticated using time information included in a ticket. Additional features and advantages of the invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings.
  • a ticket-based authentication method includes the step (a) of receiving a contents request information from the user client, the step (b) of deciding whether a payment for the requested contents is made, and the step (c) of producing a ticket corresponding to the requested contents such that the user client receives the requested contents from the contents server and providing the produced ticket to the user client, the ticket including a publishing time information therein, wherein the user client requests the contents to the contents server by transmitting the ticket provided in the step (c) to the contents server, wherein the contents server transmits the requested contents to the user client after having decided validity of the ticket using the time information included in the ticket, and wherein the ticket provided to the user client is deleted from the user client after having been transmitted to the contents server.
  • a ticket-based authentication method includes a step (a) of receiving data of ticket data, which is produced from the web server and transmitted to the user client, from the user client, the ticket including a publishing time information, a step (b) of deciding validity of the ticket data using the time information included in the ticket, and a step (c) of if the ticket data is valid, deciding contents information included in the ticket data and transmitting the corresponding contents to the user client, wherein the web server decides whether a payment for the request contents is made in case of receiving a contents request information from the user client and then transmits the ticket data corresponding to the requested contents to the user client and wherein the ticket provided to the user client is deleted from the user client after having been transmitted to the contents server.
  • FIG. 1 is a block diagram of a general authentication system according to a related art
  • FIG. 2A is a block diagram of one system applicable to a ticket-based authentication method according to the present invention
  • FIG. 2B is a block diagram of another system applicable to a ticket-based authentication method according to the present invention
  • FIG. 3 A is a block diagram of a module of a contents server according to one preferred embodiment of the present invention
  • FIG. 3B is a block diagram of a module of a contents server according to another preferred embodiment of the present invention
  • FIG. 4 is a block diagram of a module of a web server according to one preferred embodiment of the present invention
  • FIG. 5 is a block diagram of a module of a contents player according to one preferred embodiment of the present invention
  • FIG. 6A is a structural diagram of a ticket according to one preferred embodiment of the present invention
  • FIG. 6B is a structural diagram of an encryption key according to one preferred embodiment of the present invention
  • FIG. 7 is a flowchart of a ticket-based authentication method according to one preferred embodiment of the present invention
  • FIG. 8 is a flowchart of a process for deciding validity of a ticket according to one preferred embodiment of the present invention.
  • FIG. 2A is a block diagram of one system applicable to a ticket-based authentication method according to the present invention.
  • a system applicable to a ticket-based authentication method according to the present invention may include a user client 200, a contents server 202, and a plurality of web servers 204, 206, and 208.
  • a meta- information database 210 can be assembled to the contents server 202.
  • the user client 200 is connected to the contents server 202 via network, where the network can include a wired network such as Internet, a private line, etc.
  • a player for playing back contents is provided to the user client 200.
  • the contents may include moving-picture data such as a movie, animation, drama, and the like and still-picture data such as a cartoon, picture album, and the like.
  • the contents player provided to the user client 200 may be installed according to the ActiveX control format to interoperate with a web browser or may be a dedicated player for contents playback only.
  • a first to third servers 204, 206, and 208 are servers for providing web pages allow a user to request contents. Each of the web servers could be a web server providing a NOD service of a broadcasting station or a web server providing movie contents. Although three web servers are shown in FIG.
  • a plurality of the web servers 204, 206, and 208 just receive user's contents request information only but fail to provide contents in direct.
  • the contents are substantially stored in the contents server 202.
  • the web server 204, 206, or 208 provide ID information of a resource corresponding to the contents requested by the user to the user client. The user client then requests the contents corresponding to the
  • the substantial contents are received from the contents server 202.
  • Address information of the contents server 202 is needed to access to the contents server 202, where the address information may be previously set up in the player provided to the user client 200 or can be provided to the user client 200 by the web server having received the contents request information.
  • the authentication server or database is assembled to the contents server, the corresponding web server transmits the user's payment information to the authentication server, and the authentication of the contents- requesting is performed using the information stored in the authentication server.
  • the related art authentication server is not provided to the contents server 202 of the present invention and none of the web servers 204, 206, and 208 provide the payment information to the contents server.
  • the web server decides whether the user coincides with the one who has paid the bill. If the user coincides with the one who has paid the bill, the corresponding web server produces a ticket for the corresponding contents.
  • the ticket produced by the web server is provided to the user client 200.
  • the user client 200 transmits the ticket received from the web server together.
  • the contents server 202 decides validity of the ticket transmitted from the user client to authenticate the user.
  • the contents server 202 transmits the contents requested by the user to the user client 200.
  • a name of ticket is used in the present invention.
  • the 'ticket' can be replaced by one of various terms such as authentication data, authentication key, and the like.
  • each of the web servers does not transmit the user's payment information for the contents to the authentication server, whereby the corresponding loads of the web and authentication servers can be relieved.
  • the user authentication can be simply performed without developing and combining the protocol for the communications between the authentication server and the web servers.
  • the ticket produced by the web server can be provided to the user at any anytime regardless of count for the pre-determined time assigned to the user after completion of the payment. For instance, in case that the contents are set available for twenty-four hours after completion of the payment, the ticket can be provided to the user within twenty-four hours regardless of its count.
  • the present invention enables to provide more convenience to the user than the authentication method of storing the authentication key in the user client.
  • the ticket information provided to the user client from the web server includes ticket producing time information. In case that a format of the ticket is exposed, the user may be able to access the contents server 202 by illegally producing a ticket equivalent to the ticket provided from the web server.
  • the contents server decides whether the ticket is valid. In doing so, the contents server utilizes the ticket producing time information included in the ticket. A difference between a time of publishing the ticket from the web server and a contents-requesting time to the contents server 202 using the published ticket is considerably short. In other words, little difference may exist between them. Hence, if the difference between them the contents-requesting time lies within a setup error range, the contents server decides that the ticket transmitted from the user is valid. For instance, if the time difference between the time included in the ticket and the contents-requested time lies within ten seconds, the ticket can be decided as valid.
  • the time difference range for deciding the validity can be flexibly set to vary according to a network situation.
  • the time difference range for deciding the validity of the ticket is set relatively long. If the network situation is good, the time difference range is set relatively short. For instance, a value resulting from multiplying a network speed by a prescribed weight can be used as the time difference range. It is apparent to those skilled in the art that other information can be used to decide the validity of the ticket as well as the ticket producing time information. And, it is also apparent to those skilled in the art that other information can be used together with the ticket producing time information to reinforce security. For instance, an IP address of the web server can be used as the information for deciding the validity.
  • FIG. 2B is a block diagram of another system applicable to a ticket-based authentication method according to the present invention.
  • a system applicable to the present invention includes a user client 220, a contents server 222, a plurality of web servers 224, 226, and 228, and a plurality of nodes 232.
  • a meta-information database 230 can be assembled to the contents server 222.
  • Operations of the user client 220, the web servers 224, 226, and 228, and the meta-information database 230 are equivalent to those in FIG. 2A.
  • the system in FIG. 2B further includes a plurality of the nodes 232.
  • a function of the contents server 222 is different from that of the contents server in FIG. 2 A.
  • the contents server 202 in FIG. 2 A decides the validity of the ticket transmitted from the user client and then directly transmits the contents to the user client if the ticket is valid. Yet, after having decided the validity of the ticket, the contents server 222 in FIG.
  • the node may be a cast server storing the contents therein or other user client storing the contents therein.
  • the system disperses to store the contents in a plurality of the nodes 232 to relieve load of the contents server so that the user client 220 can receive the contents from the corresponding node.
  • the received contents are stored in a cache of the specific client.
  • the client storing the contents therein transmits the contents to another client requesting the contents .
  • the contents server 222 manages contents information stored in the respective nodes.
  • the system in FIG. 2B just differs from the system in FIGJA in that the transmission of contents is performed via a plurality of the nodes and plays the same role with the system in FIG. 2A in that the authentication of user is carried out based on the ticket. Namely, if a user requests contents to the web server, the corresponding web server produces a ticket to provide to the user client 220. The user client 220 then transmits the ticket having been provided from the web server to the contents server 222 and requests authentication.
  • FIG. 3A is a block diagram of a module of a contents server according to one preferred embodiment of the present invention and is a module configuration of the contents server of the system shown in FIG. 2 A. Referring to FIG.
  • a contents server may include a ticket authentication module 300, a meta-information providing module 302, a contents transmission module 304, and a contents data storage part 206.
  • the ticket authentication module 300 receives ticket information transmitted from a client and then decides whether the received ticket is valid. As mentioned in the foregoing description of the present invention, the ticket authentication module 300 enables to decide validity of the ticket in a manner of comparing time information included in the ticket to contents server access time information.
  • the ticket authentication module 300 may consider an overall format and size of the ticket instead of the time information for deciding the validity of the ticket.
  • the meta-information providing module 302 extracts meta-information of the contents requested by the user from the meta-information database and then transmits the extracted meta-information to the user client.
  • the meta-information includes information such as a file format, size, and the like of contents. And, the meta- information may further include basic information of the contents such as a copyright proprietor, production data, etc. If the contents can be played back without the meta-information, the meta-information providing module 302 may be excluded from the contents server.
  • resource ID information of contents is included in the ticket transmitted to the contents server from the user client and the contents transmission module 304 transmits the contents corresponding to the resource ID to the user client.
  • the contents server according to another embodiment of the present invention may include a ticket authentication module 330, a meta- information providing module 332, and a node management module 334. Operations of the ticket authentication module 330 and meta-information providing module 332 are equivalent to those of the contents server in FIG. 3A.
  • the contents server in FIG. 3B differs from that in FIG. 3 A in further including the node management module 334.
  • the node management module 334 is operative in managing address information of nodes connected to the contents server and contents information stored in the respective nodes.
  • FIG. 4 is a block diagram of a module of a web server according to one preferred embodiment of the present invention. Referring to FIG.
  • a web server may include a ticket producing module 400, a ticket encryption module 402, an encryption key encrypting module 404, and a web page providing module 406.
  • the ticket producing module 400 is operative in producing a ticket that the user client will present to the contents server in case of receiving the contents request information from the user client when a user requests contents to the web server.
  • FIG. 6A is a structural diagram of a ticket according to one preferred embodiment of the present invention.
  • a ticket according to one embodiment of the present invention may include information such as a provider ID 600, a resource ID 602, a user ID 604, an expiration time 606, and a site name 608.
  • the provider ID 600 means an ID for identifying a web server.
  • the ticket Since contents for a plurality of the web servers, as shown in FIG. 2A and FIG. 2B, are transmitted via the contents server, the ticket needs to include the information indicating which web server has published the corresponding ticket.
  • the resource ID 602 means unique identifier information corresponding to the user-requesting contents. If the user presents the ticket to the contents server, the contents server decides the user-requesting contents by means of the resource ID included in the ticket.
  • the user ID 604 means user ID information in the web server to which the contents are requested.
  • the expiration time 606 means information for a time available for viewing the corresponding contents. When the user having been provided with the ticket presents the ticket to the contents server, the contents server decides that the ticket is not valid if a time point of requesting the contents is behind the expiration time.
  • the expiration time is determined by a time point of paying the bill for the corresponding contents.
  • the site name 608 means a name of site corresponding to the web server having published the ticket. For instance, if the web server is a web server providing a NOD service of a broadcasting station, a name of the corresponding broadcasting station could be the site name.
  • Site name information is not mandatory to be included in the ticket but is a sort of auxiliary or optional information. And, it is apparent to those skilled in the art that various kinds of auxiliary information can be included in the ticket as well as the information in FIG. 6A.
  • the ticket producing module 400 produces a ticket of XML format for certainty in producing the ticket.
  • the ticket encryption module 402 is operative in encrypting the ticket produced from the ticket producing module 400. If a format of the ticket is drained away, the ticket can be illegally used in requesting the contents to the contents server. Hence, the ticket provided to the client is encrypted by the ticket encryption module 402. The ticket encryption is performed using an encryption key. In doing so, various encryption algorithms can be used for the ticket encryption. And, the 3-DES algorithm is applicable to the ticket encryption of the present invention.
  • FIG. 6B is a structural diagram of an encryption key according to one preferred embodiment of the present invention. Referring to FIG. 6B, an encryption key according to one embodiment of the present invention may include information such as a ticket producing time 610 and a message checksum 612.
  • the ticket producing time 610 is a time point of producing the ticket from the web-server to correspond to the user's contents request. As mentioned in the foregoing description, the ticket producing time information included in the encryption key is used as the information for deciding the validity of the ticket in the contents server.
  • the message checksum 612 means a checksum value of ticket data.
  • the checksum value could be a checksum of the ticket data and data included the ticket producing time information.
  • the ticket producing time information is included in the encryption key.
  • the ticket producing time information could be included in the ticket itself according to another embodiment of the present invention.
  • the IP address of the web server can be included in the ticket instead of the time producing time information.
  • both of the ticket producing time information and the IP address of the web server can be included in the ticket. It is apparent to those skilled in the art that various kinds of information for deciding the validity of the ticket can be included in the ticket as well as the ticket producing time information and the IP address of the web server.
  • the encryption key encrypting module 404 is operative in encrypting the encryption key used in encryption of the ticket for security of the ticket data.
  • Various kinds of encryption algorithms can be used in encrypting the encryption key as well.
  • FIG. 5 is a block diagram of a module of a contents player according to one preferred embodiment of the present invention.
  • the contents player may include a ticket storage control module 500, a ticket decryption module 502, a contents decoding module 504, and a user interface module 506.
  • the ticket storage control module 500 is operative in controlling an operation of storing the ticket received from the web server in the user client.
  • the ticket is stored in a volatile memory for the security of the ticket data.
  • the ticket can be stored as a file format in a hard disc and the like of the client.
  • the stored ticket is transmitted to the contents server in case of requesting contents to the contents server.
  • the stored ticket is preferably deleted after having been transmitted to the contents server.
  • the ticket decryption module 502 is operative in decrypting the encrypted ticket provided from the web server.
  • the ticket decryption module 502 decrypts the encryption key encrypted in the web server according to a previously setup decryption algorithm. Once the encryption key is decrypted, the ticket data can be decrypted using the decrypted encryption key.
  • the contents decoding module 504 is operative in decoding the contents data transmitted from the contents server or the node storing the corresponding contents therein after the validity of the ticket has been verified in the contents server.
  • Meta-data transmitted from the contents server prior to the transmission of the contents includes the information of the file format of the contents data.
  • the contents data is decoded according to the decoding algorithm corresponding to the file format.
  • the user interface module 506 delivers the inputted information to the corresponding module so that an operation corresponding to the inputted information can be performed. In doing so, the information can be inputted by means of keyboard, mouse, and other information input means.
  • FIG. 7 is a flowchart of a ticket-based authentication method according to one preferred embodiment of the present invention. Referring to FIG.
  • the user client accesses the web server and then transmits log-in request information including user ID and password to the web server (S700).
  • the web server is a server receiving the user's contents request information to provide various contents such as a VOD service of a broadcasting station, movies, animations, cartoons, and the like.
  • the web server does not transmit the contents to the client in direct but enables the client to receive contents from the contents server.
  • the web server having received the log-in request information of the user client decides whether the user is registered and then transmits log-in response information to the client (S702). After completion of the log-in, the client transmits contents request information to the web server (S704).
  • the user may be able to request the contents in a manner of clicking a contents view button and the like displayed on a web page of the web server.
  • the web server having received the user's contents request information decides whether the user has paid the bill for the contents (S706). If the user does not pay the bill for the contents, the web server transmits a message of payment failure to the client. Although not shown in FIG. 7, a billing process can be performed if the user has not paid the bill payment for the contents. If the user has paid the bill for the requested contents, the web server produces a ticket corresponding to the requested contents (S708). As mentioned in the foregoing description, the ticket may include various information such as provider ID, user ID, expiration time, contents resource ID, and the like.
  • the information for the ticket producing time can be included in the ticket data itself or the encryption key of the ticket data.
  • the web server encrypts the ticket data for security (S710). Although not shown in FIG. 7, a re-encryption for the encryption key used in encryption can be further performed.
  • the web-server transmits the encrypted ticket data to the user client having requested the contents (S712).
  • the user client stores the received ticket data therein. As mentioned in the foregoing description, the user client preferably stores the ticket data in a volatile memory.
  • the user client decrypts the received ticket data (S714). Once the ticket data is decrypted, the client transmits the ticket data to the contents server for a contents request (S716).
  • the client transmits the checksum data and ticket producing time information included in the encryption key as well as the information included in the ticket produced from the web server.
  • address information of the contents server receiving the ticket can be previously set up in the player.
  • the address information of the contents server receiving the ticket can be provided from the web server.
  • the stored ticket data is preferably deleted after the ticket has been transmitted.
  • the contents sever decides validity of the ticket (S718).
  • the contents server enables to decide the validity of the ticket in a manner of deciding whether the difference between the ticket producing time and the time point of requesting the contents lies within the previously setup error range.
  • the IP address of the web server can be used as the information for the validity decision as well.
  • the contents server transmits the contents data to the client (S720).
  • FIG. 7 an overall operation of the system in FIG. 2 A is explained.
  • the steps until the ticket validity deciding step are equivalent to those in Fig. 2A.
  • the contents server provides the node information of the node storing the requested contents to the client and the client then receives the contents data from the corresponding node.
  • FIG. 8 is a flowchart of a process of deciding validity of a ticket according to one preferred embodiment of the present invention. Referring to FIG.
  • the contents server decides a presence or non-presence of validity of the checksum value (S802). If the checksum value is not valid, the contents server decides that the received ticket is not valid (S808). And, the contents server decides whether the difference between the ticket producing time and the time point of requesting the contents lies within the previously setup error range (S804). If the difference of the time is not within the previously setup error range, the contents server decides that the received ticket is not valid (S808). Moreover, the contents server decides whether the contents are requested within the expiration time include in the ticket (S806).
  • the contents server decides that the ticket is valid and then executes the process of providing contents (S810).
  • the ticket validity decision can be executed in various ways. For instance, the ticket validity can be decided by means of the format of the ticket. Alternatively, the IP address of the web server can be used as the validity decision information.
  • the ticket-based authentication method according to the present invention enables to authenticate the user without a separate authentication server, thereby simplifying the system. Moreover, the user can be authenticated without a separate communication between the contents transmission service provider's server and the contents provider's server, thereby the present invention needs not to develop the communication protocol between the authentication server and the web server. While the present invention has been described and illustrated herein with reference to the preferred embodiments thereof, it will be apparent to those skilled in the art that various modifications and variations can be made therein without departing from the spirit and scope of the invention. Thus, it is intended that the present invention covers the modifications and variations of this invention that come within the scope of the appended claims and their equivalents.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The present invention provides a ticket-based authentication method, by which a user can be authenticated without a separate authentication server and by which a user can be authenticated without a separate communication between a contents transmission service provider's server and a contents provider's server. In a system including a user client, at least one web server to which the user client requests contents, and a contents server providing the requested contents to the user client, the present invention includes the step (a) of receiving a contents request information from the user client, the step (b) of deciding whether a payment for the requested contents is made, and the step (c) of producing a ticket corresponding to the requested contents such that the user client receives the requested contents from the contents server and providing the produced ticket to the user client, the ticket including a publishing time information therein, wherein the user client requests the contents to the contents server by transmitting the ticket provided in the step(c), wherein the contents server transmits the requested contents to the user client after having decided validity of the ticket using the time information included in the ticket, and wherein the ticket provided to the user client is deleted from the user client after having been transmitted to the contents server.

Description

AUTHENTICATION METHOD BASED ON TICKET
TECHNICAL FIELD The present invention relates to a ticket-based authentication method, and more particularly, to a method of deciding whether a user, who requests contents to a server providing the contents, has paid a corresponding bill using a ticket.
BACKGROUND ART Lately, a transmission rate of a data network such as Internet has been rapidly sped up. Data transmitted via Internet were mainly a general text or simple image data in the early days. Yet a transmission service of moving picture data needing a wide bandwidth is provided nowadays. Moreover, in the early day, a server providing a web page allowing a user to request contents used to transmit the contents as well. Yet, a service provider just provides the web page to allowing a user to request contents, whereas a substantial transmission of the contents tends to be mostly carried out by a server operated by a contents transmission provider nowadays. As a representative service that professionally provides contents transmission only, there is a CDN (contents delivery network) service. The CDN service is the service for transmitting a great capacity of contents data by minimizing a load put on a server in a manner of being equipped with a plurality of edge servers that are locally distributed as well as a central server. Recently, portal sites providing integrated services tend to interoperate with CDN providers. So, the portal site provides a web page allowing a user to request contents only and the transmission of the corresponding contents is mainly carried out via CDN. As the service such as the CDN transmitting the contents only is provided, a contents transmission provider gets to transmit the contents of a plurality of contents providers, e.g., portal site, broadcasting station, professional movie site, etc. Inevitably, it raises a problem in authenticating whether a user requesting contents to the contents transmission server is the one who has paid a corresponding bill. The problem of user authentication occurs because the contents transmission provider is not allowed to inquire a billing database or user database of the affiliated contents provider. Hence, the authentication of the valid user should be processed through communications with the contents provider. FIG. 1 is a block diagram of a general authentication system according to a related art. Referring to FIG. 1, an authentication system according to a related art may include a user client 100, a contents server 102, an authentication server 104, a first web server 106, a second web server 108, and a third web server 110. The contents server 102 is a server operated by a contents transmission provider. And, the first to third web servers 106, 108, and 110 are operated by a contents provider. Although three web servers are shown in FIG. 1, it is apparent that the number of the web servers can be variously varied. A user pays a bill for contents via web server. For instance, in case of intending to view a movie- A provided by the first web server 106, the user pays the bill for the move-A via the first web server 106. In doing so, user's payment information is stored in the first web server 106 and is transmitted to the authentication server 104 linked to the contents server 102. And, the authentication server 104 stores the received payment information therein. Namely, each of the web servers 106, 108, and 110 providing contents transmits payment information to the authentication server 104 each time the user pays the bill for contents. If the user requests contents to the web server after completion of the bill payment, the corresponding web server provides resource ID (identification) information corresponding to the requested contents to the user client 100. The user client 100 then requests the contents corresponding to the resource ID to the contents server 102. In doing so, user's request information includes information such as ID and the like on the web server. And, the contents server 102 decides whether the user has paid the bill via communication with the authentication server 104 to transmit the corresponding contents to the user client 100. However, the conventional authentication method as described above has the following problems or disadvantages. First of all, since each of the web servers of the affiliated contents providers transmits the corresponding payment information to the authentication server each time the corresponding bill is paid, load is excessively put on the authentication server. Secondly, since the payment information is transmitted via network, error may occur in transmitting the payment information to lower the reliance of the payment information stored in the authentication server.
Thirdly, since a unified protocol should be used between the web server and the authentication server, a separate protocol for the corresponding servers needs to be developed. DISCLOSURE OF THE INVENTION Accordingly, the present invention is directed to a ticket-based authentication method that substantially obviates one or more of the problems due to limitations and disadvantages of the related art. An object of the present invention is to provide a ticket-based authentication method, by which a user can be authenticated without a separate authentication server. Another object of the present invention is to provide a ticket-based authentication method, by which a user can be authenticated without a separate commumcation between a contents transmission service provider's server and a contents provider's server. A further object of the present invention is to provide a ticket-based authentication method, by which a user is authenticated using time information included in a ticket. Additional features and advantages of the invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings. To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described, in a system including a user client, at least one web server to which the user client requests contents, and a contents server providing the requested contents to the user client, a ticket-based authentication method according to the present invention includes the step (a) of receiving a contents request information from the user client, the step (b) of deciding whether a payment for the requested contents is made, and the step (c) of producing a ticket corresponding to the requested contents such that the user client receives the requested contents from the contents server and providing the produced ticket to the user client, the ticket including a publishing time information therein, wherein the user client requests the contents to the contents server by transmitting the ticket provided in the step (c) to the contents server, wherein the contents server transmits the requested contents to the user client after having decided validity of the ticket using the time information included in the ticket, and wherein the ticket provided to the user client is deleted from the user client after having been transmitted to the contents server. To further achieve these and other advantages and in accordance with the purpose of the present invention, in a system including a user client, at least one web server to which the user client requests contents, and a contents server providing the requested contents to the user client, a ticket-based authentication method includes a step (a) of receiving data of ticket data, which is produced from the web server and transmitted to the user client, from the user client, the ticket including a publishing time information, a step (b) of deciding validity of the ticket data using the time information included in the ticket, and a step (c) of if the ticket data is valid, deciding contents information included in the ticket data and transmitting the corresponding contents to the user client, wherein the web server decides whether a payment for the request contents is made in case of receiving a contents request information from the user client and then transmits the ticket data corresponding to the requested contents to the user client and wherein the ticket provided to the user client is deleted from the user client after having been transmitted to the contents server. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention. In the drawings: FIG. 1 is a block diagram of a general authentication system according to a related art; FIG. 2A is a block diagram of one system applicable to a ticket-based authentication method according to the present invention; FIG. 2B is a block diagram of another system applicable to a ticket-based authentication method according to the present invention; FIG. 3 A is a block diagram of a module of a contents server according to one preferred embodiment of the present invention; FIG. 3B is a block diagram of a module of a contents server according to another preferred embodiment of the present invention; FIG. 4 is a block diagram of a module of a web server according to one preferred embodiment of the present invention; FIG. 5 is a block diagram of a module of a contents player according to one preferred embodiment of the present invention; FIG. 6A is a structural diagram of a ticket according to one preferred embodiment of the present invention; FIG. 6B is a structural diagram of an encryption key according to one preferred embodiment of the present invention; FIG. 7 is a flowchart of a ticket-based authentication method according to one preferred embodiment of the present invention; and FIG. 8 is a flowchart of a process for deciding validity of a ticket according to one preferred embodiment of the present invention.
BESTMODE FORCARRYINGOUTTHEINVENTION Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. FIG. 2A is a block diagram of one system applicable to a ticket-based authentication method according to the present invention. Referring to FIG. 2A, a system applicable to a ticket-based authentication method according to the present invention may include a user client 200, a contents server 202, and a plurality of web servers 204, 206, and 208. And, a meta- information database 210 can be assembled to the contents server 202. The user client 200 is connected to the contents server 202 via network, where the network can include a wired network such as Internet, a private line, etc. and a wireless network such as wireless Internet, mobile communication network, satellite communication network, etc. A player for playing back contents is provided to the user client 200. In the present invention, the contents may include moving-picture data such as a movie, animation, drama, and the like and still-picture data such as a cartoon, picture album, and the like. The contents player provided to the user client 200 may be installed according to the ActiveX control format to interoperate with a web browser or may be a dedicated player for contents playback only. A first to third servers 204, 206, and 208 are servers for providing web pages allow a user to request contents. Each of the web servers could be a web server providing a NOD service of a broadcasting station or a web server providing movie contents. Although three web servers are shown in FIG. 2A, these are just exemplary and the number of web server can be variously modified. A plurality of the web servers 204, 206, and 208 just receive user's contents request information only but fail to provide contents in direct. The contents are substantially stored in the contents server 202. In case of receiving the user's contents request information, the web server 204, 206, or 208 provide ID information of a resource corresponding to the contents requested by the user to the user client. The user client then requests the contents corresponding to the
ID to the contents server 202, thereby enabling to receive the corresponding contents. Namely, even if the contents request is made to the web server 204, 206, or
208, the substantial contents are received from the contents server 202. Address information of the contents server 202 is needed to access to the contents server 202, where the address information may be previously set up in the player provided to the user client 200 or can be provided to the user client 200 by the web server having received the contents request information. As mentioned in the foregoing description, in the related art method, in order to decide whether the user requesting the contents to the contents server is the one who is authenticated, the authentication server or database is assembled to the contents server, the corresponding web server transmits the user's payment information to the authentication server, and the authentication of the contents- requesting is performed using the information stored in the authentication server. Yet, in the present invention, the related art authentication server is not provided to the contents server 202 of the present invention and none of the web servers 204, 206, and 208 provide the payment information to the contents server. And, in the present invention, in case that a user requests contents, the web server decides whether the user coincides with the one who has paid the bill. If the user coincides with the one who has paid the bill, the corresponding web server produces a ticket for the corresponding contents. The ticket produced by the web server is provided to the user client 200. In case of requesting the contents to the contents server 202, the user client 200 transmits the ticket received from the web server together. The contents server 202 then decides validity of the ticket transmitted from the user client to authenticate the user. If deciding that the ticket is valid, the contents server 202 transmits the contents requested by the user to the user client 200. A name of ticket is used in the present invention. Yet, the 'ticket' can be replaced by one of various terms such as authentication data, authentication key, and the like. Moreover, it is apparent to those skilled in the art that the replacement or modification of the term can be made without departing from the spirit and scope of the invention. In the present invention, each of the web servers does not transmit the user's payment information for the contents to the authentication server, whereby the corresponding loads of the web and authentication servers can be relieved. And, the user authentication can be simply performed without developing and combining the protocol for the communications between the authentication server and the web servers. Meanwhile, the ticket produced by the web server can be provided to the user at any anytime regardless of count for the pre-determined time assigned to the user after completion of the payment. For instance, in case that the contents are set available for twenty-four hours after completion of the payment, the ticket can be provided to the user within twenty-four hours regardless of its count. Hence, the present invention enables to provide more convenience to the user than the authentication method of storing the authentication key in the user client. In the preferred embodiment of the present invention, the ticket information provided to the user client from the web server includes ticket producing time information. In case that a format of the ticket is exposed, the user may be able to access the contents server 202 by illegally producing a ticket equivalent to the ticket provided from the web server. In order to prevent the contents reception using the illegal ticket, the contents server decides whether the ticket is valid. In doing so, the contents server utilizes the ticket producing time information included in the ticket. A difference between a time of publishing the ticket from the web server and a contents-requesting time to the contents server 202 using the published ticket is considerably short. In other words, little difference may exist between them. Hence, if the difference between them the contents-requesting time lies within a setup error range, the contents server decides that the ticket transmitted from the user is valid. For instance, if the time difference between the time included in the ticket and the contents-requested time lies within ten seconds, the ticket can be decided as valid. The time difference range for deciding the validity can be flexibly set to vary according to a network situation. Namely, the network situation between the client requesting the contents and the contents server is unstable, the time difference range for deciding the validity of the ticket is set relatively long. If the network situation is good, the time difference range is set relatively short. For instance, a value resulting from multiplying a network speed by a prescribed weight can be used as the time difference range. It is apparent to those skilled in the art that other information can be used to decide the validity of the ticket as well as the ticket producing time information. And, it is also apparent to those skilled in the art that other information can be used together with the ticket producing time information to reinforce security. For instance, an IP address of the web server can be used as the information for deciding the validity. And, both of the ticket producing time information and the IP address of the web server can be used as the information for deciding the validity as well. The meta-information database assembled to the contents server 202 stores the meta-information of the contents data therein. The contents meta-information is provided prior to providing the contents data in general. FIG. 2B is a block diagram of another system applicable to a ticket-based authentication method according to the present invention. Referring to FIG. 2B, a system applicable to the present invention includes a user client 220, a contents server 222, a plurality of web servers 224, 226, and 228, and a plurality of nodes 232. And, a meta-information database 230 can be assembled to the contents server 222. Operations of the user client 220, the web servers 224, 226, and 228, and the meta-information database 230 are equivalent to those in FIG. 2A. Compared to the system in FIG. 2A, the system in FIG. 2B further includes a plurality of the nodes 232. And, a function of the contents server 222 is different from that of the contents server in FIG. 2 A. As mentioned in the foregoing description of FIG. 2A, the contents server 202 in FIG. 2 A decides the validity of the ticket transmitted from the user client and then directly transmits the contents to the user client if the ticket is valid. Yet, after having decided the validity of the ticket, the contents server 222 in FIG. 2B provides the user client with node information enabling to provide the user- requesting contents so that the user client can receive the contents from the corresponding node. The node, as shown in FIG. 2B, may be a cast server storing the contents therein or other user client storing the contents therein. Namely, the system, as shown in FIG. 2B, disperses to store the contents in a plurality of the nodes 232 to relieve load of the contents server so that the user client 220 can receive the contents from the corresponding node. In accordance with the system in FIG. 2B, in case that a specific client receives contents, the received contents are stored in a cache of the specific client. The client storing the contents therein transmits the contents to another client requesting the contents . In order to control the transmission/reception between clients or between a client and a cast server, the contents server 222 manages contents information stored in the respective nodes. The system in FIG. 2B just differs from the system in FIGJA in that the transmission of contents is performed via a plurality of the nodes and plays the same role with the system in FIG. 2A in that the authentication of user is carried out based on the ticket. Namely, if a user requests contents to the web server, the corresponding web server produces a ticket to provide to the user client 220. The user client 220 then transmits the ticket having been provided from the web server to the contents server 222 and requests authentication. If the ticket is valid, the contents server 222 provides the information of the node storing the requested contents to the user client 220 so that the user client 220 can receive the corresponding contents from the corresponding node. And, the user client 220 may be connected to one node to receive the contents or can receive the contents from a plurality of the nodes in a manner of parallel/distribution. FIG. 3A is a block diagram of a module of a contents server according to one preferred embodiment of the present invention and is a module configuration of the contents server of the system shown in FIG. 2 A. Referring to FIG. 3A, a contents server according to one preferred embodiment of the present invention may include a ticket authentication module 300, a meta-information providing module 302, a contents transmission module 304, and a contents data storage part 206. The ticket authentication module 300 receives ticket information transmitted from a client and then decides whether the received ticket is valid. As mentioned in the foregoing description of the present invention, the ticket authentication module 300 enables to decide validity of the ticket in a manner of comparing time information included in the ticket to contents server access time information. The ticket authentication module 300 may consider an overall format and size of the ticket instead of the time information for deciding the validity of the ticket. If the ticket authentication module 300 decides that the ticket is valid, the meta-information providing module 302 extracts meta-information of the contents requested by the user from the meta-information database and then transmits the extracted meta-information to the user client. The meta-information includes information such as a file format, size, and the like of contents. And, the meta- information may further include basic information of the contents such as a copyright proprietor, production data, etc. If the contents can be played back without the meta-information, the meta-information providing module 302 may be excluded from the contents server. In one embodiment of the present invention, resource ID information of contents is included in the ticket transmitted to the contents server from the user client and the contents transmission module 304 transmits the contents corresponding to the resource ID to the user client. FIG. 3B is a block diagram of a module of a contents server according to another preferred embodiment of the present invention and is a module configuration of the contents server of the system shown in FIG. 2 A. Referring to FIG. 3B, the contents server according to another embodiment of the present invention may include a ticket authentication module 330, a meta- information providing module 332, and a node management module 334. Operations of the ticket authentication module 330 and meta-information providing module 332 are equivalent to those of the contents server in FIG. 3A. The contents server in FIG. 3B differs from that in FIG. 3 A in further including the node management module 334. The node management module 334 is operative in managing address information of nodes connected to the contents server and contents information stored in the respective nodes. If one (user client or cast server) of the nodes requests contents to the contents server, the ticket authentication module 330 of the contents server preferentially decides whether a ticket transmitted from the client is valid. And then, the node management module 334 then provides list information of the nodes storing the requested contents to the client. Since information of the nodes connected to the contents server and contents information stored in the respective nodes keep being updated, the contents information and the address information of the nodes managed by the node management module 334 keep being updated as well. FIG. 4 is a block diagram of a module of a web server according to one preferred embodiment of the present invention. Referring to FIG. 4, a web server according to one embodiment of the present invention may include a ticket producing module 400, a ticket encryption module 402, an encryption key encrypting module 404, and a web page providing module 406. The ticket producing module 400 is operative in producing a ticket that the user client will present to the contents server in case of receiving the contents request information from the user client when a user requests contents to the web server. FIG. 6A is a structural diagram of a ticket according to one preferred embodiment of the present invention. Referring to FIG. 6A, a ticket according to one embodiment of the present invention may include information such as a provider ID 600, a resource ID 602, a user ID 604, an expiration time 606, and a site name 608. The provider ID 600 means an ID for identifying a web server. Since contents for a plurality of the web servers, as shown in FIG. 2A and FIG. 2B, are transmitted via the contents server, the ticket needs to include the information indicating which web server has published the corresponding ticket. The resource ID 602 means unique identifier information corresponding to the user-requesting contents. If the user presents the ticket to the contents server, the contents server decides the user-requesting contents by means of the resource ID included in the ticket. The user ID 604 means user ID information in the web server to which the contents are requested. The expiration time 606 means information for a time available for viewing the corresponding contents. When the user having been provided with the ticket presents the ticket to the contents server, the contents server decides that the ticket is not valid if a time point of requesting the contents is behind the expiration time. The expiration time is determined by a time point of paying the bill for the corresponding contents. The site name 608 means a name of site corresponding to the web server having published the ticket. For instance, if the web server is a web server providing a NOD service of a broadcasting station, a name of the corresponding broadcasting station could be the site name. Site name information is not mandatory to be included in the ticket but is a sort of auxiliary or optional information. And, it is apparent to those skilled in the art that various kinds of auxiliary information can be included in the ticket as well as the information in FIG. 6A. Preferably, the ticket producing module 400 produces a ticket of XML format for certainty in producing the ticket. The ticket encryption module 402 is operative in encrypting the ticket produced from the ticket producing module 400. If a format of the ticket is drained away, the ticket can be illegally used in requesting the contents to the contents server. Hence, the ticket provided to the client is encrypted by the ticket encryption module 402. The ticket encryption is performed using an encryption key. In doing so, various encryption algorithms can be used for the ticket encryption. And, the 3-DES algorithm is applicable to the ticket encryption of the present invention. FIG. 6B is a structural diagram of an encryption key according to one preferred embodiment of the present invention. Referring to FIG. 6B, an encryption key according to one embodiment of the present invention may include information such as a ticket producing time 610 and a message checksum 612. The ticket producing time 610 is a time point of producing the ticket from the web-server to correspond to the user's contents request. As mentioned in the foregoing description, the ticket producing time information included in the encryption key is used as the information for deciding the validity of the ticket in the contents server. The message checksum 612 means a checksum value of ticket data.
Preferably, the checksum value could be a checksum of the ticket data and data included the ticket producing time information. In FIG. 6A and FIG. 6B, the ticket producing time information is included in the encryption key. Yet, the ticket producing time information could be included in the ticket itself according to another embodiment of the present invention. Moreover, as mentioned in the foregoing description, the IP address of the web server can be included in the ticket instead of the time producing time information. Alternatively, both of the ticket producing time information and the IP address of the web server can be included in the ticket. It is apparent to those skilled in the art that various kinds of information for deciding the validity of the ticket can be included in the ticket as well as the ticket producing time information and the IP address of the web server. • The encryption key encrypting module 404 is operative in encrypting the encryption key used in encryption of the ticket for security of the ticket data. Various kinds of encryption algorithms can be used in encrypting the encryption key as well.
The encryption of the encryption key is to reinforce the security. And, the encryption key encrypting module is optional if necessary. The web page module 406 is a module providing a web page allowing a user to request contents. The web page module 406 transmits web page information including a menu for requesting contents, explanation of the contents, and the like to the client. FIG. 5 is a block diagram of a module of a contents player according to one preferred embodiment of the present invention. Referring to FIG. 5, the contents player according to one embodiment of the present invention may include a ticket storage control module 500, a ticket decryption module 502, a contents decoding module 504, and a user interface module 506. The ticket storage control module 500 is operative in controlling an operation of storing the ticket received from the web server in the user client. Preferably, the ticket is stored in a volatile memory for the security of the ticket data. Yet, it is also apparent to those skilled in the art that the ticket can be stored as a file format in a hard disc and the like of the client. The stored ticket is transmitted to the contents server in case of requesting contents to the contents server. In order to prevent illegal use of the ticket, the stored ticket is preferably deleted after having been transmitted to the contents server. The ticket decryption module 502 is operative in decrypting the encrypted ticket provided from the web server. The ticket decryption module 502 decrypts the encryption key encrypted in the web server according to a previously setup decryption algorithm. Once the encryption key is decrypted, the ticket data can be decrypted using the decrypted encryption key. The contents decoding module 504 is operative in decoding the contents data transmitted from the contents server or the node storing the corresponding contents therein after the validity of the ticket has been verified in the contents server. Meta-data transmitted from the contents server prior to the transmission of the contents includes the information of the file format of the contents data. And, the contents data is decoded according to the decoding algorithm corresponding to the file format. After having received the user-inputting information, the user interface module 506 delivers the inputted information to the corresponding module so that an operation corresponding to the inputted information can be performed. In doing so, the information can be inputted by means of keyboard, mouse, and other information input means. FIG. 7 is a flowchart of a ticket-based authentication method according to one preferred embodiment of the present invention. Referring to FIG. 7, the user client accesses the web server and then transmits log-in request information including user ID and password to the web server (S700). As mentioned in the foregoing description, the web server is a server receiving the user's contents request information to provide various contents such as a VOD service of a broadcasting station, movies, animations, cartoons, and the like. The web server does not transmit the contents to the client in direct but enables the client to receive contents from the contents server. The web server having received the log-in request information of the user client decides whether the user is registered and then transmits log-in response information to the client (S702). After completion of the log-in, the client transmits contents request information to the web server (S704). In doing so, the user may be able to request the contents in a manner of clicking a contents view button and the like displayed on a web page of the web server. The web server having received the user's contents request information decides whether the user has paid the bill for the contents (S706). If the user does not pay the bill for the contents, the web server transmits a message of payment failure to the client. Although not shown in FIG. 7, a billing process can be performed if the user has not paid the bill payment for the contents. If the user has paid the bill for the requested contents, the web server produces a ticket corresponding to the requested contents (S708). As mentioned in the foregoing description, the ticket may include various information such as provider ID, user ID, expiration time, contents resource ID, and the like. And, the information for the ticket producing time can be included in the ticket data itself or the encryption key of the ticket data. After the ticket has been produced, the web server encrypts the ticket data for security (S710). Although not shown in FIG. 7, a re-encryption for the encryption key used in encryption can be further performed. After completion of the ticket encryption, the web-server transmits the encrypted ticket data to the user client having requested the contents (S712). The user client stores the received ticket data therein. As mentioned in the foregoing description, the user client preferably stores the ticket data in a volatile memory. The user client decrypts the received ticket data (S714). Once the ticket data is decrypted, the client transmits the ticket data to the contents server for a contents request (S716). In doing so, the client transmits the checksum data and ticket producing time information included in the encryption key as well as the information included in the ticket produced from the web server. In one embodiment of the present invention, address information of the contents server receiving the ticket can be previously set up in the player. In another embodiment of the present invention, the address information of the contents server receiving the ticket can be provided from the web server. As mentioned in the foregoing description, the stored ticket data is preferably deleted after the ticket has been transmitted. After having received the ticket, the contents sever decides validity of the ticket (S718). As mentioned in the foregoing description, the contents server enables to decide the validity of the ticket in a manner of deciding whether the difference between the ticket producing time and the time point of requesting the contents lies within the previously setup error range. Moreover, the IP address of the web server can be used as the information for the validity decision as well. If the ticket is decided as valid, the contents server transmits the contents data to the client (S720). In FIG. 7, an overall operation of the system in FIG. 2 A is explained. In case of the system in FIG. 2B, the steps until the ticket validity deciding step are equivalent to those in Fig. 2A. After the ticket validity has been decided, the contents server provides the node information of the node storing the requested contents to the client and the client then receives the contents data from the corresponding node. FIG. 8 is a flowchart of a process of deciding validity of a ticket according to one preferred embodiment of the present invention. Referring to FIG. 8, after having received the ticket data from the client (S800), the contents server decides a presence or non-presence of validity of the checksum value (S802). If the checksum value is not valid, the contents server decides that the received ticket is not valid (S808). And, the contents server decides whether the difference between the ticket producing time and the time point of requesting the contents lies within the previously setup error range (S804). If the difference of the time is not within the previously setup error range, the contents server decides that the received ticket is not valid (S808). Moreover, the contents server decides whether the contents are requested within the expiration time include in the ticket (S806). If all of the checksum, ticket producing time, and expiration time are valid, the contents server decides that the ticket is valid and then executes the process of providing contents (S810). In FIG. 8, the example of the ticket validity decision is shown. Hence it is apparent to those skilled in the art that the ticket validity decision can be executed in various ways. For instance, the ticket validity can be decided by means of the format of the ticket. Alternatively, the IP address of the web server can be used as the validity decision information.
INDUSTRIAL APPLICABILITY Accordingly, the ticket-based authentication method according to the present invention enables to authenticate the user without a separate authentication server, thereby simplifying the system. Moreover, the user can be authenticated without a separate communication between the contents transmission service provider's server and the contents provider's server, thereby the present invention needs not to develop the communication protocol between the authentication server and the web server. While the present invention has been described and illustrated herein with reference to the preferred embodiments thereof, it will be apparent to those skilled in the art that various modifications and variations can be made therein without departing from the spirit and scope of the invention. Thus, it is intended that the present invention covers the modifications and variations of this invention that come within the scope of the appended claims and their equivalents.

Claims

WHAT IS CLAIMED IS:
1. In a system including a user client, at least one web server to which the user client requests contents, and a contents server providing the requested contents to the user client, a ticket-based authentication method comprising: a step (a) of receiving a contents request information from the user client; a step (b) of deciding whether a payment for the requested contents is made; and the step (c) of producing a ticket corresponding to the requested contents such that the user client receives the requested contents from the contents server and providing the produced ticket to the user client, the ticket including a publishing time information therein, wherein the user client requests the contents to the contents server by transmitting the ticket provided in the step(c), wherein the contents server transmits the requested contents to the user client after having decided validity of the ticket using the time information included in the ticket, and wherein the ticket provided to the user client is deleted from the user client after having been transmitted to the contents server.
2. The ticket-based authentication method of claim 1, further comprising a step of encrypting the produced ticket using an encryption key.
3. The ticket-based authentication method of claim 2, further comprising a step of encrypting the encryption key according to a prescribed encryption algorithm.
4. The ticket-based authentication method of claim 1, wherein the produced ticket comprises a service provider's ID information, a user ID information, a resource ID information corresponding to the requested contents, and an expiration time information.
5. The ticket-based authentication method of claim 4, wherein the contents server decides whether a difference between a publishing time of the ticket and a time point of requesting the contents lies within a prescribed error range to decide the validity of the ticket.
6. The ticket-based authentication method of claim 3, wherein the encryption key includes information of a producing time of ticket data and wherein the contents server decides whether a difference between the producing time of the ticket data and the time point of requesting the contents lies within a prescribed error range to decide the validity of the ticket.
7. In a system including a user client, at least one web server to which the user client requests contents, and a contents server providing the requested contents to the user client, a ticket-based authentication method comprising: a step (a) of receiving data of ticket data, which is produced from the web server and transmitted to the user client, from the user client, the ticket including a publishing time information; a step (b) of deciding validity of the ticket data using the time information included in the ticket; and a step (c) of if the ticket data is valid, deciding contents information included in the ticket data and transmitting the corresponding contents to the user client, wherein the web server decides whether a payment for the request contents is made in case of receiving a contents request information from the user client and then transmits the ticket data corresponding to the requested contents to the user client and wherein the ticket provided to the user client is deleted from the user client after having been transmitted to the contents server.
8. The ticket-based authentication method of claim 7, the step (b) comprising the steps of: deciding whether a checksum value of the ticket data is valid; deciding whether the ticket publishing time information included in the ticket data lies within a prescribed error range from a time point of requesting the contents; and deciding whether the contents are requested within an expiration time included in the ticket data.
9. The ticket-based authentication method of claim 7, wherein the step (b), a presence or non-presence of the validity of the ticket is decided using at least one selected from the group consisting of an IP address of the web server producing the ticket and the publishing time information of the ticket.
PCT/KR2004/001980 2003-08-06 2004-08-06 Authentication method based on ticket WO2005015429A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020030054392 2003-08-06
KR10-2003-0054392 2003-08-06

Publications (1)

Publication Number Publication Date
WO2005015429A1 true WO2005015429A1 (en) 2005-02-17

Family

ID=34132118

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2004/001980 WO2005015429A1 (en) 2003-08-06 2004-08-06 Authentication method based on ticket

Country Status (1)

Country Link
WO (1) WO2005015429A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010020114A1 (en) * 2008-08-21 2010-02-25 中国移动通信集团公司 Content access authentification method, device and system
WO2011062688A1 (en) * 2009-11-20 2011-05-26 Rovi Technologies Corporation Cross platform gateway system and service
US8631508B2 (en) 2010-06-22 2014-01-14 Rovi Technologies Corporation Managing licenses of media files on playback devices
US9009794B2 (en) 2011-12-30 2015-04-14 Rovi Guides, Inc. Systems and methods for temporary assignment and exchange of digital access rights
US9129087B2 (en) 2011-12-30 2015-09-08 Rovi Guides, Inc. Systems and methods for managing digital rights based on a union or intersection of individual rights
CN114285833A (en) * 2021-12-15 2022-04-05 中国建设银行股份有限公司 WEB terminal resource file access system, device and method

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020064062A (en) * 2001-01-31 2002-08-07 엘지전자 주식회사 Call data management method for internet phone system
KR20020064672A (en) * 2001-02-02 2002-08-09 마쯔시다덴기산교 가부시키가이샤 Content usage management system and content usage management method
KR20030029244A (en) * 2001-10-05 2003-04-14 주식회사 케이티 Method of content protection and delivery on CDN service network and System thereof

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020064062A (en) * 2001-01-31 2002-08-07 엘지전자 주식회사 Call data management method for internet phone system
KR20020064672A (en) * 2001-02-02 2002-08-09 마쯔시다덴기산교 가부시키가이샤 Content usage management system and content usage management method
KR20030029244A (en) * 2001-10-05 2003-04-14 주식회사 케이티 Method of content protection and delivery on CDN service network and System thereof

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010020114A1 (en) * 2008-08-21 2010-02-25 中国移动通信集团公司 Content access authentification method, device and system
WO2011062688A1 (en) * 2009-11-20 2011-05-26 Rovi Technologies Corporation Cross platform gateway system and service
US8631508B2 (en) 2010-06-22 2014-01-14 Rovi Technologies Corporation Managing licenses of media files on playback devices
US9009794B2 (en) 2011-12-30 2015-04-14 Rovi Guides, Inc. Systems and methods for temporary assignment and exchange of digital access rights
US9129087B2 (en) 2011-12-30 2015-09-08 Rovi Guides, Inc. Systems and methods for managing digital rights based on a union or intersection of individual rights
CN114285833A (en) * 2021-12-15 2022-04-05 中国建设银行股份有限公司 WEB terminal resource file access system, device and method
CN114285833B (en) * 2021-12-15 2024-04-09 中国建设银行股份有限公司 WEB terminal resource file access system, device and method

Similar Documents

Publication Publication Date Title
AU2001269856B2 (en) Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (drm)
US7404084B2 (en) Method and system to digitally sign and deliver content in a geographically controlled manner via a network
US9418376B2 (en) Method and system to digitally sign and deliver content in a geographically controlled manner via a network
US7228427B2 (en) Method and system to securely distribute content via a network
US7415721B2 (en) Separate authentication processes to secure content
US7237255B2 (en) Method and system to dynamically present a payment gateway for content distributed via a network
US7389531B2 (en) Method and system to dynamically present a payment gateway for content distributed via a network
US7536563B2 (en) Method and system to securely store and distribute content encryption keys
US6732277B1 (en) Method and apparatus for dynamically accessing security credentials and related information
CN100588198C (en) Access control and key management system for streaming media
US20030063750A1 (en) Unique on-line provisioning of user terminals allowing user authentication
BRPI0614785A2 (en) method, device, computer program product and system for signaling geographical restrictions
AU2001269856A1 (en) Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (drm)
US20100104105A1 (en) Digital cinema asset management system
JP2003519877A (en) A service providing device that allows another device to access unique information recorded on a portable recording medium in which the unique information is recorded, a method thereof, and the recording medium.
JP2003530635A (en) System and method for securely storing confidential information, and digital content distribution device and server used in the system and method
KR20000050106A (en) multimedia streaming service method, and system for the same
JP2008523766A (en) Authority in cellular communication systems
WO2005015429A1 (en) Authentication method based on ticket
KR20050015952A (en) Authentication Method Based on Ticket
KR20020040696A (en) User authentication system and method using the same
AU2007234620B2 (en) Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (DRM)
AU2007234627B2 (en) Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (DRM)

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 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 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 IT 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
32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC (EPO FORM 1205A DATED 28.06.2006)

122 Ep: pct application non-entry in european phase