Application controlled modification of priority transition content output

Abstract

To provide a method for application-controlled modification of priority transition content output.SOLUTION: Application-controlled modification of priority transition content output is performed by: determining that an application has lost priority while the application is sending output; assigning a standby state to the application; recording a display output and audio output generated by the application; modifying the recording of the output generated by the application in response to a request from the application; and reproducing the recorded contents according to the determination that the application has a priority.SELECTED DRAWING: Figure 2

Description

[Background technology]

[0001] Output devices installed in a vehicle, such as speakers, displays, etc., are used by multiple applications. Some applications are non-flutter applications that generate continuous audio streams from radio, pre-recorded physical media, the Internet, etc. Some applications are flutter applications that generate intermittent audio data related to navigation, warnings, etc. At any given time, multiple applications may be sending requests for output by an audio output device or a video output device, such as a touchscreen.

[0002] In vehicle entertainment systems where multiple applications compete for output device priority, priorities are arbitrated and assigned in real time, so that the application holding priority, and therefore the application currently outputting, can constantly change. If an application loses priority, it continues to generate content for output. When the application regains priority, content output resumes. [Brief explanation of the drawings]

[0003] Aspects of the present disclosure are best understood from the following detailed description when read in conjunction with the accompanying figures. It should be noted that, according to standard industry practice, various features have not been drawn to scale. In fact, the dimensions of various features may be arbitrarily increased or decreased for clarity of illustration.

[0004] [Figure 1] FIG. 1 is a schematic diagram of a system for modifying application control over priority transition content output, according to at least some embodiments of the subject disclosure. [Figure 2]FIG. 2 is an operational flow for modifying application control over content output for priority transitions, according to at least some embodiments of the subject disclosure. [Figure 3] FIG. 3 is an operational flow for modifying recorded output according to at least some embodiments of the subject disclosure. [Figure 4] FIG. 4 is a block diagram of a hardware configuration for modifying application control over content output for priority transitions, according to at least some embodiments of the subject disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0005] The following disclosure provides numerous different embodiments or examples for implementing different features of the provided subject matter. To simplify the disclosure, specific examples of components, values, operations, materials, arrangements, or the like are set forth below. Of course, these are merely examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, or the like are contemplated. In addition, the disclosure may repeat reference numerals and / or characters in various examples. This repetition is for the purposes of simplicity and clarity and does not, in itself, dictate a relationship between the various embodiments and / or configurations described.

[0006] In some vehicles known to the inventors, content generated while an application did not have priority is lost. At least some embodiments of the subject disclosure mitigate content loss by recording content generated while an application did not have priority. In at least some embodiments, when an application loses priority, content for output continues to be generated and recorded. In at least some embodiments, when the application regains priority, the recorded content is played back, modified in a manner determined appropriate by the application.

[0007] In at least some embodiments, each application determines the portion of the recording that is appropriate for playback. In at least some embodiments, modifying application control over priority transition content output results in more effective and computationally efficient determination of the appropriate portion of the recorded content to be played.

[0008] In at least some embodiments, the arbitration manager determines priority among applications. In at least some embodiments, this determination is based on mediation rules stored in a rule-based automation (RBA) mediation library. In at least some embodiments, the arbitration manager considers screen output, basic sound output, and interrupt sound output. In at least some embodiments, the arbitration manager resolves conflicts among applications. In at least some embodiments, the determination results are sent to each application via the application manager.

[0009] In at least some embodiments, the arbitration manager checks whether to mediate. In at least some embodiments, this check is made in response to the mediation request originating from an application other than a privileged application. In at least some embodiments, the privileged application has greater mediation authority than that of the arbitration manager.

[0010] In at least some embodiments, the arbitration manager stores screen output, basic sound output, and / or interrupted sounds. In at least some embodiments, these outputs are an ongoing record of applications that receive a "standby" state as a result of mediation. In at least some embodiments, the arbitration manager provides applications with the opportunity to retrieve, modify, update, or delete the ongoing record.

