Distributed media system

An in-flight system provides a user with an entertainment environment including movies, music, games, internet, map, etc. The in-flight system provides stored media content on one or more servers located throughout an aircraft cabin and each server is associated with a plurality of seats. In a preferred embodiment, the in-flight system provides for a communication port (e.g., USB or mini-USB connector or micro-USB connector) for connection to personal electronic device providing access to the server containing the stored media, access to an internet connection, and power. In one embodiment, the in-flight system provides for a seat display unit (typically located in the seat back of the next forward seat) and associated media module hardware to process the stored media content and drive the display. In one embodiment, the in-flight system comprises an isolation module or equivalent circuitry or logic that can isolate the media module and/or the personal electronic device from the remainder of the in-flight system, allowing for updates to the in-flight system without recertification from the FAA.

FIELD OF THE DISCLOSURE

This application relates generally to in-flight systems.

BACKGROUND OF THE DISCLOSURE

An in-flight system provides for audio and video contents to a passenger during flight. The in-flight system becomes increasing important during long flights where passengers may associate a quality of service of the airline based on the enhanced experience they obtained with the in-flight system. To accommodate the passengers, airlines resort to providing enhanced features to the in-flight system. However, known in-flight systems are usually in-seat computers connected to a seat back display. The in-seat computers are heavy and costly to maintain. Also, because of the enhanced features that the in-seat computers have to run, heat generated by the in-seat computers is a source of problems. Further, each in-seat computer is connected to a central server with long cable lines. This configuration has potential safety and fire hazard issues.

Cost of an in-flight system is a major issue for the airlines. While passengers demand for enhanced features in an in-flight system, they are not willing to pay a premium for the services. Thus, in most instances, the enhanced features and the in-flight system add to the operating costs of the airlines. Furthermore, in-flight systems may require routine upgrades in order to keep current with the technology. However, known in-flight systems are intertwined with the public announcement and video announcement system of the airline personnel, such that any upgrade of the in-flight system may require the whole in-flight system to be recertified by the Federal Aviation Administration (FAA). Recertifications are costly, time consuming and burdensome. Many airlines simply resort to not upgrading their in-flight systems at all resulting in operating less than up-to-date in-flight systems.

SUMMARY

An in-flight system provides a user with an entertainment environment including movies, music, games, internet, map, etc. The in-flight system provides stored media content on one or more servers located throughout an aircraft cabin and each server is associated with a plurality of seats. In a preferred embodiment, the in-flight system provides for a communication port (e.g., USB or mini-USB connector or micro-USB connector) for connection to personal electronic device providing access to the server containing the stored media, access to an internet connection, and power. In one embodiment, the in-flight system provides for a seat display unit (typically located in the seat back of the next forward seat) and associated media module hardware to process the stored media content and drive the display. In one embodiment, the in-flight system comprises an isolation module or equivalent circuitry or logic that can isolate the media module and/or the personal electronic device from the remainder of the in-flight system, allowing for updates to the in-flight system without recertification from the FAA.

DETAILED DESCRIPTION

FIG. 1Aillustrates an exemplary in-flight system according to one embodiment of the invention. The in-flight system may include one or more sector servers120a-hserving a plurality of seats130. In the embodiment ofFIG. 1A, several sector servers120a-hare installed throughout an aircraft. However, it is conceivable that the in-flight system may be used in any large vehicle such as a bus or a ship. Each sector server120serves a plurality of seats130in its vicinity, in this embodiment, up to ten seats. However, generally, the number of seats that the sector server120may serve may depend on the processing power of the sector server120. A seat130, usually, a back of the seat, may include a seat display unit (SDU) that provides for a user to have access to the sector server and also, for the sector server120to provide information to the user. The SDU may be connected to one associated sector server120via an electrical connection such as, for example, Ethernet, Universal Serial Bus (USB), and the like.

In one embodiment, as seen inFIG. 1B, a seat170may or may not be provided with a SDU, but instead of or in addition to, would have a user interface174. InFIG. 1B, a user interface174includes at least one communication port176,178,179, or180(e.g., connectors for USB180, mini-USB176, micro-USB179, and/or bi-directional headphones178) that provides for a user to connect, via a wired connection182the user's personal electronic device (PED)184with the sector server; the wired connection182providing power, an internet connection, and/or access to onboard stored media. Examples of PEDs are laptop computers, Blackberries, iphones, ipads, tablets, smart phones, cellular phones, and the like.

