WO2009047939A1

WO2009047939A1 - Method and system for operating a display system in a public place

Info

Publication number: WO2009047939A1
Application number: PCT/JP2008/063076
Authority: WO
Inventors: Johan Hjelm; Takeshi Matsumura; Shingo Murakami; Toshikane Oda
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2007-10-11
Filing date: 2008-07-14
Publication date: 2009-04-16

Abstract

The present invention provides a system for enabling a display system in a public place to display the information for the specific user having a user identity. The user identity is detected and sent to an authenticating system for authenticating the user. The user profile information and metadata of the user are acquired using the user identity. Media object of the user is acquired using address included in the metadata. The acquired media object is displayed in accordance with the acquired user profile information.

Description

DESCRIPTION

METHOD AND SYSTEM FOR OPERATING A DISPLAY SYSTEM IN A PUBLIC PLACE

TECHNICAL FIELD

[0001] This present invention relates to a method and a system for operating a display system in a public place.

BACKGROUND

[0002] Recently, a digital signage system to display public information on a large screen, which is placed in many public places, such as airports, schools, supermarkets, department stores are increasingly popular in most countries.

[0003] For example, in the airport, the digital signage system provides services of displaying flight numbers, destinations, departure and arrival times, and "on schedule or delayed" flight statuses on large screens. Also, advertisements for alcoholic beverages, perfumes, handbags and like duty-free items is displayed on large screens, which are placed beyond passenger gates in the airport. [0004] In schools, a large screen is usually placed near the front gate, and public information, such as school news, event schedules, weather emergencies, sports scores or announcements are displayed on the screen for students. As a result, students can easily obtain common information regarding schools. [0005] At supermarkets, for example, advertisement of weekly, daily or hourly specials is displayed on a big screen for customers to encourage them to consider certain merchandise for purchase.

[0006] As mentioned on the above, use of public digital signage systems employing large screens in is becoming increasingly commonplace and useful in daily life. A paper, "Overcoming assumption and uncovering practices: when does the public really look at public displays? (Elaine M. Huang et al. Pervasive 2008, LNCS, p228-243, 2008)", shows how such public displays are being used in current and how to increase the visibility of displays and improve the match between peoples behavior and content.

[0007] Fig. 1 shows an example of a simplified conventional digital signage system using a personal computer. This system comprises a content/service provider 11 supplying information to display on a screen, a display system 12 and a cable 1OA to connect between the content/service provider 11 and the display system 12. A wireless communication link can be applied for the connection if the communication capacity of the wireless link is sufficient. [0008] A plurality of the display systems may be connected to the content/service provider by a network system such as Ethernet. In this example, in accordance with a predetermined schedule, a control manager HA of the content/service provider selects information to be shown to the customers, from a content library HB, sends it from a transmitter for upload HC to a receiver for download 12B in the display system 12 via the cable 1OA. [0009] Then the CPU 12A in the display system 12 stores it in a memory 12C as needed in accordance with predetermined program, and transforms it into images or characters via a data bus 1OB, and displays them as information on a screen 12E through a driver for display 12D.

[0010] As mentioned, in general, in existing applications of public display systems, it is a store manager school personnel who decides what information is important and should be displayed on a screen. Thus, the information on display in a public place is always transferred one way - from the manager or the school personnel to customers or students .

[0011] Today, there is no way by which one may interact with signs; for example, to view and receive personalized information in stores. We have not yet realized a display system, which displays personalized information on the screen in a public place after a customer provides a user identity to the display system, and the system retrieves personalized information useful or preferable to the customer. In this case, the customer information flows first from the customer to the display system to check the customer information (or ID) , and then the personalized information for the customer is returned from the display system such as a feedback system. SUMMARY

[0012] The present invention provides simple solutions for displaying personalized information for a specific user on a screen in a public place.

[0013] It is an object of the invention to provide a system for operating a display system in a public place so that the display system can display the information for the specific user (the user has a user identity (User ID) ) . [0014] The system for operating a display system comprises: a user identity memory for storing a user identity; a user identity detecting unit for detecting the user identity from the user identity memory; an authentication system for receiving the user identity to authenticates a user; a user profile database for storing a user profile information for the user and receiving the user identity to output the user profile information corresponding to the user identity; a first metadata memory included in the display system for storing metadata and receiving the user identity to output the metadata; and a media object memory for storing a media object and outputting the media object corresponding to address included in the metadata outputted from the first metadata memory so that the display system display the media object outputted. [0015] For example, the user identity detecting unit uses near-field communication (NFC) , infrared communication

