JP5377789B1 - Communication terminal, content playback method, content playback program, module program, and player program - Google Patents

Abstract

An object of the present invention is to execute and reproduce a process incapable of executing the media framework on content acquired from a server without changing the existing elements such as an OS media framework.
A communication terminal having a media framework that generates a destination by adding route information to a specific address indicating the communication terminal when receiving an instruction to reproduce content held by a server. When a get request including a destination of a specific address and route information is received from the media framework, a first content request unit that passes a content request including a destination to the server requests a content from the server, A content acquisition unit that executes content processing that cannot be performed by the media framework on the acquired content and transmits the processed content that has been subjected to the content processing to the media framework as a get response to the get request;
[Selection] Figure 1

Description

  The present invention relates to a technology for reproducing content acquired from a server.

  In the above technical field, Patent Document 1 describes that content encrypted by various encryption schemes received by a digital media integration framework (DMIF) is encrypted by a plurality of decoders. A technique for decoding corresponding to a conversion method is disclosed (see FIG. 2).

US Pat. No. 6,092,107

  However, in the technique described in the above document, a plurality of decoders are connected after the digital media integration framework to perform decoding and playback processing that the digital media integration framework does not have. Therefore, a large-scale design change is required for an existing communication device that reproduces video and audio. In addition, the design of the OS has to be changed further when upgrading the digital media integrated framework and the like, and the upgrade cannot be easily handled.

  The objective of this invention is providing the technique which solves the above-mentioned subject.

In order to achieve the above object, an apparatus according to the present invention provides:
A communication terminal having a media framework for playing back content,
When receiving a reproduction instruction for content held by the server, a first content request is generated by adding route information to a specific address indicating the communication terminal to generate a destination and passing the content request including the destination to the media framework Means,
By monitoring the destination indicated by the specific address and the route information, when a get request including the destination is received from the media framework, the server requests the content, Content acquisition means for executing content processing that the media framework does not have on the acquired content and transmitting the processed content that has been subjected to the content processing to the media framework as a get response to the get request; ,
Is provided.

In order to achieve the above object, a module program according to the present invention provides:
Monitoring a get request issued at the time of content processing that the media framework does not have from the media framework of the own communication terminal to a destination indicated by a specific address and route information indicating the own communication terminal;
When receiving the get request including the destination from the media framework, requesting content from a server outside the communication terminal ;
Performing content processing that the media framework does not have on the content acquired from the server as a response to the content request;
Sending the processed content that has undergone the content processing to the media framework as a get response to the get request;
Is executed by the computer of the communication terminal .

In order to achieve the above object, a player program according to the present invention provides:
Receiving a reproduction instruction for content held by a server outside the communication terminal ;
In response to the reproduction instruction of the content, the by adding route information to the own communication terminal modules a specific address indicating the self communication terminal generates a destination, content including the destinations for the media framework Passing the request,
Is a player program that causes a computer of the communication terminal to execute
The module of the self-communication terminal is a module that acquires the content from the server and executes content processing that the media framework of the self-communication terminal does not have .

In order to achieve the above object, the method according to the present invention comprises:
A content playback method of a communication terminal having a media framework for playing back content,
Receiving a reproduction instruction of content held by the server;
In response to the content playback instruction, adding route information to a specific address indicating the communication terminal to generate a destination, and passing the content request including the destination to the media framework;
Upon receiving a get request issued from the media framework to the destination indicated by the specific address and the route information, requesting the content from the server;
Performing content processing that the media framework does not have on the content acquired from the server as a response to the content request;
Sending the processed content that has undergone the content processing to the media framework as a get response to the get request;
including.

In order to achieve the above object, a content reproduction program according to the present invention provides:
A content playback program for a communication terminal having a media framework for playing back content,
Receiving a reproduction instruction of content held by the server;
In response to the content playback instruction, adding route information to a specific address indicating the communication terminal to generate a destination, and passing the content request including the destination to the media framework;
Upon receiving a get request issued from the media framework to the destination indicated by the specific address and the route information, requesting the content from the server;
Performing content processing that the media framework does not have on the content acquired from the server as a response to the content request;
Sending the processed content that has undergone the content processing to the media framework as a get response to the get request;
Is executed on the computer.

  According to the present invention, it is possible to execute and reproduce a process that the media framework cannot execute on the content acquired from the server, without touching existing components such as the OS media framework.

It is a block diagram which shows the function structure of the communication terminal which concerns on 1st Embodiment of this invention. It is a figure which shows the concept of a structure and operation | movement of the communication terminal which concerns on 2nd Embodiment of this invention. It is a figure which shows the example of a display of the display part of the communication terminal which concerns on 2nd Embodiment of this invention. It is a sequence diagram which shows the operation | movement procedure of the communication terminal which concerns on 2nd Embodiment of this invention. It is a figure explaining replacement of the get destination of contents concerning a 2nd embodiment of the present invention. It is a figure which shows operation | movement of the communication terminal which concerns on 2nd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 2nd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 2nd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 2nd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 2nd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 2nd Embodiment of this invention in order. It is a block diagram which shows the hardware constitutions of the communication terminal which concerns on 2nd Embodiment of this invention. It is a flowchart which shows the process sequence of the communication terminal which concerns on 2nd Embodiment of this invention. It is a flowchart which shows the process sequence of the self-made player which concerns on 2nd Embodiment of this invention. It is a flowchart which shows the process sequence of the media framework which concerns on 2nd Embodiment of this invention. It is a flowchart which shows the process sequence of the self-made module containing HTTP Client & Daemon concerning 2nd Embodiment of this invention. It is a figure which shows the concept of a structure and operation | movement of the communication terminal which concerns on 3rd Embodiment of this invention. It is a figure which shows the example of a display of the display part of the communication terminal which concerns on 3rd Embodiment of this invention. It is a sequence diagram which shows the operation | movement procedure of the communication terminal which concerns on 3rd Embodiment of this invention. It is a figure explaining replacement of the get destination of contents concerning a 3rd embodiment of the present invention. It is a figure which shows operation | movement of the communication terminal which concerns on 3rd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 3rd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 3rd Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 3rd Embodiment of this invention in order. It is a flowchart which shows the process sequence of the communication terminal which concerns on 3rd Embodiment of this invention. It is a flowchart which shows the process sequence of the self-made player which concerns on 3rd Embodiment of this invention. It is a flowchart which shows the process sequence of the self-made module containing HTTP Client & Daemon concerning 3rd Embodiment of this invention. It is a sequence diagram which shows the operation | movement procedure of the communication terminal which concerns on 4th Embodiment of this invention. It is a flowchart which shows the process sequence of the self-made player which concerns on 4th Embodiment of this invention. It is a flowchart which shows the process sequence of the self-made module containing HTTP Client & Daemon concerning 4th Embodiment of this invention. It is a sequence diagram which shows the operation | movement procedure of the communication terminal which concerns on 5th Embodiment of this invention. It is a figure which shows operation | movement of the communication terminal which concerns on 5th Embodiment of this invention. It is a sequence diagram which shows the operation | movement procedure of the communication terminal which concerns on 6th Embodiment of this invention. It is a sequence diagram which shows the operation | movement procedure of the communication terminal which concerns on 6th Embodiment of this invention. It is a figure which shows operation | movement of the communication terminal which concerns on 6th Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 6th Embodiment of this invention in order. It is a flowchart which shows the process sequence of the communication terminal which concerns on 6th Embodiment of this invention. It is a flowchart which shows the process sequence of the self-made module containing HTTP Client & Daemon concerning 6th Embodiment of this invention. It is a figure which shows operation | movement of the communication terminal which concerns on 7th Embodiment of this invention in order. It is a figure which shows operation | movement of the communication terminal which concerns on 7th Embodiment of this invention in order. It is a figure which shows the structure of the system containing the communication terminal which concerns on 8th Embodiment of this invention. It is a figure which shows the content reproduction operation | movement of the existing communication terminal.

  Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the drawings. However, the constituent elements described in the following embodiments are merely examples, and are not intended to limit the technical scope of the present invention only to them.

