US7397402B1 - Method and system for providing arithmetic code normalization and byte construction - Google Patents
Method and system for providing arithmetic code normalization and byte construction Download PDFInfo
- Publication number
- US7397402B1 US7397402B1 US11/625,417 US62541707A US7397402B1 US 7397402 B1 US7397402 B1 US 7397402B1 US 62541707 A US62541707 A US 62541707A US 7397402 B1 US7397402 B1 US 7397402B1
- Authority
- US
- United States
- Prior art keywords
- data
- bits
- input
- variable
- subsets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H03—ELECTRONIC CIRCUITRY
- H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
- H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
- H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
- H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
- H03M7/4006—Conversion to or from arithmetic code
Definitions
- This disclosure generally relates to the field of video data processing. More particularly, the disclosure relates to Context Adaptive Binary Arithmetic Coding (“CABAC”) for digital video encoders.
- CABAC Context Adaptive Binary Arithmetic Coding
- Video signals generally include data corresponding to one or more video frames.
- Each video frame is composed of an array of picture elements, which are called pixels.
- a typical color video frame having a standard resolution may be composed of over several hundreds of thousands of pixels, which are arranged in arrays of blocks.
- Each pixel is characterized by pixel data indicative of a hue (predominant color), saturation (color intensity), and luminance (color brightness).
- the hue and saturation characteristics may be referred to as the chrominance.
- the pixel data includes chrominance and luminance. Therefore, the pixel data may be represented by groups of four luminance pixel blocks and two chrominance pixel blocks. These groups are called macroblocks (“MBs”).
- MBs macroblocks
- the video frame As a video frame generally includes many pixels, the video frame also includes a large number of MBs. Thus, digital signals representing a sequence of video frame data, which usually include many video frames, have a large number of bits. However, the available storage space and bandwidth for transmitting these digital signals is limited. Therefore, compression processes are used to more efficiently transmit or store video data.
- VLC variable length coding
- Huffman Huffman coding
- blocks of symbols coding arithmetic coding
- CABAC Context Adaptive Binary Arithmetic Coding
- CABAC techniques are capable of losslessly compressing syntax elements in a video stream using the probabilities of syntax elements in a given context.
- the CABAC process will take in syntax elements representing all elements within a macroblock. Further, the CABAC process constructs a compress bit sequence by building out the following structure: the sequential set of fields for the macroblock based on the chosen macroblock configuration, the specific syntax element type and value for each of the fields within this field sequence, and the context address for each of the syntax elements.
- the CABAC process will then perform binarization of the syntax elements, update the context weights, arithmetically encode the binarizations of syntax elements (“bins”), and subsequently pack the bits into bytes through the syntax element processing component.
- the components of the CABAC process include: the CABAC weight initialization mode selection module, the macroblock syntax sequence generator, the binarization engine, the context address generator, the context weight update engine, the arithmetic coder, the bit packetizer, and the Network Abstraction Layer (“NAL”) header generator.
- the CABAC engine within a video encoder may accomplish two goals within the encoding process: (1) to carry out compressed data resource prediction for mode decision purposes; and (2) to losslessly compress the data for signal output delivery.
- the compressed data resource prediction task predicts the amount of bits required given a set of specific encoding modes for a given macroblock. Potential mode decision implementations may have up to eight modes to select from.
- the computational demand on the CABAC engine to support the mode decision task is significant.
- the weight update, arithmetic encoder and the bit packing components of the CABAC engine may require a significant amount of non-trivial computational and processing resources in a sequential processor implementation. Given that high performance encoding systems require multiple macro block rate distortion iterations of encoding per macro block, the CABAC process may impose an unreasonable resource demand on a processor-based solution. Prior implementations typically compromise on mode decision CABAC resource estimation accuracy by limiting the CABAC to bin level accuracy.
- a system capable of processing one binary symbol per clock cycle requires a matching back end-receiving engine capable of also processing the results on every cycle.
- the back end tasks consist of a value normalization task, which may generate up to eight bits of data, and a bit packing task, which groups the bits into bytes.
- the implementation solutions for the normalization and bit packing tasks are complex and computationally demanding.
- the first category includes routines that can generate at most one bit per cycle. This approach may utilize up to eight cycles to process one binary symbol as a single binary symbol may generate up to eight bits.
- the second category includes routines that achieve single cycle per binary symbol using a method that does not optimally handle all cases of the carry from the input data and the adder.
- a process extracts a plurality of subsets of bits from a first input. Each of the subsets of bits has a bit width equaling a number of leading zeros from a second input variable. Further, the process stores, in a memory, a consecutive sequence of the plurality of subsets. In addition, the process reads the consecutive sequence of the plurality of subsets from the memory if a third input release flag is established.
- a process stores a consecutive set of variable bit width data into a first in first out buffer.
- the variable bit width data has a width that is determined by a number of leading zeroes from an input variable. Further, the process reads the data from the first in first out buffer if the receiving data contains only ones.
- a process stores a consecutive set of data from a first input variable into a memory. Further, the process receives a subsequent data set from the first input variable. In addition, the process reads the consecutive set of data from the memory if the subsequent data set includes one or more binary bits having a value of zero.
- FIG. 1 illustrates a CABAC process
- FIG. 2 illustrates an arithmetic coder normalization process
- FIG. 3 illustrates an arithmetic coder normalization process that can process a new input data on every clock cycle.
- FIG. 4 illustrates a process for code normalization and byte construction.
- FIG. 5 illustrates another process for code normalization and byte construction.
- FIG. 6 illustrates yet another process for code normalization and byte construction.
- FIG. 7 illustrates a block diagram of a station or system that implements a code normalizer and byte construction engine.
- a method and system are disclosed, which provide an improved video digital data compression capable of providing a single cycle normalization for real-time digital video encoders, such as an MPEG-4 or an H-264 series encoder.
- the method and system may be utilized by the back end processor within the arithmetic encoder. As a result, normalization and payload to byte packing may be accomplished.
- FIG. 1 illustrates a CABAC process 100 .
- the CABAC process 100 selects a CABAC weight initialization mode.
- the CABAC process 100 generates an MB syntax sequence.
- the CABAC process 106 converts a syntax to binary.
- the term binarization may be utilized to denote the process block 106 .
- the CABAC process 100 performs a context address determination.
- the term ctxldx generation may be utilized to denote the process block 108 .
- the CABAC process 100 performs a context weight update.
- the CABAC process 100 performs an arithmetic encoding.
- the CABAC process 100 performs a bit packetizing.
- the CABAC process 100 performs a NAL header construction. An elementary stream results from the CABAC process 100 .
- FIG. 2 illustrates an arithmetic coder normalization process 200 .
- the arithmetic coder normalization process 200 can be utilized for the MPEG4 standard to process data at the bit level.
- the arithmetic coder normalization process 200 may utilize up to eight loop iterations to process a single binary input symbol from the front end arithmetic coder. Accordingly, an upper bound is placed on the computational demand.
- the arithmetic coder normalization process begins at a process block 202 . Further, at a process block 204 , the arithmetic coder normalization process 200 receives a codeLow input variable and a codeRange input variable.
- the codeLow input variable includes ten bits and the codeRange input variable includes nine bits.
- the arithmetic coder normalization process 200 increments an internal index. For example, the arithmetic coder normalization process 200 may increment an internal index “t” by one.
- the arithmetic coder normalization process 200 extracts the most significant bit from the codeLow input variable for a carry bit.
- the arithmetic coder normalization process 200 sets a variable to hold the number of leading zeros of the codeRange input variable. For example, the variable may be entitled shftCnt.
- the arithmetic coder normalization process 200 extracts a block of bits from the codeLow input variable. This is accomplished by discarding the most significant bits of the codeLow input variable and removing all the leading zeros to form a variable bit width block of bits.
- the variable bit width block of bits is then stored in a payload array at location t, which may be referred to by the variable payload[t].
- the arithmetic coder normalization process 200 determines if the contents of the variable payload[t], i.e., the bits, include only ones or both ones and zeroes. If the variable payload(t) includes both ones and zeroes, the arithmetic coder normalization process 200 proceeds to a process block 216 .
- the arithmetic coder normalization process begins with the first entry of the payload array. A carry is added to the first entry in the payload array. The payload is then outputted without the resulting carry. The arithmetic coder normalization process 200 then adds the carry from the addition of the first entry in the payload array to the second entry in the payload array.
- the payload is then outputted without the resulting carry.
- the arithmetic coder normalization process 200 then proceeds to a process block 220 to reset the payload array by setting the variable t to zero.
- the arithmetic coder normalization process 200 then ends at a process block 230 .
- the arithmetic coder normalization process 200 determines, at the decision block 212 , that the contents of the variable payload[t] include only ones, the arithmetic coder normalization process proceeds from the decision block 212 to the process block 222 .
- the carry bit is examined.
- the arithmetic coder normalization process 200 then proceeds to a decision block 224 to determine if the input carry bit equals one. If the arithmetic coder normalization process 200 determines that the input carry bit equals one, the arithmetic coder normalization process 200 proceeds to a process block 226 .
- the arithmetic coder normalization process 200 then proceeds to a process block 228 .
- the arithmetic coder normalization process 200 resets the index to negative one.
- the arithmetic coder normalization process 200 then ends at a process block 230 .
- the arithmetic coder normalization process 200 determines, at the decision block 224 , that the input carry bit does not equal one, the arithmetic coder normalization process 200 ends at the process block 230 .
- FIG. 3 illustrates a normalization and bit packing engine 300 capable of receiving one codeLow input and one code range input per cycle.
- This approach is based on binarization of syntax element (“bin”) level processing.
- a hardware solution is capable of providing a normalization and bit packing to bytes operation. This approach significantly reduces the hardware resources utilized by current systems. Specifically, this approach utilizes logic instead of memory lookup tables to resolve decision making tasks.
- the normalization and bit packing engine 300 receives two distinct variables: a codeLow variable 302 and a codeRange variable 304 , on every clock cycle.
- a leading zero detector 306 generates an output that is equal to the number of leading zero binary bits in the codeRange variable 304 . This output is registered in a latch shiftCnt 308 .
- a bus splitter 310 outputs a carry bit and a dchunk variable. The carry bit is extracted from the most significant bit of the codeLow variable 302 . Further, the dchunk variable, which includes the second through ninth lower bits of the codeLow variable 302 , is then shifted right by shiftCnt variable 308 through a shift latch 312 .
- the output dchunkRa of this shift latch 312 is then further shifted by bitPos 16 _ 1 variable through a bitPos 16 _ 1 shift latch 314 to align the data to fit into an output preparation register 316 .
- the output preparation register 316 is utilized to hold data until there are enough output bits to form a full byte. In another embodiment, a plurality of output preparation registers 316 may be utilized.
- a bit position calculator 318 generates a bitPos 16 _ 1 variable and a byte ready flag based on the input to the shiftCnt variable.
- the bitPos 16 _ 1 variable identifies where the dchunkR should reside within the output preparation register 316 .
- the byte ready flag identifies when the least significant byte 320 is ready for output.
- the bitPos 16 _ 1 shift latch 314 outputs dchunk 16 , which is then sent to a logical or gate 322 along with the output from the output preparation register 316 .
- the output from the logical or gate 322 is then sent to an adder 324 along with a shifted carry bit from a shift latch 326 to form both the output byte 328 and the new data for the output preparation register 316 .
- the shifted carry bit is generated by the shift latch 326 , which shifts the logically conditioned carry bit utilizing oneFlag_d, a delayed carry flag carry_d 6 , and a delayed carry flag carry_d 5 .
- the oneFlag_d is generated by first providing dchunk to an all ones detector 330 . If dchunk is all ones, the all ones detector 330 outputs oneFlag and provides oneFlag to a latch 332 . The latch 332 shifts oneFlag and outputs oneFlag_d.
- the oneFlag_d is provided along with a delayed carry flag carry_d 6 to a first gate 330 . Further, the output of the first gate 334 is provided along with a delayed carry flag carry_d 5 to a second gate 336 .
- the output of the adder 324 is split into a plurality of bytes through a bit splitter 338 .
- the bit splitter 338 splits the output of the adder 324 into three bytes. Further, in one embodiment, the bit splitter 338 is a twenty four bit splitter.
- the most significant byte is provided to an output byte register 340 , which may be denoted by the term outByte.
- the two least significant bytes are routed through a multiplexor 342 to feed the inputs of the output preparation register 316 . Based on the byteRdy flag, the multiplexor 342 selects one of the two lower output bytes from the adder 324 for the middle byte 344 of the output preparation register 316 .
- FIG. 4 illustrates a process 400 for code normalization and byte construction.
- the process 400 extracts a plurality of subsets of bits from a first input. Each of the subsets of bits has a bit width equaling a number of leading zeros from a second input variable.
- the process 400 stores, in a memory, a consecutive sequence of the plurality of subsets.
- the process 400 reads the consecutive sequence of the plurality of subsets from the memory if a third input release flag is established.
- FIG. 5 illustrates another process 500 for code normalization and byte construction.
- the process 500 stores a consecutive set of variable bit width data into a first in first out buffer.
- the variable bit width data has a width that is determined by a number of leading zeroes from an input variable.
- the process 500 reads the data from the first in first out buffer if the receiving data contains only ones.
- FIG. 6 illustrates yet another process 600 for code normalization and byte construction.
- the process 600 stores a consecutive set of data from a first input variable into a memory. Further, at a process block 604 , the process 600 receives a subsequent data set from the first input variable. In addition, at a process block 606 , the process 600 reads the consecutive set of data from the memory if the subsequent data set includes one or more binary bits having a value of zero.
- FIG. 7 illustrates a block diagram of a station or system 700 that implements a code normalizer and byte construction engine.
- the station or system 700 is implemented using a general purpose computer or any other hardware equivalents.
- the station or system 700 comprises a processor (“CPU”) 710 , a memory 720 , e.g., random access memory (“RAM”) and/or read only memory (ROM), a normalization and byte construction module 740 , and various input/output devices 730 , (e.g., storage devices, including but not limited to, a tape drive, a floppy drive, a hard disk drive or a compact disk drive, a receiver, a transmitter, a speaker, a display, an image capturing sensor, e.g., those used in a digital still camera or digital video camera, a clock, an output port, a user input device (such as a keyboard, a keypad, a mouse, and the like, or a microphone for capturing speech commands)).
- a user input device
- the code normalization and byte construction module 740 may be implemented as one or more physical devices that are coupled to the CPU 710 through a communication channel.
- the normalization and byte construction module 740 may be represented by one or more software applications (or even a combination of software and hardware, e.g., using application specific integrated circuits (ASIC)), where the software is loaded from a storage medium, (e.g., a magnetic or optical drive or diskette) and operated by the CPU in the memory 720 of the computer.
- ASIC application specific integrated circuits
- the normalization and byte construction module 740 (including associated data structures) of the present invention may be stored on a computer readable medium, e.g., RAM memory, magnetic or optical drive or diskette and the like.
Abstract
Description
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/625,417 US7397402B1 (en) | 2007-01-22 | 2007-01-22 | Method and system for providing arithmetic code normalization and byte construction |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/625,417 US7397402B1 (en) | 2007-01-22 | 2007-01-22 | Method and system for providing arithmetic code normalization and byte construction |
Publications (2)
Publication Number | Publication Date |
---|---|
US7397402B1 true US7397402B1 (en) | 2008-07-08 |
US20080175502A1 US20080175502A1 (en) | 2008-07-24 |
Family
ID=39589608
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/625,417 Expired - Fee Related US7397402B1 (en) | 2007-01-22 | 2007-01-22 | Method and system for providing arithmetic code normalization and byte construction |
Country Status (1)
Country | Link |
---|---|
US (1) | US7397402B1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080122662A1 (en) * | 2006-11-28 | 2008-05-29 | General Instrument Corporation | Method and System for Providing Single Cycle Context Weight Update Leveraging Context Address Look Ahead |
US20080247459A1 (en) * | 2007-04-04 | 2008-10-09 | General Instrument Corporation | Method and System for Providing Content Adaptive Binary Arithmetic Coder Output Bit Counting |
US20080276078A1 (en) * | 2007-04-04 | 2008-11-06 | General Instrument Corporation | Method and Apparatus for Context Address Generation for Motion Vectors and Coefficients |
US7535387B1 (en) * | 2007-09-10 | 2009-05-19 | Xilinx, Inc. | Methods and systems for implementing context adaptive binary arithmetic coding |
US20100124278A1 (en) * | 2008-11-14 | 2010-05-20 | General Instrument Corporation | Motion Compensation in Video Coding |
WO2012113255A1 (en) * | 2011-02-22 | 2012-08-30 | 中兴通讯股份有限公司 | Stream media data transmission method and streaming transmission apparatus |
US20130259116A1 (en) * | 2012-03-29 | 2013-10-03 | Hiu-Fai R. Chan | Two Bins Per Clock CABAC Decoding |
EP3116261A4 (en) * | 2014-03-24 | 2017-03-08 | Huawei Technologies Co. Ltd. | Method for transmitting physical layer data and data transmission device |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101500164B (en) * | 2008-12-31 | 2011-09-28 | 深圳市同洲电子股份有限公司 | Method and device for arithmetic code package outputting |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5111415A (en) * | 1989-11-06 | 1992-05-05 | Hewlett-Packard Company | Asynchronous leading zero counter employing iterative cellular array |
US5751233A (en) * | 1995-05-19 | 1998-05-12 | Canon Kabushiki Kaisha | Decoding apparatus and method therefor |
US5798953A (en) * | 1994-08-24 | 1998-08-25 | Advanced Micro Devices, Inc. | Apparatus and method for determining a number of digits leading a particular digit |
US6970114B2 (en) * | 1999-06-01 | 2005-11-29 | Wend Llc | Gate-based zero-stripping, varying length datum segment and arithmetic method and apparatus |
US7286066B1 (en) * | 2005-12-16 | 2007-10-23 | Nvidia Corporation | Acceleration of bitstream decoding |
-
2007
- 2007-01-22 US US11/625,417 patent/US7397402B1/en not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5111415A (en) * | 1989-11-06 | 1992-05-05 | Hewlett-Packard Company | Asynchronous leading zero counter employing iterative cellular array |
US5798953A (en) * | 1994-08-24 | 1998-08-25 | Advanced Micro Devices, Inc. | Apparatus and method for determining a number of digits leading a particular digit |
US5751233A (en) * | 1995-05-19 | 1998-05-12 | Canon Kabushiki Kaisha | Decoding apparatus and method therefor |
US6970114B2 (en) * | 1999-06-01 | 2005-11-29 | Wend Llc | Gate-based zero-stripping, varying length datum segment and arithmetic method and apparatus |
US7286066B1 (en) * | 2005-12-16 | 2007-10-23 | Nvidia Corporation | Acceleration of bitstream decoding |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080122662A1 (en) * | 2006-11-28 | 2008-05-29 | General Instrument Corporation | Method and System for Providing Single Cycle Context Weight Update Leveraging Context Address Look Ahead |
US8189683B2 (en) | 2006-11-28 | 2012-05-29 | General Instrument Corporation | Method and system for providing single cycle context weight update leveraging context address look ahead |
US20080247459A1 (en) * | 2007-04-04 | 2008-10-09 | General Instrument Corporation | Method and System for Providing Content Adaptive Binary Arithmetic Coder Output Bit Counting |
US20080276078A1 (en) * | 2007-04-04 | 2008-11-06 | General Instrument Corporation | Method and Apparatus for Context Address Generation for Motion Vectors and Coefficients |
US8213499B2 (en) | 2007-04-04 | 2012-07-03 | General Instrument Corporation | Method and apparatus for context address generation for motion vectors and coefficients |
US7535387B1 (en) * | 2007-09-10 | 2009-05-19 | Xilinx, Inc. | Methods and systems for implementing context adaptive binary arithmetic coding |
US20100124278A1 (en) * | 2008-11-14 | 2010-05-20 | General Instrument Corporation | Motion Compensation in Video Coding |
US8335256B2 (en) | 2008-11-14 | 2012-12-18 | General Instrument Corporation | Motion compensation in video coding |
WO2012113255A1 (en) * | 2011-02-22 | 2012-08-30 | 中兴通讯股份有限公司 | Stream media data transmission method and streaming transmission apparatus |
US20130259116A1 (en) * | 2012-03-29 | 2013-10-03 | Hiu-Fai R. Chan | Two Bins Per Clock CABAC Decoding |
US9681133B2 (en) * | 2012-03-29 | 2017-06-13 | Intel Corporation | Two bins per clock CABAC decoding |
EP3116261A4 (en) * | 2014-03-24 | 2017-03-08 | Huawei Technologies Co. Ltd. | Method for transmitting physical layer data and data transmission device |
Also Published As
Publication number | Publication date |
---|---|
US20080175502A1 (en) | 2008-07-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7397402B1 (en) | Method and system for providing arithmetic code normalization and byte construction | |
US8213499B2 (en) | Method and apparatus for context address generation for motion vectors and coefficients | |
US6639945B2 (en) | Method and apparatus for implementing motion detection in video compression | |
US7132963B2 (en) | Methods and apparatus for processing variable length coded data | |
US6292114B1 (en) | Efficient memory mapping of a huffman coded list suitable for bit-serial decoding | |
JP7170669B2 (en) | Coding the last significant coefficient flag | |
US7016417B1 (en) | General purpose compression for video images (RHN) | |
US8189683B2 (en) | Method and system for providing single cycle context weight update leveraging context address look ahead | |
US8989275B2 (en) | Video processing architecture | |
WO2000002319A1 (en) | Real time algorithms and architectures for coding images compressed by dwt-based techniques | |
US20080247459A1 (en) | Method and System for Providing Content Adaptive Binary Arithmetic Coder Output Bit Counting | |
WO2011005105A1 (en) | Computer implemented early skip | |
US6580828B1 (en) | Fast decoding | |
EP1292152B1 (en) | Image processing apparatus, and image processing method | |
US9407933B2 (en) | Simultaneous and loopless vector calculation of all run-level pairs in video compression | |
TWI705693B (en) | Apparatus and method for vector-based entropy coding for display stream compression | |
US6687410B1 (en) | Method and apparatus for compression and decompression of data | |
CN1849826A (en) | Method and apparatus for scalable signal processing | |
US10609382B2 (en) | Method and apparatus for compressing video data | |
US10225562B1 (en) | Embedding information about EOB positions | |
US20030067977A1 (en) | Implementation of quantization for simd architecture | |
KR20200065367A (en) | Image processing device and frame buffer compressor | |
CN112672164B (en) | Video compression system and method, and video decompression system and method | |
Murat | Key architectural optimizations for hardware efficient JPEG-LS encoder | |
EP0843483A2 (en) | A method for decoding encoded video data |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GENERAL INSTRUMENT CORPORATION, PENNSYLVANIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HU, YENDO;REEL/FRAME:018785/0071 Effective date: 20070118 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
AS | Assignment |
Owner name: MOTOROLA MOBILITY LLC, ILLINOIS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GENERAL INSTRUMENT HOLDINGS, INC.;REEL/FRAME:030866/0113 Effective date: 20130528 Owner name: GENERAL INSTRUMENT HOLDINGS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GENERAL INSTRUMENT CORPORATION;REEL/FRAME:030764/0575 Effective date: 20130415 |
|
AS | Assignment |
Owner name: GOOGLE TECHNOLOGY HOLDINGS LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA MOBILITY LLC;REEL/FRAME:034294/0001 Effective date: 20141028 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20200708 |