JP4401922B2 - Mobile terminal device - Google Patents

Description

  The present invention relates to a mobile terminal device such as a mobile phone capable of receiving content distribution by separate delivery.

In recent years, so-called third-generation mobile phone services are being introduced. In this third-generation mobile communication system, standardization is being promoted so that the same mobile terminal can be used in common all over the world. The WAP (Wireless Application Protocol) and MMS (Multimedia Messaging Service) standards are adopted as common specifications (Non-patent Document 1). Hereinafter, a mobile terminal compatible with WAP and MMS is simply referred to as a “WAP compatible terminal”.
In such a WAP-compatible terminal, copyright management conforming to OMA DRM (OMA Digital Rights Management) version 1.0 is performed. OMA DRM is a digital rights management (DRM) specification established by the Open Mobile Alliance, which is a mobile phone application standardization organization (Non-Patent Document 2).

In OMA DRM ver1.0, there are 3 content delivery methods: (1) Forward Lock, (2) Combined Delivery, and (3) Separate Delivery. There are two specifications.
(1) Forward lock is a method that does not allow transfer of acquired content.
(2) Combined delivery is a method of delivering content by adding rights (setting of usage rights) to forward lock content.
(3) Separate delivery includes encrypted content (Media Object: media object, MO) and right + key (key for decryption) part (Rights Object: rights object, RO). ) Are distributed separately. Here, the media object is distributed to the mobile terminal by various methods such as downloading from the web, acquisition from the memory card storing the content, and attachment to an e-mail, and the rights object is distributed by WAP push. On a mobile terminal, the contents can be used only when the media object and the rights object are arranged.
The WAP Forum Ltd., "WAP 2.0 Technical White Paper", [on line], (2002.01.18), [Search April 28, 2004], Internet <URL: http://www.wapforum.org/ what / WAPWhite_Paper1.pdf> Open Mobile Alliance, "OMA Digital Rights Management version 1.0", [on line], [Search April 28, 2004], Internet <URL: http://www.openmobilealliance.org/tech/release.html>

As described above, in separate delivery, encrypted content (MO) and a key (Rights Object: RO) necessary for decrypting the content are separately transmitted to the mobile terminal.
For example, when the user presses a decision button indicating that he / she is browsing web content and wants to purchase the content, (1) the server transmits the content to the mobile terminal, (2) the mobile terminal completely acquires the content When the download is completed, a download completion notification (InstallNotify) is sent to the server. (3) The server that has received the download completion notification transmits a rights object to the mobile terminal by WAP push. (4) Mobile terminal After the acquisition of the rights object, the server performs billing processing (in the case of paid content), and is distributed in a series of procedures.

However, in OMA DRM ver1.0, there is a restriction regarding the user interface (UI) of the mobile terminal during the period (hereinafter referred to as “period A”) after the end of the above (2) and before the transmission of (3). It does not stipulate that Therefore, in the period A, the user of the mobile terminal may not be able to cancel the content download on the UI. However, even if the cancellation is performed on such a UI, the server transmits the rights object to the mobile terminal and performs the charging process as usual. In other words, the OMA regulations have a problem that the user of the mobile terminal gives an impression that the user has canceled the purchase of the content even though the billing process is actually performed.
Accordingly, an object of the present invention is to provide a mobile terminal device that does not give a misunderstanding to the user regarding the purchase or acquisition of content.

In order to achieve the above object, a mobile terminal device capable of receiving content distribution by separate delivery according to the present invention sends a media object download completion notification or a rights object delivery request to a server that delivers rights objects. Until the reception of the rights object is completed, or until the estimated time required until the rights object specified in the header information included in the HTTP response is pushed to the mobile terminal device elapses. In the meantime, the cancel button that was displayed to cancel the acquisition of the content or rights object on the display unit is hidden, and the operation of the power off key and the end key in the key input unit is disabled . It is characterized by that.