In the embodiment where the PEDs184are physically connected to the user interface174, a USB connection (e.g.,180or176) may be preferred since the USB connection provides power to the PED as well as charge the PED's battery, if necessary. In the wired connection, an in-arm172user interface174comprises USB180and/or mini-USB176and/or micro-USB179connections. In one embodiment, the user interface174is located in the seat arm172. In another embodiment, the user interface174is located in a side wall. In another embodiment, the user interface174is located in the seat back where a SDU is located or could be located. The USB connection allows the in-flight system to supply power to PEDs so that said devices can be fully utilized during flight, but leave the aircraft fully charged.

The in-flight system wired connection182solution illustrated inFIG. 1B, provides a number of features and advantages to the user. First it provides an accessible internet connection with the in-flight system if internet connection is available. Second, it provides access to stored onboard media. And it provides a power connection to the PED184, which in addition to powering the operation of the PED184, also recharges the PED's batteries. As can be seen by the presently prolific use of in airport recharge towers, the advantage of being able to power the PED while onboard is huge. Users of PEDs no longer need to wait in line at the station chargers before boarding an aircraft. This feature has remained unavailable, causing dead PEDs before or after flights, particularly on long flights. Likewise, the ability to use your own PED184, whether for personal tasks, or to access the in-flight system, provides flexibility and access that have not been previously available to in-flight systems with SDUs. And, even if a user chooses not to use the in-flight system, the user interface174, and more specifically USB connector176,179, or180, still would allow the user to recharge their PED184.

In an alternative embodiment, the PED may be wirelessly connected to the sector server, for example, using a wireless communication device compatible with the wireless communication component of the PED. In one embodiment, the in-flight system is configured to connect wirelessly to a user PED when they enter the aircraft and if the necessary application software is not available on the PED, the in-flight system may offer to push the application software, so that when the user connects at their seat, their PED comprises the necessary software to access the in-flight system. In one embodiment, when the user connects their PED to the in-flight system, only the specific application software may be used on the PED, and all other functions/applications are disabled. Exemplary features of the PED seat connectors are that they provide power, an internet connection pipe, and access to stored media content.

Each sector server120is connected to one another in order to communicate with each other and/or also to share media, information, and data with each other. In this embodiment, the sector servers120a-hare serially connected in a daisy chain, however, in an alternative embodiment, the sector servers120a-hmay be connected together in parallel. In either embodiment, the plurality of sector servers120a-hare capable of copying (e.g., mirroring) data to any of the other sector servers120a-h. This architecture is distributed, not requiring media storage or management at a head end or in the seat locations. A flight attendant panel140or a cockpit panel142may be connected to one or more of the sector servers120a-hin the daisy chain. Flight attendant panel140or cockpit panel142allows for an airline personnel to take control of the in-flight system in order to provide, for example, safety, public, security and other messages and/or announcements. In one embodiment, this means pausing media being played through the in-flight system. In one embodiment, this means stopping the media being played through the in-flight system. The reason for this type of control is FAA regulation that requires that no aircraft controllable system interferes with aircraft personnel communications with users, particularly with regard to safety announcements.

An aircraft interface module110may be connected to one or more of the sector servers120in the daisy chain to provide, among other things, flight data such as GPS coordinates, speed, altitude, time, temperature, yaw, pitch, and roll values. This data may be used by the sector servers120a-h, for example, in conjunction with a map program at the sector servers120a-h, to provide a user with information regarding the status of the flight. Usually, the communication between aircraft interface module110and sector servers120a-his a one-way communication, that is, aircraft interface module110sends flight data and one or more sector servers120a-hreceive the flight data. This isolates the sector server120from being able to send or write data to the aircraft interface module110.