(IrDA) , or similar and reads the identity stored in the user identity memory. For example, the user identity memory is included in a mobile terminal or an IC card. The NFC and

IrDA are well known. Therefore, the detail explanation thereof is not necessary

[0016] This invention has the following advantages:

In a public place, the user can receive timely, personalized or useful information, which fit his/her preferences or needs .

[0017] Further features of the present invention will become apparent from the following description of exemplary embodiments with reference to the attached drawings, in which like reference characters designate the same or similar parts throughout the figures thereof.

BRIEF DESCRIPTION OF DRAWINGS

[0018] Fig. 1 shows an example of an existing concept of a display system in a public place.

[0019] Fig. 2 shows an example of personalizable digital signage systems in the present invention. [0020] Fig. 3 is a block diagram showing how to populate cache memory for a media display when a customer does not access .

[0021] Fig. 4 is a block diagram showing media flows when a customer does not access in the example of personalizable signage system in the present invention. [0022] Fig. 5 shows an example of a flow chart for setting up a media delivery when a customer accesses the personalizable digital signage system in the present invention using near field communication.

[0023] Fig. 6 is a block diagram showing how to set up the session when a customer accesses to the personalizable signage system in the present invention.

[0024] Fig. 7 is a block diagram showing how to deliver the media to the customer after setting up in the present invention.

[0025] Fig. 8 is a block diagram showing how to deliver a coupon to the customer in the present invention.

[0026] Fig. 9 is a block diagram showing how to report statistics after delivering the coupon to the customer in the present invention.

DETAILED DESCRIPTION

[0027] The idea of a display system in a public place in the present invention comes with the following concepts: if we have a system which enables us to provide a way for a user to receive personalized information from a public screen terminal, then this system can be applied at various granularities according to rules embedded in metadata and a user profile.

[0028] For example, if a store manager can provide the customer with the personalized information and/or coupons, then the customer is more likely to purchase the merchandise using the coupons; thus the selected coupons will encourage the customer to purchase the given merchandise. [0029] A personalizable digital signage system as the display system in the present invention can be applied at various granularities according to rules embedded in metadata and a user profile.

[0030] For example, in the airport, where extremely personalized announcement information can be applied; for instance, "Hello Johan, your flight is at 09:30 from gate 12, which is 15 minutes from here if you stop by at the duty free (tax free) store. By the way the DKNY perfume your wife likes is on sale this week - if you buy two you get double points" can be applied. Or the profile information of the customer can be broken down to a very rough granularity in the same airport terminal: "Hello 40+ male gold-card holder. Would you like to view a BMW advertisement now?" Because the profile information is also stored in a decentralized profile system (XDMS, which is standardized) , it can be accessed by third parties (apart from the user and operator as described in the standard) . This can include service providers, but also other third parties, for example, family members.

[0031] The features of the invention will now be described with .reference to the figures, in which similar elements are identified with the same reference numbers. [0032] Fig.2 shows a personalizable digital signage system 22 , a network 21 and a mobile terminal of a customer 23 having a user identity memory in the embodiment of present invention. The mobile terminal includes a user identity (User ID) memory for storing User ID and has near field communication (NFC) unit for the personalizable digital signage system. In this embodiment, the User ID memory is included in the mobile terminal. But the User ID memory can be included in an IC card, which enables communicate with the personalizable digital signage system 22. The network comprises service/network provider 21A and content/service provider 21B. The personalizable digital signage system includes at least a personalizable digital signage controller 22D, a network interface unit 22B, metadata memory such as a cache memory 22A, an NFC read/write 22C for detecting a User ID and a screen 22E, wherein the personalizable digital signage controller 22D can be an ASIC, which contains a microprocessor, memories and logic circuits for managing the personalizable digital signage system, and also has communication links such as a data bus 2OB for transferring data using the network interface 22B, the cache memory 22A, the NFC read/write 22C and the like. The service/network provider 2IA and content/service provider 21B in the network system 21 and the personalizable digital signage system 22 are connected through a network interface 2OA such as LAN, wireless LAN or Firewire (IEEE 1394) .