According to the mobile terminal device of the present invention, in the separate delivery, while the cancel button is displayed on the display screen while the acquisition of the content or the rights object can be stopped, the process proceeds to the stage where it cannot be stopped. Then, since the cancel button is not displayed on the display screen, the user cannot perform an operation for canceling the acquisition of the content or the rights object.
Therefore, in the period during which the acquisition of the content or the rights object cannot be canceled, the user is not given an impression that the user can cancel.
In addition, the operation of the power-off key and the end key must be disabled during the period from when the content download completion notification or rights object distribution request is sent until the rights object is completely received or until a predetermined time has elapsed. Accordingly, it is possible to prevent the user from arbitrarily stopping the reception of the rights object.

FIG. 1 is a block diagram showing an outline of a hardware configuration of a mobile terminal apparatus (hereinafter simply referred to as “mobile terminal”) of the present invention.
The mobile terminal 1 of the present invention is the WAP-compatible terminal described above. As shown in FIG. 1, the mobile terminal 1 includes an antenna 21, a radio communication unit 22 including a radio reception unit and a radio transmission unit, audio signal processing, baseband signal processing, A signal processing unit 23 for performing transmission, a microphone 24 for transmission, a speaker 25 for reception, a control unit 26 for controlling the entire mobile terminal, a memory 27 for storing various programs such as a control program and a program for downloading contents, and various data. , A display unit 28, a key input unit 29, and the like. The hardware configuration of the mobile terminal 1 is the same as that of a normal mobile terminal.

FIG. 2 is a block diagram showing a main configuration of a mobile communication system to which the mobile terminal 1 of the present invention is connected.
In this figure, 1 is the mobile terminal (MS), 2 is a mobile communication network (3G mobile network) in which the mobile terminal 1 is accommodated, and 3 is a gateway between the mobile communication network 2 and an IP network such as the Internet. (GGSN: Gateway GPRS Support Node) 4 is a short message service center (SMSC) for delivering a short message to the mobile terminal 1.
Reference numeral 5 denotes a WAP gateway (WAP-GW: WAP-Gateway) which is a node for converting the WAP 2.0 protocol and HTTP (HyperText Transfer Protocol) used with the mobile terminal 1, and 6 is a WAP push or mail notification. It is a push proxy gateway (PPG) that executes push services such as distribution.
Reference numeral 7 denotes a Web gateway (WGW) that is provided between the WAP-GW 5 and the Internet 11 and mediates a request from the mobile terminal 1, and relates to management of a service registration state and billing for an information amount. It also has a processing function.

Reference numerals 8, 9 and 10 denote a group of servers constituting a DRM platform for providing a DRM usage service.
Here, reference numeral 8 denotes a DRM transaction management server (DRMMS: DRM Transaction Management Server) that performs DRM content transaction management, and performs control of requests from the mobile terminal 1 and state management in communication with the mobile terminal 1.
9 is a license server (LS) that generates and manages rights objects (RO) based on the registered rights information, and 10 is a package that controls the registration of content information and the accompanying rights information. A packaging server (PS).

11 is the Internet, and 12 is a server (CP: Contents Provider / Contents Partner) that provides contents.
CP12 is provided with a packaging tool for performing a series of processing (packaging) for converting content into a DRM compatible format, and the content is packaged in cooperation with the PS10 or the like. The content file (media object) can be created. This content file is a DRM content format (DCF: DRM Content Format) file (hereinafter referred to as a “DCF file”), and is composed of an unencrypted header portion and an encrypted content portion. ing.

When there is a content distribution request from the mobile terminal 1, in separate delivery, the content (media object MO) and its rights object (RO) are distributed separately.
The media object (MO) is downloaded from the CP 12 using HTTP according to a download method (OMA download) defined by OMA. In this system, it is possible to notify what content is to be acquired in advance by acquiring a download descriptor (DD) before downloading the content. In addition, after the download is completed, a download completion notification (Install Notify) can be sent to an arbitrary URL.
On the other hand, the rights object (RO) is sent from the license server LS9 to the PPG 6 under the control of the DRMTMS 8, and the same as the SMS (Short Message Service) to the mobile terminal 1 via the PPG 6 and the SMSC 4. Push distribution is performed in a system (WAP push). As described above, the rights object cannot be acquired from the license server installed by the mobile communication carrier unless it is based on the WAP push.
There are two types of separate delivery: the case where the mobile terminal 1 receives the content (media object) and the rights object through a series of processing, and the case where the content is acquired in advance and only the rights object is received. is there.