In one embodiment, a media loader module150may be connected to one or more of the sector servers120a-h. The media loader module150may be used to upload and/or download media contents and information to/from the aircraft from/to an external entity190. For example the media contents may be movie, music, maps, internet, preprogrammed media contents for the aircraft, airline status/transfer information, or any other media contents and information required by the aircraft or a user of the aircraft. External entity190may be third party media content providers, the airline, or another aircraft. Alternatively, external entity190may be a terrestrial media storage facility for the in-flight system. Media loader module150may communicate with the external entity190through a wired or wireless communication medium while the aircraft is on the ground, or through a wireless communication medium while the aircraft is taxing or flying at an altitude where wireless communication is possible, or through a satellite at higher altitudes. In one embodiment, media loader module150is directly connected to one sector server (e.g.,120binFIG. 1A), and is used to load specialized material (e.g., GUIs, fonts, graphics, etc.) and/or mass media updates from local removable storage that would be more efficiently updated locally than via an external entity190.

FIG. 2illustrates an exemplary seat display unit (SDU)200that is used in the in-flight system according to one embodiment of the invention. The SDU200comprises a media module210, a display220, and an isolator/driver module230. At the seat, an audio output, for example, headphone jack, and a user input module240may be provided to receive user input. In one embodiment, the seat may not include a user input module and the display220may be a touchscreen LCD configured to receive user input.

In one embodiment, the media module210may be the same or similar to the electronic components that are found in a personal electronic device (PED) that is used to send and receive media contents. The media module210may operate under one or more platforms. In this embodiment, the media module210at least supports the Google Android™ application programming interface (API) provided by the Android™ platform. The media module210may run one or more Android™ applications in order to communicate with the sector server that also runs on a platform, for example the Android™ platform. The application that is written to run on the media module210allows the media module210to access the media contents through the sector server. The media module210may communicate with the sector server through Ethernet and the like. This communication may occur via the network using one or more sockets, ports, etc. In one embodiment, the media module210may access stored media content via a USB connection using Android™ android.hardware.usb package. The media module210may mount the stored media, which may be stored in different physical storage devices, as a conventional file system in order to access the media contents therein. As understood in the art, media module210may comprise one or more device drivers to access the stored media, whether it is by a network or physical storage device. In one embodiment, when the stored media is encrypted, using AES-256 for example, media module210also includes the requisite decryption software to the stored media after accessing the contents therein. When the media module210is accessing the sector server via a wireless network using, for example, wireless fidelity (Wi-Fi) protocol, the media module210may be implemented using Android™ android.net.wifi package to access the sector server. Further information on the Android™ application programming interface (API) and software development kit (SDK) may be found at the Android developers' website.

Whether the media contents requested by the media module210are received by the media module210is dependent on the mode of the isolator/driver module230. In the “isolation” mode, the isolator/driver module230prevents or halts the media contents from being received by the media module210. In the “pass” mode, the isolator/driver module230allows the requested media contents to be received by the media module210. Simply stated, the isolator/driver module230serves to perform as a pass-through module of data when an aircraft interface interaction is not being performed, and serves to isolate or prevent the display220from displaying the media content requested by the user when an aircraft interface interaction is being performed. Examples of the aircraft interface interaction may be an audio and/or video announcement from the airline personnel regarding safety, security, or general announcement. It should be noted, that isolator/driver module230or some related circuitry also filters input request from user input module240or touchscreen display220as will be described in more detail below with reference to finite state machine600. The same principles may be implement in isolator/driver module230.

In one embodiment, the isolator/driver module230is a finite state machine formed using a Field Programmable Gate Array (FPGA). However, the isolator/driver module230need not necessarily be limited to a FPGA and may be formed using an application specific integrated circuit (ASIC), a complex programmable logic device (CPLD) or other suitable integrated circuit devices. In one embodiment, a FPGA available from Xilinx® Inc., located in San Jose, Calif., USA, may be used. As an example, the Virtex-5 series may be used. An example of a finite state machine based on a FPGA may be found in U.S. provisional patent application Ser. No. 61/449,960, filed Mar. 7, 2011, which is incorporated herein be reference in its entirety for all purposes. The isolator/driver module230that is configured as a finite state machine transitions to a state in a finite number of states when triggered by an event in the in-flight system. Examples of an event may be when the media module210of the SDU200indicates that the module is malfunctioning, or when a flight attendant panel or cockpit panel indicates that a public announcement (PA) or a video announcement (VA) is to be made. Simply put, the finite state machine is driven by events.