[0011] In at least some embodiments, the arbitration manager stores the final screen / sound output. In at least some embodiments, this output is the final status of an application that receives an "inactive" state as a result of mediation. In at least some embodiments, the arbitration manager provides a means for applications to retrieve, update, or delete the final status.

[0012] In at least some embodiments, the arbitration manager does not determine how to handle records based on, for example, individual application or application type settings. In at least some embodiments, the arbitration manager allows each application to retrieve, modify, update, or delete records or status. In at least some embodiments, the arbitration manager also allows each application to change state from standby to inactive. In at least some embodiments, an application stops generating content for output in the inactive state.

[0013] In at least some embodiments, in response to the application having a lower priority, the arbitration manager places the application in a standby state. In at least some embodiments, the arbitration manager begins recording any display and audio output generated by the application. In at least some embodiments, in response to an application request, the arbitration manager stops recording the display and audio output. In at least some embodiments, the arbitration manager maintains a final status. In at least some embodiments, in response to an application request, the arbitration manager places the application in an inactive state from a standby state. In at least some embodiments, the arbitration manager stops recording and maintains a final status. In at least some embodiments, in response to an application request, the arbitration manager updates the record. In at least some embodiments, the arbitration manager removes all but the most recent 5 seconds. In at least some embodiments, in response to an application request, the arbitration manager deletes the record and the final status. In at least some embodiments, in response to an application request, the arbitration manager submits the record or status for review by the application. In at least some embodiments, in response to the arbitration manager determining that the application has the highest priority, the record or the final status is output. In at least some embodiments, in response to the recording being output, the recording continues through the buffer.

[0014] In at least some embodiments, in response to an application returning to highest audio priority, the application determines the best content to output. In at least some embodiments, a radio application plays what was skipped. In at least some embodiments, a maps application skips what was skipped and jumps straight to the latest content.

[0015] 1 is a schematic diagram of a system for application-controlled modification of priority transition content output, according to at least some embodiments of the subject disclosure. In at least some embodiments, the system is located in an automobile or other vehicle. The system includes a head unit 100 and an output device 120.

[0016] Head unit 100 communicates with output devices 120 and includes an arbitration manager 110 and applications 112. In at least some embodiments, head unit 100 is a central component of a vehicle entertainment system. In at least some embodiments, head unit 100 is configured to host and execute the functions of arbitration manager 110 and applications 112. In at least some embodiments, head unit 100 is configured to control content sent to output devices 120. In at least some embodiments, head unit 100 includes a microcontroller unit (MCU), microprocessor unit (MPU), or electronic controller unit (ECU) configured to execute instructions stored in memory components. In at least some embodiments, head unit 100 includes memory components, such as random access memory (RAM), read-only memory (ROM), or flash memory, configured to store instructions and data. In at least some embodiments, head unit 100 includes a storage component, such as a hard disk drive (HDD) or solid-state drive (SSD), configured to store data for long-term storage. In at least some embodiments, head unit 100 includes an input / output (I / O) interface configured to communicate with external devices, e.g., output device 120. In at least some embodiments, head unit 100 is an embedded system designed specifically for a vehicle, e.g., a vehicle entertainment system.

[0017] Arbitration manager 110 communicates with applications 112 and includes recorder 114, modifier 116, and player 118. In at least some embodiments, arbitration manager 110 manages system resources and provides services to software hosted by head unit 100. In at least some embodiments, arbitration manager 110 interacts with all other components of the vehicle, e.g., components outside of head unit 100. In at least some embodiments, arbitration manager 110 comprises a kernel configured to manage resources of head unit 100, e.g., CPU, memory, and I / O devices. In at least some embodiments, arbitration manager 110 comprises a file system configured to organize and manage files on a storage device, e.g., files related to recorded output and modifications thereof.