[0033] The relation between the network interface unit 22B and the cache memory 22A is not special but similar to any network interface: thus, the network interface unit 22B listens for communications through physical medium of the network system. When a communication arrives, it captures the communications wherein the packet address corresponds to its address, de-encapsulates the packet, decodes the flow of bits into alphanumeric, and then passes the alphanumeric symbols to a protocol stack based on the port number of the address, which is a program executed in a processor included in the personalizable digital signage controller in the embodiment. The protocol stack reads the message that the lower layer (the link layer) now has passed to it, and, depending on what the content is, takes appropriate action. One of those appropriate actions may be to pass it to a server program, which decides to store the messages in the cache memory 22A, or it may be to store the content in the cache memory 22A for later retrieval and use.

[0034] The personalizable digital signage controller 22D has the following functions and features: i. Assertion engine ii. Rules engine iii. Local profiles database iv. Media server v. Media client vi. IMS (IP multimedia subsystem) client vii. Presence Client viii. Statistics report How the above function and features work in the personalizable digital signage controller is shown in later.

[0035] CASE A: There is no individual user of the personalizable digital signage system.

[0036] The personalizable digital signage system displays generic content on a screen in a public place. This case can take place at any time (e.g., at night, when there is little traffic) . A further precondition is that a SIP session is already established between the personalizable digital signage system 22 and the network system 21 comprising a service/network provider 21A and a content/service provider 21B in Fig. 2. Authentication and authorization has taken place, as well as all other

IMS-related operations.

[0037] Fig. 3 shows how the population of the cache memory

22A is performed.

[0038] Step 301: Rules for how content is to be displayed are created based on received statistics and other information by a campaign management server 31A. The rules

(which at this stage are business rules) are transmitted to a content provider station 31B.

[0039] Step302: The rules are translated into logic statements, for instance in OWL (Web Ontology Language) , and included in the XML (Extensive Markup Language) documents which describe the media, which can be in for example, SMIL (Synchronized Multimedia Integration Language) . The media and metadata are transmitted to the media library (the assumption being that older media objects can also be addressed and re-used) : a. Note that the system will work with downloaded files in preference of streams since there is an assumption that this can be made more bandwidth-efficient (this is explained further in step 306) ; b. The SMIL description is used to describe when media objects should be played, and how they should be played in relation to each other. SMIL can also contain timing instructions.

[0040] Step 303: Metadata is transferred into the cache memory 22A. This step does not have to be explicit; the system can be triggered by the cache memory 22A receiving a URI through some messaging system (since there is an assumption that it has established a session already) , and then does an HTTP (Hypertext Transfer Protocol) GET from the address concerned (which would be the metadata memory (cache) 31D in this example) : a. There are obvious security concerns with this method which are not discussed here.

[0041] Step 304: The media proxy is populated in the same way as the metadata proxy.

[0042] Step 305: The metadata is populated into the cache memory 22A. Note that this can be done as a triggered download, as described in step 303; or it can be a push of the content into the cache, using for example, FLUTE. [0043] Step 306: The media is populated into the cache memory 22A. The presence of the metadata and the media in the cache triggers the next step.

[0044] The assumption behind this document is that there can be a multitude of individual terminals which display information. There is no strict limitation, and the only constraint on their number is the network. The control language used (based on SMIL) can handle an infinite number of simultaneous terminals, as the commands of what to display are not dependent on the individual terminal. [0045] Note that an additional advantage of this invention is the ability to adapt the composition of the metadata and send an updated document to the cache (which is then parsed and used to re-populate the cache, if required) . Hence, during periods of heavy network load metadata documents which require refreshed media objects can be designed to point to media objects which are less bandwidth-consuming than those which would ordinarily be displayed. [0046] Fig. 4 shows the next steps when the data has been received in the cache.