FIG. 3illustrates an exemplary state diagram of the finite state machine implemented in an exemplary isolator/driver module230according to one embodiment of the invention. Each event causes the finite state machine to transition from a current state to another state, or in some cases, the finite state machine does not transition to another state but returns to the current state. There are many action types in the finite state machine such as “entry action” where an action is performed when entering a state; and “exit action” where an action is performed when exiting a state. Usually, the finite state machine described above performs entry action. However, the finite state machine need not be limited to this type of action.

Referring toFIG. 3, at state310, the isolator/driver module230initializes to set up and verify its functionality. Once the isolator/driver module230verifies that all functions are operating correctly, the state machine transitions to state320, which is the Local Menu. In this state, the media module210outputs are disconnected and the isolator/driver module230provides the video and audio data to be displayed in the display220. Because the media module210is disconnected in this state, media module210can be updated, such as, for example, an update of the Android™ application.

If the user selects an attendant call from the Local Menu state320, for example, through the user input module240or the touchscreen display, this event would trigger the finite state machine to transition to state330. At state330, the isolator/driver module230may cause information to be displayed at the display220indicating that the attendant call has be activated and/or cause information to be displayed at the flight attendant panel140indicating that attendant attention is needed by the user. Here, the isolator/driver module230causes video and/or audio information to be generated at the user's display220and/or the flight attendant panel140. In one embodiment, attendant call information is displayed over the local menu of the user's display220. The finite state machine may transition back to state320if the user clears the attendant call or the flight attendant clears the call.

When the user requests media content from the sector server120at the Local Menu320, the isolator/driver module230queries the media module210for operational status. If the media module210signals to the isolator/driver module230that it is fully functional, the finite state machine transitions from state320to Media, which is state350. In state350, the media module210is utilized to access the media content from the sector server120, and the isolator/driver module230passes through the media content requested by the user through the media module210. Therefore, media content such as games, pictures, internet, map, and movies, etc. as requested by the user may be run and displayed at the display220through the media module210. If the media module210is malfunctioning (i.e., a fault is detected) or a timeout occurs, the state machine of the isolator/driver module230does not transition to state350, but instead remains at state320, which means that the media module210will not be used in the SDU200. In one embodiment, the FPGA includes an emergency video and/or audio engine which the isolator/driver module230could fall back on, which is capable of accessing data from the sector server and generating video and audio signals to be displayed on the display220, so that full functionality of the in-flight system at the SDU will not be lost. In that case, isolator/driver module230becomes the driver for the media contents and communicates with sector server120. For example, a system for accomplishing this FPGA driven media presentation along with interaction with a server is disclosed in U.S. provisional patent application Ser. No. 61/449,960, filed Mar. 7, 2001, which is fully incorporated herein by reference in its entirety for all purposes.

When the in-flight system requires isolation from media contents provided by the media module210or, in certain instance, provided by the isolator/driver module230, for example for public safety announcements, the state machine of the isolator/driver module230transitions to another state360, which is PA/VA. In this state, the isolator/driver module230stops, pauses, filters, or simply disconnects the flow of data (either media content and/or display data) from being output through a media module210, or in certain instances, the isolator/driver module230. As shown inFIG. 3, state360may be entered from either the Local Menu (state320) or the Media (state350). From either state320or state350, the finite state machine transitions to state360triggered by a signal (e.g., keyline or system message) for a public announcement or video announcement regarding safety of the passengers, for example. Once the system message (i.e., PA/VA signal) is cleared, the finite state machine returns to its previous state320or state350. While the isolator/driver module230is in PA/VA (state360), the media module210output, or, in certain circumstances, media content outputted by the isolator/driver module230, is disconnected and the isolator/driver module230generates video and/or audio outputs corresponding to the public announcement or video announcement.

While the user is in the Media (state350) viewing or otherwise accessing media content, they may request an attendant call which may cause the state machine to enter Media Att Call (state340), which would, for example, display information over media content being viewed. This may be exited by the user again pressing the attendant call button or the flight attendant clearing the call. In state340, the media module210output is not prevented or blocked by the isolator/driver module230and the isolator/driver module230instead overlays locally generated video (e.g., that an “Attendant has been called”) to the media content at the display220. The transition out of state340puts the finite state machine to transition to Media state350.