[First Embodiment]
A communication terminal 100 as a first embodiment of the present invention will be described with reference to FIG.

  As shown in FIG. 1, the communication terminal 100 is a communication terminal having a media framework 120 that reproduces content, and includes a first content requesting unit 110 and a content acquisition unit 130. When receiving a content reproduction instruction of the server 140, the first content requesting unit 110 generates a destination by adding route information 112 to the specific address 111 indicating the communication terminal, and sends the destination to the media framework 120. Pass the content request including the destination. The content acquisition unit 130 monitors the destination indicated by the specific address 111 and the route information 112, and when receiving a get request (HTTP GET Request) including the destination from the media framework 120, the content acquisition unit 130 Request content. Next, the content acquisition unit 130 executes content processing that the media framework 120 cannot execute on the content acquired from the server 140. Then, the content acquisition unit 130 transmits the processed content subjected to the content processing to the media framework 120 as a get response (HTTP GET Response) to the get request (HTTP GET Request).

  Further, the content acquisition unit 130 includes a monitoring unit 131, a second content request unit 132, an execution unit 133, and a transmission unit 134. The monitoring unit 131 monitors a get request (HTTP GET Request) issued from the media framework 120 to the destination indicated by the specific address 111 and the route information 112. When receiving a get request (HTTP GET Request) from the media framework 120, the second content request unit 132 requests content from the server 140. The execution unit 133 executes content processing on the content acquired from the server 140 as a response to the request from the second content request unit 132. The transmission unit 134 transmits the processed content that has been processed by the execution unit 133 to the media framework 120 as a get response (HTTP GET Response) to the get request (HTTP GET Request).

  According to the present embodiment, it is possible to execute and reproduce a process that cannot be executed by the media framework on the content acquired from the server without changing the existing components such as the OS media framework. Note that the content list information in this embodiment may be obtained by “server search” or “content search” as in the third embodiment, but from the content list or storage medium from other communication terminals. A content list or the like may be acquired. Alternatively, a content list that matches the user's preference prepared in advance in the server may be used.

  In the following second to eighth embodiments, more specific operations will be described by taking a copyright protected content decoding function and transcoding processing as examples of functions that the media framework does not have or that cannot be executed. However, the functions that the media framework of the present invention does not have are not limited to the copyright protection content decoding function and transcoding processing. It includes a decryption function corresponding to other encryption, and further includes other functions necessary for content reproduction that other media frameworks do not have. In addition, the local loopback address is used as a specific address destined for the communication terminal (self-communication terminal) and the port number is used as route information. .

[Second Embodiment]
Next, a communication terminal according to the second embodiment of the present invention will be described. When there is an instruction to reproduce copyright-protected content, the communication terminal of the present embodiment responds to the content of the local loopback address from the self-made player application as the first content requesting unit to the media framework. Issue a get request (HTTP GET Request). The self-made module as the content acquisition unit of the get request destination by the local loopback address acquires and decrypts the encrypted content from the content server, and the decrypted content as a get response (HTTP GET Response) is the media frame. Return to work.

  According to the present embodiment, it is possible to decrypt content encrypted for copyright protection as a function that the media framework does not have, without putting a hand in the OS view system or media framework.

  Note that the software configuration of the communication terminal according to the present embodiment will be described along the architecture of the Android (registered trademark) terminal, but the software configuration of other communication terminals can be similarly applied. In the present embodiment, an example will be described in which a media framework for reproducing content does not have a function of decrypting copyright-protected encrypted content.

<Operation of existing communication terminal>
First, in order to clarify the advantage of the content reproduction operation of the communication terminal according to the present embodiment, the content reproduction operation of the existing communication terminal will be described with reference to FIG.

  As shown in FIG. 23, in the existing communication terminal, when there is an instruction for streaming playback of content, the player application specifies an acquisition destination of the content to be streamed and a URL indicating the content. Then, the player application requests content playback from the media framework (Media Framework in the drawing) via the view system (View System in the drawing). The media framework requests content from a server (not shown) using a specified URL.

  However, if the media framework does not have a function of decrypting content encrypted for copyright protection, the acquired content cannot be reproduced. One solution is to modify the code of the media framework so that the encrypted content is decrypted and played back. However, it is difficult to find a corresponding portion of the correction, and the code may change with the version upgrade of the OS media framework, etc., so that the maintainability is very poor.

<< Concept of composition and operation >>
FIG. 2A is a diagram illustrating the concept of the configuration and operation of the communication terminal 200 according to the present embodiment. FIG. 2A shows a configuration related to the operation of the present embodiment.

  2A, communication terminal 200 includes an input / output unit 210 and a software configuration 220 for operating communication terminal 200. The input / output unit 210 includes an operation unit 211 such as a touch panel for operating the communication terminal 200, a display unit 212 that displays operation buttons and playback content, and a voice input / output unit 213 that inputs and outputs audio including a microphone and a speaker. ,including.

  The software configuration 220 includes an application 230, an application framework 240, a library 250, and a kernel 260. FIG. 2A shows a self-made player 231, a view system 241, a media framework 251, a self-made module 252, and a WiFi driver 261 as software related to the present embodiment. These are included in the content reproduction program. A self-made player 231 serving as a first content requesting unit is one of the applications 230, and is a program created to cause the communication terminal 200 to function as a player and to decrypt the copyright protected encrypted content. The view system 241 is one of the application frameworks 240 and is a program for providing a display tool and a format for the display unit 212. The media framework 251 is a program for acquiring and reproducing contents such as images, sounds, and videos (Video) from inside or outside the communication terminal 200. A self-made module 252 as a content acquisition unit is one of the libraries 250. In the present embodiment, the self-made module 252 has a decryption unit 253 as an execution unit, and is a program created to decrypt copyright-protected encrypted content. It is. The WiFi driver 261 is one of the kernels 260, and is a program that communicates with the media framework 251, the self-made module 252 of this embodiment, or other functional elements via a network.

  In the present embodiment, the copyright protected content 271 is acquired from the content server 270 via the WiFi driver 261. The content server 270 may be outside the communication terminal 200 or inside the communication terminal 200.

  In the present embodiment, the self-made player 231 uses the existing view system 241 and the media framework 251 for the content selected by the user from the content list displayed on the display unit 212 via the operation unit 211, and the self-made module. 252 requests content acquisition. The self-made module 252 acquires the copyright-protected content 271 from the content server 270, decrypts it with the decryption unit 253, and passes the decrypted copyright-protected content 271 to the media framework 251 that does not have a decryption function. With this configuration, the copyright-protected content 271 that is a function that the media framework 251 does not have is realized without touching the existing view system 241 and the media framework 251.

<Display example>
FIG. 2B is a diagram illustrating a display example of the display unit 212 of the communication terminal 200 according to the present embodiment.

  On the display screen 280, a content list is displayed. In this state, the user selects “content to be reproduced” 281. The acquisition destination address and the content name of “content to be played” are “http://192.168.10.100/play.mp4”.

  On the display screen 290, the acquired content is decoded and a video 291 is output. Although it is not clear in FIG. 2B, a video of the same format and adjustment reproduced by the view system 241 and the media framework 251 of the existing communication terminal 200 is output as the video 291.

