DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Instant application eligible to benefit from the domestic priority claimed by applicant on 07/10/2020 and effective filling date was considered as 07/10/2020.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/9/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Status
Claims 1-45 are cancelled.
Claims 46 - 86 are pending and examined on the merits.
Claims 46 - 86 are rejected.
Claim Objections
Claims 57 and 77 are objected to because of the following informalities:
The preamble of claim 57 and 77 recites “A method for encoding MPEG-G encoded data” – which appears to be an error carried over from claim 46’s “decoding MPEG-G encoded data” preamble. An encoder does not encode already encoded data; it encodes uncoded/raw genomic information (as confirmed by the body of the claim itself: “uncoded genomic information,” “the data” being encoded).
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 46-86 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite methods, and systems for encoding and decoding MPEG-G data. This judicial exception is not integrated into a practical application because while claims 46-86 attempt to integrate the exception into a practical application, said practical application is a generically recited computer element that does not add meaningful limitations to the abstract idea as it is simply implementing the abstract idea on a computer. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the computer elements only store and retrieve information in memory as well as perform basic calculations that are known to be well-understood, routine and conventional computer functions as recognized by the decisions listed in MPEP § 2106.05(d).
Framework with which to Analyze Subject Matter Eligibility:
Step 1: Are the claims directed to a category of statutory subject matter (a process, machine manufacture, or composition of matter)? [see MPEP § 2106.03]
Claims are directed to statutory subject matter, specifically methods (claims 46-66) and systems (claims 67-86).
Step 2A Prong One: Do the claims recite a judicially recognized exception, i.e., an abstract idea, a law of nature, or a natural phenomenon? [see MPEP § 2106.04(a)]
With respect to the Step 2A Prong One evaluation, the instant claims are found herein to recite abstract ideas that fall into the grouping of mental processes.
The following claims recite abstract ideas (mental processes and mathematical concepts):
Claims 46 and 67: Extracting encoded data, selecting a predictor type, selecting arithmetic coding contexts, and decoding encoded data are processes of identifying selecting, and calculating information that can be done via pen and paper or within the human mind and are therefore abstract ideas, specifically mental processes. The predictor type specifying the specified methods, and the prediction type being the specified information is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 47 and 68: The arithmetic encoding type being the specified coding is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claim 48: The predictor type being a neural network is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 49 and 69: Identifying a machine learning model is a process of selecting information that can be done via pen and paper or within the human mind and is therefore an abstract idea, specifically a mental process. The encoding parameters including the specified information is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 50 and 70: The extracted parameters including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 51 and 71: The training data including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 52 and 72: The training data including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 53 and 73: The extracted parameters including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 54 and 74: The context data including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 55 and 75: The context including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 56 and 76: The context data including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 57 and 77: Selecting a predictor type, selecting arithmetic encoding contexts, and encoding the data are processes of identifying, selecting, and calculating information that can be done via pen and paper or within the human mind and are therefore abstract ideas, specifically mental processes. The encoding parameters specifying the given information, the predictor type being a machine-learning and count-based prediction, and the encoded data comprises the specified information are merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 58 and 78: The arithmetic encoding type being those specified is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 59 and 79: The encoding parameters including the specified information is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 60 and 80: The extracted encoding parameters including the specified information is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 61 and 81: The training mode data including the specified information is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 62 and 82: The training mode data including the specified information is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 63 and 83: The extracted encoding parameters including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 64 and 84: The context data including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 65 and 85: The context data including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Claims 66 and 86: The context data including the specified data is merely further limiting the data itself, which is an abstract idea, specifically a mental process.
Step 2A Prong Two: If the claims recite a judicial exception under prong one, then is the judicial exception integrated into a practical application? [see MPEP § 2106.04(d)]
Because the claims do recite judicial exceptions, direction under Step 2A Prong Two provides that the claims must be examined further to determine whether they integrate the abstract ideas into a practical application.
The following claims recite the following additional elements in the form of non-abstract elements:
Claims 46 and 67: Receiving MPEG-G encoded data is an insignificant extra solution activity, specifically mere data gathering (See Performing clinical tests on individuals to obtain input for an equation, In re Grams, 888 F.2d 835, 839- 40; 12 USPQ2d 1824, 1827-28 (Fed. Cir. 1989) and Determining the level of a biomarker in blood, Mayo, 566 U.S. at 79, 101 USPQ2d at 1968. See also PerkinElmer, Inc. v. Intema Ltd., 496 Fed. App'x 65, 73, 105 USPQ2d 1960, 1966 (Fed. Cir. 2012) (assessing or measuring data derived from an ultrasound scan, to be used in a diagnosis)) [See MPEP § 2106.05(g)]. A system, memory, and processor are generic and nonspecific elements of a computer that do not improve the functioning of any computer or technology described herein [See MPEP § 2106.04(d)(1) and MPEP § 2106.05(d)].
Claims 57 and 77: Receiving encoding parameters and training the encoder based on the parameters are insignificant extra solution activities, specifically mere data gathering (See Performing clinical tests on individuals to obtain input for an equation, In re Grams, 888 F.2d 835, 839- 40; 12 USPQ2d 1824, 1827-28 (Fed. Cir. 1989) and Determining the level of a biomarker in blood, Mayo, 566 U.S. at 79, 101 USPQ2d at 1968. See also PerkinElmer, Inc. v. Intema Ltd., 496 Fed. App'x 65, 73, 105 USPQ2d 1960, 1966 (Fed. Cir. 2012) (assessing or measuring data derived from an ultrasound scan, to be used in a diagnosis)) [See MPEP § 2106.05(g)]. A system, memory, and a processor are generic and nonspecific elements of a computer that do not improve the functioning of any computer or technology described herein [See MPEP § 2106.04(d)(1) and MPEP § 2106.05(d)].
Step 2B: If the claims do not integrate the judicial exception, do the claims provide an inventive concept? [see MPEP § 2106.05]
Because the additional claim elements do not integrate the abstract ideas into a practical application, the claims are further examined under Step 2B, which evaluates whether the additional elements, individually and in combination, amount to significantly more than the judicial exception itself by providing an inventive concept.
The claims do not recite additional elements that are sufficient to amount to significantly more than the judicial exceptions because the claims recite additional elements that are generic, conventional, nonspecific, or insignificant extra solution activity. These additional elements include:
The additional elements of a system, memory, and a processor are all generic and nonspecific elements of a computer that are well-understood, routine and conventional within the art and therefore do not improve the functioning of any computer or technology described therein (Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information), Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values), and Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)) [See MPEP § 2106.05(d)(II)]. Therefore, taken both individually and as a whole, the additional elements do not amount to significantly more than the judicial exception by providing an inventive concept.
The additional elements of receiving MPEG-G encoded data, receiving encoding parameters, and training the encoder based on the parameters are all insignificant extra solution activities, specifically mere data gathering (See Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission), OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015)) [See MPEP § 2106.05(g)]. Therefore, taken both individually and as a whole, the additional elements do not amount to significantly more than the judicial exception by providing an inventive concept.
Therefore, claims 46-86, when the limitations are considered individually and as a whole, are rejected
under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 46-48, 53, 57-58, 63, 67-68, 77-78, and 83 are rejected under 35 U.S.C. 103 as being unpatentable over Alberti et al. (bioRxiv (2018) 1-18), Voges et al. (Bioinformatics (2020) 2275–2277), and Song et al. (IEEE Visual Communications and Image Processing (VCIP) (2017) 1-4).
Claim 46 is directed to a method for decoding MPEG-G encoded data using machine learning and extracted parameters.
Claim 57 is directed to a method for encoding MPEG-G encoded data using machine learning and extracted parameters.
Claim 67 is directed to a system for decoding MPEG-G encoded data using machine learning and extracted parameters.
Claim 77 is directed to a system for encoding MPEG-G encoded data using machine learning and extracted parameters.
Alberti et al. teaches in the abstract “The MPEG-G standardization initiative is a coordinated international effort to specify a compressed data format that enables large scale genomic data to be processed, transported and shared. The standard consists of a set of specifications (i.e., a book) describing: i) a normative format syntax, and ii) a normative decoding process to retrieve the information coded in a compliant file or bitstream”, and on page 2, paragraph 6 “It should be clarified that the MPEG-G standard only specifies the decoder syntax and the algorithms necessary to extract information from files and streams encoded using MPEG-G”, reading on a method for decoding MPEG-G encoded data of genomic information, comprising receiving MPEG-G encoded data and a method for encoding MPEG-G encoded data of genomic information, as receiving and parsing this standardized bitstream is a routine data reception step. Alberti et al. teaches on page 13, paragraph 6-9 “In step 2 (value transformation) an optional (sequence of) transformation(s) is applied to the values produced by step 1. Some of the transformations generate additional data streams. Each of the resulting transformed subsequences is processed separately in steps 3 to 5. In step 3 (value binarization) the values in the different transformed subsequences are converted to a binarized representation (i.e., a set of bits). To allow for effective compression in step 5, the combination of transformation and binarization should be selected in such a way that the value of each bit of the binarization is as predictable as possible. The stream of binarizations serves as input for step 5. In step 4 (context selection) the context sets that will be used during the encoding step (step 5) are identified. Each context set contains the contexts required to encode one input value. The goal of the context selection step is to select the context set that is expected to resemble as much as possible the distribution of the bits in the binarized representations generated at step 3. The stream of selected contexts serves as support values for the entropy encoder in step 5. In step 5 (CABAC) the bins of the binarized representations generated at step 3 are encoded, using the context sets that have been selected in step 4 or in bypass mode, using a non-adaptive context that represents equiprobability”, reading on extracting encoding parameters from the encoded data and selecting arithmetic coding contexts based upon the extracted encoding parameters and receiving encoding parameters to be used to encode data, where encoding parameters specify how uncoded genomic information is to be encoded. Alberti et al. teaches on page 14, paragraph 2 “The normative decoding process includes all hierarchies of data structures, from the multiplexed bitstreams included in MPEG-G files or the data streams in streaming scenarios, to the descriptors Blocks and to the normative output. A simplified diagram of the decoding process is shown in Figure 6”, and in figure 6 “Simplified MPEG-G decoding process from a Data Unit to the normative output”, reading on decoding the encoded data using the selected predictor and the selected arithmetic coding contexts.
Alberti et al. does not teach extracting encoding parameters from the encoded data and selecting a predictor type from the extracted encoding parameters, which extracting encoding parameters from the encoded data specifies the method to obtain probabilities of symbols which were used for arithmetically encoding the data.
Voges et al. teaches on page 1, column 2, paragraph 2 “the compression process implemented by GABAC (and specified in the MPEG-G standard) consists of a five stage pipeline: input parsing, (optional) 3-step transformation, symbol binarization, context selection and CABAC. In the input parsing step, the descriptor stream is parsed into a stream of symbols. These symbols are then processed by the 3-step transformation stage that converts the symbol stream into one or more transformed sub streams. In the first transformation step, the input symbols are processed using one of the following three transformations (or no transformation, i.e. pass-through): (i) run-length coding, where a repeated symbol is replaced by the symbol itself and its run-length; (ii) match coding, an LZ77-style transformation and (iii) equality coding, where a symbol is replaced by a flag indicating equality with its predecessor and a correction symbol, if required. In the second transformation step, for each sub-stream separately, a look-up table transformation can be applied. Finally, in the third transformation step, one can choose to apply differential coding. For each transformed sub-stream, a binarization algorithm (used for conversion of each symbol into a bit string) is picked together with a context selection algorithm. In the last step, each bit of the binarization is combined with a context and both are processed using CABAC” reading on extracting encoding parameters from the encoded data and selecting a predictor type from the extracted encoding parameters, which extracting encoding parameters from the encoded data specifies the method to obtain probabilities of symbols which were used for arithmetically encoding the data and selecting a predictor type specifying the method to obtain probabilities of symbols which are used for arithmetically encoding the data based upon the received encoding parameters and wherein the encoded data comprises encoding parameters, which specify the method to obtain probabilities of symbols which were used for arithmetically encoding the data. Furthermore, it would have been obvious at the time of filing to have Modified prior art genomic encoders/decoders to parse additional parameters, as extracting headers to guide subsequent decoding is a fundamental requirement in data compression.
Alberti et al. and Voges et al. do not teach that “the predictor type may be selected from either a count-based predictor type or a machine learning predictor type.”
Song et al. teaches in the abstract “In this paper, we propose an arithmetic coding strategy by training neural networks, and make preliminary studies on coding of the intra prediction modes in HEVC. Instead of binarization, we propose to directly estimate the probability distribution of the 35 intra prediction modes with the adoption of a multi-level arithmetic codec. Instead of handcrafted context models, we utilize convolutional neural network (CNN) to perform the probability estimation”, on page 1, column 2, paragraph 2 “More recently, Toderici et al. proposed an image compression framework using combined CNN and recurrent neural network (RNN). That framework adopts an RNN to perform the entropy coding of the binary codes. These works indicate a promising approach to video coding by using neural networks to further improve the compression efficiency. Motivated by the recent works, we propose an arithmetic coding strategy by training neural networks instead of manually designing binarization and context models”, and on page 3, column 2, paragraph 2 “We use the deep learning framework TensorFlow2 to train the proposed CNN on an NVIDIA Tesla K40C graphical processing unit. The loss is minimized using the Adam algorithm. The training data are obtained from a subset of natural images coming from UCID, including 885 images with resolution 512×384. The other images in UCID are used for validation purpose. We use the abovementioned HM-intra N encoder to achieve training data for block size N. The quantization parameter (QP) is set to 32. After training, we use the trained CNN together with the HM-intra-N encoder to test the effectiveness of the proposed method. Test is performed according to HEVC common test conditions with all-intra configuration and QP equal to {22, 27, 32, 37}, on the HEVC common test sequences”, reading on the prediction type is one of count-based type and machine learning type; …… selected arithmetic coding contexts and training the encoder based upon the received encoding parameters; and encoding the data using the trained encoder.
It would have been obvious at the time of first filing to have modified the MPEG-G decoding systems of Alberti et al. and Voges et al. to allow selection between a count-based predictor and the machine-learning predictor taught by Song et al. Song et al. teaches that machine-learning predictors can replace traditional count-based probability estimation within arithmetic coding systems to improve coding efficiency (Abstract), and further teaches an arithmetic coding system in which symbol probabilities are generated either by conventional count/statistical context models or by machine-learning (neural network) predictors, with such predictors used during arithmetic decoding (Introduction; pg. 3, c2, middle). Because Voges et al.’s GABAC decoder already performs arithmetic decoding using context-adaptive probability models and already selects among arithmetic coding contexts during decoding (Introduction), and because Song et al. discloses machine-learning prediction as an alternative source of those same symbol probabilities, a PHOSITA would have recognized that configuring the combined Alberti/Voges decoder to select between the count-based predictor already taught by Voges et al. and the machine-learning predictor taught by Song et al. is nothing more than substituting one known probability-generation technique for another within the same, unchanged arithmetic-decoding framework. This proposed modification is well-founded because both count-based and machine-learning predictors were recognized, standard alternatives for generating symbol probabilities in arithmetic coding systems. Substituting one established probability estimation technique for another within the same arithmetic decoding framework yields highly predictable results. Also, a person having ordinary skill in the art would be motivated to make this modification to achieve the known benefits of improved coding efficiency and operational flexibility. Furthermore, taken together, Alberti et al., Voges et al., and Song et al. are all directed to the same field of genomic bitstream compression and decoding, and each performs its own discrete, known role – standardized bitstream reception and decoding (Alberti et al.), header/descriptor-based parameter extraction and context-adaptive arithmetic decoding (Voges et al.), and machine-learning-based symbol-probability prediction as an alternative to count-based prediction (Song et al.) as each reference already discloses. Therefore, this modification represents merely the simple substitution of one known element for another, and the combination of known elements performing their known functions, to obtain the predictable result of a decoding method that receives MPEG-G encoded data, extracts encoding parameters, selects between a count-based or machine-learning predictor type, selects arithmetic coding contexts, and decodes the data accordingly, rendering the combination unpatentable.
Claim 47 is directed to the method of claim 46 but further specifies that the encoding type is one of binary coding and multi-symbol coding.
Claim 58 is directed to the method of claim 57 but further specifies that the encoding type is one of binary coding and multi-symbol coding.
Claim 68 is directed to the system of claim 67 but further specifies that the encoding type is one of binary coding and multi-symbol coding.
Claim 78 is directed to the system of claim 77 but further specifies that the encoding type is one of binary coding and multi-symbol coding.
Voges et al. teaches in the abstract “This paper discusses the first implementation of an MPEG-G compliant entropy codec: GABAC. GABAC combines proven coding technologies, such as context-adaptive binary arithmetic coding, binarization schemes and transformations, into a straightforward solution for the compression of sequencing data”.
Song et al. teaches in the abstract “we propose an arithmetic coding strategy by training neural networks, and make preliminary studies on coding of the intra prediction modes in HEVC. Instead of binarization, we propose to directly estimate the probability distribution of the 35 intra prediction modes with the adoption of a multi-level arithmetic codec. Instead of handcrafted context models, we utilize convolutional neural network (CNN) to perform the probability estimation. Simulation results show that our proposed arithmetic coding leads to as high as 9.9% bits saving compared with CABAC” which in view of Voges et al. reads on an arithmetic encoding type is one of binary coding and a multi-symbol coding.
Claim 48 is directed to the method of claim 46 but further specifies the predictor type is a neural network.
Song et al. teaches in the abstract “In this paper, we propose an arithmetic coding strategy by training neural networks, and make preliminary studies on coding of the intra prediction modes in HEVC. Instead of binarization, we propose to directly estimate the probability distribution of the 35 intra prediction modes with the adoption of a multi-level arithmetic codec. Instead of handcrafted context models, we utilize convolutional neural network (CNN) to perform the probability estimation”, reading on the predictor type is a neural network.
Claim 53 is directed to the method of claim 46 but further specifies that the encoded parameters included context data.
Claim 63 is directed to the method of claim 57 but further specifies that the encoded parameters included context data.
Claim 83 is directed to the method of claim 77 but further specifies that the encoded parameters included context data.
Voges et al. teaches in the abstract “This paper discusses the first implementation of an MPEG-G compliant entropy codec: GABAC. GABAC combines proven coding technologies, such as context-adaptive binary arithmetic coding, binarization schemes and transformations, into a straightforward solution for the compression of sequencing data”, on page 1, column 1, paragraph 2 “GABAC combines proven coding technologies, such as context-adaptive binary arithmetic coding (CABAC) (Marpe et al.,2003), binarization schemes and transformations, into a straightforward solution for the com pression of sequencing data”, and page 1, column 2, paragraph 1 “is to represent genomic information by splitting the data into a set of homogeneous descriptor streams, each containing one specific type of data (e.g. mapping positions, quality scores, mismatch information, etc.). Each stream is more likely to contain stationary data, enabling a more effective data compression, as redundancies are more probable and value distributions are more predictable. Given an input stream, the compression process implemented by GABAC (and specified in the MPEG-G standard) consists of a five stage pipeline: input parsing, (optional) 3-step transformation, symbol binarization, context selection and CABAC. In the input parsing step, the descriptor stream is parsed into a stream of symbols. These symbols are then processed by the 3-step transformation stage that converts the symbol stream into one or more transformed sub streams”, reading on the extracted encoding parameters includes context data.
Claims 49, 59, 69, and 79 are rejected under 35 U.S.C. 103 as being unpatentable over Alberti et al. (bioRxiv (2018) 1-18), Voges et al. (Bioinformatics (2020) 2275–2277), and Song et al. (IEEE Visual Communications and Image Processing (VCIP) (2017) 1-4) as applied to the claims 46-48, 53, 57-58, 63, 67-68, 77-78, and 83 and above and further in view of Bourdev et al. (US 11256984 B2)
Claim 49 is directed to the method of claim 46 but further specifies that the predictor type identifies a machine learning model, and the encoding parameters include a definition of the machine learning model.
Claim 59 is directed to the method of claim 57 but further specifies that the predictor type identifies a machine learning model, and the encoding parameters include a definition of the machine learning model.
Claim 69 is directed to the system of claim 67 but further specifies that the predictor type identifies a machine learning model, and the encoding parameters include a definition of the machine learning model.
Claim 79 is directed to the system of claim 77 but further specifies that the predictor type identifies a machine learning model, and the encoding parameters include a definition of the machine learning model.
Alberti et al., Voges et al., and Song et al. teach the method and system of claims 46-48, 53, 57-58, 63, 67-68, 77-78, and 83.
Alberti et al., Voges et al., Song et al. do not teach when a machine-learning predictor is used, the encoded bitstream includes information (encoding parameters) defining the machine-learning model used by the decoder.
Bourdev et al. teaches in the abstract “A machine learning (ML) task system trains a neural network model that learns a compressed representation of acquired data and performs a ML task using the compressed representation. The neural network model is trained to generate a compressed representation that balances the objectives of achieving a target codelength and achieving a high accuracy of the output of the performed ML task. During deployment, an encoder portion and a task portion of the neural network model are separately deployed. A first system acquires data, applies the encoder portion to generate a compressed representation, performs an encoding process to generate compressed codes, and transmits the compressed codes. A second system regenerates the compressed representation from the compressed codes and applies the task model to determine the output of a ML task”, in claim 1 “a data compression system comprising: a data acquisition module coupled to acquire data; an encoder portion of a neural network coupled to the data acquisition module to encode the acquired data into a compressed representation”, in paragraph [0031]-[0038] “Referring to the flow process shown in FIG. 2, the encoder model 140 receives acquired data 250 of a training example. Acquired data 250 can be one of an image, video, data file, text file, dataset, and the like. In various embodiments, the encoder model 140 performs a feature extraction process that identifies features of the acquired data 250 that are informative for the ML task. The encoder model 140 generates a compressed representation 210 of the acquired data 250. Generally, the compressed representation 210 represents the acquired data 250 with respect to the structural features of the acquired data 250”, and in paragraph [0043] “The loss feedback module 170 calculates the task loss 265 by comparing the predicted ML task output 275 and a ML task output label 255 of the training example. As stated above, the task loss 265 represents one component of the loss function that is used to train the encoder model 140 and decoder model 150. Examples of loss functions that can be employed by the loss feedback module 170 to calculate the task loss 265 can include a square loss function, hinge loss function, logistic loss function, and cross entropy loss function”, thus enabling the decoder to reconstruct or instantiate the same machine learning model used during encoding. These above references recognize that a decoder must know which machine learning model to use in order to perform proper decoding reading on when the predictor type identifies a machine learning model, the encoding parameters further include a definition of the machine learning model. The cited machine learning-learning compression prior art by Bourdev et al. teaches transmitting machine learning model definitions, model identifiers, architecture information, or model parameters in encoded data so that a decoder can reconstruct and utilize the same model used during encoding.
It would have been obvious at the time of first filing to modify the Voges and Song MPEG-G decoder to explicitly include model-definition data within the encoding parameters. Voges et al. teaches decoding MPEG-G encoded genomic information using arithmetic decoding and context-adaptive probability models, including selection and use of arithmetic coding contexts during decoding (Introduction), and Song et al. teaches that a machine-learning (neural network) predictor may be selected, as an alternative to a conventional count-based predictor, to generate the symbol probabilities used during arithmetic decoding (Abstract; Introduction; pg. 3, c2, middle). Neither reference, however, teaches what information must accompany the bitstream so that a decoder can actually reconstruct the particular machine-learning model the encoder used. Bourdev et al. directly supplies this missing teaching, disclosing encoding data using machine-learning models (Abstract; claim 1) and transmitting model-identification information, model parameters, model architecture information, or model definitions to a decoder (paragraphs 0031, 0045, 0051, 0055), thereby enabling the decoder to reconstruct or instantiate the same machine-learning model used during encoding. This ensures encoder-decoder synchronization, a fundamental requirement for any machine-learning-based coding system, because a decoder cannot correctly generate symbol probabilities with Song et al.’s machine-learning predictor unless it first knows the specific predictor model used by the encoder, as Bourdev et al. already recognizes. To a PHOSITA the modification was obvious because A) machine-learning predictors cannot function properly without alignment between encoder and decoder. A decoder using Song et al.’s machine-learning predictor requires the exact identity and definition of the predictor used by the encoder, which is the information Bourdev et al. teaches transmitting as model-identification information, model parameters, model architecture information, or model definitions (paragraphs 0031, 0045, 0051, 0055) B) transmitting model-definition information through encoded parameters was a well-established and predictable practice for maintaining encoder-decoder synchronization, as evidenced by Bourdev et al.’s disclosure of encoding data using machine-learning models and transmitting the corresponding model information to the decoder (Abstract; claim 1; paragraphs 0031, 0045, 0051, 0055), and is directly analogous to Voges et al.’s own disclosure of transmitting headers and stream descriptors that define how MPEG-G data was compressed (pg. 1, c2, bottom). A PHOSITA would have taken the known technique of embedding model-defining parameters into a bitstream, as taught by Bourdev et al., and integrated it directly into the encoding parameters of the Voges and Song decoder, which extracts and uses encoding parameters (including predictor-type information) to guide decoding. Because Bourdev et al.’s model-definition data is the same general type of parameter information that Voges et al. already teaches transmitting and extracting via headers and stream descriptors (pg. 1, c2, bottom), a PHOSITA would have had a reasonable expectation that adding Bourdev et al.’s model-identification and model-parameter data to that same parameter set would succeed in enabling the decoder to reconstruct the specific machine-learning model selected by Song et al.’s predictor-type selection, as Bourdev et al. already discloses. This adaptation applies a recognized synchronization technique, disclosed by Bourdev et al., to an analogous decoding environment already disclosed by Alberti et al., Voges et al., and Song et al., yielding the expected and predictable result of properly decoding the encoded data, including reconstruction of the correct machine-learning model, without requiring inventive effort (MPEP 2143, 2144).
Claims 50-52, 56, 60-62, 66, 70-73, 76, 80-82, and 86 are rejected under 35 U.S.C. 103 as being unpatentable over Alberti et al. (bioRxiv (2018) 1-18), Voges et al. (Bioinformatics (2020) 2275–2277), and Song et al. (IEEE Visual Communications and Image Processing (VCIP) (2017) 1-4) as applied to the claims 46-48, 53, 57-58, 63, 67-68, 77-78, and 83 above and further in view of Mentzer et al. (Proceedings of the IEEE/CVF conference on computer vision and pattern recognition (2019) 10629- 10638) and Marpe et al. (IEEE Transactions on circuits and systems for video technology (2003) 620-636).
Claim 50 is directed to the method of claim 46 but further specifies that the encoding parameters include the specified data.
Claim 60 is directed to the method of claim 57 but further specifies that the encoding parameters include the specified data.
Claim 70 is directed to the system of claim 67 but further specifies that the encoding parameters include the specified data.
Claim 80 is directed to the system of claim 77 but further specifies that the encoding parameters include the specified data.
Alberti et al., Voges et al., and Song et al. teach the method and system of claims 46-48, 53, 57-58, 63, 67-68, 77-78, and 83.
Alberti et al., Voges et al., and Song et al. does not teach the extracted encoding parameters includes training mode data, which specifies how the model for predicting probabilities of symbols which are arithmetically encoded varies over time in the decoding.
Mentzer et al. teaches in the abstract “At the core of our method is a fully parallelizable hierarchical probabilistic model for adaptive entropy coding which is optimized end-to-end for the compression task. In contrast to recent autoregressive discrete probabilistic models such as PixelCNN, our method i) models the image distribution jointly with learned auxiliary representations instead of exclusively modeling the image distribution in RGB space, and ii) only requires three forward-passes to predict all pixel probabilities instead of one for each pixel”, on page 1, column 1, paragraph 1 “This is not surprising as (lossless) entropy coding using likelihood-based discrete generative models amounts to a decoding complexity essentially identical to the sampling complexity of the model, which renders many of the recent state-of-the-art autoregressive models such as PixelCNN, PixelCNN++, and Multiscale-PixelCNN impractical, requiring minutes or hours on a GPU to generate moderately large images, typically <256 × 256px (see Table 2)… In this paper, we address these challenges and develop a fully parallelizable learned lossless compression system, outperforming the popular classical systems”, on page 7, column 2, paragraph “While PixelCNN-based approaches are not designed for lossless image compression, they learn a probability distribution over pixels and optimize for the same log-likelihood objective”, on page 8, column 1, paragraph 2 “To encode/decode images with L3C (and other methods outputting a probability distribution), a pass with an entropy coder is needed. We implemented a relatively simple pipeline to encode and decode images with L3C, which we describe in the supplementary material, in Section A.2. The results are shown in Tables 4 and A1. As noted in Section A.2, we did not optimize our code for speed, yet still obtain practical runtimes. We also note that to use other likelihood-based methods for lossless compression, similar steps are required”, on page 11, column 2, paragraph 4 “In practice, the division into intervals [a,b) required for arithmetic coding described in Sec. 3.1 is most efficiently done by having access to the cumulative distribution function (CDF) of the symbol to encode. Thus, for the RGB scale (s = 0), we obtain the CDF analogously to Eq. (6)…”, on page 12, column 1, paragraph 5 “To save the expensive copying from GPU to CPU, we implemented our own CUDA kernel to store the calculated C directly into “managed memory”, which can be accessed from both CPU and GPU. However, we did not optimize this CUDA kernel for speed. Finally, while state-of-the-art adaptive entropy coders typically require on the order of milliseconds per MB (see[13] and in particular [14] for bench marks on adaptive entropy coding),we implemented a simple arithmetic coding module to obtain the times in our tables”, and in Figure A4 “Visualizing encoding and decoding: At every step, the arithmetic coder (AC) takes a probability distribution and a z(s)”, thus recognizing that probability models may be updated or adapted during coding and decoding, reading on “predicting probabilities of symbols which are arithmetically encoded varies over time in the decoding.”
Marpe at al. teaches in the abstract “Context-Based Adaptive Binary Arithmetic Coding (CABAC) as a normative part of the new ITU-T/ISO/IEC standardH.264/AVC for video compression is presented. By combining an adaptive binary arithmetic coding technique with context modeling, a high degree of adaptation and redundancy reduction is achieved. The CABAC framework also includes a novel low-complexity method for binary arithmetic coding and probability estimation that is well suited for efficient hardware and software implementations”, on page 2, column 2, paragraph 5 “In the so-called regular coding mode, prior to the actual arithmetic coding process the given binary decision which, in the sequel, we will refer to as a bin, enters the context modeling stage, where a probability model is selected such that the corresponding choice may depend on previously encoded syntax elements or bins. Then, after the assignment of a context model the bin value along with its associated model is passed to the regular coding engine, where the final stage of arithmetic encoding together with a subsequent model updating takes place”, and on page 5, column 1, paragraph 2 “Both the second and third concatenated scheme are derived from the TU and the EGk binarization. These schemes, which are referred to as Unary/ th order Exp-Golomb (UEGk) binarizations, are applied to motion vector differences and absolute values of transform coefficient levels. The design of these concatenated binarization schemes is motivated by the following observations. First, the unary code is the simplest prefix-free code in terms of implementation cost. Secondly, it permits a fast adaptation of the individual symbol probabilities in the sub sequent context modeling stage, since the arrangement of the nodes in the corresponding tree is typically such that with increasing distance of the internal nodes from the root node the corresponding binary probabilities are less skewed… for larger values, the EGk suffix part represents already a fairly good fit to the observed probability distribution, as already mentioned above. Thus, it is reasonable to speedup the encoding of the bins related to the EGk suffix part in CABAC by using the fast bypass coding engine for uniformly distributed bins, as further described in Section III-D”, thus, adaptive arithmetic coders routinely convey information indicating whether probability models remain fixed or adapt continuously or adapt according to selected update schedules.
It would have been obvious at the time of first filing to combine these elements. Song et al. teaches that a machine-learning (neural network) predictor may be selected as an alternative to a conventional count-based predictor to generate the symbol probabilities used during arithmetic decoding (Abstract; Introduction; pg. 3, c2, middle), but does not teach that the extracted encoding parameters include training mode data specifying how that predictor’s probability model varies over time during decoding. Mentzer et al. fills this gap, teaching neural-network probability models for entropy coding (pg. 1, c1, bottom; pg. 7, c1, bottom), transmission of coding configuration information (pg. 7, c2, middle; pg. 8, c1, middle), adaptive probability estimation (pg. 11, c2, middle; pg. 12, c1, bottom), and encoder/decoder synchronization of learned probability models (pg. 8, c1, middle; Figure A4). Marpe et al. independently confirms that this type of training/adaptation information is a standard, component of adaptive entropy coding, teaching adaptive probability models (Abstract), model update during decoding (pg. 2, c2, bottom; Figure 2), and coding mode indicators that control adaptation behavior (pg. 5, c1, middle) – specifically, that adaptive arithmetic coders routinely convey information indicating whether probability models remain fixed, adapt continuously, or adapt according to selected update schedules. In adaptive entropy coding, communicating model updates is a fundamental requirement to maintain encoder-decoder synchronization, so adapting Song et al.’s machine-learning predictor with Mentzer et al.’s and Marpe et al.’s techniques merely constitute a predictable combination yielding expected results. Because the combination of these familiar elements relies on known methods to do no more than their ordinary functions, the resulting system would have produced entirely predictable results. A PHOSITA would have possessed the technical skill to implement this variation and would have had a reasonable expectation of success in achieving encoder-decoder synchronization, consistent with the MPEP 2143, 2144 and KSR rationale that combining familiar elements according to known methods to yield predictable results.
Claim 51 is directed to the method of claim 50, and thus claim 46, but further specifies the data including an initializing type that includes the specified information.
Claim 61 is directed to the method of claim 60, and thus claim 57, but further specifies the data including an initializing type that includes the specified information.
Claim 71 is directed to the system of claim 70, and thus claim 67, but further specifies the data including an initializing type that includes the specified information.
Claim 81 is directed to the system of claim 80, and thus claim 77, but further specifies the data including an initializing type that includes the specified information.
Alberti et al., Voges et al., and Song et al. teach the method and system of claims 46-48, 53, 57-58, 63, 67-68, 77-78, and 83.
Alberti et al., Voges et al., and Song et al. do not teach initialization type that includes one of a static training mode, semi-adaptive training mode, and adaptive training mode.
Voges et al. teaches MPEG-G decoding using arithmetic coding and extracted coding parameters.
Song et al. teaches the use of machine-learning predictors for generating symbol probabilities used during arithmetic decoding.
Marpe at al. teaches on page 13, column 1, paragraph 1 “The derivation of the transition rules for the LPS probability is based on the following relation between a given LPS probability pold and its updated counterpart pnew”, on page 2, column 1, “In our prior work on wavelet-based hybrid video coding, which led to one of the proposals for the H.26L standardization, the entropy coding method of partitioning, aggregation and conditional coding (PACC) was developed. One of its main distinguishing features is related to the partitioning strategy: Given a source with a specific alphabet size, for instance, quantized transform coefficients, it was found to be useful to first reduce the alphabet size by partitioning the range according to a binary selector which, e.g., in the case of transform coefficients, would be typically given by the decision whether the coefficient is quantized to zero or not. In fact, range partitioning using binary selectors can be viewed as a special case of a binarization scheme, where a symbol of a nonbinary alphabet is uniquely mapped to a sequence of binary decisions prior to further processing”, and page 1, column 2, “Although, from a conceptual point-of-view, it is well known for a long time that all these deficiencies can be most easily resolved by arithmetic codes [23], little of this knowledge was actually translated into practical entropy coding schemes specifically designed for block-based hybrid video coding. One of the first hybrid block-based video coding schemes that incorporate an adaptive binary arithmetic coder capable of adapting the model probabilities to the existing symbol statistics was presented in [6]. The core of that entropy coding scheme was inherited from the JPEG standard (at least for coding of DCT coefficients) [25], and an adjustment of its modeling part to the specific statistical characteristics of typically observed residual data in a hybrid video coder was not carried out”, thus, Marpe et al. teaches probability-model operating modes including fixed and adaptive probability-state initialization and updating, adaptive modeling approaches in which probability models may remain fixed, be selectively updated, or be continuously updated during decoding, and Marpe et al. explains that coding systems may select among different adaptation behaviors depending upon coding objectives suggesting the limitation of “the training mode data includes an initialization type that includes one of a static training mode, semi-adaptive training mode, and adaptive training mode.”
Claim 52 is directed to the method of claim 50, and thus claim 46, but further specifies the training data includes the specified data.
Claim 62 is directed to the method of claim 60, and thus claim 57, but further specifies the training data includes the specified data.
Claim 72 is directed to the system of claim 70, and thus claim 67, but further specifies the training data includes the specified data.
Claim 82 is directed to the system of claim 80, and thus claim 77, but further specifies the training data includes the specified data.
Alberti et al., Voges et al., and Song et al. teach the method and system of claims 46-48, 53, 57-58, 63, 67-68, 77-78, and 83.
Voges et al. teaches MPEG-G decoding using in which encoding parameters are extracted from a compressed bitstream and used to configure arithmetic decoding operations.
Song et al. teaches the use of machine-learning predictors including neural-network predictors, for generating symbol probabilities used during arithmetic decoding.
Alberti et al., Voges et al., and Song et al. do not teach the training mode data includes one of a training algorithm definition, training algorithm parameters, training frequency, and training epochs.
Mentzer et al. teaches in the abstract “At the core of our method is a fully parallelizable hierarchical probabilistic model for adaptive entropy coding which is optimized end-to-end for the compression task. In contrast to recent autoregressive discrete probabilistic models such as PixelCNN, our method i) models the image distribution jointly with learned auxiliary representations instead of exclusively modeling the image distribution in RGB space, and ii) only requires three forward-passes to predict all pixel probabilities instead of one for each pixel”, on page 1, column 1, paragraph 1 “This is not surprising as (lossless) entropy coding using likelihood-based discrete generative models amounts to a decoding complexity essentially identical to the sampling complexity of the model, which renders many of the recent state-of-the-art autoregressive models such as PixelCNN, PixelCNN++, and Multiscale-PixelCNN impractical, requiring minutes or hours on a GPU to generate moderately large images, typically <256 × 256px (see Table 2)… In this paper, we address these challenges and develop a fully parallelizable learned lossless compression system, outperforming the popular classical systems”, on page 7, column 2, paragraph “While PixelCNN-based approaches are not designed for lossless image compression, they learn a probability distribution over pixels and optimize for the same log-likelihood objective”, on page 8, column 1, paragraph 2 “To encode/decode images with L3C (and other methods outputting a probability distribution), a pass with an entropy coder is needed. We implemented a relatively simple pipeline to encode and decode images with L3C, which we describe in the supplementary material, in Section A.2. The results are shown in Tables 4 and A1. As noted in Section A.2, we did not optimize our code for speed, yet still obtain practical runtimes. We also note that to use other likelihood-based methods for lossless compression, similar steps are required”, on page 11, column 2, paragraph 4 “In practice, the division into intervals [a,b) required for arithmetic coding described in Sec. 3.1 is most efficiently done by having access to the cumulative distribution function (CDF) of the symbol to encode. Thus, for the RGB scale (s = 0), we obtain the CDF analogously to Eq. (6)…”, on page 12, column 1, paragraph 5 “To save the expensive copying from GPU to CPU, we implemented our own CUDA kernel to store the calculated C directly into “managed memory”, which can be accessed from both CPU and GPU. However, we did not optimize this CUDA kernel for speed. Finally, while state-of-the-art adaptive entropy coders typically require on the order of milliseconds per MB (see[13] and in particular [14] for bench marks on adaptive entropy coding),we implemented a simple arithmetic coding module to obtain the times in our tables”, and in Figure A4 “Visualizing encoding and decoding: At every step, the arithmetic coder (AC) takes a probability distribution and a z(s)”. The cited machine learning compression references (Mentzer et al.) teach communicating machine-learning model configuration information, including training procedures, update schedule, learning parameters, retaining intervals, and optimization settings, demonstrating that entropy coding systems using machine learning require model-related metadata to ensure decoder operation, thereby reading on “training mode data includes one of a training algorithm definition, training algorithm parameters, training frequency, and training epochs.”
Claim 73 is directed to the system of claim 70, and thus claim 67, but further specifies that the encoded parameters included context data.
Voges et al. teaches in the abstract “This paper discusses the first implementation of an MPEG-G compliant entropy codec: GABAC. GABAC combines proven coding technologies, such as context-adaptive binary arithmetic coding, binarization schemes and transformations, into a straightforward solution for the compression of sequencing data”, on page 1, column 1, paragraph 2 “GABAC combines proven coding technologies, such as context-adaptive binary arithmetic coding (CABAC) (Marpe et al.,2003), binarization schemes and transformations, into a straightforward solution for the com pression of sequencing data”, and page 1, column 2, paragraph 1 “is to represent genomic information by splitting the data into a set of homogeneous descriptor streams, each containing one specific type of data (e.g. mapping positions, quality scores, mismatch information, etc.). Each stream is more likely to contain stationary data, enabling a more effective data compression, as redundancies are more probable and value distributions are more predictable. Given an input stream, the compression process implemented by GABAC (and specified in the MPEG-G standard) consists of a five stage pipeline: input parsing, (optional) 3-step transformation, symbol binarization, context selection and CABAC. In the input parsing step, the descriptor stream is parsed into a stream of symbols. These symbols are then processed by the 3-step transformation stage that converts the symbol stream into one or more transformed sub streams”, reading on the extracted encoding parameters includes context data.
Claim 56 is directed to the method of claim 53, and thus claim 46, but further specifies that the context data include at least one of the specified data.
Claim 66 is directed to the method of claim 62, and thus claim 57, but further specifies that the context data include at least one of the specified data.
Claim 76 is directed to the system of claim 73, and thus claim 67, but further specifies that the context data include at least one of the specified data.
Claim 86 is directed to the system of claim 83, and thus claim 77, but further specifies that the context data include at least one of the specified data.
Alberti et al. in view of Voges et al., Song et al., Mentzer et al. and Marpe et al. do not teach the context data including a context descriptor, context output variable, context internal variable, context computed variable, and context computation function.
Voges et al. teaches MPEG-G decoding using context-adaptive arithmetic coding and extraction of context-related coding parameters.
Marpe et al. teaches on page 13, column 2, paragraphs 2-3 “Actually, the CABAC coding engine consists of two sub-engines, one for the regular coding mode, which includes the utilization of adaptive probability models, and another so-called “bypass” coding engine for a fast encoding of symbols, for which an approximately uniform probability is assumed to be given…The internal state of the arithmetic encoding engine is as usual characterized by two quantities: the current interval range and the base (lower endpoint) of the current code interval. Note, however, that the precision needed to store these registers in the CABAC engine (both in regular and bypass mode) can be reduced up to 9 and 10 bits, respectively”, on page 4, column 2, paragraph 2 “Even for a zero-order model, the task of tracking 255 individual probability estimates according to the previous example is quite demanding. However, typically measured probability density functions (pdf) of prediction residuals or transformed prediction errors can be modeled by highly peaked Laplacian, generalized Gaussian or geometric distributions [28], where it is reasonable to restrict the estimation of individual symbol statistics to the area of the largest statistical variations at the peak of the pdf”, on page 13, column 1, paragraph 1 “The derivation of the transition rules for the LPS probability is based on the following relation between a given LPS probability pold and its updated counterpart pnew…With regard to a practical implementation of the probability estimation process in CABAC, it is important to note that all transition rules can be realized by at most two tables each having 63 entries of 6-bit unsigned integer values”, in the abstract “Context-Based Adaptive Binary Arithmetic Coding (CABAC) as a normative part of the new ITU-T/ISO/IEC standardH.264/AVC for video compression is presented. By combining an adaptive binary arithmetic coding technique with context modeling, a high degree of adaptation and redundancy reduction is achieved. The CABAC framework also includes a novel low-complexity method for binary arithmetic coding and probability estimation that is well suited for efficient hardware and software implementations”, and furthermore, teaches context models that include context-states, probability variables, state-transition functions, and context-initialization reading on the context data includes one of a context descriptor, context output variable, context internal variable, context computed variable, and context computation function.
Claim 54-55, 64-65, 74-75, and 84-85 are rejected under 35 U.S.C. 103 as being unpatentable over Alberti et al. (bioRxiv (2018) 1-18), Voges et al. (Bioinformatics (2020) 2275–2277), Song et al. (IEEE Visual Communications and Image Processing (VCIP) (2017) 1-4), Mentzer et al. (Proceedings of the IEEE/CVF conference on computer vision and pattern recognition (2019) 10629- 10638), and Marpe et al. (IEEE Transactions on circuits and systems for video technology (2003) 620-636) as applied to the claims 46-48, 50-53, 56, 60-63, 66-68, 70-73, 76-78, 80-83, and 86 above and further in view of Witten et al. (Communications of the ACM (1987) 520-540) and Howard et al. (Proceedings of the IEEE (1994) 857-865)
Claim 54 is directed to the method of claim 53, and thus claim 46, but further specifies that the context data includes the specified data.
Claim 64 is directed to the method of claim 62, and thus claim 57, but further specifies that the context data includes the specified data.
Claim 74 is directed to the system of claim 73, and thus claim 67, but further specifies that the context data includes the specified data.
Claim 84 is directed to the system of claim 83, and thus claim 77, but further specifies that the context data includes the specified data.
Alberti et al., Voges et al., Song et al., Mentzer et al., and Marpe et al. teach the claims 46-48, 50-53, 56, 60-63, 66-68, 70-73, 76-78, 80-83, and 86.
Voges et al. teaches MPEG-G decoding using context-adaptive arithmetic coding and extraction of context-related coding parameters.
Marpe et al. teaches context-model configuration information including context classes, multiple context models, context-initialization information, and context-state ranges used during arithmetic decoding.
Alberti et al., Voges et al., Song et al., Mentzer et al., and Marpe et al. do not teach the context data includes one of a coding order, number of additional contexts used, context type, and range.
Witten et al. teaches on page 13, column 1, paragraphs 1, and 3 “It is advantageous to sort the model into frequency order, so as to minimize the number of executions of the decoding loop (line 189). To permit such reordering, the char/index translation is implemented as a pair of tables, index-to-char and char-to-index. In one of our models, these tables simply form the index by adding 1 to the char, but another implements a more complex translation that assigns small indexes to frequently used symbols… Unlike Figure 2 the program in Figure 3 represents low and high as integers. A special data type, code_value, is defined for these quantities, together with some useful constants”, on page 13, column 2, paragraph 2 “Incremental reception is done using a number called value as in Figure 2, in which processed bits flow out the top (high-significance) end and newly received ones flow in the bottom”, on page 20, column 1, paragraph 1 “The template contained a total of 10 pixels, selected from those above and to the left of the current one so that they precede it in the raster scan. This creates 1024 different possible contexts, and for each the probability of the pixel being black was estimated adaptively as the picture was transmitted”, on page 2, column 2, paragraph 3 “In arithmetic coding, a message is represented by an interval of real numbers between 0 and 1… Before anything is transmitted, the range for the message is the entire interval [0, l)”, and a central parameter of PPM systems is the context order and context range, which correspond to the claimed limitation of “coding order” and “context range. The reference therefore, establishes that context metadata commonly includes: context type, context order, context image and number of contexts, thereby reading on wherein the context data includes one of a coding order, number of additional contexts used, context type, and range.
It would have been obvious at the time of first filing to integrate the context parameters of Witten et al. and Howard et al. into the MPEG-G framework of Voges et al. and Marpe et al. This is because combining these established coding descriptors utilizes known techniques to yield predictable results in standard entropy coding. Witten et al. and Howard et al. teach conventional descriptors for context-based entropy coding systems, specifically identifying context parameters such as coding order (pg. 13, c1, top, bottom; pg. 13, c2, middle), context hierarchy (pg. 20, top), context range (pg. 2, c2, middle, bottom), and, per Howard et al., the number of contexts used to configure a practical arithmetic-coding implementation (Introduction). These context-model configuration parameters were standard knowledge in the field prior to the effective filing date, confirmed independently by both Witten et al.’s context-modeling reference and Howard et al.’s practical arithmetic-coding implementation. A PHOSITA would recognize their utility and incorporate them into the MPEG-G decoder of Voges et al. and Marpe et al. without undue experimentation. The proposed modification functions as intended. Incorporating these known descriptors – coding order, number of contexts, context type, and range, as taught by Witten et al. and confirmed by Howard et al. – simply tailors the configuration parameters already used by Voges et al. and Marpe et al. to the decoding framework, producing a predictable and expected improvement in the efficiency of the context model. Therefore, it would have been obvious at the time of first filing to have modified the teachings of each and to be successful.
Claim 55 is directed to the method of claim 53, and thus claim 46, but further specifies that the context data includes the specified data.
Claim 65 is directed to the method of claim 62, and thus claim 57, but further specifies that the context data includes the specified data.
Claim 75 is directed to the system of claim 73, and thus claim 67, but further specifies that the context data includes the specified data.
Claim 85 is directed to the system of claim 83, and thus claim 77, but further specifies that the context data includes the specified data.
Alberti et al., Voges et al., Song et al., Mentzer et al., and Marpe et al. teach the claims 46-48, 50-53, 56, 60-63, 66-68, 70-73, 76-78, 80-83, and 86.
Alberti et al. in view of Voges et al., Song et al., Mentzer et al. and Marpe et al. do not teach the context data includes a range flag.
Witten et al. teaches on page 2, column 2, paragraph 3 “In arithmetic coding, a message is represented by an interval of real numbers between 0 and 1… Before anything is transmitted, the range for the message is the entire interval [0, l)”, it would have been obvious to incorporate a range flag in the data as you already have a defined range, so ensuring your value falls within the acceptable range would be a necessary precursor step to processing (i.e. pre-processing), and a flag within the data would make this easy to process, thereby reading on wherein the context data includes a range flag.
Conclusion
No claims are allowed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEENAN NEIL ANDERSON-FEARS whose telephone number is (571)272-0108. The examiner can normally be reached M-Th, alternate F, 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Karlheinz Skowronek can be reached at 571-272-9047. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.N.A./ Examiner, Art Unit 1687
/LARRY D RIGGS II/ Supervisory Patent Examiner, Art Unit 1686