In all states of the finite state machine, the isolator/driver module230is in control of the output (i.e., video and audio) whether (i) pass-through, (ii) isolate, or (iii) driven. In one embodiment, in all states of the finite state machine, the isolator/driver module230may accept user input to turn on the reading light. And each state of the finite state machine is configured to generate system messages for activating the reading light. In one embodiment, every state of the isolator/driver module's230finite state machine300, except the PA/VA state360, allows the isolator/driver module230to generate a system message to activate the reading light. In yet another embodiment, a user request for a reading light requires the state machine300to enter either Local Attendant Call state330or Media Attendant Call state340.

Because the media module210may be isolated or blocked from having access to media contents from the sector server120using the isolator/driver module230, media module210upgrades may be made without requiring the entire in-flight system to be recertified by the Federal Aviation Administration (FAA). This is because isolator/driver module230may function to isolate or block the media module210and thereby, the media module210is isolated or blocked from competing with the public announcements and video announcements made by the airline personnel. Media module210may be updated with software/firmware, or even physically replaced, without recertification.

FIG. 4illustrates an exemplary sector server400that may be used to store media contents according to one embodiment of the invention. In one embodiment, the sector server400includes electronic components that may access media contents external to the aircraft using the media loader module150. The aircraft may include a plurality of sector servers400dependent on the size of the aircraft and/or the number of seats130. The sector server400may either be powered from an aircraft power bus or can have its own power supply (not shown) that provides the voltages/currents and power quality needed by the sector server400.

Each sector server400comprises a storage device410for storing a large collection of media content such as movies, pictures, maps, games, queued internet pages, music, etc. In one embodiment, the storage device410may be partitioned in accordance with a number of elements. For example, and without limitation, the partitions may comprise, new (movies, music, etc.), classics (movies, music, etc.), foreign (musics, music, etc.) and the like. According to one embodiment, the storage device410may include a personal partition space for each seat for unique movies, music, etc.). Thus, while the majority of the media contents comprise standard movies, music, games, etc., that appeal to a majority of the users, a selection of movies, music, games, etc., are stored in the storage device that are tailored specifically to a user which the sector server400is servicing.

In one embodiment, the sector server400also includes a Secure Digital (SD) memory device420, which stores airline/aircraft specific personalization data, for example, airline logos, specialized fonts, local menu backgrounds, airline safety presentation, etc. This data may be used to present the user with a local menu setup, which will have some standardized selections (e.g., buttons, menus, etc. . . . ).

In one embodiment, the sector server400may also include an input/output port, such as a USB port and the like, to receive a removable memory device such as the SD memory device. The SD memory device may contain graphic image data that may be used by a isolator/driver module230for displaying one or more graphic images at the SDU or the PED. The sector server400may further include one or more input/output (I/O) interfaces from which the sector server400may communicate with other sector servers, a SDU or a PED, or server/seat interface may communicate with the sector server400and from which the sector server400may communicate with the server/seat interface.

A connectivity server430may be a blade system including one or more blades in a blade enclosure. The one or more blade servers may be commercially available through Hewlett-Packard, IBM, Dell, Cisco, and etc. In general, the connectivity server430may include a microprocessor or a plurality of microprocessors that execute a sequence of instructions based on one or more inputs received by the connectivity server430and usually the connectivity server430outputs one or more results based on the executed sequence of instructions. The connectivity server430may further include a memory, which may be volatile, such as Dynamic Random Access Memories (DRAMs) or Static Random Access Memories (SRAMs). The connectivity server430connects to SD memory device420if the sector server400includes SD memory device420, and to one or more storage devices410such as a hard drive and/or an optical drive all which are coupled together through a bus. In the case of the storage device410, the connectivity server430may access the storage device410through a storage device controller such as a Serial Advanced Technology Attachment (SATA) controller. The connectivity server430may use the storage device410to store and execute instructions of an operating system or an application, and/or to store and manipulate data. The storage device410is used to store the operating system and applications which the connectivity server430may retrieve to the memory when needed, and is used to store data which among others pertains to moving maps showing progress of flight, movies, shopping, games, and information of interest to a user. While various operating systems, which may be customized or commercially available, may be used, in this embodiment, the connectivity server may use Android™ platform.