<< Operation procedure of communication terminal >>
FIG. 3A is a sequence diagram showing an operation procedure of the communication terminal 200 according to the present embodiment.

  In step S <b> 301, the self-made player 231 uses the view system 241 to instruct the display unit 212 to display a content list. In step S303, the display unit 212 displays a content list. When the user selects content on the operation unit 211, the view system 241 detects the selected list and transmits it to the self-made player 231 in step S305.

  If the selected content is to be acquired from the server, the self-made player 231 reproduces the content to the media framework 251 with the local loopback address as the destination instead of the server address that is the acquisition destination address in step S307. Request. A predetermined port number, an arbitrary content name, a server address, and a content name to be acquired are added to the local loopback address. In this example, an arbitrary content name is meaningless data in the format, but may be used as significant information as an option.

  In step S309, the media framework 251 that has received the local loopback address issues a get request (HTTP Get Request) to a predetermined port number designated with the local loopback address as a destination. At that time, as shown in FIG. 3B, a character string after the port number is designated as the requested content name.

  The self-made module 252 that has been monitoring a get request (HTTP GET Request) to a predetermined port number destined for the local loopback address receives the get request (HTTP GET Request) from the media framework 251. In step S311, the self-made module 252 replaces the content acquisition destination and the content name with the server address and the content name set in the get request from the media framework, as shown in FIG. 3B. In step S313, the self-made module 252 requests the content server 270 for copyright-protected content in this example. In step S315, the content server 270 searches for and transmits content. Although not shown in detail because it is complicated, a key for decrypting the encrypted copyright-protected content is acquired upon authentication. In step S317, the homebrew module 252 decrypts the content acquired by the decryption unit 253 using the acquired key. In step S319, the self-made module 252 transmits the decrypted content to the media framework 251 by a get response (HTTP GET Response) in response to the get request (HTTP GET Request) from the media framework 251.

  In step S321, the media framework 251 that has received the decrypted content decodes the content and decodes the content to the display unit 212 (and / or the audio output unit) using the view system 241. The presentation of content is instructed (see S323 and S325).

  Communication between the media framework 251, the self-made module 252, and the content server 270 is performed by a get request (HTTP GET Request) and a get response (HTTP GET Response) compliant with RFC2616 (HTTP / 1.1). In addition, a content request addressed to the local loopback address from the self-made player 231 becomes a get request (HTTP GET Request) to the communication terminal by the OS. Therefore, a get request is issued from the media framework 251 to the self-made module 252 and the decrypted content is passed as a response thereto. Similarly, encrypted content from the server is acquired by the self-made module 252 by a get response in response to a get request from the self-made module 252 whose destination is replaced by the server to the content server 270. Further, in FIG. 3A and the subsequent sequence diagrams, content acquisition and playback are shown once in order to avoid complication, but in actual streaming playback, content of a predetermined length is repeatedly transmitted, and decoding and playback are performed. Repeated.

《Replace Get Destination》
FIG. 3B is a diagram for explaining replacement of the content get destination according to the present embodiment.

  The get request 310 is a format example of a get request (HTTP GET Request) passed from the media framework 251 to the self-made module 252. In the get request 310, the destination host (hereinafter referred to as Host) is the port number 20000 of the local loopback address (127.0.0.1), and “target.mp4 / 192.168.10.100 / play. mp4 ”is added. Among these, “target.mp4” is an arbitrary content name to be acquired by the local loopback address. “192.168.10.100” 311 is a server address. “Play.mp4” 312 is a content name to be reproduced.

  The get request 320 is a get request (HTTP GET Request) for the self-made module 252 to acquire content to be reproduced from the server. In the get request 320, the host is replaced with the server address “192.168.10.100” 321 from the port number 20000 of the local loopback address (127.0.0.1). Further, the content name is replaced with a content name “play.mp4” 322 to be reproduced.

  When the media framework 251 receives a reproduction request from the self-made player 231, it issues a get request (HTTP GET Request) to the port number 20000 of the local loopback address according to the existing processing procedure. Thus, the self-made module 252 acquires and decrypts the content to be played back from the server, and acquires the decrypted content that can be processed by the media framework 251 as a get response (HTTP GET Response) to the get request (HTTP GET Request). be able to. That is, it becomes possible to obtain decrypted content using the existing media framework 251.