[0018] Applications 112 communicate with arbitration manager 110. In at least some embodiments, applications 112 generate content for output. In at least some embodiments, applications 112 generate content to be recorded. In at least some embodiments, applications 112 interact with arbitration manager 110, recorder 114, and playback unit 118. In at least some embodiments, applications 112 comprise a user interface configured to receive instructions from a user. In at least some embodiments, applications 112 include instructions or rules for modifying a recording that is suitable for playback. In at least some embodiments, applications 112 include instructions or rules for determining portions of a recording that are suitable for playback. In at least some embodiments, applications 112 are any software that executes on head unit 100 to generate output for, for example, navigation, media presentation, emergency announcements, user communications, etc.

[0019] In at least some embodiments, recorder 114 records the output of application 112. In at least some embodiments, recorder 114 interacts with application 112. In at least some embodiments, recorder 114 comprises a capture module configured to capture the output of application 112. In at least some embodiments, recorder 114 comprises a storage module configured to store the captured output in a memory or storage device. In at least some embodiments, recorder 114 is a software module that is part of arbitration manager 110 or a separate application.

[0020] In at least some embodiments, the modifier 116 modifies the recorded output in response to a request from the application 112. In at least some embodiments, the modifier 116 interacts with the application 112. In at least some embodiments, the modifier 116 comprises a processing module configured to process the recorded output and apply the modifications. In at least some embodiments, the modifier 116 is a software module that is part of the reconciliation manager 110 or a separate application.

[0021] In at least some embodiments, the player 118 plays back the recorded content. In at least some embodiments, the player 118 interacts with the application 112. In at least some embodiments, the player 118 comprises a playback module configured to read the recorded or modified content from a memory or storage device for transmission to an output device. In at least some embodiments, the player 118 is a software module that is part of the arbitration manager 110 or a separate application.

[0022] Output device 120 communicates with head unit 100. In at least some embodiments, output device 120 is hardware used by the system to play recorded or modified content to a user. In at least some embodiments, output device 120 includes speakers for audio output and a display for visual output. In at least some embodiments, output device 120 includes a display, such as a liquid crystal display (LCD) or a light-emitting diode (LED) display, configured to display visual content. In at least some embodiments, output device 120 includes speakers configured to output audio content. In at least some embodiments, output device 120 includes an I / O interface configured to communicate with head unit 100 and other components of the vehicle. In at least some embodiments, output device 120 includes built-in speakers and a touchscreen display integrated into the vehicle's dashboard.

[0023] 2 is an operational flow for modifying application control over content output for priority transitions, according to at least some embodiments of the subject disclosure. The operational flow provides a method for simultaneous audio output resulting from priority arbitration. In at least some embodiments, the method is performed by a controller, such as controller 402 of FIG. 4.

[0024] At S230, the controller determines whether the application has lost priority. In at least some embodiments, the controller determines that the application has lost priority while the application is sending output. In at least some embodiments, the controller interfaces with a process scheduler of the operating system. In at least some embodiments, the controller queries the scheduler using a system call to determine the application's current priority. In at least some embodiments, the controller determines priority among the applications. In at least some embodiments, this determination is based on mediation rules stored in a rule-based automation (RBA) mediation library. In at least some embodiments, the controller considers screen output, basic sound output, and interrupt sound output when determining priority. In at least some embodiments, an arbitration manager resolves priority conflicts among the applications. In response to the application losing priority, the operational flow proceeds to state assignment at S232. In response to the application not losing priority, the operational flow returns to priority determination at S230.

[0025] At S232, in at least some embodiments, an allocation section of the controller allocates a standby state to the application. In at least some embodiments, the allocation section changes the state of the application in a system process table. In at least some embodiments, the allocation section uses a system call to modify the process table and set the state of the application to standby. In at least some embodiments, the allocation section sends the decision result to the application via an application manager. In at least some embodiments, the allocation section notifies the application of the standby state via the application manager.