The connectivity server430communicates with SDUs (e.g.,200), other sector servers (e.g.,120a-h), the flight attendant panel (e.g.,140), the cockpit panel (e.g.,142), the aircraft interface module (e.g.,110), and the media loader module (e.g.,150) through a Communications Mezzanine440, which may operate under Ethernet protocol, USB protocol, and/or Wi-Fi protocol, and the like.

FIG. 5illustrates an exemplary sector server500configured to be used with a personal electronic device (PED) according to one embodiment of the invention. The sector server500comprises a storage device510and a connectivity server530. The sector server500may further comprise a SD memory device520. As media storage510and connectivity server530function and are connected similarly to related media storage410and a combination of media module210and connectivity server430respectively, they will not be further delineated here.

In one embodiment, the sector server500may also include an input/output port, such as a USB port and the like, to receive a removable memory device such as a Secure Digital (SD) memory device. The SD memory device may contain graphic image data that may be used by a PED for displaying one or more graphic images on the PED. The sector server500may further include one or more input/output (I/O) interfaces from which the sector server500may communicate with other sector servers, a PED, or server/seat interface may communicate with the sector server500and from which the sector server500may communicate with the server/seat interface.

In one embodiment, as shown inFIG. 5, and unlike the exemplary sector server400shown inFIG. 4, the connectivity server530does not connect to the communications mezzanine540, but rather passes through an isolator/driver module550which may or may not be the same as isolator/driver module230. For example, the isolator/driver module550may not require any functions to drive a display (e.g.,220). In this embodiment, the media module (PED) is placed at a downstream location of isolator/driver module550and thus, the data communications to the media module (PED) is also passed through the isolator/driver module550and can be paused, filtered, stalled, cut-off, etc., as needed. This embodiment supports the situation where the media module is actually a user supplied personal electronic device (PED) brought onto the plane and connected to the user interface of a seat, for example arm or seat back, via for example USB such that in addition to data and/or internet connectivity, power is also supplied. In this embodiment, data, such as media content, may be paused, filtered, stalled, cut-off, etc., before going to the PED and thus, the in-flight system does not need to take control of the PED.

To establish a communication with the in-flight system, the user may have to install an application in their PED. Thus, when the user connects their PED to a user interface (or otherwise connects to the sector server system), such as, for example, a USB connection, which may be located at the arm of the seat or seatback, the servicing sector server detects whether the application has been installed at the PED, and if it is not, the user may download the application for access to the media contents provided by the sector server. In the event that the user chooses not to have access to the media contents of the sector server, the user, by connecting the PED to the user interface via the USB connection, would still be able to utilize the power supply to power the PED.

FIG. 6illustrates an exemplary state diagram of a finite state machine600implemented in the isolator/driver550according to one embodiment of the invention. Referring toFIG. 6, the isolator/driver module550initializes to set up and verify its functionality, state610. Once the isolator/driver module550verifies that all functions are operating correctly, the state machine600transitions to state620, which is the Menus state. In state620, various media contents from the sector server500, such as maps, movies, music, etc. are available to the user. In one embodiment, internet access (such as a web browser, email, and SMS) is available to the user through the sector server (e.g.,500/120) establishing communication with an external terrestrial source or an external satellite source (e.g.,190).

In one embodiment, when the PED connects with the sector server500and the installed application requests access to media contents from the sector server500, at state620, a security handshake may occur between the sector server and the PED in order to verify that the PED and installed application are authorized and also capable for accessing the sector server500. Once the security handshake is completed, the finite state machine600may transition to state630, which is the Media state. At state630, the sector server500provides the requested media content, which may be streamed through the USB connection to the PED. Therefore, media such as games, pictures, and movies, etc. may utilize the hardware of the PED to enhance the capability of the in-flight system.

When the aircraft signals, for example, a public safety announcement, the finite state machine600transitions to state640, which is PA/VA. At state640, the sector server500stops, pauses, filters, or simply disconnects the flow of media content from being output to the PED. State640may be entered from either the state620, Menu, or the state630, Media. From either state620or state630, state640is entered by a signal (e.g., keyline or system message) for a public announcement or video announcement regarding safety of the passengers. Once the system message (e.g., PA/VA signal) is cleared the finite state machine may return to its previous state620or state630.