<Operation of communication terminal>
4A to 4F are diagrams illustrating the operation of communication terminal 200 according to the sequence shown in FIG. 3A in more detail in order. The self-made module 252 is shown to include HTTP Client & Daemon, DTCP-IP, and UPnP, but is not limited to this. In this example, “HTTP Client & Daemon” that is the main body of the self-made module 252, “DTCP-IP” that is a decryption unit, and “UPnP” that provides a communication protocol are shown as an example.

  FIG. 4A is a point in time when “content to be reproduced” is selected from a list of contents displayed on the display screen of communication terminal 200. It is a figure which shows the state of the software configuration 220 corresponding to the display screen 280 of the communication terminal 200 at that time. In this process 410, the view system 241 detects that (12) the user has selected and tapped the content to be reproduced from the (11) server content list display state, and notifies the self-made player 231.

  FIG. 4B is a diagram illustrating a state of the corresponding software configuration 220 of the communication terminal 200 that is transmitted from the self-made player 231 to the media framework 251 via the view system 241. First, in the process 420, (13) “http://127.0.0.1:20000/target.mp4/192.168.10.100/play.mp4”, which is information for acquiring playback content, is transmitted from the self-made player 231 to the view system 241. It is done. In the process 430, (13) “http://127.0.0.1:20000/target.mp4/192.168.10.100/play.mp4”, which is information for acquiring the playback content, is transferred from the view system 241 to the media framework 251. It is told as it is.

  FIG. 4C shows a point in time when the media framework 251 receives the local loopback address (127.0.0.1) and outputs a get request (HTTP GET Request) to the port number (20000). It is a figure which shows the state of the corresponding software structure 220 of the communication terminal 200 at that time. In the process 440, (15) the media framework 251 makes a content acquisition request (HTTP Get Request) to 127.0.0.1 (see the get request 310 in FIG. 3B).

  FIG. 4D shows a point in time when the self-made module 252 replaces the destination of the get request (HTTP GET Request) issued from the media framework 251 with the name of the content to be played and requests the server to get the content. It is a figure which shows the state of the corresponding software structure 220 of the communication terminal 200 at that time. In the process 450, (16) HTTP Client & Daemon of the self-made module 252 replaces the “transmission destination” and “content name” of the get request issued from the media framework 251, and the server (http://192.168.10.100 ) Is issued to the content (play.mp4) (see get request 320 in FIG. 3B).

  FIG. 4E shows that the self-made module 252 receives the encrypted content transmitted from the server, decrypts it, and sends it to the media framework 251 as a get response (HTTP GET Response) to the get request (HTTP GET Request). It is time to send. It is a figure which shows the state of the corresponding software structure 220 of the communication terminal 200 at that time. In process 460, (17) when encrypted data is received from the server, the encrypted data is decrypted into plain text, and then transferred to the media framework 251 by HTTP Get Response.

  4F shows that the media framework 251 receives the decrypted content from the home-made module 252 and outputs the decoded content to the display unit 212 (and / or the audio output unit) using the view system 241. It is time to do. It is a figure which shows the state of the software structure 220 corresponding to the image | video 291 reproduced | regenerated on the display screen 290 of the communication terminal 200 at that time. In the process 470, (18) content that has been link protected (encrypted) by the media framework 251 is played back.

<< Hardware configuration of communication terminal >>
FIG. 5 is a block diagram showing a hardware configuration of the communication terminal 200 according to the present embodiment.

  In FIG. 5, a CPU (Central Processing Unit) 510 is a processor for arithmetic control, and implements the functional components of the communication terminal 200 of FIGS. 1 and 2A by executing a program. A ROM (Read Only Memory) 520 stores fixed data and programs such as initial data and programs. The communication control unit 530 communicates with other communication terminals and servers via a network or a LAN.

  Note that the number of CPUs 510 is not limited to one, and may be a plurality of CPUs or may include a GPU for image processing. The communication control unit 530 preferably has a CPU independent of the CPU 510 and writes or reads transmission / reception data in the RAM 540 area. Further, it is desirable to provide a DMAC for transferring data between the RAM 540 and the storage 550 (not shown). Furthermore, the input / output interface 560 preferably has a CPU independent of the CPU 510 and writes or reads input / output data in the RAM 540 area. Therefore, the CPU 510 recognizes that the data has been received or transferred to the RAM 540 and processes the data. Further, the CPU 510 prepares the processing result in the RAM 540 and leaves the subsequent transmission or transfer to the communication control unit 530, the DMAC, or the input / output interface 560.

  The RAM 540 is a random access memory used by the CPU 510 as a work area for temporary storage. In the RAM 540, an area for storing data necessary for realizing the present embodiment is secured. The server list 541 is data of a server list from which the communication terminal 200 can acquire content. The selected server address 542 is an address of a server selected by the user from the server list. The content list 543 is content list data stored in the selected server. The selected content name 544 is the name (or ID) of the content that the user has instructed to reproduce from the content list. A get request 545 to the homebrew module is a get request message issued by the media framework 251 that receives the local loopback address from the homebrew player 231. A get request 546 to the server is a get request message to the content server 270. Here, the self-made module 252 that has received a get request (HTTP GET Request) from the media framework 251 replaces the content request destination with the server, and replaces the content name with the content name to be reproduced. The received content data 547 is encrypted content acquired by the homebrew module 252 from the server. The decrypted content data 548 is content decrypted by the homebrew module 252. The input / output data 549 is data input / output via the input / output interface 560.

  The storage 550 stores a database, various parameters, or the following data or programs necessary for realizing the present embodiment. The application 230, the application framework 240, the library 250, and the kernel 260 are existing programs installed in the communication terminal 200. The application framework 240 includes an existing view system 241, the library 250 includes an existing media framework 251, and the kernel 260 includes an existing WiFi driver 261.

  The communication terminal control program 551 is a control program that controls the entire communication terminal 200 (see FIG. 6A). The self-made player 231 is a program which is included in the application 230 but has the characteristics created in the present embodiment (see FIG. 6B). The self-made module 252 is a program that is included in the library 250 but has a feature newly created in the present embodiment (see FIG. 6D). In the present embodiment, the self-made module 252 includes HTTP Client & Daemon, DTCP-IP, and UPnP.

  The input / output interface 560 interfaces input / output data with input / output devices. A display unit 212 and an operation unit 211 such as a touch panel / keyboard are connected to the input / output interface 560. Also, an audio input / output unit 213 such as a speaker or a microphone is connected. Furthermore, an imaging unit 561 and a GPS position detection unit 562 are also connected. For example, a content storage unit 56 such as an SD card is connected as content incorporated in the communication terminal 200. Note that the RAM 540 and the storage 550 of FIG. 5 do not show programs and data related to general-purpose functions and other realizable functions of the communication terminal 200.

<< Processing procedure of communication terminal >>
FIG. 6A is a flowchart illustrating a processing procedure of the communication terminal 200 according to the present embodiment. This flowchart is executed by the CPU 510 in FIG. 5 while using the RAM 540, and implements the functional components in FIGS. 1 and 2A.

  In step S601, the communication terminal 200 displays a content list. In step S603, the communication terminal 200 waits for the user to select and select content to be reproduced from the content list. If there is a selection instruction, the communication terminal 200 issues a content request to the local loopback address by the self-made player 231 in step S605.

  In step S607, the communication terminal 200 issues a get request (HTTP GET Request) whose destination is the local loopback address, in response to the content request for the local loopback address. In step S609, the communication terminal 200 receives the get request (HTTP GET Request) issued by the media framework 251 and acquires the copyright-protected content 271 from the content server 270. Then, the copyright protected content 271 is decrypted and sent to the media framework 251 as a get response (HTTP GET Response).

  In step S611, the communication terminal 200 reproduces and outputs the content according to the existing content reproduction procedure.

(Procedure for self-made player)
FIG. 6B is a flowchart showing a processing procedure of the self-made player 231 that is the self-made player program according to the present embodiment.

  In step S621, the self-made player 231 instructs the view system 241 to display a content list. In step S623, the self-made player 231 waits for information from the view system 241 that the user has instructed to select content to be reproduced from the content list. If the selection instruction is acquired from the view system 241, the home-made player 231 adds a port number (20,000 in this example) and an arbitrary content name (significant in this example) to the local loopback address in step S625. In addition, a server address and a content name to be reproduced are added. In step S 627, the self-made player 231 issues a playback request based on the local loopback address to the media framework 251 via the view system 241.

  Note that it is the processing of the view system 241 that waits for the reception of the content from the media framework 251 and outputs the content in the format set by the player 231, but this is an existing procedure, and the description thereof is omitted here.

(Media framework processing procedure)
FIG. 6C is a flowchart illustrating a processing procedure of the media framework 251 according to the present embodiment.

  In step S <b> 641, the media framework 251 receives a content reproduction request from the self-made player 231 via the view system 241. In step S643, the media framework 251 issues a get request for the specified content to the specified destination based on the specified URI. In other words, if the destination of the specified URI is a local loopback address, a get request is issued to the local loopback address (to the homebrew module), and the destination is the actual server address. For example, a get request is issued to the actual server. In this example, a get request (HTTP GET Request) is issued for the port number of the local loopback address (in this example, 20000).

  In step S645, the media framework 251 waits for a get response (HTTP GET Response). Upon receiving a get response (HTTP GET Response), the media framework 251 transmits the result of decoding the received plaintext content to the view system 241 as playback content in step S647.

(Processing procedure of self-made module)
FIG. 6D is a flowchart showing a processing procedure of a self-made module 252 which is a self-made module program including HTTP Client & Daemon according to the present embodiment.

  In step S661, the self-made module 252 receives a get request (HTTP GET Request) issued to a predetermined port number (in this example, 20000). Upon receipt of the get request (HTTP GET Request), the self-made module 252 replaces the destination of the get request (HTTP GET Request) with the server address and the content name to be reproduced in step S663.

  In step S665, the self-made module 252 determines whether the content to be reproduced is copyright-protected content. If the content is copyright-protected content, the home-made module 252 performs device authentication and key exchange (AKE) in step S667.

  In step S669, the self-made module 252 issues a get request (HTTP GET Request) in which the destination is the server address and the content name is replaced with the content name to be reproduced. Then, in step S671, the homebrew module 252 receives content to be reproduced from the server.

  In step S673, the self-made module 252 determines whether the content to be reproduced is copyright-protected content. If the content is copyright-protected content, the home-made module 252 decrypts the content data with the key obtained by the key exchange in step S675. In step S677, the self-made module 252 returns the decrypted content data as a get response (HTTP GET Response) to the media framework 251.

  Device authentication and key exchange are not limited to the procedure of this example. Before and after the procedure can be changed freely.

  According to the present embodiment, it is possible to decrypt content encrypted for copyright protection as a function that the media framework does not have, without putting a hand in the OS view system or media framework.

[Third Embodiment]
Next, a communication terminal according to the third embodiment of the present invention will be described. Compared to the second embodiment, the communication terminal according to the present embodiment accesses the server by replacing it in the homebrew module even if the homebrew player does not send the server address or the content name to be played back to the media player. It is different in point. Since other configurations and operations are the same as those of the second embodiment, the same configurations and operations are denoted by the same reference numerals, and detailed description thereof is omitted.

  According to the present embodiment, the server address and the name of the content to be reproduced are obtained by the procedure until the user selects the content to be reproduced, so that the get request from the self-made player to the self-made module can be simplified.

<< Concept of composition and operation >>
FIG. 7A is a diagram illustrating the concept of the configuration and operation of the communication terminal 700 according to the present embodiment. FIG. 7A shows a configuration related to the operation of this embodiment. Moreover, in FIG. 7A, the same reference numerals are given to the same components as those in FIG.

  7A differs from FIG. 2A in that, in the software configuration 720, the server address of the content request destination in the procedure prior to the user's content selection between the home-made player 731 of the application 730 and the home-made module 752 of the library 750. And the content name to be reproduced. The self-made module 752 has a storage unit 754 that stores a server address and a content name to be reproduced.

<Display example>
FIG. 7B is a diagram showing a display example of the display unit 212 of the communication terminal 700 according to the present embodiment.

  The display screen 760 of the communication terminal 700 displays a button 761 for requesting a list of content servers accessible by the communication terminal 700. The display screen 760 is not limited to FIG. 7B. The display screen 770 of the communication terminal 700 is a screen in which the movie content server 771 is selected from the content server list display, and a content list stored in the movie content server 771 is requested. The display screen 780 of the communication terminal 700 is a screen on which a content list of the movie content server 771 is displayed. The display screen 280 of the communication terminal 700 is a screen in which “content to be reproduced” 281 is selected from the content list. The display screen 280 is the same as the display screen 280 of FIG. 2B. Hereinafter, since the server address and the content name to be reproduced are acquired from the storage unit 754 of the self-made module 752, the procedures for acquiring, decrypting, reproducing, and outputting the content are the same as in the second embodiment. Detailed description is omitted.

<< Operation procedure of communication terminal >>
FIG. 8A is a sequence diagram showing an operation procedure of the communication terminal 700 according to the present embodiment. In FIG. 8A, the same reference numerals and the same step numbers are assigned to the same components or steps as in FIG. 3A, and the description thereof is omitted.

  In step S801, the view system 241 transmits a server list display instruction from the user via the operation unit 211 to the self-made player 731. In step S <b> 803, the self-made player 731 instructs the self-made module 752 to search for a server accessible by the communication terminal 700. In response to the server search instruction, the homebrew module 752 executes a search for the content servers 270 to 27n in step S805. In step S807, the content servers 270 to 27n respond to the search. In step S809, the homebrew module 752 transmits a server list of search results to the homebrew player 731 and holds a server address in the storage unit 754.

  The self-made player 731 that has received the server list from the self-made module 752 instructs the view system 241 to display the server list in step S811. In step S813, the display unit 212 displays a server list. Then, the view system 241 transmits a server selection instruction from the user via the operation unit 211 to the self-made player 731 in step S815. Here, it is assumed that the content server 270 is selected. The homebrew player 731 notifies the selected server to the homebrew module 752 in step S816, and the homebrew module 752 stores the selected server in the storage unit 754 and holds it.

  In step S817, the self-made player 731 instructs the self-made module 752 to search for the content stored in the server selected by the user. In response to the content search instruction, self-made module 752 executes content search for content server 270 in step S819. In step S821, the content server 270 responds to the content search. In step S823, the homebrew module 752 transmits a content list as a search result to the homebrew player 731 and holds the content name in the storage unit 754.

  The self-made player 731 that has received the content list from the self-made module 752 instructs the view system 241 to display the content list in step S825. Thereafter, the process proceeds to the sequence of FIG. 3A of the second embodiment. However, the content selection information by the user is sent from the home-made player 731 to the home-made module 752 in step S827 and stored in the storage unit 754 of the home-made module 752 in step S829.

《Replace Get Destination》
FIG. 8B is a diagram for explaining replacement of the content get destination according to the present embodiment. In FIG. 8B, the same reference numerals are assigned to the same data as in FIG. 3B.

  The get request 810 is a format example of a get request (HTTP GET Request) passed from the media framework 251 to the self-made module 752. In the get request 810, the get destination (Host) is the port number 20000 of the local loopback address (127.0.0.1), and only “target.mp4” is passed as the get target content name.

  The storage unit 754 holds a server address 822 to be connected and a content name 821 (ID 823) to be played back acquired by the self-made module 752 in the server list display, server selection, content list display, and content selection procedures. ing.

  The get request 320 is a get request (HTTP GET Request) for the self-made module 752 to acquire content to be reproduced from the server. In the get request 320, the get destination (Host) is replaced with the server address “192.168.10.100” 321 stored in the storage unit 754 from the port number 20000 of the local loopback address (127.0.0.1). In addition, the content name to be obtained is replaced with the content name “play.mp4” 322 to be reproduced, which is stored in the storage unit 754.

  Thus, in this embodiment, the server address and the content name to be reproduced are not added to the get request (HTTP GET Request) to the port number 20000 of the local loopback address issued by the player 731. Still, the homebrew module 752 acquires and decrypts the content to be played back from the server, and acquires the decrypted content that can be processed by the media framework 251 as a get response (HTTP GET Response) to the get request (HTTP GET Request). be able to. That is, it becomes possible to obtain decrypted content using the existing media framework 251.

<Operation of communication terminal>
9A to 9D are diagrams illustrating the operation of communication terminal 700 according to the sequence shown in FIG. 7A in more detail. The self-made module 252 is shown to include HTTP Client & Daemon, DTCP-IP, and UPnP, but is not limited to this. In this example, “HTTP Client & Daemon” that is the main body of the self-made module 252, “DTCP-IP” that is a decryption unit, and “UPnP” that provides a communication protocol are shown as an example.

  FIG. 9A shows the state of the software configuration 720 corresponding to the display screen 760 of the communication terminal 700 when the user requests display of a list of servers accessible from the communication terminal 700 and displays the acquired server list. FIG. In this process 910, (21) the homebrew player 731 requests the homebrew module 752 to search for a server. (22) The server search results are acquired and the view system 241 displays a list, prompting the user to make a selection, and the self-made module 752 holds the obtained search results.

  FIG. 9B is a diagram illustrating a display screen 770 of the communication terminal 700 and a state of the corresponding software configuration 720 when the user selects one server in the server list from the communication terminal 700. In this process 920, (23) when the user selects a server, the self-made player 731 sets the information of the selected server obtained from the view system 241 in the self-made module 752, so that the self-made module 752 has which server Is the “target server”.

  FIG. 9C is a diagram showing the state of the software configuration 720 corresponding to the display screen 780 of the communication terminal 700 when the content list display is requested in response to the user's server selection and the acquired content list is displayed. It is. In this process 930, (24) the homebrew player 731 requests the homebrew module 752 to acquire a content list. (25) The self-made module 752 issues a Browse action to the “target server”, acquires a content list from the target server, and holds the obtained content list. (26) The self-made player 731 displays the acquired content list on the view system 241 and prompts the user to select content.

  FIG. 9D is a diagram showing a state of the software configuration 720 corresponding to the display screen 280 of the communication terminal 700 when the user selects one content in the content list from the communication terminal 700. In this process 940, (27) when the user selects content, the home-made player 731 sets the information of the selected content obtained from the view system 241 in the home-made module 752, and thus the home-made module 752 determines which content currently Is “target content”.

  Thereafter, the selected content is reproduced, but the procedure for acquiring, decoding, reproducing, and outputting the content is the same except that the server address and the content name to be reproduced are acquired from the storage unit 754 of the self-made module 752. Since it is the same as that of 2nd Embodiment, detailed description is abbreviate | omitted.

<< Processing procedure of communication terminal >>
FIG. 10 is a flowchart showing a processing procedure of the communication terminal 700 according to the present embodiment. This flowchart is executed by the CPU 510 in FIG. 5 while using the RAM 540, and implements the functional components in FIGS. 1 and 7A.

  In step S1001, the communication terminal 700 searches for a server that the communication terminal 700 can access. In the case of a system of DLNA (Digital Living Network Alliance), DMS (digital media server) is searched. In step S1003, the communication terminal 700 displays a server list of search results.

  In step S1005, the communication terminal 700 waits for a server selection by the user. If there is a server selection, in step S1007, the communication terminal 700 acquires the content list by Browse in the case of DLNA. Then, the communication terminal 700 displays a content list in step S601 in FIG. 6A. The subsequent processing is the same as that in FIG. 6A except that the server address and the content name to be reproduced are acquired from the storage unit 754 of the homebrew module 752.

(Procedure for self-made player)
FIG. 11A is a flowchart showing a processing procedure of the self-made player 731 according to the present embodiment.

  In step S1101, the self-made player 731 instructs the view system 241 to display the menu. In step S <b> 1103, the self-made player 731 determines whether or not server search is selected from the menu based on the notification from the view system 241. If it is not a server search, other menu processing is performed.

  If it is a server detection, the self-made player 731 will instruct | indicate a server search to the self-made module 752 in step S1105. Then, the home-made player 731 receives the server search result in step S1107. Upon receiving the server search result, the home-made player 731 instructs the view system 241 to display the server list on the display unit 212 in step S1109.

  Next, the home-made player 731 determines whether or not the user has selected a server from the server list in accordance with a notification from the view system 241 in step S1111. When the server is selected, the home-made player 731 notifies the selected server to the home-made module 752 in step S1112, and instructs the home-made module 752 to search the content of the selected server in step S1113. When the content search result is received in step S1115, the home-made player 731 instructs the view system 241 to display the content list on the display unit 212 in step S621. Then, in step S623, the home-made player 731 receives selection information of content to be reproduced from the view system 241 and notifies the selected content to the home-made module 752 in step S1117.

  The subsequent processing is the same as in FIG. 6B except that the local loopback address is not added to the server address and the content name to be played back, and thus the description thereof is omitted.

(Processing procedure of self-made module)
FIG. 11B is a flowchart showing the processing procedure of the self-made module 752 including HTTP Client & Daemon according to the present embodiment.

  In step S <b> 1121, the homebrew module 752 determines whether or not it is a server search instruction from the homebrew player 731. If it is not a server search instruction, other processing is performed.

  If it is a server search instruction, self-made module 752 performs a server search process in step S1123. Then, the homebrew module 752 stores the server search result in the storage unit 754 in step S1125, and reports it to the homebrew player 731 in step S1127. In step 1128, the homebrew module 752 stores the selected server information notified from the homebrew player 731 in the storage unit 754. Next, the homebrew module 752 waits for a content search instruction of the selected server from the homebrew player 731 in step S1129.

  Upon receiving a content search instruction from self-made player 731, self-made module 752 performs content search processing in step S 1131. Then, the homebrew module 752 stores the content search result in the storage unit 754 in step S1133, and reports it to the homebrew player 731 in step S1135. The homebrew module 752 stores the selected content in the storage unit 754 in step S1137.

  In step S661, the self-made module 752 waits for reception of a get request (HTTP GET Request) issued to a predetermined port number (in this example, 20000). Since the subsequent processing is the same as that in FIG. 6D except that the server address and the content name to be reproduced are read from the storage unit 754, description thereof will be omitted.

  According to the present embodiment, the server address and the name of the content to be reproduced are obtained by the procedure until the user selects the content to be reproduced, so that the get request from the self-made player to the self-made module can be simplified.

[Fourth Embodiment]
Next, a communication terminal according to the fourth embodiment of the present invention will be described. The communication terminal according to the present embodiment is different from the second embodiment and the third embodiment in that a content reproduction start time can be set. Since other configurations and operations are the same as those of the second embodiment or the third embodiment, the same configurations and operations are denoted by the same reference numerals, and detailed description thereof is omitted.

<< Operation procedure of communication terminal >>
FIG. 12 is a sequence diagram showing an operation procedure of the communication terminal according to the present embodiment. In FIG. 12, the same steps as those in FIG. 3A are denoted by the same step numbers, and description thereof is omitted.

  In FIG. 12, a step different from FIG. 3A is a step in which the operation unit 211 sets the reproduction start time input by the user in step S1206. The self-made player 1231 that has received the playback start time from the view system 241 adds the playback start time as an argument to the data following the local loopback address and transmits it to the media framework 251 in step S1207.

  In step S1211, the self-created module 1252 adds a reproduction start time to the get request (HTTP GET Request) issued from the media framework 251 in addition to replacing the content request destination and the content name. In step S1215, the content server 270 transmits the content after the reproduction start time to the self-made module 1252.

(Procedure for self-made player)
FIG. 13A is a flowchart showing a processing procedure of the self-made player 1231 according to the present embodiment. In FIG. 13A, steps similar to those in FIG. 6B are denoted by the same step numbers, and description thereof is omitted.

  13A is different from FIG. 6B in that the home-made player 1231 adds a playback start time after the local loopback address in step S1325. Other steps are the same as in FIG. 6B.

(Processing procedure of self-made module)
FIG. 13B is a flowchart showing the processing procedure of the self-made module 1252 including the HTTP Client & Daemon according to the present embodiment. In FIG. 13B, steps similar to those in FIG. 6D are denoted by the same step numbers, and description thereof is omitted.

  13B is different from FIG. 6D in that, in step S1363, the self-made module 1252 adds a reproduction start time in addition to replacing the content acquisition destination and content name of the get request (HTTP GET Request). . The other steps are the same as in FIG. 6D.

  According to the present embodiment, the reproduction is performed from the reproduction start time (reproduction position) of the content that the user desires to reproduce, and thus, for example, it is possible to cope with simultaneous reproduction and trick operation from a plurality of communication terminals.

[Fifth Embodiment]
Next, a communication terminal according to the fifth embodiment of the present invention will be described. Compared with the second embodiment to the fourth embodiment, the communication terminal according to the present embodiment has a plurality of self-made modules, each of which acquires and decodes content from the server, and displays the display unit. It differs in that it is displayed on the same screen. Other configurations and operations are the same as those of the second embodiment to the fourth embodiment, and thus the same configurations and operations are denoted by the same reference numerals and detailed description thereof is omitted.

<< Operation procedure of communication terminal >>
FIG. 14 is a sequence diagram showing an operation procedure of the communication terminal according to the present embodiment. In FIG. 14, steps similar to those in FIG. 3A are denoted by the same step numbers and description thereof is omitted.

  14 is different from FIG. 3A in that, in steps S1405 to S1409, another self-made module 1452 is requested to reproduce other content (content B in this example) at the same time. Also, in steps S1413 to S1417, the self-made module 1452 acquires the content B from the content server 1470 and decrypts it. In steps S1419 to S1425, the content B is displayed on the display unit 212 simultaneously with the content A (for example, picture in picture).

<Operation of communication terminal>
FIG. 15 is a diagram showing in more detail the operation of communication terminal 1500 according to the sequence shown in FIG. The self-made module 2 (1452) is shown to include HTTP Client & Daemon, DTCP-IP, and UPnP, but is not limited thereto. In this example, “HTTP Client & Daemon” that is the main body of the self-made module 2 (1452), “DTCP-IP” that is a decryption unit, and “UPnP” that provides a communication protocol are shown as an example.

  FIG. 15 shows that the self-made modules 252 and 1452 receive the encrypted content transmitted from the server, decrypt it, and obtain a get response (HTTP GET Response) to the media framework 1451 to the get request (HTTP GET Request). ). It is a figure showing the state of software configuration 1520 corresponding to videos 291 and 1591 reproduced on display screen 1510 of communication terminal 1500 at that time. In the media framework 1451 and the view system 1441, a plurality of content items that have been link protected (encrypted) are simultaneously reproduced on the display screen 1510.

  According to this embodiment, a plurality of contents can be decoded and simultaneously reproduced on the same screen.