[0026] At S233, in at least some embodiments, a recording section of the controller records output generated by the application. In at least some embodiments, the recording section records display and audio output generated by the application. In at least some embodiments, the recording section interfaces with the system's display and audio drivers. In at least some embodiments, the recording section uses system calls to capture the application's display and audio output and stores it in a buffer. In at least some embodiments, the recording section stores one or more of screen output, basic sound output, or interrupted sounds. In at least some embodiments, these outputs are an ongoing record of the application receiving a "standby" state. In at least some embodiments, the recording section stores the final screen / sound output. In at least some embodiments, this output is the application's final status. In at least some embodiments, this record is then available for modification by a record modifier.

[0027] At S235, in at least some embodiments, a modification section of the controller modifies the recorded output. In at least some embodiments, the modification section modifies the record of output generated by the application in response to a request from the application. In at least some embodiments, the modification section applies a transformation to the data in the buffer. In at least some embodiments, the modification section uses a system call to access the buffer and apply the requested modification.

[0028] At S237, in at least some embodiments, the controller determines whether the application has regained priority. In at least some embodiments, the controller interfaces with the system's process scheduler, similar to the priority determiner. In at least some embodiments, the controller queries the scheduler using a system call to determine the application's current priority. In at least some embodiments, the controller determines whether the application has priority in response to disabling transmission. In response to the application regaining priority, the operational flow proceeds to playback in S238. In response to the application not regaining priority, the operational flow returns to output recording in S233.

[0029] At S238, in at least some embodiments, the playback section of the controller plays the modified recording output. In at least some embodiments, the playback section plays the contents of the recording in response to determining that the application has priority. In at least some embodiments, in response to the recording being output, the playback section causes the recording section to continue recording through a buffer. In at least some embodiments, in response to the controller determining that the application has regained priority, the playback section outputs the recording or a final status. In at least some embodiments, the radio application plays what was skipped. In at least some embodiments, the maps application skips what was skipped and jumps straight to the latest content.

[0030] 3 is an operational flow for modifying recorded output according to at least some embodiments of the subject disclosure. The operational flow provides a method for modifying recorded output, such as the recorded output modification in S235 of FIG. 2. In at least some embodiments, the method is performed by a controller, for example, controller 402 of FIG. 4.

[0031] At S340, in at least some embodiments, the correction section of the controller sends the record to the application. In at least some embodiments, the correction section sends the recorded output to the application in a secure communication channel established between the correction section and the application. In at least some embodiments, the correction section provides the application with an opportunity to retrieve, modify, update, or delete the ongoing record. In at least some embodiments, the correction section does not determine how to handle the record based on, for example, individual application or application type settings. In at least some embodiments, the reconciliation manager allows the application to retrieve, modify, update, or delete the record or status. In at least some embodiments, operations are performed to allow the application to review the application's recorded output and make decisions regarding any modifications.

[0032] At S342, in at least some embodiments, the modification section determines whether a modification request has been received from the application. In at least some embodiments, the modification section listens for incoming requests from the application. In at least some embodiments, if a modification request is received, the modification section captures details of the request. In response to determining that a modification request has been received, the operational flow proceeds to modify application in S343. In response to determining that a modification request has not been received, the operational flow proceeds to inactive state determination in S345.

[0033] At S343, in at least some embodiments, the modification section applies the modification. In at least some embodiments, the modification section applies specific modifications requested by the application to the recording. In at least some embodiments, the application determines the best content to output. In at least some embodiments, the modification section deletes all but the first second of the recording. In at least some embodiments, the modification section keeps only the most recent 5 seconds of the recording. In at least some embodiments, the modification section deletes all content of the recording. In at least some embodiments, the modification section modifies the recording according to the application's requests as a result of this action.