In one embodiment, in all states of the finite state machine600, the isolator/driver module550is in control of the audio and video output. Therefore, in all states the isolator/driver module550is capable of accepting user input from the PED or a seat control unit to turn on the reading light. Thus, in this embodiment, for each state of the finite state machine, the isolator/driver module550is configured to generate system messages for activating the reading light. In one embodiment, every state of finite state machine600except the PA/VA state640allows the isolator/driver module550to generate a system message to activate the reading light.

In order to protect against intrusions (e.g., hacker, viruses, spybots, etc. . . . ) from a PED into the sector server500and particularly into connectivity server530, the finite state machine also comprises a finite number of states (not shown) for handling the input request of the PED. For example, from state620or state630, there may be a number of options displayed on the user PED allowing them to input to the system. For instance, from the Menus state620, there may be a number of choices shown on the PED for, such as, displaying a map, connecting to the internet, viewing or listening to stored media, calling an attendant, or turning on a reading light. If the PED attempts to send a command or instruction that is not one of the available choices, the finite state machine of the isolation/driver module simply prompts the available option and does not forward the command or instructions to the connectivity server530, effectively ignoring or dropping the PED command or instruction. Alternatively, choosing one of these options will cause a particular packet of data to be send from the PED to the connectivity server530. If the sent packet is not part of a list of expected packet (e.g., that represent the actions listed above), said packets may be discarded by the connectivity server530. This same procedure holds true in other modes of the state machine, such as Media state630. While the delineated function calls above are not exhaustive of what may be contained within the system, they are meant to be illustrative of the feature that the sector server500is designed such that only authorized packets are able to flow into the server.

In addition to only allowing authorized packets to enter the sector server500, the operating system running on the connectivity server also does not have any commonly used ports, as a person of ordinary skill in the art would understand, open. Therefore, the sector server500has multiple levels of security against communications from the PED affecting the status of the sector server500and particularly the connectivity server530.

The SDU system described earlier may comprise this same type of intrusion protection scheme and protected operating system, if desired.

By the use of the isolator/driver module500in the in-flight system, the in-flight system, including the PEDs, does not require the entire in-flight system be recertified by the FAA even though the software of the PEDs are routinely upgraded, or that the PEDs have never been certified by the FAA. This is because isolator/driver module550may function to electrically isolate the PED and may prevent the PED from tampering with the sector server such that the PED does not interfere with the public announcements or video announcements made by an airline personnel as well as the sector server.

In one embodiment, sector server500does not comprise an isolator/driver module550and the connectivity server530is connected directly to the communications mezzanine540. In this embodiment, the pausing or stopping of the of the media data to the PED is done by the connectivity server530of the server500. In one embodiment, there is an FPGA wrapper around the connectivity server530that performs the functions of state machine600as described above. In yet another embodiment, there is no pausing of the media stream and the server500continues to supply media data even when a PA/VA occurs.

As mentioned earlier, each sector server120/400/500comprises a partitioned amount of space for customized media associated with the seats served by the respective sector server120/400/500. This personal partition may be used to store particular movies, music, games, etc. that are only chosen for the seat associated with that particular partition. In one embodiment, prior to aircraft departure (i.e., taxing upon arrival or while at the gate), the manifest for the next flight is input into the in-flight system. The in-flight system may then check against a database, either stored locally or remotely, as to whether there is known preferences of passengers of the next flight. This may be done for example by requiring each user to initially set-up a login account if they desire personalized content to be available to them. In one embodiment, this type of account could be fee based. If a user has stored preferences, those preferences (GUI look, content, etc.) are loaded into the personal partition in sector server120/400/500storage media410/510. The personalized or general preferences appear as specific content and information menus. The customization may be referred to as “context.” That is, media, fonts, graphics, etc. can be loaded into sector server120/400/500as unique context, for example, per airline, or per flight, or per destination, or per user. The updating of the media in a sector server120/400/500may be accomplished via media loader module150discussed previously. In one embodiment this update occurs during the taxing of the aircraft after landing. Alternatively, in another embodiment, a hardwire or wireless network connection may service the aircraft at the gate, at which time the sector server120/400/500may be updated. The daisy chained sector server120/400/500are also able to copy among other things content from one sector server120/400/500to another sector server120/400/500utilizing the overhead/transfer partition space in the sector server120/400/500. This feature is useful in situations where the media storage has been updated with data for a certain passenger seating arrangement, and then there are last minute changes to the seating arrangement. The sector server120/400/500are able to mirror the personal data from one sector server120/400/500to another sector server120/400/500. In one embodiment, the general partitions (e.g., new and classics) are identical on each sector server120/400/500and thus do not need to be copied.