[Sixth Embodiment]
Next, a communication terminal according to the sixth embodiment of the present invention will be described. The communication terminal according to the present embodiment differs from the second embodiment in that one self-made module can perform different processes that the media framework does not have. Since other configurations and operations are the same as those of the second embodiment, the same configurations and operations are denoted by the same reference numerals, and detailed description thereof is omitted.

  In the present embodiment, a plurality of processes of the decoding program and transcoding will be described. However, other functions that the media framework does not have can be added to the self-made module, and are included in the present embodiment. . Here, transcoding is a process in which original digital video data is decompressed by decoding and then re-encoded to convert it to another desired video compression code, vertical / horizontal resolution, and bit rate. . That is, depending on the communication terminal, the reproducible moving image format is limited, so that it is possible to reproduce by converting to a reproducible moving image format by transcoding. Note that the transcoding unit may be provided by software or a hardware chip.

<< Operation procedure of communication terminal >>
16A and 16B are sequence diagrams showing an operation procedure of the communication terminal 1700 according to the present embodiment. In FIG. 16A and FIG. 16B, the same steps as in FIG.

  In the procedure of FIG. 16A, the self-made module 1652 decrypts the encrypted content acquired from the content server 270 in steps S1613, S1615, and S1617 in response to the selection of the content A, and obtains a get response (HTTP GET Response). Return to the media framework 251.

  In the procedure of FIG. 16B, the self-made module 1652 transcodes the content of the non-adaptive code for the communication terminal acquired from the content server 270 in steps S1614, S1616, and S1618 in response to the selection of the content B. Processing is performed and returned to the media framework 251 as a get response (HTTP GET Response).

