Media appliance
Abstract
A game console (105) comprising: an audio and video output (307) operable to output video signals from the game console (105) to a television screen (309); a network interface (302) for accessing a packet-based network (101); a memory (318) that stores a communication client application (113) and a video game (331), the video game (331) comprising an API to communicate with an API of the communication client application (113); a wireless interface (315) for communicating with a game controller (317); and a processing apparatus (301) coupled to the memory (318), the network interface (302), the audio-video output (307) and the game controller (317), and arranged to execute the application of the communication client (113) and the video game (331); where the communication client application (113) is configured to: allow the user to carry out two-way communications with other users through the packet-based network (101); receiving, from the video game API (331), a signal indicating an occurrence within the video game (331); use the API signal from the video game (331) to identify a delineation within the video game (331); and defer the output of one or more notifications to the user of the incoming communication events received, through the packet-based network (101), from one or more of the other users during the video game (331) until the delineation within the video game (331).

Term
4.5 yearsto projected expiry
Projected expiry 30 March 2031, counted from filing; an application has no term until it is granted.
- Priority
- Filed
- Published
- Today
- Projected expiry
12 claims: 3 independent, 9 dependent
- 1REIVINDICACIONES 1. Una consola de juegos (105) que comprende:una salida de audio y vídeo (307) operable para emitir señales de vídeo de la consola de juegos (105) a una pantalla de televisión (309);una interfaz de red (302) para acceder a una red basada en paquetes (101);una memoria (318) que almacena una aplicación del cliente de comunicación (113) y un videojuego (331), el videojuego (331) que comprende una API para comunicarse con una API de la aplicación del cliente de comunicación (113);una interfaz inalámbrica (315) para comunicarse con un controlador de juego (317);y un aparato de procesamiento (301), acoplado a la memoria (318), la interfaz de red (302), la salida de audio-vídeo (307) y el controlador de juegos (317), y dispuesto para ejecutar la aplicación del cliente de comunicación (113) y el videojuego (331);donde la aplicación del cliente de comunicación (113) está configurada para: permitir al usuario llevar a cabo comunicaciones bidireccionales con otros usuarios a través de la red basada en paquetes (101);recibir, desde la API del videojuego (331), una señal que indica una ocurrencia dentro del videojuego (331);utilizar la señal de la API del videojuego (331) para identificar una delineación dentro del videojuego (331);y diferir la salida de una o más notificaciones al usuario de los eventos de comunicación entrantes recibidos, a través de la red basada en paquetes (101), de uno o más de los otros usuarios durante el videojuego (331) hasta la delineación dentro del videojuego (331).
- 2La consola de juegos (105) de la reivindicación 1, donde:la aplicación del cliente de comunicación (113) está además configurada para devolver, antes de dicha delineación en el videojuego (331), un mensaje automatizado al uno o más de los otros usuarios a partir de los cuales se originaron los eventos de comunicación entrantes.
- 3La consola de juegos (105) de la reivindicación 2, donde el mensaje automatizado informa a uno o más de los otros usuarios a partir de los cuales se originaron los eventos de comunicación entrantes sobre la falta de disponibilidad del usuario.
- 4La consola de juegos (105) de la reivindicación 3, donde el mensaje automatizado indica, a uno o más de los otros usuarios a partir de los cuales se originaron los eventos de comunicación entrantes, la razón por la que el usuario no está disponible.
- 5La consola de juegos (105) de cualquiera de las reivindicaciones 1-4, donde:la aplicación del cliente de comunicación (113) se configura además para identificar la delineación dentro del videojuego (331) en función del momento en que un jugador muere o pierde dentro del videojuego (331).
- 6La consola de juegos (105) de la reivindicación 1, donde:la aplicación del cliente de comunicación (113) se configura además para emitir señales de vídeo de la una o más de dichas notificaciones de eventos de comunicación entrantes a la pantalla de televisión (309) junto con un control en pantalla que permite al usuario iniciar una comunicación de retorno, a través de la red basada en paquetes (101), con uno correspondiente de los otros usuarios a partir de los cuales se originaron los eventos de comunicación entrantes.
- 7Un procedimiento para operar una consola de juegos (105) que tiene una salida de audio y vídeo (307) operable para emitir señales de vídeo de la consola de juegos (105) a una pantalla de televisión (309), una interfaz de red (302) para acceder a una red basada en un paquete (101), una interfaz inalámbrica (315), una memoria (318) para almacenar una aplicación del cliente de comunicación (113) y un videojuego (331), el videojuego (331) que comprende una API para comunicarse con una API de la aplicación del cliente de comunicación (113) y un aparato ES 2 744 567 T3 de procesamiento (301), acoplados a la memoria (318), la interfaz de red (302), la salida de audio-vídeo (307) y el controlador de juego (317), y dispuestos para ejecutar la aplicación del cliente de comunicación (113) y el videojuego (331), siendo que el procedimiento comprende:permitir al usuario llevar a cabo comunicaciones bidireccionales con otros usuarios a través de la red basada en paquetes (101);recibir, desde la API del videojuego (331), una señal que indica una ocurrencia dentro del videojuego (331);utilizar la señal de la API del videojuego (331) para identificar una delineación dentro del videojuego (331);y diferir la salida de una o más notificaciones de los eventos de comunicación entrantes recibidos, a través de la red basada en paquetes (101), de uno o más de los otros usuarios durante el videojuego (331) hasta la delineación dentro del videojuego (331).
- 8El procedimiento de la reivindicación 7, que además comprende:devolver, antes de dicha delineación en el videojuego (331), un mensaje automatizado al uno o más de los otros usuarios a partir de los cuales se originaron los eventos de comunicación entrantes.
- 9El procedimiento de la reivindicación 8, donde el mensaje automatizado informa a uno o más de los otros usuarios a partir de los cuales se originaron los eventos de comunicación entrantes sobre la falta de disponibilidad del usuario.
- 10El procedimiento de la reivindicación 9, donde el mensaje automatizado indica, a uno o más de los otros usuarios de los que se originaron los eventos de comunicación entrantes, la razón por la que el usuario no está disponible.
- 11El procedimiento de cualquiera de las reivindicaciones 7-10, que comprende además:identificar la delineación dentro del videojuego (331) en función de cuándo un jugador muere o pierde dentro del videojuego (331).
- 12El procedimiento de cualquiera de las reivindicaciones 7-11, que comprende además:emitir señales de vídeo de la una o más de dichas notificaciones de eventos de comunicación entrantes en la pantalla de televisión (309) junto con un control en pantalla que permite al usuario iniciar una comunicación de retorno, a través de la red basada en paquetes (101), con uno correspondiente a uno o más de los otros usuarios a partir de los cuales se originaron los eventos de comunicación entrantes.
Independent claims12
88 paragraphs in 4 sections, as filed
DESCRIPTION
Game console and procedure for operating a game console
Field of the invention
The present invention relates to a game console comprising a processing apparatus for making voice or video calls through a packet-based network and a method for operating said game console.
Background
Some communication systems allow the user of a terminal, such as a personal computer, to make voice or video calls over a packet-based computer network such as the Internet. Such communication systems include voice or video over Internet Protocol (VoIP) systems. These systems are beneficial to the user as they are often significantly less costly than conventional fixed line or mobile networks. This can be particularly the case for long distance communication. To use a VoIP system, the user installs and runs the client software on their terminal. The client software configures the VoIP connections as well as other functions such as registration and authentication. In addition to voice communication, the customer can also establish connections for other means of communication such as instant messaging (“IM”), SMS messaging, file transfer, and voicemail.
One type of communication system for packet-based communications uses a peer-to-peer ("P2P") topology. To enable access to a peer-to-peer system, a user runs p2p client software provided by a P2P software provider on their terminal and registers with the P2P system. When the user registers with the P2P system, the client software receives a digital certificate from a server. This can be called a "user identity certificate" (UIC). Once the client software has been provided with the certificate, calls or other communication connections can be configured and subsequently routed between the end users ("peers") of the P2P system without the additional use of a server in the call setup. . Instead, the client looks up the required IP addresses from the information distributed between the P2P client software on the terminals of other end users within the P2P system. That is, the address look-up list is distributed among the colleagues themselves. Once the IP address of a receiver's terminal has been thus determined, the peer P2P client software then exchanges the UIC certificates with the receiver's P2P client software. The exchange of these digital certificates between users provides proof of the identities of the users and that they are duly authorized and authenticated in the P2P system. Therefore, the presentation of digital certificates provides confidence in the identity of the users.
Therefore, it is a feature of peer-to-peer communication that, once registered, users can configure their own communication paths through the P2P system in an at least partially decentralized manner based on distributed address lookup and / or the exchange of one or more digital certificates, without using a server for these purposes. More details of an example P2P system are described in WO 2005/008524 and WO 2005/009019.
VoIP communications or other packet-based communications can also be implemented using non-P2P systems that use centralized call setup and / or authorization, for example through the server.
One problem with packet-based communications is that their accessibility to users is limited. In particular, these communications are most commonly accessed using a personal computer. This has the disadvantage that the user must be technically competent enough to download, install and operate the packet-based communication client software on their personal computer, which constitutes a barrier to acceptance. Even when the communication client is installed and running on a personal computer, its use may be limited because personal computers are often not in a place where the user is familiar or comfortable with communication. For example, a personal computer is often found in a study, which for many users is not the most natural or comfortable environment for making phone calls.
Although packet-based communication systems can also be accessed through certain mobile devices, they generally do not have processing resources or display screens available to offer a full range of features, such as video calls.
ES 2 744 567 T3
Therefore, it would be desirable to make packet-based communications more accessible to users. One way to do this would be to run a packet-based communication client on a processor built into a familiar media device such as a television or set-top box to connect to a television. Integrated in this context means within the housing of the apparatus. The ability to integrate an integrated processor into a television or decoder is known, and indeed many modern televisions and decoders already contain a processor to perform at least part of the digital signal processing required to decode and output television signals visible to the screen.
EP 2 114 062 A1 describes a television comprising a television screen, an alternate user interface, a network port for connecting the television to a network, and a processor arranged to run a client program configured to allow an end user to communicate in a call through the network, to receive a notification of an incoming communication event signaled to the television through the network, to control the television screen to notify the user of the incoming communication event when the television screen is available and to control the alternate user interface to indicate the incoming communication event when the television screen is not available due to displaying broadcasts of TV.
Resume
However, the inventors have recognized that one or more potential problems may still exist due to a conflict between the added functionality of the customer application and the existing functionality of a conventional television.
In particular, the client's operation is likely to interfere with the user's vision, because incoming calls will be asynchronous with the current state of the TV. That is, the calls are not chosen to be initiated by the television user, but arrive over the packet-based network at unpredictable times at the start of another remote user, and therefore can arrive when the television is busy with viewing content from a game console.
According to one aspect of the present invention, there is provided a game console according to claim 1 and / or a method for operating a game console according to claim 7.
Therefore, embodiments of the present invention automatically defer notifications of incoming calls or other communications until after a suitable moment in the video game, sending the notifications to the user once that time has been reached. This means that a user will not be unduly disturbed by incoming asynchronous communication events during the video game in question, but will instead be sent those communication events later at a more suitable time.
Incoming communication events may comprise an incoming packet-based voice or video call.
The client application may be configured to detect such delineation based on a timer set by the user.
The client application may be configured to detect such delineation based on a timer set by the user.
The notification may take the form of audible and / or on-screen notifications. Therefore, in further embodiments, the client application can be configured to issue one or more deferred notifications for display on the screen.
In addition, the client application can be configured to issue the one or more deferred notifications for display on the screen along with an on-screen control that allows the user to initiate a return communication with a different corresponding user over the packet-based network. .
This advantageously facilitates the most efficient return of the call or other communication.
In further embodiments, the client application can be configured to return, prior to such delineation, an automatic message to one or more users of one or more incoming communication events received during the video game.
ES 2 744 567 T3
Therefore, it is possible not only to defer a notification until after delineation, but also to inform the other remote user about the unavailability. In a further embodiment, the communication client may comprise a user configuration arranged to alternate between a first mode of operation where notifications of incoming communication events received during the video game are deferred, and a second mode of operation where said not deferred. notifications. Instead, they are sent to the user during the game.
The client application can be configured to detect such delineation when a player dies or loses within the video game.
In embodiments, the method may conform to any of the above game console features.
Brief description of the drawings
For a better understanding of the present invention and to show how it can be put into practice, reference is made, by way of example, to the accompanying drawings where:
Figure 1 is a schematic representation of a communication system, Figure 2 is a schematic representation of a remote control unit, Figure 3a is a schematic block diagram of a television set outside the scope of the present claims, Figure 3b is a schematic block diagram of a game console according to an embodiment of the present invention, Figure 4 is a schematic representation of a user interface, and Figure 5a is a schematic representation of a deferred call notification, Figure 5b is a schematic representation of another deferred call notification, Figure 5c is a schematic representation of another deferred call notification, and Figure 6 schematically illustrates the transmission of a transport frame.
Detailed description
An embodiment of the invention will be described with reference to Figure 3b. However, to aid in the description of that embodiment, arrangements outside the scope of the present claims will first be described with reference to Figures 1, 2 and 3a.
Figure 1 shows a communication system 100 comprising a packet-based network 101 such as the Internet; and further comprising a separate television broadcast network 108, such as a terrestrial, satellite, or cable television network. A plurality of computer terminals 102 are shown coupled to the Internet 101, each comprising a network interface for communicating over the Internet. Also shown is a plurality of televisions 103 coupled to the Internet 101, each of which also comprises a network interface for communicating over the Internet. In addition to the network interface, each television set 103 further comprises a television receiver for receiving analog and / or digital television signals that are broadcast through the television network 108. Alternatively or additionally, a television set 103 could be arranged to receive packet-based television signals over the Internet 101 or other packet-based network. The difference between a broadcast and a communication made over a packet-based network is that the broadcast signals are transmitted indiscriminately, without transmitting to the selected destination devices and regardless of whether the end user has selected to receive the signal (although it can still be a decryption key or similar is necessary so that only authorized users can obtain meaningful information from the television signal for viewing). On the other hand, packet-based communications are point-to-point, an address of the intended destination device being included in the packets. In the case of television signals based on
ES 2 744 567 T3 packets transmitted over the Internet, these are still point-to-multipoint communications rather than broadcast.
Each computer terminal 102 is installed with a communication client application 110. Each computer terminal 102 also comprises an audio transceiver 111 comprising a speaker and a microphone, for example, in the form of an earphone, or a speaker and a built-in microphone. Most of the computer terminals 102 also preferably comprise a camera 112. In addition, each television 103 comprises an integrated processor and memory installed with a version of the communication client application 113 specially adapted to operate on a television. Each television set 103 also comprises a web camera 115 and an audio transceiver with speaker and microphone, or is connected to or can communicate with such components. An audio transceiver may be provided in a remote control unit 114 of the television 103, which is briefly explained.
The communication client applications 110 and 113 are preferably peer clients for establishing and conducting VoIP calls according to the peer-to-peer principles as discussed above. For this purpose, a peer-to-peer backend server 104 is coupled to the Internet 101 to receive registration requests from client applications 111 and 113. The back end server 104 is arranged to distribute UIC certificates to the respective client applications 111 and 113 running on the computer terminals 102 and on the televisions 103 in response to registration requests. Once registered and, therefore, in possession of a UIC certificate, the client applications 111 and / or 113 can look up the addresses of others, exchange and authenticate the certificates of others, and thus establish a voice or video call through Internet 101. It will be appreciated, however, that other types of communication client may alternatively be used, for example based on server-based centralized call setup.
Furthermore, the communication system 100 may comprise a telephone network 107 such as a circuit switched network, and a gateway 106 that connects between the Internet 101 and the telephone network 107. A gateway version of the client application is arranged to run on the gateway 106, and a communication client application 110 or 113 running on a computer terminal 102 or a television set 103 is capable of establishing a call with a unit. dedicated telephone number 109 of the telephone network 107. This is accomplished by establishing a connection to the client at gateway 106 using the peer-to-peer call setup and then supplying the relevant phone number to gateway 107 (effectively the client of user 110 or 113 sees gateway 106 as a peer) . The telephone network 107 may comprise, for example, a fixed line network ("land line") and / or a mobile cellular network.
Each television set 103 has an associated remote control unit 114, the example of which is illustrated in FIG. 2.
As shown in Figure 2, the remote control unit (or simply "remote control") comprises a microphone 201, a speaker 202, a first remote interface in the form of an infrared (IR) transmitter 203 and a second remote interface in the form of a short-range RF interface 204 such as a Bluetooth interface. Microphone 201 and speaker 202 are operatively coupled to Bluetooth interface 204. The remote control 114 is thus arranged to communicate voice signals from the microphone 201 to the television set 103 through the Bluetooth interface 204 and to receive voice signals from the television set 103 through the Bluetooth interface 204 for the reproduction of the speaker 202. .
The remote control 114 further comprises a plurality of buttons operatively coupled to the infrared transmitter 203, arranged so as to allow the user to control the television set 103 through the infrared transmitter 203. The buttons comprise a "hold" button 205 for the setting the TV to a low power mode. The buttons further comprise numeric or alphanumeric buttons 206 for changing channels or supplying other numeric or alphanumeric data to the television 103; function buttons 208 to control various functions of the television 103, for example, to control a cursor and / or menu system; and optionally dedicated call buttons 207 to perform specific dedicated operations related to the call functionality of the customer application 113, for example, "Call", "hang up" or buttons to zoom in and out during a video call.
Figure 3a is a schematic block diagram of a television set 103 outside the scope of the present claims. The television 103 is a dedicated television unit in the sense that its primary purpose is as television and is designed to fulfill the role of a family or home television. However, at the same time a secondary built-in functionality such as VoIP calls is additionally provided.
The television set 103 comprises, within a single housing: an integrated processing apparatus 301; a memory
Random Access (RAM) ES 2 744 567 T3 319; and an integrated non-volatile storage device 318 that may comprise an erasable and electronically reprogrammable memory (EEPROM or "flash" memory), a magnetic storage medium, and / or a one-time write ROM. Non-volatile storage device 318 is coupled to processing apparatus 301 and stores a basic operating system (OS) 326, a television application 330, and a communication client application 113 such as a VoIP client. Processing apparatus 301 is arranged to execute operating system 326, for example, either by collecting instructions directly from ROM or by first loading from flash memory to RAM 319 prior to extraction. When executed, operating system 326 is configured to load television application 330 and client application 113 into RAM 319 and schedule them for execution in processing apparatus 301. Processing apparatus 301 is thus arranged to execute the display. television application 330 and client application 113 under the control of operating system 326. In some examples, only a minimum 326 operating system may be required, in the form of a basic scheduler.
The television set 103 also comprises, within the same housing: a video frame buffer 320 and a user interface (UI) frame buffer 322, a video hardware 324, a display 309, an amplifier 314 and a speaker 316 or an output to an external speaker or headphones, a receiver of television 304, an external audio and video (AV) input 306, such as a SCART or HDMI input from an external source, a webcam or webcam input 308 to connect to an external webcam, a network interface 302 in the form of a first short-range RF transceiver such as a Wi-Fi transceiver, a first remote interface 310 in the form of an infrared (IR) receiver, and a second remote interface in the form of a second short-range RF transceiver 312 such as a Bluetooth transceiver.
The video frame buffer 320 and the user interface (UI) frame buffer 322 each have an input coupled to the processing apparatus 301. The video hardware 324 has an input coupled to the outputs of the video frame buffer. 320 and the UI frame buffer 322. The display 309 has an input to the output of the video hardware 324. Frame buffers 320 and 322 could be dedicated hardware buffers or alternatively could be implemented in general-purpose memory. Amplifier 314 has an input coupled to processing apparatus 301 and an output coupled to speaker 316. Processing apparatus 301 is further coupled to network interface 302, television receiver 304, auxiliary input 306, camera input web 308, infrared interface 310, and Bluetooth interface 312.
Any or all of the above components may be coupled to processing apparatus 301 through intermediate components such as a bus and / or cache (not shown), as will be understood by one of ordinary skill in the art.
The television receiver 304 comprises an input for connecting at least one receiving means such as an antenna, a satellite dish or a cable line, and is thus arranged to receive television broadcast signals from the television network 108 via the means of reception. Television receiver 304 is a hardware front end that may comprise, for example: sampling circuitry, low noise amplifier, filter, mixer, and / or analog-to-digital converter (ADC). Once received by the television reception unit 304, the television signals are thus made available to the processing apparatus 301 for signal processing. Television application 330 comprises a signal processing engine in code form which, when executed, performs at least part of the required signal processing on received television signals. The processed television signals are then sent to video frame buffer 320 and amplifier 314 for consumption by the end user. The signal processing engine may comprise, for example: a digital filter, a demodulator, a demultiplexer, a decoder, a decryption block and / or an error checking block. However, different ways of allocating television receiver and processing functionality are also possible between dedicated hardware and software. For example, more of the functionality, such as demultiplexing, could be moved to the front end of receiver 304. Techniques for receiving and processing television signals will be known to one of ordinary skill in the art.
In the case of traditional analog television broadcasts, signals from a plurality of different simultaneous programs (from different TV channels) are frequency division multiplexed onto radio waves by being transmitted on different frequencies. The television receiver 304 will then comprise a tuning circuit to demultiplex the transmissions and therefore separate the signal from the required program. In the case of digital television transmissions, the signals of different concurrent programs are each divided into packets and interleaved to multiplex the signals of the different programs in a transport frame for broadcasting with time division. The television application signal processing engine 330 will then comprise a packet filter to demultiplex the packets of different transport frames and thus separate the signal from the required program. It is also possible to transmit multiple frames of
ES 2 744 567 T3 transport on different frequencies, requiring a tuner as well. Furthermore, for digital television, one or more of the transport frames may comprise additional program information such as an electronic program guide (EPG).
Video signals for output to television screen 309 can also be received through AV input 306 from an external source such as a DVD player or game console.
Television application 330 further comprises a graphics UI engine, a remote protocol engine, an application programming interface (API), and a television UI layer. The general operation of the signal processing engine, UI graphics engine, remote protocol engine, and API is controlled by the TV UI layer. The user can select the broadcast to be viewed by pressing buttons 205, 206, 208 on remote control 114, causing remote control 114 to communicate control signals to processing apparatus 301 via infrared transmitter 203 and receiver 310 The user can also use the buttons in a similar way to view additional information such as EPG or control menus, and to navigate EPG or menus. The relevant control signals are interpreted by the television application remote protocol engine 113, which in turn communicates with the television UI layer. In response, the television UI layer controls the signal processing engine to output the television program corresponding to the video frame buffer 320, and / or controls the UI graphics engine to output graphics to the UI frame buffer. 322 (for example, to display EPG or menu graphics). The frame buffers 320 and / or 322 supply their content to the video hardware 324 for display on the screen 309. The UI frame buffer 322 and the video hardware 324 may be arranged to overlay UI graphics on top of the video program. current television in a partially transparent way, and / or leave at least part of the television program visible.
As mentioned, the television set 103 comprises a network interface 302. This network interface 302 may take the form of a wireless transceiver, such as a Wi-Fi transceiver, to communicate wirelessly with a wireless router for home or wireless use. Office 303, as found in most modern homes or offices. Router 303 in turn connects to Internet 101. However, alternatively, the network interface 302 may comprise other options such as a wired modem or a port to an external wired modem.
The communication client application 330 comprises a protocol stack having an I / O layer that, when executed in the processing apparatus 301, is operable to transmit and receive signals over the Internet 101 via the network interface. 302. The I / O layer comprises a network signaling protocol for transmitting and receiving control signals over the Internet 101 through the network interface 302. The I / O layer may also comprise an API to communicate with the API of the television application 301.
The I / O layer further comprises a speech engine comprising a speech codec. The speech engine is arranged to accept speech signals from microphone 201, and to encode said speech signals for transmission over the Internet 101 via network interface 302. The speech engine is also arranged to decode speech signals received through the Internet 101, through the network interface 302, for output to the television amplifier 314 and to the speaker 316, or to the speaker 202 on the remote control. 114 via Bluetooth interfaces 312 and 204. The I / O layer further comprises a video engine comprising a video codec. The video engine is arranged to accept video signals from the webcam input 308, and to encode said video signals for transmission over the Internet 101 via the network interface 302. The video engine is also arranged to decoding video signals received over the Internet 101 via Network Interface 302, for output to the frame buffer of UI 322, video hardware 326, and a display 309. Alternatively, in a full screen mode, the video codec could stream video through the video frame buffer 320.
Higher up the protocol stack, the client application 113 comprises a client engine that is responsible for the call setup. The client engine controls the client network signaling protocol engine 113 in order to establish a live video or voice call with another user terminal 102 or 103 over the Internet 101, preferably using the P2P call setup. as discussed above or potentially using a centralized call setup through a server. The client engine can also handle other functions such as connection management, authentication, encryption and / or exchanging presence information with client applications 111 or 113 of other user terminals (presence information indicates the availability of a user for communication , and preferably defined at least in part, by the respective user himself).
Still higher up the protocol stack, the client application 113 comprises a client UI layer that is responsible for the client's user interface. The client UI layer is operable to generate an interface of
ES 2 744 567 T3 client user for output to frame buffer of UI 322, video hardware 324 and display 309. This can be transmitted via APIs and the UI graphics engine of the TV application 330 under control of the TV UI layer (or, alternatively, client application 113 could be provided with its own UI graphics protocol to send graphics directly to UI frame buffer 322). The customer user interface thus presents the user with on-screen controls that can be activated using the buttons 206, 207, 208 on the remote control 114. Based on these button presses, the remote control 114 communicates control signals to the apparatus. processing 301 via infrared transmitter 203 and receiver 310. These control signals can be interpreted by the UI protocol engine in the television application 330 and then signaled via APIs to the I / O layer of the client application 113 (or alternatively the I / O layer of the client application 113 could be provided with its own remote control protocol to directly interpret these control signals). In turn, the client I / O layer protocol 113 communicates with the client UI layer. Therefore, the client UI layer is configured to respond to user input in order to control the overall operation of the client application 113, for example by allowing the user to select contacts to call, hang up, etc.
Figure 4 illustrates an example user interface that could be displayed on screen 309 by client application 113 when called by the user using the relevant buttons on remote control 114. The user interface may only be displayed in part of display 309, allowing at least a portion of a currently viewed program to remain viewable; or it can alternately fill the entire screen 309. The displayed user interface comprises a series of panels. For example, the user interface may comprise a first panel 402 that displays profile information of the user of the television 103 where the client 113 is running. For example, the profile information may comprise the user's name, an "avatar image" (an image that the user has chosen to represent himself) and / or a "mood message" (a short statement defined by the user for inclusion in their profile). Furthermore, the user interface may comprise a second panel 404 that displays a list of the user's contacts (preferably the client 113 is configured to only allow calls between users who have agreed to be contacts). In addition, the user interface may comprise a third panel 406 that displays a profile of a selected one of the contacts and / or a fourth panel 408 that provides a menu or other controls for selecting to call the selected contact.
In addition, the UI layer of the client 113 may be configured to communicate with the UI layer of the television application 330, through the APIs and the operating system 326. This allows the client application 113 and the television application 330 negotiate control of screen 309 and / or speaker 316 or 202.
Whether the client application 113 or television application 330 takes precedence may depend on the implementation and / or the situation. Since television set 103 is primarily a television, then preferably customer application 113 should require permission from television application 330 before controlling display 309 or speaker 316 or 202. However, a user-defined setting may be provided that allows the user to control whether or not the client application 113 can autonomously take control of the display 309 and / or the speaker 316 or 202, for example, to notify the user in case of an incoming call event. Preferably, this setting would be stored in non-volatile memory 318 and could be read by client application 113 and / or television application 330. For example, television application 330 can be configured to read a setting from memory and, if set, to unambiguously allow client application 113 to control the screen and / or the speaker. Alternatively, client application 113 may be configured to read a setting from memory and, if configured, to control the screen and / or speaker without seeking permission from television application 330.
At least one such user configuration can be read by the client application 113 and, when established, the client application 113 is configured to defer any notification of incoming VoIP calls or other incoming communication events received over the Internet 101 until a suitable juncture in the user's television viewing. This could mean deferring a notification until after a television program has ended, or until some other appropriate juncture in the program, such as a business interruption. Another possibility would be to defer a notification until the video signals are no longer received through the AV input 306 from an external source such as a DVD player or a game console. Generally speaking, incoming communication events signaled asynchronously to the television set 103 over the Internet 101 through the network interface 302 are postponed in deference to a higher priority source, such as the television receiver 308 and the network. TV 108 or an AV input 306 and the external source.
It should be borne in mind that the concept of postponement of a notification is different and advantageous compared to the mere total suppression of a notification. The suppression of the notification would mean the total prohibition so that
ES 2 744 567 T3 is never sent to the user; while the deferral requires that the notification continues to be issued to the user, but postponed until a later time.
To do this, the client application 113 is configured with a mechanism to delineate the display activity in question. The client application 113 will not understand the actual user content of the television program or the like, so it cannot directly tell when one program ends and another begins, or it cannot directly indicate the difference between the main program and commercial breaks. Therefore, a delineation mechanism is required, for which there are a number of options as discussed below.
A first preferred mechanism involves receiving additional program information broadcast through television network 108. In this case, the additional program information is received by client application 113 through television receiver 308 and comprises timing information that it can be used by the client application 113 to outline the television program in order to defer notifications.
As schematically illustrated in Figure 6, a digital television broadcast may comprise audio data 601 and video data 602 of one or more program frames all interleaved (i.e. time division multiplexed) in one frame. of combined transport for transmission on a particular frequency. Additional program information 603 that provides timing information for one or more programs (potentially among other information such as captions and textual program summaries or minutes) is also embedded in the transport frame. The additional program information 603 may take the form of a general data frame multiplexed in the transport frame in conjunction with a plurality of program frames, providing program information for a plurality of programs. An example of this would be an electronic program guide (EPG). Alternatively or additionally, the respective individual program information may be provided in the frame of each program. The audio data, video data, and additional program information are decoded by the signal processing engine of the television application 331, and the required program timing information can be accessed by the client application 113 through the API under control of the TV UI layer.
In a variant of this first mechanism, the program timing information 603 comprises program schedule information such as the EPG. That is, nominal information about when the program or programs are scheduled to start or end. For example, the API of the client application 113 may allow you to access the EPG decoded by the signal processing engine of the television application 331. The client 113 can therefore determine that the television program currently being viewed on screen 309 is scheduled to end at a certain time, and defer notification until that time.
An example is shown in figure 5a. Here, the client 113 determines through the API to the EPG that the television program being watched is scheduled to run from 8:00 pm to 9:00 pm If an incoming call is signaled over the Internet 101 and received on the network interface 302 during the program, for example at 8:13 pm, then the client application 113 will temporarily block the notification of the incoming call until scheduled end time at 9:00 pm A similar procedure would occur if an incoming IM chat message is received during the program, after the scheduled end time of the program (either at that time or right after), the client application 113 will then take control of the screen 309 to display a list 503 of one or more communication events missed during the program. The list 503 preferably comprises a control such as a cursor 505 that can be controlled by the user, for example, via the function buttons 208 on the remote control, to thereby cause the customer 113 to initiate a VoIP call. return or other corresponding packet-based communication with the respective other user.
In another variant of the first mechanism, the program timing information 603 may comprise a real-time indication of the actual end time of the program (which can be accessed by the client via the API to the television application of a similar to that discussed above).
As shown in figure 5b, if the schedule is exceeded until a time after the scheduled time, for example, until 9:02 pm, then the client 113 will not display the list 503 of missed events until the end time of 9: 02pm This advantageously avoids delayed notifications that interfere with the last few minutes of a show (which could be the most critical part of the show in the case of a suspense drama, for example). Client 113 will also defer any incoming communication received during the bypass period (eg, 9:01 pm).
ES 2 744 567 T3
Also, as shown in figure 5c, the time information of the real-time program can also indicate the time of the breaks in the program (it is normally used as commercial breaks to show ads, but it can also be used for other purposes, like newsletters). in case the client application 113 is enabled to show the list of missed events 503 during the break.
A second mechanism for delineating the program is for client application 113 to download program timing information via the Internet 101 and network interface 302, for example, from a server of a third party broadcaster, program producer or service. This downloaded information may include scheduling information and / or real-time updates of scheduled times. This second mechanism has the advantages of the first mechanism, with the additional advantage of being compatible with legacy technologies where certain timing information 603 may not be available. available via broadcast (most digital television broadcasts today include at least programming information such as EPG, but not all necessarily provide real-time indications of program programming, and also analog broadcasts do not include no information about the program schedule), it can even be used in conjunction with the earlier variant of the first mechanism to provide updates to the schedule information received on stream 603,
A third, less preferred mechanism for outlining the program is to provide a timer that can be set by the user. The timer may be a feature of the client application 113, or a feature of the television application 330 that can be accessed through the API. In this arrangement, the user sets the timer for a predetermined time, and the client application 113 waits until that time before displaying the list of missed events 503. This would have an effect similar to that shown in Figure 5a. As with the first variant of the first mechanism, the third mechanism has the disadvantage of possible interference with the end of a program being overshot, and also has the added disadvantage of requiring an inconvenient user input procedure. On the other hand, this third mechanism has the advantage of being compatible with legacy technologies such as analog broadcasts that do not include program timing information, and without requiring an additional server infrastructure to provide said information over the Internet 101.
A fourth mechanism would be to provide a user-defined “do not disturb” (DND) setting that the client could assert at the beginning of the program. That could be a DND presence state existing within the client application 113. In this case, the client application 113 is configured to detect when the user overrides the DND state, and after detecting it automatically display the list of missed events 503.
In some of the above mechanisms it may be necessary for the client application 113 to monitor the current time. This could be done based on a local clock 340 or by receiving current time updates from the Internet 101 or the television network 108. However, using the latter variant of the first mechanism, it may not be necessary to monitor the current time if the program timing information 603 provides real-time triggering (as opposed to a real-time update of the end time in hours and hours). minutes of the day). Nor will it be necessary to monitor the current time in the fourth mechanism, based on DND.
In a particularly advantageous addition to the present invention, the client application 113 may be further configured to return automated messages to the callers of the missed calls (or more generally to the other users who are the originators of the missed communication events). The automatic message is returned by the client application 113 when an incoming communication event is received during a program in progress, without requiring input from the local user viewing the program (the receiver). It is transmitted to the other remote user (the caller) over the network interface 302 and Internet 101, and informs the caller that the receiver is not available. Preferably, the automated message tells the caller why the receiver is not available (watching television). In a particularly preferred embodiment, client application 113 may be configured to use program scheduling or other timing information to predict when the receiver is likely to be available again (i.e., when the current program is finished), and you can include this prediction information in the automated message for the benefit of the caller. This could even be incorporated as a new type of presence state.
The invention is not limited to on-screen notifications. The notifications may comprise audible notifications delivered through a loudspeaker, and it may be desirable to defer audible notifications so that they do not disrupt the user experience of a current television program.
The arrangements described above are not limited to any particular mechanism for delineating a television program or other viewing activity. Several examples have been described above, and others may be
ES 2 744 567 T3 obvious to one skilled in the art given the disclosure herein. For example, in an arrangement outside the scope of the present claims, notifications could be deferred until the user changes channels, switches to a different source, such as from TV shows to AV input 308, or accesses the EPG. In another example, outside the scope of the present claims, the customer can access the decoded audio through an API for the television application 330 and attempt to determine when a business interruption occurs based on a change in the maximum or maximum volume levels. medium (broadcasters tend to increase the volume during commercial breaks to get the user's attention, although this procedure will be vulnerable to false alarms, for example during action sequences of a program).
Note also that the term "show" is not limited to any particular type of show content, and can refer to, for example, a movie, soap opera, documentary, sporting event, news show, and so on.
In addition, other ways of assigning the various clients, television and other functionalities between different processors are envisaged. For example, one or more dedicated signal processors (DSP) could be arranged to run the television signal processing engine of the television application 330 and / or the video engine and / or voice engine of the client application. 113; one or more separate CPUs being arranged to execute the UI layer, the client engine, the protocol and the graphics engines of the client application 113 and / or the UI layer and the protocol and the graphics engines of the television application 330. In another example, the customer application and the television application could each run on a respective different CPU built into the television 103. Part or all of the functionality of the television application 330 could alternatively be implemented in dedicated hardware, including the possibility of a signal processing apparatus wired at the front end of the television receiver 304.
Furthermore, despite the preferred application, the above-described technique is not limited to use in a television that has the above components, including the television screen, all within a single self-contained housing. In another example outside the scope of the present claims, the technique could be implemented in a set-top box for plugging into such a television. In that case, the diagram would be similar to Figure 3a, but with the television hardware 320, 322, 324 and the display 309 replaced by an audio-video (AV) output.
In an exemplary embodiment of the present invention, illustrated in Figure 3b, the client application 113 is installed on a game console 105. Similar to television 103, console 105 comprises a processing apparatus 301 in the form of one or more CPUs, coupled to: a non-volatile storage medium 318 such as a hard disk drive, flash memory, and / or drive. Optical disc; a RAM 319; a webcam or input 308 from a webcam; and a network interface 302 such as a Wi-Fi transceiver for accessing a packet-based network, such as the Internet 101 (eg, through wireless router 303). Processing apparatus 301 is further coupled to dedicated gaming graphics hardware 325 and dedicated audio hardware 327, which in turn are connected to an audio-video (AV) output 307 to connect console 105 to a television 103 . The processing apparatus 301 is further coupled to a further wireless interface 315 operating on a suitable band to communicate to and from a wireless controller 317 or other such game controller (or, alternatively, a wired interface could be provided). The non-volatile storage 318 supplies the client application 113 and a video game 331 (not necessarily from the same unit or storage medium), both arranged for execution in the processing apparatus 301 (preferably under the control of an operating system 326) . The video game comprises a console library arranged to handle the I / O with the various devices 315, 325, 327 and 308; a game engine arranged to perform the underlying game logic, and a game UI layer arranged to generate game graphics and sound for output through the graphics and sound hardware and console library 325, 327.
The video game 331 also comprises an API to communicate with the client application API 113 through the operating system 326. The APIs can be used to point occurrences within the video game 331 to the client 113, and these flagged occurrences can be used by the client 113 to outline the video game in order to defer notifications. For example, notifications of an incoming call can be deferred until a player dies or loses within the video game. This may be a better time to notify the user that they are in the middle of the game and do not want to be distracted.
Although the present claims are directed to a game console and a method of operating a game console, generally speaking, the technique may, in examples outside the scope of the present claims, be applied to any other media device that has an apparatus. video to output signals. to a television screen. The video apparatus may comprise any combination of dedicated hardware and / or memory storage software module regions, with any software modules running on the same or on a different processor unit such as customer application 103. Depending of
ES 2 744 567 T3 device and implementation, video apparatus can take different forms. In the television set outside the scope of the present claims, shown in Figure 3a, for example, the video apparatus can be said to comprise a combination of frame buffers 320 and 322, video hardware 324 and / or a region of the non-volatile memory 318 that stores the signal processing code of the television application. In the example console 105 of the embodiment shown in Figure 3b, the video apparatus can be said to comprise the video hardware 325, the external AV output 307, and / or a non-volatile storage region 318 that stores the video code. video game graphics processing 331.
Furthermore, it is to be appreciated that the present invention is not particularly limited to VoIP or a 10-peer topology. Other packet-based networks, protocols, and call setup procedures can also be used.
Other variations of the present invention may be apparent to one of ordinary skill in the art from the disclosure herein. The scope of the present invention is not limited by the described embodiments, but only by the appended claims.
Contents4
1 sheet
Sheet 1
27 members in 9 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 201005458 | United Kingdom | – | |
| 201005458 | United Kingdom | A |
Members27
| Document | Office | Kind | |
|---|---|---|---|
| GB201005458D0 | United Kingdom | D0 | |
| US2011244955A1 | United States of America | A1 | |
| WO2011121006A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CN102823238A | China | A | |
| EP2543179A1 | European Patent Office (EPO) | A1 | |
| US8998720B2 | United States of America | B2 | |
| US2015215250A1 | United States of America | A1 | |
| CN102823238B | China | B | |
| CN105915976A | China | A | |
| EP2543179B1 | European Patent Office (EPO) | B1 | |
| ES2634035T3 | Spain | T3 | |
| EP3229452A1 | European Patent Office (EPO) | A1 | |
| EP3229452B1 | European Patent Office (EPO) | B1 | |
| DK3229452T3 | Denmark | T3 | |
| PT3229452T | Portugal | T | |
| US10454862B2 | United States of America | B2 | |
| EP3576395A1 | European Patent Office (EPO) | A1 | |
| ES2744567T3This record | Spain | T3 | |
| US2020084167A1 | United States of America | A1 | |
| US11496427B2 | United States of America | B2 | |
| US2023022815A1 | United States of America | A1 | |
| EP3576395B1 | European Patent Office (EPO) | B1 | |
| PT3576395T | Portugal | T | |
| DK3576395T3 | Denmark | T3 | |
| FI3576395T3 | Finland | T3 | |
| EP4557751A2 | European Patent Office (EPO) | A2 | |
| EP4557751A3 | European Patent Office (EPO) | A3 |
Numbers
- Publication
- 2744567
- Application
- 16207628
Titles2
- Spanish
- Consola de juegos y procedimiento para operar una consola de juegos
- English
- Game console and procedure for operating a game console
Classification
- CPC, 25
- H04N21/4104
- H04N21/47
- H04L51/10
- H04N21/431
- H04N21/434
- H04N21/4385
- A63F2300/572
- A63F2300/577
- H04M7/006
- H04M7/122
- H04L65/1089
- H04N21/4221
- H04N21/42221
- H04N21/42222
- H04N21/4431
- H04N21/4542
- H04N21/4781
- H04N21/4788
- H04N21/485
- H04N21/4882
- H04N21/6125
- H04N21/6175
- H04N21/84
- H04N21/4316
- H04L67/10
- IPC, 16
- H04M7 00
- H04N5 445
- H04L29 06
- A63F13 00
- H04L12 58
- H04N21 422
- H04N21 443
- H04N21 454
- H04N21 478
- H04M7 12
- H04N21 4788
- H04N21 485
- H04N21 488
- H04N21 61
- H04N21 84
- H04L29 08