[0034] At S345, in at least some embodiments, the correction section determines whether an inactive state update has been received. In at least some embodiments, the correction section listens for incoming state updates from applications. In at least some embodiments, the correction section enables each application to change state from standby to inactive. In at least some embodiments, the correction section captures details of the update in response to receiving an inactive state update. In at least some embodiments, the correction section determines whether there is an inactive state update. In response to determining that an inactive state update has been received, the operational flow proceeds to an inactive state assignment in S346. In response to determining that an inactive state update has not been received, the operational flow ends.

[0035] At S346, in at least some embodiments, the modify section assigns an inactive state to the application. In at least some embodiments, the modify section changes the state of the application in the system's process table. In at least some embodiments, the modify section uses a system call to modify the process table to set the application's state to inactive. In at least some embodiments, the application ceases generating content for output in the inactive state. In at least some embodiments, this action is taken to change the application's state to inactive when an inactive state update is received.

[0036] At S347, in at least some embodiments, the modification section deletes all but the first second of the recording. In at least some embodiments, the modification section truncates the recording, retaining only the first second. In at least some embodiments, the modification section uses a system call to access a buffer and apply the truncation operation. In at least some embodiments, only the first second of the recording is retained as a result of this operation. In at least some embodiments, the modification section deletes in response to assigning an inactive state to the application. In at least some embodiments, this operation is performed to limit the length of the recording after the application has been assigned an inactive state.

[0037] FIG. 4 is a block diagram of a hardware configuration for modifying application control over content output for priority transitions, according to at least some embodiments of the subject disclosure.

[0038] A preferred hardware configuration includes a head unit 400 that communicates with input devices 408, either directly or through a network 407. In at least some embodiments, network 407 is an Ethernet network, a controller area network (CAN), or any other wired or wireless network, or a combination thereof. In at least some embodiments, head unit 400 is a computer or other computing device that receives input or commands from input devices 408. In at least some embodiments, head unit 400 is integrated into input devices 408. In at least some embodiments, head unit 400 is a computer system that executes computer-readable instructions to perform operations related to application control modification of priority transition content output.

[0039] The head unit 400 includes a controller 402, a storage unit 404, an input / output interface 406, and a communication interface 409. In at least some embodiments, the controller 402 includes a processor or programmable circuit that executes instructions to cause the processor or programmable circuit to perform operations in accordance with the instructions. In at least some embodiments, the controller 402 includes analog or digital programmable circuitry, or any combination thereof. In at least some embodiments, the controller 402 includes physically separate storage or circuitry that communicates through communications. In at least some embodiments, the storage unit 404 includes a non-volatile computer-readable medium capable of storing executable and non-executable data accessed by the controller 402 during execution of instructions. The communication interface 409 sends and receives data from a network 407. The input / output interface 406 connects to various input and output units, such as input devices 408 via parallel ports, serial ports, keyboard ports, mouse ports, monitor ports, and the like, to accept commands and present information. In some embodiments, the storage unit 404 is external to the head unit 400 .

[0040] The controller 402 includes an allocation section 450, a recording section 452, a modification section 454, and a playback section 456. The storage unit 404 includes state parameters 460, recording 462, and modification parameters 464.

[0041] Allocation section 450 is circuitry or instructions in controller 402 configured to allocate states to applications. In at least some embodiments, allocation section 450 is configured to allocate a standby state to an application in response to determining that the application does not have priority. In at least some embodiments, allocation section 450 utilizes information in storage unit 404, such as state parameters 460. In at least some embodiments, allocation section 450 includes subsections for performing additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0042] Recording section 452 is circuitry or instructions of controller 402 configured to record content generated by an application for output. In at least some embodiments, recording section 452 is configured to record display and audio output generated by an application. In at least some embodiments, recording section 452 records information, e.g., recording 462, in storage unit 404. In at least some embodiments, recording section 452 includes subsections for performing additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0043] Modification section 454 is circuitry or instructions in controller 402 configured to modify recorded content. In at least some embodiments, modification section 454 is configured to modify recordings of output generated by applications in response to requests from the applications. In at least some embodiments, recording section 452 utilizes information in storage unit 404, such as modification parameters 464. In at least some embodiments, modification section 454 includes subsections for performing additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0044] Playback section 456 is circuitry or instructions in controller 402 configured to play back recorded output or modified content. In at least some embodiments, playback section 456 is configured to play back content of a recording in response to an application determining that it has priority. In at least some embodiments, playback section 456 utilizes information in storage unit 404, such as recording 462. In at least some embodiments, playback section 456 includes subsections for performing additional functions as described in the flowcharts above. In at least some embodiments, such subsections are referenced by names associated with the corresponding functions.

