Description
Category: Technology Licenses
Created On: 2022-04-28
Record Count: 4
Primary Industries
- Internet
- Telecommunications Equip
- Media & Entertainment
- Broadcasting/Cable TV
- Telecommunications Svcs & Equip
- Software
- Content
- Tool
IPSCIO Report Record List
Below you will find the records curated into this collection. This summary includes the complete licensed property description so that you can review and determine if this collection covers the topics, technology or transaction type that is relevant for your needs. The full report will include all relevant deal data such as the royalty base, agreement date, term description, royalty rates and other deal terms. For reference, here is a sample of a full IPSCIO curated royalty rate report: Sample Report
IPSCIO Record ID: 28827
Communication System Having Automatic Circuit Board Initialization Capability.
U.S. Patent 4, 914,650
Bandwidth Sharing and Congestion Control Scheme for an Integrated Voice and Data Network.
U.S. Patent 5,631,846
Upstream Communications for Interactive Networks.
U.S. Patent Application Serial No. 10/391982 – (Carroll 4)
Methods and Apparatus for Rescheduling a Communication System Channel after a Channel Property Change.
U.S. Patent Application Serial No. 10/388981 – (Carroll 5)
Method and Apparatus for Aligning Timing Intervals across Communication System Channels.
Headend Devices – Cable Modem Termination System (CMTS).
CMTS is designed to meet the increasing demand placed on broadband over cable systems from new subscribers and to handle the dynamic loads from existing subscribers. The CMTS allows for scalability that can increase subscriber capacity quickly and within a limited budget. The scalable hardware design of the CMTS uses DOCSIS 1.1 and Euro-DOCSIS 1.1 standards and offers a single downstream channel using 64 or 256QAM modulations and upstream channel supporting QPSK and or 16QAM modulation. The architecture supports up to 8 upstream channels with single channel expansion cards that can be factory or field installed. This scalability and flexibility allows the operator to make maximum use of its capital budget.
IPSCIO Record ID: 26589
Provider (Licensee) also agreed to provide us with a sufficient number of qualified and skilled personnel to perform the Services necessary to maintain the product quality of the VCSL and provide us with all necessary equipment, tools and other material necessary to complete the technology and maintain our quality of market.
IPSCIO Record ID: 29015
Technology shall mean the eViewMediaEngine which is owned by Licensor and protected by USA Patent numbers 7,003,168, 6,711,299 and 6,904,175.
Video Archive
The technology provides APIs to control the processes of uploading the ME format media into an archive that supports media distribution and rendering. The underlying engine components reside in both the execution time client and server(s). The archive structure supports maintaining more than one copy of an object for both redundancy and for load sharing considerations. Each archive object in the ME format has, as a minimum
• Video index file(s)
• Video data file(s)
• Audio index file(s)
• Audio data file(s)
Within the scope of this agreement, it is understood that the ME format will be extended to include
• Script index file(s)
• Script data file(s)
The archive will also be extended to support the Asier encryption model.
Video Distribution
The technology provides APIs to control access to objects in the video archive, supporting object rendering in a web distribution model. There is an underlying Java based player that supports rendering multiple videos simultaneously on an HTML web page with programmable coordination among the videos. The player and its supporting Javascript environment have all of the elements required to
• Access the index and data files from an archive
• Buffer the video object such that the video starts to play quickly (typically within 3 seconds), but can sustain interruptions in the flow of data from the server.
• Manage the overall processor and bandwidth constraints. The player supports bandwidth coordination among the videos that are playing simultaneously. Each video can be designated as “primary†or “secondaryâ€. When initial buffering occurs, primaries are able to get to the initial fast start state (3 seconds worth of render time) before a secondary may start. At any time while playing/buffering, the secondary(s) will back off if a primary is about to stall for lack of data. Any video may have its buffering bandwidth effect controlled to a percentage of its computed average bandwidth requirement (i.e., a video may be loaded at 110% of its average bit rate rather than loading as fast as it can – ME supports both paradigms).
• Start a video on any designated frame. The player supports an API that includes a request to play from frame(x) to frame(y) and/or start playing to end at frame(x). This is used to effect slider drag operations that allow the subscriber to advance or backup to any position within a movie with no dependence on prior buffering.
• Render the video from an internal memory cache. The video is buffered from a stream and is not stored on the local disk. Thus, a two hour movie is never completely contained within the client machine.
• Support a coordinated actor/director rendering paradigm. Each video rendered on the web page is represented by a Java actor. The page also contains, in this paradigm, a Java director that controls everything visualized by the actor(s) on the page. The director contains a context for each video being managed by it. At any instant in time, an actor is associated (receiving rendering data) with one context within the director. The director may have more contexts than actors in order to buffer video data before it is needed. The contexts may be programmed to trigger events when they get to certain states (i.e., when playing a particular frame, when there is enough data buffered to safely play, when the user clicks on an actor associated with the context, etc.). Each context also supports a complete API control mechanism. The combination of the event architecture and the API allows the context events to trigger control actions in other contexts. This supports a high degree of coordination between videos on the page. As a video plays to certain frames (arrives at certain scenes), another video (or image) on the page may be triggered to take an action.
• Automatically recover from server disconnects. When connected to a web server to pull the video data, the player will encounter frequent disconnects during the course of a two hour period. The technology supports automatically detecting that this has occurred and to reconnect before the object buffer is drained.
• Automatically select from multiple object formats. Any ME archive object may be represented in more than one format (resolution, frame rate, etc.). The player environment is capable of analyzing the processor speed and available bandwidth and selecting an appropriate format. The player may also be directed to select or change formats while playing and not be required to start over.
• Restrict access to the video. The Java player is restricted to operation within a specific web domain. If a different web page tries to activate a player not authorized for it, the player will fail to run. It is understood that under this agreement, this security model will be extended to support the Asier encryption model.
• Support complex ME formats. The complex ME object format is structurally the same, but supports dynamic frame rate and resolution settings. The video may use a different frame rate for each included scene.
Video Chat
The technology provides a comprehensive solution for live video chat. The chat architecture includes a client API that supports
• Connecting the client to a VXN server. This operation results in an internal endpoint or IP address that is used to route data from one chat client to another.
• Enabling local camera capture. The video from the camera is automatically made available to the internal chat architecture for both local display and transmission to the server for use in the chat conference.
• Making a call. The API allows the local client to make a call through the VXN connection to anyone connected to the VXN by referencing the destination’s endpoint address. After the appropriate handshake, this will cause the local client’s audio and video to be transmitted to the destination.
• Making multiparty calls. The technology supports up to an 8 party call, depending on available bandwidth.
• Controlling call parameters. The API supports controlling parameters that affect the destination’s user experience and the bandwidth usage for both parties. These include resolution, frame rate, and quality settings. Most parameters can be changed mid-call.
• Making audio only calls.
• Interoperation with H.323 devices.
The technology consists of a combination of source and object (executable) code and associated documentation
• ME encoder Windows dynamic link library executables
• ME encoder controller Java applet executable
• ME player Java applet executable
• ME upload applet executable
• ME installer applet executable
• ME chat installer executable
• ME chat engine Java applet executable
• ME chat engine Windows dynamic link library executables
• ME media service controller JavaScript source code
• ME media engine hosting service PHP executable (obfuscated source code)
IPSCIO Record ID: 1046
Under the Development and Licensing Agreement, we have a worldwide, perpetual and non-exclusive license to use certain specified related the Licensor technologies and solutions to develop, market and sell broadband access products.