[0047] Step 401: The metadata is parsed by an assertion engine 41A in the personalizable digital signage controller 22D. This assertion engine 4IA reads the included logic statements and parses them to resolve any conditional statements, which are made in the metadata: a. Such statements may be dependent on the media objects present in the cache, the user profile, the time of day, or other conditions external to the metadata document; b. The conditions which result in assertions may also be dependent on the metadata document itself, that is, the ordering of the display of the media objects by the SMIL document.

[0048] Step 402: The assertion engine 41A delivers its result to a rules engine 41B, which will apply its rules to the metadata document and create a resulting document which is then passed on to a media server 41D. [0049] Step 403: The rules engine 41B retrieves the rules from the profile database B. Since there is no user logged in (i.e., there is a generic IMS user) , the rules are assumed to have been provisioned during the session setup, and the rules are generic: a. Note that profiles database 41C is local profile database in the personalizable digital signage system 22, on the other hand, the central profile database (which is central in the sense that it is placed in the core of the system as shown in Fig. 6. It is assumed to be implemented in a distributed fashion using the XDMS standard) .

[0050] Step 404: The rules are returned to the rules engine

41B. The metadata document is processed (as described in step 402) .

[0051] Step 405: The resulting metadata document is passed to a media server 41D for display.

[0052] Step 406: The media server 41D requests the applicable media objects from the cache memory 22A.

[0053] Step 407: The media server 41D receives the applicable media objects from the cache memory 22A.

[0054] Step 408: The media server 41D passes the ordered media objects (in effect of a stream) to the media client

41E for rendering on the screen 22E.

[0055] Step 409: The media objects are rendered on the screen 22E.

[0056] CASE B: There is an individual user of the personalizable digital signage system.

[0057] In the embodiment of the present invention, an individual user can register to view personalized information, and to receive coupons after watching advertising. While there are alternative methods for doing so (e.g. , photographing a QR code which is resolved and sent to the data center, and a session then set up to the terminal) , the method described here assumes that the user has a mobile phone, which is enabled to use near-field communication to identify the user.

[0058] The main procedures for setting up and delivering personalized information to the individual user are shown in Fig. 5.

[0059] F501: First, a customer holds his mobile terminal

(23) over a NFC read/write unit 22C in the personalized signage system, and then near field communication (NFC) link is established between the NFC read/write unit (23A) of the mobile terminal and the NFC read/write unit 22C.

[0060] F502: The NFC read/write unit 22C reads out a unique user identity and other pertinent information from the mobile terminal (23) .

[0061] F503: The personalized signage controller (22D) sets up a central session management system, for example, the IMS core system (61A) which is housed in a service/network provider (21A) . The IMS core system (61A) has a function of an authentication system

[0062] F504: The personalized signage controller (22D) requests profile information, which contains media preferences of the user, from a central profile database

(61C) in the service/network provider (21A) , and receives the profile information from the central profile database

(61C) .

[0063] F5Q5: The personalized signage controller (22D) requests and receives metadata of the customer by checking the cache (22B) if metadata is available.

[0064] F506: The personalized signage controller (22D) requests and receives media objects using addresses of the media objects, which are included in the metadata by communicating with the download server (31E) having a media object memory in the service/network provider (21A) .

[0065] F507: The personalized signage controller (22D) analyzes the metadata and media objects, and as a result, displays the personalized information in accordance with a determined sequence of the media objects on the screen of the display (22F) .

[0066] F508: After the customer finishes viewing the sequence of the media objects, the personalized signage controller (22D) looks up the metadata contents and determines how a coupon is to be constructed. Then, the personalized signage controller (22D) sends the determined coupon to the NFC read/write unit (22C) , and the coupon is delivered to the mobile terminal (23) via the established

NFC link.

[0067] F509: The personalized signage controller (22D) generates a statistics report and sends it to a statistics collection function (91A) in the service/network provider

(21A) , and the statistics collection function forwards it to a campaign management system (31A) in the content/service provider (21B) .

[0068] Now, the detailed steps of delivering the personalized information will be explained. For the user, the registration of the session is completely invisible.

The registration process is shown in Fig. 6.

[0069] Step 601: The user walks up to a display and holds his NFC enabled device to the reader/writer. The unique identity of the NFC device is read out, together with other pertinent information: a. While it is assumed that the only information required to realize this use case is the unique identity, which is assumed to be an IMS user identity (public or private) , the information read out can potentially be any type of information which can be stored on a card. Additional profile information could be read out and included in the profile processing (in essence, between step 614 and 615 below) .