[0045] In at least some embodiments, the apparatus is a separate device capable of processing logical functions to perform the operations herein. In at least some embodiments, the controller and storage unit need not be entirely separate devices, and in some embodiments, share circuitry or one or more computer-readable media. In at least some embodiments, the storage unit includes a hard drive that stores both computer-executable instructions and data accessed by the controller, and the controller includes a central processing unit (CPU) and RAM combination, where the computer-executable instructions are copyable in whole or in part for execution by the CPU during performance of the operations herein.

[0046] In at least some embodiments where the device is a computer, programs installed on the computer can cause the computer to function as or perform operations associated with the device embodiments described herein, and in at least some embodiments, such programs are executable by a processor to cause the computer to perform specific operations associated with some or all of the blocks in the flowcharts and block diagrams described herein.

[0047] At least some embodiments are described with reference to flowcharts and block diagrams, where the blocks represent (1) steps in a process in which an operation is performed or (2) sections of a controller responsible for performing an operation. In at least some embodiments, particular steps and sections are implemented by dedicated circuitry, programmable circuitry provided with computer-readable instructions stored on a computer-readable medium, and / or a processor provided with computer-readable instructions stored on a computer-readable medium. In at least some embodiments, dedicated circuitry includes digital and / or analog hardware circuitry, including integrated circuits (ICs) and / or discrete circuits. In at least some embodiments, programmable circuitry includes reconfigurable hardware circuitry, e.g., field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), etc., comprising logical AND, OR, XOR, NAND, NOR, and other logic operations, flip-flops, registers, memory elements, etc.

[0048] In at least some embodiments, a computer-readable storage medium comprises a tangible device capable of holding and storing instructions for use by an instruction execution device. In some embodiments, a computer-readable storage medium includes, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or a ridge-in-a-groove structure having instructions recorded thereon, and any suitable combination thereof. Computer-readable media as used herein should not be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0049] In at least some embodiments, the computer-readable program instructions described herein can be downloaded to each computing / processing device from a computer-readable storage medium or can be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. In at least some embodiments, the network includes copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. In at least some embodiments, a network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0050] In at least some embodiments, the computer-readable program instructions for performing the operations described above are either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. In at least some embodiments, the computer-readable program instructions execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In at least some embodiments, in the latter scenario, the remote computer is connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or is connected to an external computer (e.g., over the Internet using an Internet Service Provider). In at least some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) executes computer-readable program instructions by utilizing state information in the computer-readable program instructions to individualize the electronic circuitry to perform aspects of the present invention.

[0051] Although embodiments of the present invention have been described, the scope of any claimed subject matter is not limited to the above-described embodiments. Those skilled in the art will understand that various modifications and improvements to the above-described embodiments are possible. Those skilled in the art will also understand from the claims that additional embodiments incorporating such modifications or improvements are within the scope of the present invention.

[0052] Unless an order is indicated by "before," "before," or the like, and unless output from a previous process is used in a later process, the operations, procedures, steps, and stages of each process performed by the apparatus, system, program, and method described in the claims, embodiments, or figures may be performed in any order. Even when a claim, embodiment, or figure describes a process flow using phrases such as "first" or "then," such description does not necessarily imply that the process must be performed in the order described.

