Patent Application
20140281011
In network broadcasting, a broadcast provider may transmit data to viewers over a network, such as, the Internet. The rate of data transmission is generally limited by the network's available bandwidth. To effectively transmit data within this limited bandwidth, broadcast providers may balance the quality and streaming speed of the transmitted data. For example, broadcasts transmitted at relatively high quality (demanding more bandwidth) typically have relatively slow streaming speeds, while broadcasts transmitted at relatively low quality (demanding less bandwidth) typically have relatively fast streaming speeds.
In “real-time” broadcasting, streaming speed is paramount, and broadcasts typically have a streaming speed equal to at least the speed of the recording to simulate real-time viewing. However, to compensate for such fast streaming speeds, the quality of the data is typically degraded causing low-quality broadcasts.
The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of this specification. Specific embodiments of the present invention, both as to organization and method of operation, together with objects, features, and advantages thereof, will be described and may best be understood with reference to the following detailed description when read with the accompanying drawings, wherein:
It will be appreciated that, for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.
The invention provides a system and method for recording a dual output stream—a first for real-time broadcast with relatively low quality, and a second for later rebroadcast with significantly improved quality relative to the first stream. The first output stream is recorded at, or converted to, relatively low quality for relatively fast transmission speed, in order to provide real-time viewing, e.g., over a wireless or high traffic channel. A second output stream is also recorded at, or converted to, relatively high quality in a local storage for relatively slow transmission speed, in order to provide high quality viewing, e.g., generally not in real time. The first and second streams may be recorded or generated simultaneously and may record the same exact content, but with different quality; the second stream having better quality (preferable for high quality viewing) but requiring more memory than the first stream (preferable for real-time viewing). The first, lower quality stream may be transmitted with higher priority for immediate viewing (e.g., in real-time during the recording period), while the second, higher quality stream is initially stored locally (during the recording period) and only transmitted later (after the recording period) or may be transmitted at the same time but with lower priority, e.g., over bandwidth not otherwise needed for the first stream.
During the real-time broadcast, the recorded content may be edited in real-time. In one embodiment, an editing display may have multiple windows with lower quality stream content recorded from multiple sources, which may be edited, e.g., with other fast streams or alone, to provide the final lower quality stream broadcast. An edit-log may record the specific segments from the multiple sources that are used in the real-time, fast stream broadcast. Once bandwidth is available (e.g., after the real-time broadcast has been completed), the higher quality stream source data may be edited locally or transmitted to a remote server for remote editing where they are compiled to replicate the original broadcast. The segments of the higher quality stream identified in the edit-log are assembled in the same manner as they were in the original lower quality stream broadcast so as to replicate the real-time broadcast, but with the improved quality recorded with the higher quality stream. The result is an exact or substantial replica of the real-time final edited broadcast, which is only available at a time delay after the real-time broadcast, but with significantly improved quality.
In the following description, various aspects of the present invention will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the present invention. However, it will also be apparent to one skilled in the art that the present invention may be practiced without the specific details presented herein. Furthermore, well known features may be omitted or simplified in order not to obscure the present invention.
Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulates and/or transforms data represented as physical, such as electronic, quantities within the computing system's registers and/or memories into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices.
“Broadcast” may mean any display, stream, playback or presentation of content in any medium, such as, image, videos, multi-media, audio, text, graphics, etc. Broadcasts may be provided via any public or private media channel, for example, a wired or wireless channel or network such as the Internet, television, closed-circuit television, radio, on a user's computer, etc. Broadcasts may be displayed on any output device, such as a television screen, personal computer monitor, wireless device monitor, cellular phone monitor, tablet computer monitor, radio player, etc. Broadcasts may use any personal or collaborative viewing platform including web-based seminars (webinars), synchronized media displays for a collection of viewers, etc. In some embodiments herein, Internet broadcast is described as an example and may refer to any other type of broadcast of streaming display.
Broadcasts may be edited as a plurality of different segments from a plurality of different media streams generated at a plurality of different recording devices or other sources. Each media stream segment may include content or media objects, such as, for example, images, videos, audio tracks, text streams, social media or chat streams, webpages, applications, advertisements, etc. Multiple media stream segments may be assembled to create a broadcast, e.g., a single stream or multiple streams, each with a combination of the media objects. For example, a multi-frame broadcast may simultaneously display, in different windows, segments from a plurality of data streams received by a plurality of respective recording devices. Broadcasts may also include a plurality of design parameters, such as, layouts, themes, backgrounds and layer arrangements.
Current network broadcasting systems present a trade-off between quality and streaming speed, but cannot reliably provide both high quality and fast streaming speed at current bandwidth capacities. To meet available bandwidth capacities, relatively high-quality broadcasts typically have relatively slow streaming speeds, while relatively fast streaming broadcasts typically have relatively poor quality.
In order to improve network broadcasting, embodiments of the invention provide the advantages of both high quality and fast streaming speed in a dual-mode broadcast system. The dual-mode broadcast system splits broadcasting into two paths: a first, “fast” path for optimizing speed for real-time viewing, and a second, “slow” or “quality” path for optimizing the viewing quality. In the “fast” path, broadcast content may be recorded as a “fast” data stream with relatively low quality for fast streaming speed. In the “quality” path, the broadcast data content may be recorded as a “slow” data stream with relatively high quality in a local storage for later viewing. The fast and slow streams record the same exact content, but with different quality. The slow stream may have better quality (preferable for high quality viewing), but typically requires more memory than the fast stream (preferable for real-time viewing). The fast stream may be transmitted with higher priority for immediate viewing, while the slow stream is initially stored locally, e.g., at the recorder, and only transmitted over the broadcast network at a later time, for example, after the full length real-time broadcast is completely transmitted, or at the same time but with lower bandwidth priority, or later, when the network bandwidth is available.
In one embodiment, the two data streams are transmitted simultaneously, but with different priorities. The first, lower quality data stream has a higher priority than the second, higher quality data stream and is allocated as large a portion of the available bandwidth as is necessary to transmit the first, lower quality data stream at its full, unrestricted speed and resolution. In some examples, the portion of available bandwidth allocated to the first, lower quality data stream is larger (for example, a greater rate of packet transmission) than the portion allocated to the second, higher quality data stream. In some examples, the portion of available bandwidth allocated to the first, lower quality data stream is smaller than the portion allocated to the second, higher quality data stream, as long as the first, lower quality data stream is transmitted at a higher proportion of its full, unrestricted transfer rate and resolution.
The two streams may be transmitted to the same or different devices.
During the real-time broadcast, the fast, i.e., lower quality or higher priority, stream may be edited, e.g., with other fast streams or alone. For example, the real-time broadcast may be a composite of video segments from multiple video, radio or other media sources interplayed in an edited (non-chronological) order selected by an editor. An edit-log or the edited stream itself may catalogue or index the edited order of the segments of the fast stream used in the real-time broadcast. The edit-log may be generated by editing the streams remotely, e.g., at the same device or terminal as the recording devices, and/or centrally, e.g., at a central server.
After the real-time broadcast, the slow, i.e., higher quality or lower priority, stream may be transmitted to a remote server where the slow stream may be edited to replicate the real-time broadcast of the fast stream. When the broadcast is edited using content recorded at multiple remote sources, all the slow streams from each source may be synchronized, e.g., at a central server, by their time stamps for editing. Once synchronized, segments of the slow streams identified in the edit-log, e.g., by their stream source and time-stamp, may be assembled to replicate the real-time broadcast, but with the improved quality recorded with the slow streams. The result is an exact replica of the real-time broadcast, which is only generated at a time delay after the real-time broadcast, but has significantly improved quality.
In one embodiment, the dual-mode broadcast may be turned on or off, for example, automatically activated when network traffic is substantially high, when available bandwidth is below a threshold rate, or after attempting and failing to transfer data using the relatively high quality second stream, and automatically deactivated otherwise. In another embodiment, the dual-mode broadcast may toggle between broadcasting relatively higher and lower quality frames or segments as the available network bandwidth oscillates, for example, transferring higher quality content when network traffic or bandwidth permits it, and transferring lower quality content when network traffic or bandwidth does not permit it.
In another embodiment, the dual-mode broadcast may be customized such that the output resolution and/or frame rate of the first, i.e., lower quality or higher priority, data stream from each recording device(s) is selected as desired, e.g., in advance of transmission. In a further embodiment, the dual-mode broadcast may be customized such that the output resolution and/or frame rate of the first data stream from each recording device(s) dynamically changes during its recording or transmission so as to fit within the available bandwidth or within the bandwidth assigned for high priority data transmissions.
Although some embodiments of the invention describe broadcasting media in an Internet, television, radio or other broadcast display, it may be appreciated that such embodiments of the invention may similarly be used for any other type of display, including, for example, newspaper or magazine layout, text or multi-media layout, combining different streams or media sources, or any other system and method for designing and displaying media objects.
Reference is made to
Dual-mode broadcast system 100 may include a plurality of recording devices 102 for capturing content used in system 100 broadcasts. Recording devices 102 may include, for example, video recorders, cameras, web-cams, microphones, telephones, etc., and may record any media types, such as, video, audio, multi-media, etc. Each recording device 102 may have a local processor 106, e.g., to execute commands received from broadcast server 120 (either directly or via a broadcast client installed locally on recording device 102), and/or a local memory 108, e.g., to locally store its recorded content.
Each recording device 102 may create two streams of duplicate content for each recording. The first stream may have a relatively fast streaming speed and relatively low quality, e.g., for use in the first real-time broadcast, and the second stream may have a relatively slow streaming speed and high quality, e.g., for use in the second, postponed or simultaneous but lower priority (e.g., lower proportion of bandwidth), high-quality broadcast. Additional third or more streams of differing quality may also be used for a third or more duplicate broadcasts to be replicated with different qualities. In one example, different playback devices may have different specific resolution or quality requirements, each of which may be generated and sent for playback to the different respective devices. The first and second streams of the same recording device 102 may record the exact same or substantially identical content and may be indexed by the same sequence of time-stamps or other identifiers. Due to the relatively higher quality, the second stream may have a significantly greater data size than the first stream of each recording device 102. Duplicate recording by recording devices 102 may be controlled or initiated by server-side logic and data installed at broadcast server 120 via remote commands to recording device 102 or by client-side logic and data installed at recording device 102 as an application, plug-in, software or code.
Each recording device 102 may transmit the first (fast, e.g., real-time, or higher priority) stream automatically, immediately and/or in real-time, to the remote broadcast server 120, e.g., over network 140, and may withhold and store the second (slow) stream locally, e.g., in memory 108, for later transmission. Transmitting the first stream may be almost instantaneous, e.g., delayed by at most a few seconds or minutes of recording, while transmitting the second data stream may take a significant amount of time, e.g., one to two hours (the exact times depending on data size and available bandwidth). Since the data size of the second data stream is substantially greater than the first data stream, network 140 traffic may be minimized by postponing transmission of the larger second data stream, e.g., at least until after the entire smaller first data stream is transmitted, or simultaneously or at overlapping time periods, but with a lower bandwidth priority. The first and second data streams may be transmitted over any type of communication channel, such as, for example, cable connections, ISDN, DSL, or wireless connections such as Wi-Fi, satellite or cellular such as GSM, W-CDMA, GPRS, EDGE, etc. The first and second data streams may be transmitted over the same or different communication channels, e.g., the first data stream may be transmitted over a relatively faster communication channel than the second data stream.
Broadcast server 120 may host an editing interface for an editing device 110 to edit the first (real-time) set of data streams to generate a first (real-time) version of a broadcast. Since data from the first set of data streams is available to editing device 110 in real-time, and data from the second set of data streams is reserved for later use, the broadcast creator may edit data only from the first (fast or real-time) data streams, not from the second (slow or high-quality data) data streams.
The interactive design interface may present the editor with a set of different first (real-time) data streams, each captured or generated by a different recording device 102 with relatively faster streaming speed and lower quality. Each stream may be visualized as a video thumbnail and may be viewed live, as it is recorded, from each of selected recording device 102, or, at a slight time delay thereof, for example, at most ten to twenty minutes. The set of first data streams may be synchronized for editing by synchronizing the respective time stamps of the first data streams.
A broadcast creator or editor may operate editing device 110 to design the broadcast by selecting a combination of frames or segments from two or more of the plurality of first streams, composed in an edited, selected and/or non-chronological order. The editor may edit by manipulating and controlling an interactive design interface to create a simulation of the broadcast on the moderator screen. The design interface may function as a staging area, or “green room”, which may mimic the broadcast screen. Broadcast server 120 may automatically transcribe the editor's selections to generate a first (real-time) version of the edited broadcast. For example, if the editor drags a data stream's thumbnail to a primary (front) window in the broadcast simulation at a particular time, a set of edit parameter values may be automatically created corresponding to that edit, for example, (data stream identification (ID), timestamp 1:15, layout design, window 1). Edit parameters for broadcasting a data segment may include, for example, the segment's input data stream ID, a timestamp of the input data stream when the segment starts, ends and/or the segment length, a timestamp when the segment is to be displayed in the broadcast, a layout design or theme for displaying that segment, the display window or spatial position within the layout design for displaying that segment, display size or dimensions (e.g., number or positions of pixels, and pixels×pixels) of the segment viewing window, layer order, coloring or transparency for displaying that segment, segment run-time, etc.
Each edited broadcast may be defined by an edit-log cataloging the one or more edit parameters, including the stream segment time-stamps defining the ordering and timing of broadcasting each edited segment. For example, a broadcast may be defined by an edit-log including the following portion: {. . . timestamp 1:15, stream 3, layout A, front window; timestamp 1:25, stream 2, layout A, side window 3; timestamp 2:43, stream 5, layout B, front window; . . . }. The edit-log together with only the set of input data streams from recording devices 102 (either the first or second sets) may be used to fully create the edited broadcast (either a first or second version, respectively). In the example above, the broadcast may be a multi-frame broadcast having multiple windows (e.g., a front window, three or more side windows 1-3, etc.) for simultaneously displaying segments from a plurality of data streams received by a plurality of respective recording devices 120. A single window broadcast may also be used, displaying at most one data stream segment in each broadcast time interval.
Broadcasts may be edited and designed in real-time. For example, as the moderator selects stream segments to be displayed and/or selects an “on-air” feature, these stream segments may be transmitted automatically instantaneously to one or more viewer devices 104. In another embodiment, real-time editing need not be executed instantaneously and instead, may first be designed and edited in an “off-air” mode in a staging area and then, once finalized, may be implemented when an “on-air” signal is sent. It may be appreciated that real-time editing and broadcasting need not be instantaneous and may include slight delays of, for example, up to ten or twenty minutes.
Broadcast server 120 may transmit the first (real-time) version of the edited broadcast to one or more viewer devices 104. In one embodiment, the first version of the edited broadcast may be assembled at broadcast server 120 and transmitted as a single data stream to viewer devices 104. In another embodiment, broadcast server 120 may transmit each consecutive broadcast segment separately, in pieces, according to the sequence ordering in the edit-log, and viewer devices 104 may assemble the broadcast locally at the remote client-side. In another example, the central broadcast server 120 may simply transmit the edit log to viewer devices 104, where viewer devices 104 may download segments according to the edit-log directly from the broadcast content storage, e.g., database 130 or memory unit 124.
Viewer devices 104 may display the first version of the broadcast in real-time (immediately or in the next available broadcast slot(s)), e.g., synchronized, on all devices subscribed and/or connected to broadcast server 120 via network 140. Viewer devices 104 may include, for example, television screens, personal computer monitors, wireless device monitors, cellular phone monitors, tablet computer monitors, radio players, electronic billboards, or any output device capable of displaying the broadcast media.
The first version of the edited broadcast may have a desirable streaming speed, e.g., greater than or equal to the streaming speed of the first input data streams (a greater streaming speed achieved by further compression of the input data), suitable for real-time viewing. However, the quality of the first version of the broadcast may be relatively low, e.g., less than or equal to the quality of the first input data streams (a lesser quality achieved by further compression of the input data). To improve such low quality, embodiments of the invention may turn to the other “higher-quality” data path in the dual-mode broadcast system 100 to create a second higher quality version of the broadcast using the second set of input data streams stored locally at their respective source recording devices 102.
The second (high-quality) input data streams may be transferred (e.g., after transferring all the first input data streams or at a lower transmission priority) from local storage 108 in recording devices 102 over network 140 to memory unit 124 in broadcast server 120 or its associated database 130. The second set of data streams may be transferred over a secure network 140 platform, e.g., Transmission Control Protocol (TCP)/Internet Protocol (IP), which acknowledges receipt of transmissions to ensure all data is properly transferred. Broadcast server 120 may assemble the second set of input data into the second version of the broadcast using the same edit-log used to generate the first (lower quality) version of the broadcast. Since the same edit-log is used to edit the same exact content in the first and second sets of data streams, the first and second versions of the broadcast should have exactly the same or substantially identical context, but with different quality. The second version of the broadcast, available only at a time delay, e.g., after all the first data streams are transferred, provides a significant improvement in viewing quality. In one embodiment, the first version of the broadcast may be displayed only once for an initial real-time showing (or not at all if not requested), and the second versions of the broadcast may be displayed for every subsequent viewing at viewing devices 104.
Although the functionality of the dual-mode broadcast system 100 is attributed to broadcast server 120, equivalently such functionality may be implemented on recording device 102 and/or editing device 110 via logic and data installed in the client device as an application, plug-in, software or code, or may be streamed together with logic and data commands.
Recording devices 102, viewing devices 104, editing device 110 and broadcast server 120, may include one or more processor(s) 106, 116, 112 and 122, respectively, for executing operations and one or more memory unit(s) 108, 118, 114 and 124, respectively, for storing data and/or instructions (e.g., software) executable by a processor. Processor(s) 106, 116, 112 and/or 122 may include, for example, a central processing unit (CPU), a digital signal processor (DSP), a microprocessor, a controller, a chip, a microchip, an integrated circuit (IC), or any other suitable multi-purpose or specific processor or controller. Memory unit(s) 108, 118, 114 and/or 124 may include, for example, a random access memory (RAM), a dynamic RAM (DRAM), a flash memory, a volatile memory, a non-volatile memory, a long-term memory unit, a short-term memory unit, a cache memory, a buffer, or other suitable memory units or storage units. In
Reference is made to
Recording device 102 may record or generate content at an initial (high) quality and store the content, in duplicate, as a low quality version 126 used in accordance with the first path and a high quality version 128 used in accordance with the second path. The higher quality version may have a higher resolution and higher display frame rate than the lower quality version.
In the first path, low quality version 126 may be scheduled for immediate transmission from recording device 102 to broadcast server 120 (between buffers, caches or other short-term or internal processor memories 108a and 124a, respectively) as the data is recorded or generated. Using the low quality version 126, a first version of a broadcast 132 (and/or an edit-log 134 associated with the broadcast) may be generated, e.g., via editing device 110, to include segments of low quality version 126. First version of the broadcast 132 (and/or an edit log 134) may be transmitted to viewing device 104 and displayed, e.g., in real-time, on a monitor or screen 138.
Recording device 102 may transmit the entire low quality version 126 in the first path during the data stream recording and, upon completion of the recording, may switch to the second to transmit high quality version 128.
In the second path, recording device 102 may store high quality version 128 in a long-term memory 108b while its content is being recorded or generated. Once the recording is ended and low quality version 126 is completely transmitted, recording device 102 may compress, encrypt and/or transmit high quality version 128. High quality version 128 may be transmitted from long-term memory 108b in recording device 102 to a long-term memory 124b in broadcast server 120. High quality version 128 may be transmitted over a network protocol (e.g., TCP/IP) that is more secure than is used to transmit low quality version 126; alternatively, the same network protocol may be used. Once high quality version 128 is completely transferred to broadcast server 120, edit log 134 may already be generated, and processor 122 may begin to edit high quality version 128 according to edit log 134 to generate a second version of the broadcast 136. High quality version 128 may be transmitted in whole, or in part including only the segments or frames identified by edit-log, so as to reduce the amount of transferred data.
Second version of the broadcast 136 may be assembled into a single stream by processor 122 at broadcast server 120 and may be transmitted to viewing device 104, e.g., in consecutive data packets, according to the stream sequence. Alternatively, broadcast server 120 may transmit unassembled segments identified in edit log 134 (e.g., along with edit log 134) to viewing device 104 to be assembled by processor 116 into second version of the broadcast 136. Second version of the broadcast 136 may be identical in content, but having higher quality, validity, resolution, reliability, and/or security than first version of the broadcast 132. Viewing device 104 may display second version of the broadcast 136 on a monitor or screen 138, e.g., upon request by or establishing a connection with a subscribing user device. All instances of first version of the broadcast 132 may be automatically updated and replaces with second version of the broadcast 136, for example, for improved quality viewing.
Reference is made to
In operation 310, a processor (e.g., processor 122 of broadcast server 120 of
In operation 320, the processor may edit the first version of one or more data streams, each received from one of the plurality of devices to generate a first version of an edited broadcast. Editing may include automatically transcribing editing instructions received from a client editing device (e.g., editing device 110 of
In operation 330, one or more display(s) (e.g., monitor(s) 138 of viewing device(s) 104 of
In operation 340, the processor may receive a second version of one or more same data streams (e.g., high quality version 128 of
In operation 350, a processor (e.g., a server-side processor 122 at broadcast server 120 or a client-side processor 116 at viewing device 104 of
In operation 360, the processor may automatically replace (all or some) instances of the first version of the edited broadcast with the second version of the edited broadcast and/or transfer the second version of the edited broadcast to a viewing device (e.g., viewing device 104 of
In operation 370, the display(s) may display the second version of the edited broadcast at a time postponed from when the first version of the broadcast is available for viewing.
Other operations of orders of operations may be used.
It may be appreciated that the terms “high” or “low” quality and “fast” or “slow” streaming speed are relative terms and are described in reference to each other. For example, the streaming speed of the first recorded stream or broadcast is faster relative to the streaming speed of the second recorded stream or broadcast and the quality of the second recorded stream or broadcast is greater (e.g., higher resolution or storing more data per frame) than the quality of the first recorded stream or broadcast.
The “quality” of media content may refer to the image resolution (e.g., the number or density of pixels or pixel rows and/or columns), the rate of data transfer necessary to support media playback at those resolutions, and/or a capture or playback rate of the media (e.g., the number of frames per second (fps)). In some embodiments, these terms may be defined independently, e.g., associated with value ranges. For example, “low-definition” (LD) broadcasts may have a resolution of, e.g., less than 300×400 pixel ratio, which is relatively lower quality than “standard-definition” (SD) broadcasts that may have a resolution of, e.g., 640-480 pixel ratio, which in turn is relatively lower quality than “high-definition” (HD) broadcasts that may have a resolution of, e.g., 1080×720 pixel ratio, which in turn is relatively lower quality than “ultra high-definition” (UHD) broadcasts that may have a resolution of, e.g., 3840×2160 pixels. To support playback at these image resolutions, a “high” quality broadcast stream at present technological standards may include high quality, e.g., high definition, image detail, such as a data transfer rate of 2-3 mbps (megabits per second) or greater playback quality, preferably approximately 2.5 mbps, or up to 4 mbps or greater. In addition, for example, a “low” quality stream at present technological standards may include low quality or definition image detail having a data transfer rate of 30-100 kbps (kilobits per second), or less than 800 kbps, depending upon the bandwidth of the uplink.
For example, a “fast” streaming speed may refer to the speed of transmissions that are prioritized or queued to be sent before data transmissions sent at a “slow” streaming speed. The exact speeds depend on the quality discussed above, available bandwidth and other competing transmissions.
It should be appreciated that the speed discussed herein may refer to the speed at which data can stream, not the speed of transmission or the speed of the memory or processor to process the data. It may be appreciated that different versions having “substantially” the same content means that the versions have primarily the same content but allows for minor variations due to errors in transmission, decryption, etc. It may be appreciated that different versions having “substantially” different quality may mean that the quality has a great enough difference to be visibly noticeable to the human eye.
Embodiments of the invention may include an article such as a computer or processor readable non-transitory storage medium, such as for example a memory, a disk drive, or a USB flash memory encoding, including or storing instructions, e.g., computer-executable instructions, which when executed by a processor or controller (e.g., processor 106, 116, and/or 122 of
Various embodiments are discussed herein, with various features. However, not all features discussed herein must be in all embodiments. Furthermore, features of certain embodiments may be combined with features of other embodiments; thus certain embodiments may be combinations of features of multiple embodiments.
Although the particular embodiments shown and described above will prove to be useful for the many distribution systems to which the present invention pertains, further modifications of the present invention will occur to persons skilled in the art. All such modifications are deemed to be within the scope and spirit of the present invention as defined by the appended claims.
This application claims the benefit of U.S. Provisional Patent Application No. 61/793,484, filed Mar. 15, 2013, which is incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61793484 | Mar 2013 | US |