<Operation of communication terminal>
FIGS. 17 and 18 are diagrams showing the operation of communication terminal 1700 in more detail in order according to the sequence shown in FIGS. 16A and 16B. In addition, although the self-made module 1652 is shown including HTTP Client & Daemon, DTCP-IP, a transcoding part, and UPnP, it is not limited to this. In this example, “HTTP Client & Daemon” which is the main body of the self-made module 1652, “DTCP-IP” which is a decoding unit, a transcoding unit which performs transcoding processing, and “UPnP” which provides a communication protocol are included. It is shown as an example.

  FIG. 17 shows that, in the communication terminal 1700, since the encrypted content 1791 that the media framework 251 does not have is selected from the content list on the display screen 1790, the self-made module 1652 receives (17) encrypted data from the server. After decrypting to plain text by DTCP-IP, data is transferred to the media framework by HTTP Get Response.

  On the other hand, FIG. 18 shows that in the communication terminal 1700, content 1792 having a media format that cannot be played back by the media framework 251 is selected from the content list on the display screen 1790, so that the self-made module 1652 receives data from the server (33) Then, the data is transferred to the media framework by HTTP Get Response after being converted into a code format that can be played back by the transcode unit.

<< Processing procedure of communication terminal >>
FIG. 19 is a flowchart showing a processing procedure of the communication terminal 1700 according to the present embodiment. In FIG. 19, steps similar to those in FIG. 6A are denoted by the same step numbers and description thereof is omitted.

  In step S1909, the communication terminal 1700 acquires the content from the content server, determines whether the content is encrypted content / non-adaptive code, executes processing corresponding to the determination result, and executes the media framework. In 251, the content data is returned by a get response (HTTP GET Response).