[0070] Step 602: The IMS identity is transported to the IMS client 62A.

[0071] Step 603 : The IMS client 62A starts to set up a session with the IMS core system 61A in a authentication system 61, which authenticates a user.

[0072] Step 604: The session has been set up.

[0073] Step 605: Having set up the session, the IMS client

62A triggers the presence client 62B to register in the presence server 61B of the authentication system 61.

[0074] Step 606: The presence client 62B registers in the presence server 61B using standard protocols.

[0075] Step 607: And then, receives a confirmation.

[0076] Step 608: Having registered in the presence server

61B, the presence client 62B hands over the profile information which can be derived from local presence client

62B to the local profile database 41C.

[0077] Step 609: The local profile database 41C requests further profile information from the central profile database 61C, which stores user profile information for the user. a. A more advanced profile system than is described here, for instance OMA XDMS, is probably used. However, in that case, a request will be sent to the authorization proxy, and it will receive data as described in this ID.

[0078] Step 610: The profile information, which includes rules which the user intends to apply, are retrieved from the central profile database 61C into the local profile database 41C. This retrieval can be done as an HTTP GET, as described in Step 609a.

[0079] When the user session is set up, media specific to the user can be retrieved. This also assumes that metadata which is specific to the user, or at least the generic demographic of the user, is used. The process will be shown in Fig.7.

[0080] Step 701: The profile information, which contains the media preferences of the user, is provided from the local profile database 41C to the media server 41D. [0081] Step 702: The media server 41D requests resolution of the profile by the rules engine 41B.

[0082] Step 703: The rules engine 41B reads the profile from the local profile database 41C.

[0083] Step 704: And then gets back to the local profile database 41C.

[0084] Step 705: The rules engine 41B then provides a resolved version of the profile (i.e., one where the rules have been applied, such as what information can be sent on by the statistics reporting function 71A, and with which granularity) to the media server 4ID. [0085] Step 706: The media server 41D checks the cache memory 22A for metadata and media.

[0086] Step 707: Assuming no metadata is present, the following steps will be applied. If metadata is present, step 712 will be applied.

[0087] Step 708 : The media server 41D requests metadata from the cache memory 22A: a. If the metadata is in the cache, it is fresh (latest) (according to RFC 2616) , and no retrieval is necessary, it will be served from the cache memory 22A to the media server 4ID; b. If the metadata is not fresh, step 709 takes place.

[0088] Step 709: The metadata is retrieved by the cache memory 22A: a. If the metadata in the cache memory 22A is not fresh, it will be retrieved from the metadata cache 31D into the cache memory 22A and served to the media server 41D. In step 709 a, a request is sent to the metadata cache 31D; b. A response is sent to the cache memory 22A. Then this serves the metadata requested in step 708a to the media server 41D.

[0089] Step 710: The metadata contains addresses to media objects which should be retrieved. The cache memory 22A requests these from the download server 31E including a media object memory for storing a media object. [0090] Step 711: and then the cache memory 22A receives the requested media objects from the download server 31E.

[0091] Step 712: The metadata is handed to the assertion engine 4IA by the media server 4ID which hands the document to the assertion engine 4IA after having retrieved it from the cache memory 22A.

[0092] Step 713 : The assertion engine 41A resolves any logic statements included in the metadata, and delivers them to the rules engine 41B.

[0093] Step 714: The rules engine 41A applies the rules and assertions to the metadata document, and delivers it to the media server 41D. In essence, the document now consists of the addresses of a sequence of media objects, possible with included overlays (audio, text, graphics, or video overlays) which can include user information such as name, status in bonus program, and the like.

[0094] Step 715: The media server 41D passes the metadata document to the media client 41E, which will prepare it for rendering by chaining the objects, including any overlays which may be applicable, and the like.

[0095] Step 716: The media client 41E requests the media objects from the cache memory 22A.

[0096] Step 717: The media objects are delivered from the cache memory 22A to the media client 4IE.

[0097] Step 718: The media client 41E sends the composed stream to the screen 22E for the user to view.