In one embodiment, the status of media usage for a user is maintained in the personal partition associated with the user and then saved into the account information, such that if the user is making a connection flight they can continue the media application in another aircraft with the same system, where they left off. This is also part of the maintained “context” or even better described as the “persistent context.” In one embodiment, the status of media viewing is saved on the user PED and later communicate to a sector server on a subsequent flight. In one embodiment, a master account database saves the user media selection(s) and the status of media viewing, and the master database is accessible via the internet (e.g., on their PED). In yet another embodiment, sector server(s) store information on the airports that are serviced by the particular airline having the present in-flight system installed. The system may offer a push of data comprising the arrival airport information for any user that has their PED connected to the system. This data may comprise information on food and other services in the airport, connecting gate information, and support a guidance application to navigate the user through the airport.

FIG. 7illustrates an exemplarily flight/data transition according to one embodiment of the invention. As mentioned earlier, aircraft (e.g.,730a) taxing after arrival and before arriving at the gate (here Gate A,720a) might connect via a number of communications means740(e.g., satellite, cellular, or wireless) and update a terrestrial database with information such as personal media status, personal or alternatively per seat usage information. Arriving aircraft730amay also download (i.e., update) there media storage content via the communications means740. In one embodiment, this update includes a download of the passenger list for the next flight on aircraft730a. This information, as discussed previously, may be utilized by the present in-flight system to reconfigure the sector servers with media content for the next flight's passengers. Likewise, before and/or during the time when aircraft730ais uploading/downloading relevant information from the in-flight system's terrestrial storage facility, aircraft730b, which may be at Gate B720bor may also be taxing to Gate B720b, is performing the same operations, such that its sector servers are reconfigured with media content for the next flight's passengers.

FIG. 8illustrates another exemplary in-flight system according to one embodiment of the invention. In at least one embodiment, an SDU810(discussed previously herein) also comprises a camera. In one embodiment, a camera may be located on a PED820. The camera may be utilized in a number of ways comprising, but not limited to, video chat and security profiling. In one embodiment, the camera could be used for facial recognition, including but not limited to expression detection and alerting airline personnel. In either of these embodiments the SDU810or the PED820communicates the images (still or video) through a sector server850to either the flight attendant panel830(which may also comprise a camera) or to another SDU/PED840. In the embodiment comprising video chat, the system might also be used as a flight attendant call (discussed previously herein) where the flight attendant is able to communicate with the seat130without actually walking to the physical location. This could increase efficiency and provide for quicker resolution to attendant calls. Likewise, this embodiment may be used to profile suspicious behavior and/or identify individuals not complying with aircraft crew member instructions. In one embodiment, this system would allow for seat to seat video communications, which would be an added feature particularly for those situations when passengers are traveling together but have not been seated together. In the security embodiment, the camera located in either the SDU810or PED820could be used as another verification of a person's facial characteristics against a known database of facial characteristics (e.g., FBI, CIA, local police, Interpol, plurality of DMV records, INS, CBP, etc. . . . ) for a variety of purposes. Because this feature must navigate through the sector servers, it too can be isolated from the system in case of a PA/VA.

In one embodiment, the camera located, for example, in SDU810or PED820is used to recognize hand and/or facial gestures to manipulate the user input, as discussed above. For example, while watching a movie a user may swipe their hand right-to-left to rewind a certain amount or left-to-right to skip forward a certain amount. There are a plurality of additional hand gesture gestures that might be used, and a plurality of input actions that can be associated with said hand gestures. In one embodiment, the user might personalize the association of hand gestures to input actions. This personalization may be saved (and then uploaded or downloaded) in the personal partition area of a sector server mentioned earlier.

Although various embodiments of the invention have been described, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in there are without departing from the spirit and scope of the appended claims.