(Processing procedure of self-made module)
FIG. 20 is a flowchart showing the processing procedure of the homebrew module 1652 including HTTP Client & Daemon according to this embodiment. In FIG. 20, the same steps as those in FIG. 6D are denoted by the same step numbers, and description thereof is omitted.

  If the acquired content is copyright-protected content, self-produced module 1652 decrypts the content data in step S675, and then retains the decrypted content in step S2077. On the other hand, if the acquired content is not copyright-protected content, the self-made module 1652 proceeds to step S2079. Then, in step S2079, self-made module 1652 determines whether or not the content of the code is not applicable to communication terminal 1600. If it is a non-adaptive code, self-made module 1652 performs a transcoding process to a code adapted to communication terminal 1600 in the transcoding unit in step S2081. In step S677, the homebrew module 1652 returns the decrypted and / or transcoded content corresponding to the acquired content to the media framework 251 as a get response (HTTP GET Response).

  According to the present embodiment, not only can the decoding be performed without putting a hand in the OS view system and the media framework, but even if the server-side content is in a video format that cannot be played back by itself, transcoding is possible. By doing so, it is possible to play by converting to a playable video format.

[Seventh Embodiment]
Next, a communication terminal according to the seventh embodiment of the present invention will be described. The communication terminal according to the present embodiment differs from the second embodiment in that a plurality of homebrew modules can be added and can be selectively used. Since other configurations and operations are the same as those of the second embodiment, the same configurations and operations are denoted by the same reference numerals, and detailed description thereof is omitted.