FIG. 3 is a diagram showing a sequence when the mobile terminal 1 receives the content and its rights object through a series of processes, and FIG. 4 shows the transition of the screen displayed on the display unit 28 of the mobile terminal 1 at that time. It is a figure which shows an example. The control of this screen is performed by the control unit 26.
The mobile terminal 1 is connected to the Internet 11 according to the WAP sequence, accesses the CP 12 using a browser or the like, and selects the content download from the content download screen provided by the CP 12 (41 in FIG. 4). Then, a download descriptor (DD: Download Descriptor) acquisition request “Request (download descriptor)” for downloading the content (MO) is sent to the network (NW) ((1) in FIG. 3).
This request is relayed by the WAP-GW 5 and transferred to the DRMTMS 8. The DRMTMS 8 creates a download descriptor for downloading the requested content and transmits it to the mobile terminal (“Response (download descriptor) ").

Upon receiving the download descriptor, the mobile terminal 1 analyzes the download descriptor ((2) in FIG. 3).
The download descriptor includes metadata (content name, size, type, version, etc.) regarding the content (MO), a URL (ObjectURI) indicating the location of the content, a URL (InstallNotifyURI) that is a notification destination of the status report, and the like Is a file in which is described. Note that ObjectURI is an address in CP12, and InstallNotifyURI is an address in DRMTMS8.
As a result of analyzing the download descriptor, if an error such as size not being able to download to the mobile terminal 1 is detected, the download descriptor is discarded, the error is notified to InstallNotifyURI, and "Request" (download descriptor) "is returned to the previous screen (download screen 41 in FIG. 4).

If normal, screen A (42 in FIG. 4) showing the contents is displayed based on the download descriptor, and the user is inquired whether download is possible ((3) in FIG. 3).
Here, if the user operates the NO button, the download screen 41 is returned to without downloading.
When the user operates the YES button, the content (MO) acquisition request “Request (Media Object)” is sent to the URL (ObjectURI) indicating the location of the content included in the download descriptor. It is sent out ((4) in FIG. 3).
Then, instead of the screen A (42 in FIG. 4), a screen B (43 in FIG. 4) indicating that content is being acquired is displayed. On this screen B, as shown in the figure, a display (in this example, a progress bar) indicating a progress state of the content acquisition process and a cancel button are also displayed.

The content acquisition request “Request (Media Object)” is transferred to the CP 12 where the content (MO) is stored, and the “Response (Media Object)” including the content requested from the CP 12 is transmitted using HTTP. Returned to the mobile terminal 1 (OMA download).
At this time, the progress of the download is displayed on the screen B (43 in FIG. 4). Here, when the user wants to cancel the download, the download of the content can be canceled by operating the displayed cancel button. When the cancel button is operated, the download of the content is stopped and the screen A (42 in FIG. 4) is returned.
After receiving the content (MO), the mobile terminal 1 determines whether or not the object is an invalid object that cannot be used by itself ((5) in FIG. 3). Notify that there is an error and return to the download screen (41 in FIG. 4) before sending “Request (download descriptor)”.

If it is not an invalid object, a download completion notification “Request (InstallNotifyURI)” (Install Notify Sucess) is sent to InstallNotifyURI ((6) in FIG. 3).
At this time, the control unit 26 changes the display screen from the screen B (43 in FIG. 4) to the screen C (44 in FIG. 4). As is clear from the comparison between screen B and screen C, the cancel button is no longer displayed on screen C. In this screen C, even if the user tries to stop the distribution of content, the user can perform the operation. It is made impossible.

The download completion notification “Request (InstallNotifyURI)” is sent to the DRMTMS 8 (described in InstallNotifyURI), and the DRMTMS 8 returns a response “Response (InstallNotify)” and the media object from the license server (LS) 9. The rights object (RO) corresponding to is received, and the rights object is transmitted to the PPG 6 to be pushed to the mobile terminal 1. The PPG 6 that has received the rights object pushes the rights object to the mobile terminal 1 via the SMSC 4 (WAP push).
In this way, the download completion notification “Request (InstallNotifyURI)” is used as a trigger to start processing for push distribution of a rights object by the DRMTMS 8. When the push distribution (WAP push) process is activated, the process cannot be stopped from the mobile terminal 1, so that the cancel button is not displayed on the screen C (44 in FIG. 4) as described above. ing.

After receiving the response “Response (InstallNotify)” from the DRMTMS 8 ((7) in FIG. 3), the mobile terminal 1 receives the rights object transmitted by the WAP push ((8) in FIG. 3). Then, a delivery status notification “Delivery Receipt (Rights Object)” is created and sent to the PPG 6 ((9) in FIG. 3).
When the reception of the rights object is completed, a screen D (45 in FIG. 4) for indicating whether or not to reproduce the content is displayed and the user is notified of the completion of the reception. ((10) in FIG. 3). On the other hand, when reception of the right content is not completed within the set time, a screen E (46 in FIG. 4) indicating that is displayed.
As described above, since the distribution of the rights object (RO) is performed after the distribution of the content (MO) by a method different from the content, there is a possibility that there is a delay until the distribution is completed. Therefore, as will be described later, when the scheduled time required until the rights object is push-distributed is specified, and reception of the rights object is not completed even after the time has elapsed, screen E (46) is displayed. , The fact that the reception of the rights object has not been completed is displayed.

  When the PPG 6 receives the delivery status notification “Delivery Receipt (Rights Object)” from the mobile terminal 1, the PPG 6 creates a delivery result notification “Delivery Report” according to the content, and transmits it to the DRMTMS 8. The DRMTMS 8 transmits a billing notification to the WGW 7 and performs billing processing only when the rights object has been successfully distributed.

FIG. 5 is a flowchart showing a processing flow of the control unit 26 after receiving a content (MO) download descriptor from the DRMTMS 8. In addition, (A)-(E) in the figure has shown that the corresponding screen in FIG. 4 is displayed.
As described above, when the download descriptor “Response (download descriptor)” is received from the DRMTMS 8, the OMA download process (the processes (3) and (4) in FIG. 3) for receiving the media object is executed ( Step S1). At this time, the screen A is changed to the screen B.
Then, as described above, when the media object “Response (Media Object)” is received from the CP 12, it is determined whether or not the HTTP header at the time of receiving the media object includes the X-Oma-Drm-Separate-Delivery header. (Step S2).
This X-Oma-Drm-Separate-Delivery header is added to the HTTP response containing the DCF file to indicate that the rights object is a separate delivery download that is pushed separately, unlike a normal media object download. In the HTTP header, an estimated time required until the rights object is push-distributed to the mobile terminal 1 can be specified.

If the determination result in step S2 is NO, the OMA download process is continued because the OMA download is normal (step S10).
If the X-Oma-Drm-Separate-Delivery header is included, the process advances to step S3 to determine whether or not to send a download completion notification “Request (InstallNotifyURI)” (InstallNotifySucess). This is the same processing as (5) in FIG. When the download completion notification is not sent, the process proceeds to step S10.
When a download completion notification is sent, a download completion notification is sent and the process proceeds to step S4. At this time, the display screen is changed from the screen B to the screen C from which the cancel button is deleted.

In step S4, it is determined whether reception of the rights object is completed. When the reception of the rights object is completed, the rights object is stored (step S7), and the screen D is displayed to notify the user of the completion of the rights object reception (step S8).
It is determined whether or not the prediction time specified in the X-Oma-Drm-Separate-Delivery header has elapsed before the reception of the rights object is completed (step S5). In step S6, a screen E indicating that the rights object has not been received is displayed, and the user is notified accordingly.
During the period of steps S4 and S5, the screen C is displayed so that the user cannot perform a cancel operation.

  As described above, in this embodiment, during the period during which the content is being received, it is possible to cancel the content acquisition by displaying a cancel button during the period in which the content acquisition can be canceled. Since the cancel button is not displayed after the reception of the media object is completed and the download completion notification requesting the distribution of the rights object is sent, the user can cancel the acquisition of the content. There is no misunderstanding.

Next, a case where the mobile terminal receives only the rights object will be described. In this case, it is assumed that the content (media object) is stored in the mobile terminal 1 via download from the web, attachment to an e-mail, or a memory card storing the content.
FIG. 6 is a diagram showing a sequence when the mobile terminal 1 receives only the rights object, and FIG. 7 is a diagram showing an example of transition of the display screen of the display unit 28 in the mobile terminal 1 at that time.

It is assumed that a target content selection screen (51 in FIG. 7) for selecting the content for which the rights object is acquired by browsing the web page of the CP 12 that provides the content with a browser is displayed on the display unit 28. . Here, when the user selects content for which a rights object is to be acquired, “Request (Rights Issuer URI)” is transmitted to the CP 12 that provides the content ((1) in FIG. 6).
In response to this, a response “Response (Rights Object)” including data of the rights object acquisition screen is transmitted from the CP 12 to the mobile terminal 1.
When receiving the response “Response (Rights Object)” ((2) in FIG. 6), the control unit 26 of the mobile terminal 1 displays a rights object acquisition screen (52 in FIG. 7) on the display unit 28.
Here, when the user selects acquisition of the rights object, it is linked to a selection element (anchor, in the example shown in 52 of FIG. 7, “Buy Activation”) indicating acquisition on the rights object acquisition screen. The right object distribution request (“Request (Rights Object)” is transmitted to the URI (the above-described DRMTMS8 is specified) ((3) in FIG. 6). 7 is a screen F indicated by 53 in Fig. 7. Since a cancel button is displayed on this screen F (53 in Fig. 7), if the user operates the cancel button at this stage, the rights object is displayed. The acquisition screen 52 can be returned.

Upon receipt of the rights object delivery request (“Request (Rights Object)”), the DRMTMS 8 checks the service ID included in the rights object delivery request and sends a response “Responce (Rights Object)” to the Return to mobile terminal 1. If there is no problem as a result of this check, the DRMTMS 8 receives the rights object from the license server 9 and transmits the rights object to the PPG 6 for pushing to the mobile terminal 1 as described above. . Further, the HTTP header of the response (“Responce (Rights Object)”) at this time includes the X-Oma-Drm-Separate-Delivery header described above.
When receiving the response “Responce (Rights Object)”, the mobile terminal 1 shifts to a rights object reception state ((4) in FIG. 6). At this time, the display screen of the display unit 28 is changed to a screen G indicated by 54 in FIG. As shown in the figure, since the cancel button is not displayed on this screen G (54 in FIG. 7), the user cannot perform an operation to cancel acquisition of the rights object at this stage.

As described above, the rights object (“RO Delivery (Rights Object)”) is delivered to the mobile terminal 1 from the PPG 6 that has received the rights object from the DRMTMS 8.
Similarly to the above, when the mobile terminal 1 receives the rights object ((5) in FIG. 6), the mobile terminal 1 sends a delivery status notification “Delivery Receipt (Rights Object)” to the PPG 6 and displays a screen H indicating that effect. (55 in FIG. 7) is displayed on the display unit 28 ((6) in FIG. 6). On the other hand, when the reception of the rights object is not completed within the set time, a screen I (56 in FIG. 7) indicating that fact is displayed on the display unit 28.
Note that the PPG 6 that has received the delivery status notification “Delivery Receipt (Rights Object)” creates a delivery result notification “Delivery Report” according to the content and sends it to the DRMTMS 8 in the same manner as described above. Only when the distribution is successful, a billing notice is sent to the WGW 7 (for a fee).

FIG. 8 is a flowchart showing the flow of processing of the control unit 26 when the HTTP header of the response (“Responce (Rights Object)”) includes an X-Oma-Drm-Separate-Delivery header. .
As described above, when the response (“Responce (Rights Object)”) received from the DRMTMS 8 includes the X-Oma-Drm-Separate-Delivery header in the screen F (53 in FIG. 7), Whether the mobile terminal 1 shifts to a rights object distribution waiting state ((4) in FIG. 6), and has the reception of the rights object been completed within the time specified by the X-Oma-Drm-Separate-Delivery header? It is determined whether or not (steps S11 and S12).
If reception of the rights object is not completed within the scheduled time (NO in step S12), a screen I (56 in FIG. 7) indicating that the rights object has not been received is displayed (step S13). .
On the other hand, when reception of the rights object is completed within the scheduled time specified in the X-Oma-Drm-Separate-Delivery header (S11 is YES), the received rights object is stored in the memory 27 or the like. (Step S14). If no error occurs at that time (NO in step S15), the screen H (55 in FIG. 7) is displayed to notify the user that reception of the rights object has been completed (step S16). On the other hand, when an error has occurred (YES in step S15), the fact is notified to the user (step S17). And the process of browsing a web page is continued (step S18).

  As described above, in this embodiment, when only the rights object is received in the separate delivery, after the rights object distribution request is transmitted, an operation button for canceling the acquisition of the rights object is displayed on the display unit. Since it is not displayed, there is no misunderstanding that the user can cancel the acquisition of the rights object.

In each of the above-described embodiments, the cancel button is not displayed on the content or rights object download screen as in the screen C. In addition to this, the key input unit 29 (FIG. 1) It is more effective to control so that the operations of the power-off key and the end-call key provided are also invalidated.
That is, after sending the download completion notification “Request (InstallNotifyURI)” or the rights object delivery request “Request (Rights Object)” to the server (DRMTMS8) that delivers the rights object, reception of the rights object is completed. Power off key and end call provided in the key input unit 29 until the predetermined time (the scheduled time specified in the X-Oma-Drm-Separate-Delivery header) elapses. Even if a key operation signal is input, control is performed so that the signal is invalidated.
Thus, even if the user tries to cancel acquisition of the content or rights object and operates the power off key or the call end key during the period, the operation cannot be canceled by invalidating the operation. Is possible.

It is a block diagram which shows the structure of the mobile terminal device of this invention. It is a figure which shows the whole structure of the mobile communication system to which the mobile terminal device of this invention is connected. It is a figure which shows a sequence when receiving a content and its rights object in a series of processes. It is a figure which shows an example of the transition of a screen display when receiving a content and its rights object in a series of processes. It is a flowchart which shows the flow of a process in a mobile terminal device when receiving a content and its rights object by a series of processes. It is a figure which shows a sequence when receiving only a rights object. It is a figure which shows an example of the screen display when receiving only a rights object. It is a flowchart which shows the flow of a process in a mobile terminal device when receiving only a rights object.

Explanation of symbols

  1: mobile terminal device, 2: mobile communication network, 3: GGSN, 4: SMSC, 5: WAP gateway (WAP-GW), 6: push proxy gateway (PPG), 7: web gateway (WGW) 8: DRM transaction management server (DRMTMS) 9: License server (LS) 10: Packaging server (PS) 11: Internet 12: Content providing server (CP) 21: Antenna 22: Wireless communication unit , 23: signal processing unit, 24: microphone, 25: speaker, 26: control unit, 27: memory, 28: display unit, 29: key input unit

Claims (2)

A mobile terminal device capable of receiving content delivery by separate delivery,
A display unit, a key input unit, and a control unit;
When the control unit receives the media object and the rights object in a series of processes, after the download of the media object is finished, and sends a download completion notification to the server that delivers the rights object related to the media object , Estimated time required until reception of the rights object is completed or until the rights object specified in the header information included in the HTTP response at the time of receiving the media object is pushed to the mobile terminal device Until the time elapses, the cancel button displayed for canceling the acquisition of the content on the display unit is not displayed, and the operation of the power off key and the call end key in the key input unit is disabled. movement which is characterized in that End devices. A mobile terminal device capable of receiving content delivery by separate delivery,
A display unit, a key input unit, and a control unit;
Wherein, when the media object is to receive only the rights object are stored in the own device, transmits a delivery request of the hand rights object to the server which distributes the rights object, HTTP to said delivery request After receiving the response, until the reception of the rights object is completed, or the rights object specified in the header information included in the HTTP response to the rights object delivery request is pushed to the mobile terminal device Until the estimated time required for distribution elapses, the cancel button displayed for canceling acquisition of the rights object is not displayed on the display unit, and the power off key in the key input unit is displayed. and it is characterized in that it invalidates the operation of the call termination key Mobile terminal equipment.

Images