[0098] Step 719: A notification is sent to the statistics reporting system 7IA.

[0099] In the system, the metadata can be adapted to the transport (as described in a separate document) . The metadata, being used as a composition guide, creates the content stream based on the cache memory 22A (hence, it is not an EPG) .

[0100] Fig. 8 shows how to deliver a coupon for the individual user in the embodiment of the invention. When the user has viewed the media, he/she can receive a coupon on his NFC-enabled device. Note that if this device does not have a writable NFC card, the coupon can be stored in the users profile. That method is not described here. The coupon delivery proceeds as follows:

[0101] Step 801: The media client 41E sends notification that the user has finished viewing the media object to the rules engine 41B: a. This can possibly be accompanied by a message to the user, for example, saying "Thank you for your patience. As a small token of our appreciation, we'd like to offer you this coupon toward a future purchase".

[0102] Step 802: The rules engine 41B queries the profile database 41C for the user profile.

[0103] Step 803: The profile database 41C returns the profile. This includes both rules, and other information (such as encryption keys) which may be required: a. In case the coupon is not stored on the card, the process will, in step 806, not update the NFC device in the phone, but update the local profile database B. This would then be synchronized with the profile database L through some means which are not more precisely described here, but which could involve SIP SUBSCRIBE-NOTIFY, SynchML, or other means .

[0104] Step 804: The rules engine 41B looks up the metadata in the cache memory 22A to find out what the coupon consists of, and how it is structured. This includes redemption criteria, data, value, and all relevant information. [0105] Step 805: The relevant metadata is sent to the assertion engine 41A to extract any assertions containing the information outlined in step 802.

[0106] Step 806: The assertion is returned from the assertion engine 41A to the rules engine 41B. [0107] Step 807: The rules engine 41B draws the necessary conclusions about how the coupon should be designed, and forwards the finished coupon to the NFC reader/writer 22C. [0108] Step 808 : The NFC reader/writer 22C writes the coupon to the users NFC-enabled phone 23.

[0109] Step 809: The NFC reader/writer 22C sends a report to the statistics reporting system 71A.

[0110] Statistics can either be reported on a real-time basis, that is, as soon as an advertisement has been displayed to a user; or in an aggregated fashion, that is, when the traffic situation in the network allows it, or when it is appropriate from a business purpose.

[0111] In the simplest form, the statistics report basically includes the user identity and the information that a program was watched and a coupon downloaded. It may also include other information, such as when the user watched the content, and the location of the terminal where the content was viewed, other relevant information such as the temperature of the location, the presence of other users, and so on.

[0112] Fig. 9 shows how to report the statistics in this embodiment. The statistics reporting will in either case proceed as follows:

[0113] Step 901: The statistics reporting system 71A sends the statistics to the statistics collection function 91A in the service network provider 21A: a. This can be done in several ways. i. Use SIP SUBSCRIBE-NOTIFY, with the statistics sent in the NOTIFY (alternatively, a URI where they can be retrieved) ; ii. Periodic polling by the statistics collection function P, for example, using HTTP GET. iii. Periodic updates by the statistics reporting function M, by doing an HTTP POST or PUT to the statistics collection function P. iv. Sending the statistics over email, MMS, or similar. b. Before the statistics are reported, an algorithm can be applied to them, for example, to anonymize, aggregate, or otherwise process them.

[0114] Step 902: The statistics are forwarded to the campaigning management system Q by the statistics collection function P. a. Before they are forwarded, the statistics can be further anonymized, collated, aggregated or otherwise operated on to make sure that they can be used to derive a comprehensive representation.

[0115] Step 903: The statistics are turned into business rules, and the business rules are forwarded to the content provider station T, starting the process which begins in step 301 of Fig.3.

[0116] While the principles of the invention have been described above in connection with the embodiment, it is clearly understood that this description is made only by way of the example and not as a limitation on the scope of the invention.

Claims