<Operation of communication terminal>
21A and 21B are diagrams sequentially illustrating the operation of the communication terminal 2100 of the present embodiment. The self-made module 1 (2152) is shown to include HTTP Client & Daemon, DTCP-IP, and UPnP, and the self-made module 2 (2153) is assumed to contain HTTP Client & Daemon, the transcoding unit, and UPnP. However, the present invention is not limited to this. 21A and 21B, the same processes as those in FIGS. 4A to 4F are denoted by the same reference numerals, and description thereof is omitted.

  FIG. 21A shows a case where the communication terminal 2100 activates a self-made module for transcoding the selected content from a plurality of self-made modules and issues a get request (HTTP GET Request) to the server. is there. It is a figure which shows the state of the software configuration 2120 corresponding to the display screen 2110 of the communication terminal 2100 at that time. Here, it is assumed that the sample content 2111 can be transcoded by the transcoding unit included in the self-made module 2 (2153).

  In the process 2140, (43) the URL of the HTTP Daemon of its own module 2 (2153) is designated and passed to the view system 241 (http://127.0.0.1:20001/target2.mp4). In the process 2160, (44) (Http://127.0.0.1:20001/target2.mp4) is transmitted to the media framework 251.

  In process 2170, (45) the media framework 251 makes a content acquisition request (HTTP Get Request) to 127.0.0.1. In this case, since the content name (target2.mp4) of the port number (20001) following the local loopback address is targeted, the self-made module 2 (2153) receives the content acquisition request. In process 2180, (46) HTTP Client & Daemon of self-made module 2 (2153) replaces only the “destination” request message from media framework 251, and server (http://192.168.10.100/movie.mp4) ) A get request (HTTP GET Request).

  FIG. 21B shows the time when the communication terminal 2100 transcodes the content acquired from the server, returns it to the media framework 251, and outputs the playback video to the communication terminal 2100. It is a figure which shows the state of the software structure 2120 corresponding to the image | video 291 of the display screen 290 of the communication terminal 2100 at that time.

  In the process 2190, (47) when content data of a code that cannot be handled by the communication terminal 2100 is received from the server, the transcoding part of the self-made module 2 (2153) executes a transcoding process to a code adapted to the communication terminal 2100. Then, data is transferred to the media framework 251 by a get response (HTTP Get Response).

  According to the present embodiment, it is possible to increase the functions that the media framework not limited to decoding does not have without changing the OS view system and the media framework by switching the processing by a plurality of types of self-made modules. Also in the present embodiment, both decryption processing and transcoding processing may be executed depending on the content. In this case, the self-made module 2152 temporarily holds the decrypted content for subsequent transcoding processing and passes it to the self-made module 2153.

[Eighth Embodiment]
Next, a communication terminal according to the eighth embodiment of the present invention will be described. The communication terminal according to the present embodiment is different from the second embodiment in that a server is included in the communication terminal. Since other configurations and operations are the same as those of the second embodiment, the same configurations and operations are denoted by the same reference numerals, and detailed description thereof is omitted.

"System configuration"
FIG. 22 is a diagram illustrating a configuration of a system including a communication terminal according to the present embodiment. In FIG. 22, as an example in which the location of the server is easy to understand, DMC (Digital Media Controller), DMS (Digital Media Server), and DMR (Digital Media Renderer) in DLNA (Digital Living Network Alliance) are illustrated. It is not limited to this.

  In the first system 2210 of FIG. 22, both the first client terminal 2230 and the second client terminal 2240 have only DMRs (renderers) 2233 and 2243. The DMS (server) 2222 is in the server device 2220. That is, the server is outside the client terminal.

  On the other hand, the second system 2250 is a system of the third client terminal 2260 and the fourth client terminal 2270 without any server device. Here, the third client terminal 2260 has a DMC (controller) 2261, and the fourth client terminal 2270 has a DMS 2272.

  According to this embodiment, a flexible system configuration can be achieved without fixing a communication terminal to a client terminal or a server terminal.

[Other Embodiments]
The present invention has been described above with reference to the embodiments, but the present invention is not limited to the above embodiments. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention. In addition, a system or an apparatus in which different features included in each embodiment are combined in any way is also included in the scope of the present invention.

  In addition, the present invention may be applied to a system composed of a plurality of devices, or may be applied to a single device. Furthermore, the present invention can also be applied to a case where an information processing program that implements the functions of the embodiments is supplied directly or remotely to a system or apparatus. Therefore, in order to realize the functions of the present invention on a computer, a program installed in the computer, a medium storing the program, and a WWW (World Wide Web) server that downloads the program are also included in the scope of the present invention. . In particular, at least non-transitory computer readable media are within the scope of the present invention.

Claims (13)

A communication terminal having a media framework for playing back content,
When receiving a reproduction instruction for content held by the server, a first content request is generated by adding route information to a specific address indicating the communication terminal to generate a destination and passing the content request including the destination to the media framework Means,
By monitoring the destination indicated by the specific address and the route information, when a get request including the destination is received from the media framework, the server requests the content, Content acquisition means for executing content processing that the media framework does not have on the acquired content and transmitting the processed content that has been subjected to the content processing to the media framework as a get response to the get request; ,
A communication terminal comprising: The content acquisition means includes
Monitoring means for monitoring a get request issued from the media framework to a destination indicated by the specific address and the route information;
Second content requesting means for requesting the content from a server when the get request including the destination is received from the media framework;
Execution means for executing the content processing on the content acquired from the server as a response to the request by the second content request means;
Transmitting means for transmitting the processed content executed by the execution means to the media framework as a get response to the get request;
The communication terminal according to claim 1, comprising: The content processing executed by the execution means is decryption processing of encrypted content,
3. The communication terminal according to claim 2, further comprising key exchange means for exchanging a key for decrypting the encrypted content prior to the request of the encrypted content from the server by the second content requesting means.   The communication terminal according to claim 2 or 3, wherein the content process executed by the execution unit is a transcode process for converting a format of the content acquired from the server.   The communication terminal according to any one of claims 1 to 4, wherein the specific address is a local loopback address, and the route information is a port number. The first content requesting unit adds the server address of the server that acquires the content and the content name of the content to be acquired to the destination, and passes the content request to the media framework. ,
The content acquisition unit changes the get request including the destination from the media framework into a get request for the content name to the server address, and transmits the request to the server, thereby transmitting the request to the server. Requesting the content to the content, executing the content processing that the media framework does not have on the content acquired from the server, and executing the content processing as the get response to the get request The communication terminal according to claim 1, which transmits to the media framework . Before the first content request means passes the content request to the media framework,
Requesting the content acquisition means to search for a server capable of acquiring content, and displaying a list of searched servers;
Notifying the content acquisition means of the server selected from the server list display, requesting a search for the content held by the selected server, displaying the searched content as a list,
To the content acquisition section notifies the selected content name from the contents list,
The content acquisition means includes
Storage means for storing the server address of the selected server and the selected content name notified by the first content requesting means ;
The get request including the destination received from the media framework, and change the target request of the content name to the server address stored in the storage means, by transmitting towards the server, the The processed content is requested by requesting the content from a server, executing content processing that the media framework does not have on the content acquired from the server, and executing the content processing as a get response to the get request The communication terminal according to claim 1 , wherein content is transmitted to the media framework . The first content requesting unit further adds a playback start time and transmits it to the media framework,
The communication terminal according to any one of claims 1 to 7, wherein the content acquisition unit acquires the content to be acquired from the playback start time onward from the server and transmits the content to the media framework. A plurality of content acquisition means for processing content acquired from a server;
The first content request means generates the destination by adding different route information following the specific address,
The communication terminal according to any one of claims 1 to 8, wherein a content acquisition unit corresponding to the route information among the plurality of content acquisition units receives a get request from the media framework. Monitoring a get request issued at the time of content processing that the media framework does not have from the media framework of the own communication terminal to a destination indicated by a specific address and route information indicating the own communication terminal;
When receiving the get request including the destination from the media framework, requesting content from a server outside the communication terminal ;
Performing content processing that the media framework does not have on the content acquired from the server as a response to the content request;
Sending the processed content that has undergone the content processing to the media framework as a get response to the get request;
Is a module program that causes the computer of the communication terminal to execute. Receiving a reproduction instruction for content held by a server outside the communication terminal ;
In response to the reproduction instruction of the content, the by adding route information to the own communication terminal modules a specific address indicating the self communication terminal generates a destination, content including the destinations for the media framework Passing the request,
Is a player program that causes a computer of the communication terminal to execute
A player program, wherein the module of the self-communication terminal is a module that acquires the content from the server and executes content processing not included in the media framework of the self-communication terminal . A content playback method of a communication terminal having a media framework for playing back content,
Receiving a reproduction instruction of content held by the server;
In response to the content playback instruction, adding route information to a specific address indicating the communication terminal to generate a destination, and passing the content request including the destination to the media framework;
Upon receiving a get request issued from the media framework to the destination indicated by the specific address and the route information, requesting the content from the server;
Performing content processing that the media framework does not have on the content acquired from the server as a response to the content request;
Sending the processed content that has undergone the content processing to the media framework as a get response to the get request;
Content playback method. A content playback program for a communication terminal having a media framework for playing back content,
Receiving a reproduction instruction of content held by the server;
In response to the content playback instruction, adding route information to a specific address indicating the communication terminal to generate a destination, and passing the content request including the destination to the media framework;
Upon receiving a get request issued from the media framework to the destination indicated by the specific address and the route information, requesting the content from the server;
Performing content processing that the media framework does not have on the content acquired from the server as a response to the content request;
Sending the processed content that has undergone the content processing to the media framework as a get response to the get request;
A content playback program that causes a computer to execute.

Images