[0053] In at least some embodiments, modifying application control over content output for a priority transition is accomplished by determining that the application has lost priority while the application is sending output, assigning a standby state to the application, recording the display and audio output generated by the application, modifying the recording of the output generated by the application in response to a request from the application, and playing the content of the recording in response to determining that the application has priority.

[0054] In at least some embodiments, modifying the application's control over content output for priority transitions is performed in response to disabling transmission by further determining whether the application has the highest priority. In at least some embodiments, modifying the application's control over content output for priority transitions is performed by further transmitting the recording to the application. In at least some embodiments, the modification includes deleting all but the first second of the recording. In at least some embodiments, the deletion is in response to assigning an inactive state to the application. In at least some embodiments, the modification includes keeping only the most recent five seconds of the recording. In at least some embodiments, the modification includes deleting all content of the recording.

[0055] In at least some embodiments, the modification of application control over priority transition content output is performed by a device having a processor that executes instructions in accordance with the above operations or a controller that includes circuitry configured to perform the above operations.

[0056] The foregoing outlines features of some embodiments so that those skilled in the art may more fully appreciate aspects of the present disclosure. Those skilled in the art should appreciate that this disclosure may readily be used as a basis for designing or modifying other processes and structures to carry out the same purposes and / or achieve the same advantages as the embodiments incorporated herein. Those skilled in the art should also appreciate that such equivalent structures do not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and alterations can be made therein without departing from the spirit and scope of the present disclosure.

Claims

1. 1. A computer program product for causing at least one processor to perform operations, said operations comprising: determining that an application has lost priority while the application is sending output; assigning a standby state to the application; recording the display and audio output generated by the application; modifying the record of output generated by the application in response to a request from the application; playing content of the recording in response to determining that the application has priority; a computer program comprising:

2. The operation is The computer program product of claim 1 , further comprising determining whether the application has priority in response to disabling output transmission.

3. The operation is The computer program of claim 1 or 2, further comprising transmitting the record to the application.

4. 3. A computer program as claimed in claim 1 or 2, wherein the modification comprises deleting all but the first second of the recording.

5. The computer program product of claim 4 , wherein the removal is in response to assigning an inactive state to the application.

6. 3. The computer program of claim 1, wherein the modification includes keeping only the most recent 5 seconds of the record.

7. 3. A computer program as claimed in claim 1 or 2, wherein the modification comprises deleting all content of the recording.

8. 1. A processor-implemented method comprising: determining that an application has lost priority while the application is sending output; assigning a standby state to the application; recording the display and audio output generated by the application; modifying the record of output generated by the application in response to a request from the application; playing content of the recording in response to determining that the application has priority; A method comprising:

9. The method of claim 8 , further comprising determining whether the application has priority in response to disabling output transmission.

10. The method of claim 8 or 9, further comprising transmitting the record or status to the application.

11. 10. A method according to claim 8 or 9, wherein the modification comprises deleting all but the first second of the recording.

12. The method of claim 11 , wherein the removal is in response to assigning an inactive state to the application.

13. 10. The method of claim 8 or 9, wherein the modification includes keeping only the most recent 5 seconds of the record.

14. 10. The method of claim 8 or 9, wherein the modification comprises deleting all content of the recording.

15. 1. A device comprising a controller including circuitry configured to perform operations, the operations comprising: determining that an application has lost priority while the application is sending output; assigning a standby state to the application; recording the display and audio output generated by the application; modifying the record of output generated by the application in response to a request from the application; playing content of the recording in response to determining that the application has priority; Including, the device.

16. The device of claim 15 , further comprising: determining whether the application has priority in response to disabling output transmission.

17. 17. The device of claim 15 or 16, further comprising transmitting the record or status to the application.

18. 17. A device as claimed in claim 15 or 16, wherein the modification comprises deleting all but the first second of the recording.

19. The device of claim 18 , wherein the removal is in response to assigning an inactive state to the application.

20. 17. A device as claimed in claim 15 or 16, wherein the modification comprises keeping only the most recent 5 seconds of the recording.

Images