1. A method for operating a display system in a public place, which can communicate with a user identity memory (23) for storing a user identity, an authentication system (61A) which authenticates a user, a user- profile database (61C) which stores user profile information for the user, and a media object memory (31E) for storing a media object, the display system including a first metadata memory (22A) for storing metadata, the method comprising the steps of: detecting the user identity from the user identity memory (23) (F502) ; sending the user identity to the authenticating system (61A) for authenticating the user (F503) ; using the user identity for acquiring the user profile information from the user profile database (61C) corresponding to the user identity (F504) ; using the user identity for acquiring metadata of the user from the first metadata memory (22A) (F505) ; using address included in the metadata for acquiring media object of the user from the media object memory (31E) (F506) ; and displaying the acquired media object in accordance with the acquired user profile information.

2. A method as claimed in claim 1, wherein the detecting the user identity is done using near field communication (NFC) or infrared communication (IrDA), and reading the user identity stored in the user identity memory (23) .

3. A method as claimed in claim 2, wherein the user identity memory (23) is included in a mobile terminal.

4. A method as claimed in claim 2, wherein the user identity memory (23) is included in an IC card.

5. A method as claimed in claim 1, wherein the user identity is IP Multimedia Subsystem (IMS) identity, the display system further includes an IMS client (62A), the authenticating system includes and IMS core (61A) , and the IMS client (62A) transports the IMS identity to the IMS core (61A), and then the IMS client (62A) sets up session with the IMS core (61A) .

6. A method as claimed in claim 5, wherein the display system further includes a presence client (62B), the authenticating system further includes a presence system (6lB), after the IMS client (62A) has set up the session with the IMS core (61A), the presence client (62B) registers in the presence system (61B).

7. A method as claimed in claim 6, wherein after the presence client (62B) has registered the presence system

(61B), the user profile information is acquired from the user profile database (61C) .

8. A method as claimed in claim 1, wherein the display system can communicate with a second metadata memory (31D) , and if the first metadata memory (22A) does not have fresh metadata of the user, the fresh metadata is retrieved from the second metadata memory (31D) .

9. A method as claimed in claim 1, wherein the first metadata memory (22A) is a cache memory.

10. A method as claimed in claim 8, wherein the second metadata memory (31D) is a cache memory.

11. A method as claimed in claim 1, wherein the first metadata memory (22A) is a cache memory.

12. A method as claimed in claim 1, further comprising a step of issuing coupon to the user in accordance with the metadata.

13. A system for operating a display system in a public place, comprising: a user identity memory (23) for storing a user identity; a user identity detecting unit (22C) for detecting the user identity from the user identity memory (23) ; an authentication system (61) for receiving the user identity to authenticates a user; a user profile database (61C) for storing a user profile information for the user and receiving the user identity to output the user profile information corresponding to the user identity; a first metadata memory (22A) included in the display system for storing metadata and receiving the user identity to output the metadata; and a media object memory (31E) for storing a media object and outputting the media object corresponding to address included in the metadata outputted from the first metadata memory so that the display system display the media object outputted.

14. A system as claimed in claim 13, wherein the user identity detecting unit (22C) uses near field communication (NFC) or infrared communication (IrDA) , and reads the identity stored in the user identity memory (23) .

15. A system as claimed in claim 14, wherein the user identity memory (23) is included in a mobile terminal.

16. A system as claimed in claim 14, wherein the user identity memory (23) is included in an IC card.

17. A system as claimed in claim 13, wherein the user identity is IP Multimedia Subsystem (IMS) identity, the display system further includes an IMS client (62A), the authenticating system includes an IMS core (61A) , and the IMS client (62A) transports the IMS identity to the IMS core (61A) then the IMS client (62A) sets up session with the IMS core (61A) .

18. The system as claimed in claim 17, wherein the display system further includes a presence client (62B), the authenticating system further includes a presence system (61B), after the IMS client (62A) has set up the session with the IMS core (61A), the presence client (62B) registers in the presence system (61B) .

19. A system as claimed in claim 18, wherein after the presence client (62B) has registered the presence system

(61B), the user profile information is acquired from the user profile database (61C).

20. A system as claimed in claim 13, further comprising a second metadata memory (31D) , and if the first metadata memory (22A) does not have fresh metadata of the user, the fresh metadata is retrieved from the second metadata memory (31D) .

21. A system as claimed in claim 13, wherein the first metadata memory (22A) is a cache memory.

22. A system as claimed in claim 20, wherein the second metadata memory (31D) is a cache memory.