A system and method for pushing live media to a client device in an adaptive streaming environment. In one aspect, a media server configured to transmit live media includes a storage unit for storing media segments of a live media programming stream, wherein the media segments are encoded at multiple bitrates identified in respective media presentation data structures associated therewith. A websocket interface is provided that is operative to facilitate a websocket session with the client device. One or more processors of the system are operative to execute service logic for pushing the media segments to the client device substantially in real time during the websocket session.
|
4. A method operating at a client device configured to receive live media from a media server, the method comprising:
initiating a hypertext transfer protocol (http) connection with the media server;
initiating a handshake transaction with the media server to open a bidirectional websocket interface over an underlying Transmission Control protocol (TCP) connection;
generating a message to the media server to initiate transmission of a live media programming stream in a websocket session;
receiving media segments from the media server of the live media programming stream in real time via a websocket connection during the websocket session for playback by a media player, whereby padding latency at the media server for the websocket session is reduced;
maintaining control of the websocket session based on comparing a received segment's length with a varying inter-segment time period monitored by the client device and activating a bitrate representation switching with respect to the media segments responsive thereto; and
generating one or more text messages for transmission to the media server via the websocket interface, wherein a text message is configured for commencing transmission of the live media programming stream at a live point with a specified delay.
1. A client device configured to receive live media from a media server, the client device comprising:
one or more processors;
a media player; and
a hypertext transfer protocol (http) client module and a websocket client module coupled to the one or more processors, wherein the one or more processors are operative to control the http client and websocket client modules and execute associated program instructions configured to:
initiate an http connection with the media server;
initiate a handshake transaction with the media server to open a bidirectional websocket interface over an underlying Transmission Control protocol (TCP) connection;
facilitate generating a message to the media server to initiate transmission of a live media programming stream in a websocket session;
facilitate receiving media segments from the media server of the live media programming stream in real time via a websocket connection during the websocket session for playback by the media player, whereby padding latency at the media server for the websocket session is reduced;
maintain control of the websocket session by the client device based on comparing a received segment's length with a varying inter-segment time period monitored by the client device and activating a bitrate representation switching with respect to the media segments responsive thereto; and
a control message generator operative to generate control messages as text messages for transmission to the media server via the websocket interface, wherein a text message is configured for commencing transmission of the live media programming stream at a live point with a specified delay.
17. A client device configured to receive live media from a media server, the client device comprising:
one or more processors;
a media player; and
a hypertext transfer protocol (http) client module and a websocket client module coupled to the one or more processors, wherein the one or more processors are operative to control the http client and websocket client modules and execute associated program instructions configured to:
initiate an http connection with the media server;
initiate a handshake transaction with the media server to open a bidirectional websocket interface over an underlying Transmission Control protocol (TCP) connection;
facilitate generating a message to the media server to initiate transmission of a live media programming stream in a websocket session;
facilitate receiving media segments from the media server of the live media programming stream in real time via a websocket connection during the websocket session for playback by the media player, whereby padding latency at the media server for the websocket session is reduced;
maintain control of the websocket session by the client device based on comparing a received segment's length with a varying inter-segment time period monitored by the client device and activating a bitrate representation switching with respect to the media segments responsive thereto; and
a control message generator operative to generate control messages as text messages for transmission to the media server via the websocket interface, wherein a text message is configured for commencing transmission of the live media programming stream from a particular point in a wall-clock time associated with the live media programming stream.
2. The client device as recited in
3. The client device as recited in
5. The method as recited in
6. The method as recited in
7. The method as recited
8. The method as recited in
9. The client device as recited in
10. The client device as recited in
11. The client device as recited in
12. The client device as recited in
13. The method as recited in
14. The method as recited in
15. The method as recited in
16. The method as recited in
|
This nonprovisional application claims priority based upon the following prior United States provisional patent application(s): (i) “SYSTEM AND METHOD FOR PUSHING LIVE MEDIA CONTENT IN AN ADAPTIVE STREAMING ENVIRONMENT,” Application No. 62/020,557, filed Jul. 3, 2014, in the name(s) of Richard Mitic, Beatriz Grafulla-González and Robert Swain; each of which is hereby incorporated by reference in its entirety.
The present disclosure generally relates to communication networks. More particularly, and not by way of any limitation, the present disclosure is directed to a system and method for pushing live media content in an adaptive streaming environment.
Adaptive streaming based on HyperText Transfer Protocol (HTTP) has become a popular approach for delivering multimedia content over the Internet. Typical streaming implementations use a “client-controlled” methodology in which the client requests media segments from the server at an appropriate time, which it then processes and renders. Data transfer takes place over HTTP, the infrastructure for which is far more widespread than that of other media streaming protocols such as Real-time Transport Protocol (RTP) and Real Time Streaming Protocol (RTSP).
For adaptive live media streams, it is desirable to reduce the overall end-to-end delay so that the media as viewed by the end consumer is as close as possible in time to reality. Delays may be caused by several factors as outlined in
In addition, it is common to see clock drift between the client and associated server in a streaming environment. In an embodiment based on the Moving Picture Expert Group (MPEG) Dynamic Adaptive Streaming over HTTP (MPEG-DASH) technology, this may be partially corrected by the addition of a timing element, e.g., the <UTCTiming> element in Amendment 1 of the ISO/IEC 23009-1 specification, which allows both server and client to be synchronized to a common clock. The time resolution of this clock is not defined, but it is a non-zero value and might typically be on the order of a second or longer. Hence, there is still a chance of a client attempting to access a media segment that does not exist yet, especially when trying to keep as close as possible to the “live point”. Further, there is no normative behavior defined for the situation where a client encounters a HTTP 404 response (i.e., the requested media segment does not exist). A server therefore cannot fully prepare for a situation where clients are requesting media segments erroneously.
Embodiments of the present disclosure are broadly directed to systems, methods, devices, apparatuses and associated computer-readable media for advantageously pushing live media content in an adaptive bitrate (ABR) streaming environment in view of the foregoing. To that end, various embodiments may be generally grouped relative to the following aspects. First, live media can be pushed to the client using a persistent socket connection over HTTP (hereinafter referred to as a websocket connection), as will be set forth in detail hereinbelow. This will eliminate need for a client device to request media at the correct time, and hence will reduce end-to-end delay and avoid HTTP 404 responses. In essence, the length of padding may be minimized to zero. This also has the advantage that clock drift between the client and server can be corrected every time the client receives a segment. During the playout of segment, there may still be drift, but it will be negligible if corrected frequently, as will be seen below. Secondly, a set of defined messages and session protocols are set up according to the teachings herein in order for the server and client to communicate successfully in the disclosed implementations. In an example scenario, this will cover communication between client and server during a persistent socket connection as will be described below. The same socket connection may be generalized to cover other forms of client-server communication, e.g. metric reporting or SAND (Server and Network Assisted DASH Operation) communication. Thirdly, several embodiments for measuring network metrics (e.g., bandwidth rate, download speeds, congestion, etc.) in a live media presentation environment are set forth.
Accordingly, in one aspect, an HTTP connection is initiated by the client device with a “media server,” which for purposes of the present patent application may comprise a general HTTP sever configured for adaptive streaming. A handshake transaction is effectuated with the media server to open a websocket interface over an underlying transport layer (e.g., a Transmission Control Protocol or TCP connection). A bidirectional websocket session is effectuated between the media server and associated client device wherein the media segments of a live media programming stream are delivered to the client device substantially in real time without the client device sending requests therefor, whereby undesirable characteristics such as delay and/or latency (e.g., associated with padding, etc.) are eliminated or reduced. It should be appreciated that an embodiment of the HTTP media server is therefore operative to maintain and/or provide the media segments without padding regardless of the segment lengths.
In another aspect, a further embodiment of a media server configured to transmit live media to a client device is disclosed. The claimed media server comprises, inter alia, a storage unit for storing media segments of a live media programming stream wherein the media segments are encoded at multiple bitrates identified in respective media presentation data structures associated therewith. A persistent bidirectional communication channel over a websocket interface is provided operative to facilitate a websocket session with the client device. The media server further includes one or more processors executing service logic for pushing the media segments to the client device substantially in real time during the websocket session.
In yet another aspect, an embodiment of a client device configured to receive live media from a media server in a push-based streaming environment is disclosed. The claimed embodiment comprises, inter alia, one or more processors for controlling an HTTP client module and a websocket client module coupled thereto. The processors are operative to execute associated program instructions in conjunction with the client modules configured to perform: initiate an HTTP connection with the media server; initiate a handshake transaction with the media server to open a bidirectional websocket interface over an underlying TCP connection; facilitate generating a control message to the media server to initiate transmission of a live media programming stream in a websocket session; and facilitate receiving media segments from the media server of the live media programming stream substantially in real time during the websocket session for playback by a media player of the client device.
In a further aspect, an embodiment of a method operative at a media server system is disclosed. The claimed embodiment comprises, inter alia, capturing live media programming associated with an event and processing the live media programming for ABR transmission as a live media programming stream comprising a plurality of media segments that are encoded in multiple bitrates identified in corresponding media presentation data structures. The method further involves effectuating a websocket interface with a client device responsive to a websocket handshake transaction received therefrom and pushing the media segments to the client device substantially in real time during a websocket session established with the client device via the websocket interface.
In still further aspects, additional or alternative embodiments of methods operative at a media server and associated client device are disclosed. In still further related aspects, embodiments of non-transitory computer-readable media containing program instructions or code portions stored thereon are disclosed for performing one or more processes, methods and/or schemes set forth herein.
Advantages of the present invention include, but not limited to, facilitating a live media presentation wherein clients may accept media segments without having to explicitly request them, which reduces the end-to-end delay and eliminates the risk of premature requests for media. A client device configured with one or more embodiments of the present disclosure may also evaluate the quality of the network connection even though it is not using the traditional “request-receive” methodology, as is required in the current implementations.
Further features of the various embodiments are as claimed in the dependent claims. Additional benefits and advantages of the embodiments will be apparent in view of the following description and accompanying Figures.
Embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the Figures of the accompanying drawings in which like references indicate similar elements. It should be noted that different references to “an” or “one” embodiment in this disclosure are not necessarily to the same embodiment, and such references may mean at least one. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
The accompanying drawings are incorporated into and form a part of the specification to illustrate one or more exemplary embodiments of the present disclosure. Various advantages and features of the disclosure will be understood from the following Detailed Description taken in connection with the appended claims and with reference to the attached drawing Figures in which:
In the following description, numerous specific details are set forth with respect to one or more embodiments of the present patent disclosure. However, it should be understood that one or more embodiments may be practiced without such specific details. In other instances, well-known circuits, subsystems, components, structures and techniques have not been shown in detail in order not to obscure the understanding of the example embodiments. Accordingly, it will be appreciated by one skilled in the art that the embodiments of the present disclosure may be practiced without such specific components-based details. It should be further recognized that those of ordinary skill in the art, with the aid of the Detailed Description set forth herein and taking reference to the accompanying drawings, will be able to make and use one or more embodiments without undue experimentation.
Additionally, terms such as “coupled” and “connected,” along with their derivatives, may be used in the following description, claims, or both. It should be understood that these terms are not necessarily intended as synonyms for each other. “Coupled” may be used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” may be used to indicate the establishment of communication, i.e., a communicative relationship, between two or more elements that are coupled with each other. Further, in one or more example embodiments set forth herein, generally speaking, an element, component or module may be configured to perform a function if the element is capable of performing or otherwise structurally arranged to perform that function.
As used herein, a network element or node may be comprised of one or more pieces of service network equipment, including hardware and software that communicatively interconnects other equipment on a network (e.g., other network elements, end stations, etc.), and is adapted to host one or more applications or services with respect to a plurality of subscribers. Some network elements may comprise “multiple services network elements” that provide support for multiple network-based functions (e.g., NV media management, session control, QoS policy enforcement, bandwidth scheduling management, subscriber/device policy and profile management, content provider priority policy management, streaming policy management, and the like), in addition to providing support for multiple application services (e.g., data and multimedia applications). Subscriber end stations or client devices may comprise any device configured to execute, inter alia, at least one streaming client application (e.g., an ABR streaming client application) for receiving content from a streaming server or content provider in accordance with a streaming application specification. Further, such client devices may be configured to effectuate a websocket interface for establishing bidirectional websocket sessions with suitable media server nodes for real-time or substantially real-time transmission of live audio/video media (i.e., multimedia) as will be described in detail hereinbelow. Accordingly, example client devices may include set-top boxes, PVR/DVRs, workstations, laptops, netbooks, palm tops, mobile phones, smartphones, multimedia phones, Voice Over Internet Protocol (VOIP) phones, mobile/wireless user equipment, IP-connected high definition TV terminals, portable media players, location-aware subscriber equipment, gaming systems or consoles (such as the Wii®, Play Station 3®, Xbox 360®), etc., that may access or consume live content/services provided over a delivery network (e.g., an IP network) in accordance with one or more embodiments set forth herein. Further, the client devices may also access or consume content/services provided over broadcast networks (e.g., cable and satellite networks) as well as a packet-switched wide area public network such as the Internet via suitable service provider access networks. In a still further variation, the client devices or subscriber end stations may also access or consume content/services provided on virtual private networks (VPNs) overlaid on (e.g., tunneled through) the Internet.
One or more embodiments of the present patent disclosure may be implemented using different combinations of software, firmware, and/or hardware. Thus, one or more of the techniques shown in the Figures (e.g., flowcharts) may be implemented using code and data stored and executed on one or more electronic devices or nodes (e.g., a subscriber client device or end station, a network element, etc.). Such electronic devices may store and communicate (internally and/or with other electronic devices over a network) code and data using computer-readable media, such as non-transitory computer-readable storage media (e.g., magnetic disks, optical disks, random access memory, read-only memory, flash memory devices, phase-change memory, etc.), transitory computer-readable transmission media (e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals, digital signals), etc. In addition, such network elements may typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (e.g., non-transitory machine-readable storage media) as well as storage database(s), user input/output devices (e.g., a keyboard, a touch screen, a pointing device, and/or a display), and network connections for effectuating signaling and/or bearer media transmission. The coupling of the set of processors and other components may be typically through one or more buses and bridges (also termed as bus controllers), arranged in any known (e.g., symmetric/shared multiprocessing) or heretofore unknown architectures. Thus, the storage device or component of a given electronic device or network element may be configured to store code and/or data for execution on one or more processors of that element, node or electronic device for purposes of implementing one or more techniques of the present disclosure.
Referring now to the drawings and more particularly to
By way of illustration, content may be delivered via IP/CDN 122 using adaptive bitrate (ABR) streaming techniques compliant with specifications such as, e.g., MPEG-DASH, Microsoft® Silverlight® Smooth Streaming, HTTP Live Streaming (HLS), HTTP Dynamic Streaming (HDS), Icecast, and so on, to one or more subscriber end stations disposed in the streaming environment 100, as illustrated by an example client device or user equipment (UE) device 124. It will be apparent that one or more such client devices may be associated with a subscriber/customer for consuming content delivered via CDN 122 in any type or number of access technologies including broadband access via wired and/or wireless (radio) communications. For purposes of the present patent application, the terms “streaming client device” and “client device” may be used synonymously and may comprise any UE device or appliance that in one implementation not only receives program assets for live viewing, playback and/or decoding the content, but also operates as a command console or terminal that can accept user inputs, messages, commands or requests to interact with a network element disposed in CDN 122 and/or the associated streaming server systems 102 for controlling transmission of content via a bidirectional interface. As such, the example client device 124 may include one or more streaming client modules 128 (e.g., an ABR streaming client) and associated decoding functionalities depending on the streaming technologies implemented (e.g., MPEG-DASH) as well as a websocket client module 130 operative to effectuate one or more persistent connections with the server system 102 via a bidirectional or full-duplex communication interface 138. The streaming client module(s) 128 and the websocket client module 130 are operably coupled to a processor module 134 and video buffer memory 132 via a suitable bus structure 136 for effectuating acquisition, decoding and rendering of the streamed media content, e.g., at a display 126. Although not specifically shown, the client device 124 also includes appropriate user interfaces for viewing one or more electronic program guides that list, identify or otherwise show various streaming channels (live media and//or on-demand) the subscriber is able to receive. Such user interfaces may also be configured to allow the user to scroll through an electronic program guide (i.e., channel surfing), select or otherwise change a particular streaming channel, and the like. Further, as will be described in additional detail hereinbelow, example client device 124 may also include appropriate structures and modules operating in conjunction with or as part of the websocket client 130 for facilitating real-time transmission of media from the server system 102.
Continuing to refer to
Configured as a live multimedia server, DASH server 202 is operative to cooperate with media capture, encoding, and segment processing as set forth above in reference to
Referring back to
As one skilled in the art will appreciate, in an implementation of the WebSocket protocol and associated API within the DASH server-client architecture as set forth above, the client device 222 uses HTTP to communicate with the server 202, and then both endpoints switch to using the underlying connection (e.g., TCP or TCP/SSL) that HTTP is layered on to establish an end-to-end TCP/SSL socket connection for bidirectional application communication (i.e., streaming). As such, the WebSocket protocol is an independent TCP-based protocol that comprises a handshake part and a data transfer part. To establish a websocket connection, the client device 222 sends a websocket handshake request, responsive to which the server 202 returns a websocket handshake response, whose example formats may take on the form as shown in the following illustration:
Client request:
Server response:
Once the client 222 and server 202 have both sent their handshakes, and if the handshake transaction was successful, appropriate data transfer may be commenced with respect to facilitating real-time media streaming. After a successful handshake, the client 222 and server 202 may send data back and forth asynchronously in conceptual units known as messages that may be in textual format or in binary data format. In accordance with the teachings of the present patent disclosure, text messages may be configured for transmitting control messages (between the client 222 and server 202) to modulate or otherwise control a live media streaming session and binary data may be used for sending media segments to the client device 222. Other data such as MPD files and/or initialization segments may be obtained by the client device 222 via channels other than the websocket channel. These processes are formalized in the flowcharts of
Taking reference to
As pointed out previously, textual messages may be used for transmitting control messages (e.g., requests from the client device to the server, responses from the server to the client, etc.). Although binary data is primarily used for transmission of media segments to the client device, control messages in binary data format may also be developed in additional or alternative implementations. In one embodiment, the textual control messages may be formatted in the form of string-encoded JavaScript Object Notation (JSON) objects, as set forth in the following example:
{
“command”: “start streaming”,
“parameters”:
{
“from”: “segment”,
“url”: “representation_A/segment0000.m4s”
}
}
One or more variations of the foregoing example format may be implemented by a client device, with additional parameterization as needed, to generate a number of JSON-formatted text messages as control messages to the media server. By way of illustration, set forth below are a plurality of control messages that a client device may generate to the media server:
In analogous fashion, a server may generate and forward the following example control messages to a client:
Those skilled in the art will recognize that the foregoing control messages are merely examples and numerous additional or alternative messages (e.g., either in textual for binary format compliant with the WebSocket protocol) may be provided in other implementations within the scope of the present patent disclosure.
As to establishing websocket channels between a server and a client for live media streaming, several connection architectures may be implemented depending on the trade-offs between scalability and complexity. Turning now to
One skilled in the art should appreciate that the foregoing implementation may not scale well because there could easily be numerous representations (e.g., 10 or more) in a single DASH presentation. This implies that the server would have to maintain many connections per client, thereby potentially impeding scalability. It may further imply that the server and client would have to react to messages sent on any connection, which may introduce unnecessary complexity.
A highly scalable connection architecture 400C is shown in
Server 500B shown in
Turning to
Referring to
Referring back to
If the measured inter-segment period (T) is substantially same as the segment length (block 610), a determination or assessment may be obtained that the network conditions are acceptable (block 612), whereupon the client device 628 may continue monitoring (block 622). On the other hand, if the inter-segment period (T) is shorter than the segment length (block 614), a determination or estimation may be obtained that network conditions may allow faster download times (block 616). As the media segments are being received at faster than real time, they may be buffered as needed (block 618). Depending on internal buffer conditions, rendering/processing efficiencies, etc., the client device 628 may generate appropriate control messages, including but not limited to switching to higher bitrate representations as may be indicated by a suitable adaptation logic module, to the server 624 via websocket interfacing as described hereinabove (block 620). Thereafter, the client device 628 may continue monitoring segment transmission characteristics as before (block 622). In one implementation, the client device 628 may be configured to “probe” the network in order to switch up to a higher bitrate representation. For example, it can request a few segments of the higher bitrate representation and, after a transition/transient period, reassess the network speed as set forth above, e.g., to determine if the conditions sustain even inter-segment separation.
It will be appreciated that in the methodology set forth above, no additional complexity is introduced (e.g., at the server) because it requires nothing other than media to be set through the websocket interface in normal course. As time measurements are made only at the client device, temporal disparity (i.e., out-of-sync clocks) between the server and client nodes does not pose a hurdle in assessing jitter/delay measurements.
Reference numeral 700A in
The methodology set forth above is fairly straightforward to implement at the client side, although it may slightly impact the overall bitrate because of the addition of header processing/transmission. It should be appreciated that instead of using JSON-formatted text messages as headers, binary JSON-formatted messages may be used in an alternative/additional implementation wherein the overall bitrate impact may be less since it can be more transmission-efficient.
Taking reference to example client websocket implementation 800B shown in
In addition to the foregoing client-based measurement methodologies, a server-based measurement methodology 900A is set forth in
Server-based acts and processes relative to the foregoing scheme are set forth in the flowchart of
In the above-description of various embodiments of the present disclosure, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and may not be interpreted in an idealized or overly formal sense expressly so defined herein.
At least some example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. Such computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, so that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s). Additionally, the computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.
As alluded to previously, tangible, non-transitory computer-readable medium may include an electronic, magnetic, optical, electromagnetic, or semiconductor data storage system, apparatus, or device. More specific examples of the computer-readable medium would include the following: a portable computer diskette, a random access memory (RAM) circuit, a read-only memory (ROM) circuit, an erasable programmable read-only memory (EPROM or Flash memory) circuit, a portable compact disc read-only memory (CD-ROM), and a portable digital video disc read-only memory (DVD/Blu-ray). The computer program instructions may also be loaded onto or otherwise downloaded to a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of the present invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as “circuitry,” “a module” or variants thereof.
Further, in at least some additional or alternative implementations, the functions/acts described in the blocks may occur out of the order shown in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction relative to the depicted arrows.
Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above Detailed Description should be read as implying that any particular component, element, step, act, or function is essential such that it must be included in the scope of the claims. Reference to an element in the singular is not intended to mean “one and only one” unless explicitly so stated, but rather “one or more.” All structural and functional equivalents to the elements of the above-described embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Accordingly, those skilled in the art will recognize that the exemplary embodiments described herein can be practiced with various modifications and alterations within the spirit and scope of the claims appended below.
Mitic, Richard, Swain, Robert, Grafulla-González, Beatriz
Patent | Priority | Assignee | Title |
11102272, | Dec 19 2019 | WANGSU SCIENCE AND TECHNOLOGY CO., LTD. | Method and device for downloading resource file |
11343306, | Nov 07 2018 | WANGSU SCIENCE & TECHNOLOGY CO , LTD | Method, device and system for downloading data block of resource file |
Patent | Priority | Assignee | Title |
7835283, | Jun 30 2000 | Nokia Technologies Oy | Method and system for managing quality of service by feeding information into the packet network |
20120124179, | |||
20130041934, | |||
20130054743, | |||
20130114482, | |||
20140006564, | |||
20140032777, | |||
20140201335, | |||
20140215085, | |||
20140215536, | |||
20140222930, | |||
20160212496, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Sep 12 2014 | Telefonaktiebolaget LM Ericsson (publ) | (assignment on the face of the patent) | / | |||
Sep 16 2014 | GRAFULLA-GONZÁLEZ, BEATRIZ | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 040012 | /0054 | |
Sep 16 2014 | MITIC, RICHARD | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 040012 | /0054 | |
Sep 16 2014 | SWAIN, ROBERT | TELEFONAKTIEBOLAGET LM ERICSSON PUBL | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 040012 | /0054 |
Date | Maintenance Fee Events |
Apr 25 2022 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Date | Maintenance Schedule |
Oct 23 2021 | 4 years fee payment window open |
Apr 23 2022 | 6 months grace period start (w surcharge) |
Oct 23 2022 | patent expiry (for year 4) |
Oct 23 2024 | 2 years to revive unintentionally abandoned end. (for year 4) |
Oct 23 2025 | 8 years fee payment window open |
Apr 23 2026 | 6 months grace period start (w surcharge) |
Oct 23 2026 | patent expiry (for year 8) |
Oct 23 2028 | 2 years to revive unintentionally abandoned end. (for year 8) |
Oct 23 2029 | 12 years fee payment window open |
Apr 23 2030 | 6 months grace period start (w surcharge) |
Oct 23 2030 | patent expiry (for year 12) |
Oct 23 2032 | 2 years to revive unintentionally abandoned end. (for year 12) |