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 .
Allowable Subject Matter
Claims 10 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 103
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.
Claims 1, 3-8, 11 and 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over Bostick (US PG Pub 20160062965) in view of Ramam et al. (US Patent 9,477,836; hereinafter “Ramam”).
As per claims 1 and 11, Bostick discloses:
A method of mojibake detection and correction, and a mojibake detection and correction engine, comprising: one or more processors (Bostick; Fig. 1, item 304; p. 0046); and one or more storage devices storing instructions that are configured, when executed by the one or more processors, to cause the one or more processors to perform operations (Bostick; Fig. 3, items 306 & 308; p. 0047 - Memory 306 and persistent storage 308 are computer-readable storage media; p. 0053 - The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention) comprising: reading a string of characters from storage (Bostick; Fig. 2, item 205; p. 0027 - To identify mojibake and missing characters document processing program 115 accesses document repository 117, selects and retrieves a document to be processed…); detecting mojibake characters in the string of characters (Bostick; Fig. 2, item 205; p. 0027 - Entries in the document that are not matched to entries of that code page are identified by processing program 115 as mojibake. These instances of mojibake are logged by processing program 115 as code page errors and saved as part of document repository 117; see also 0029 - document processing program 115 determines whether the document includes mojibake and/or missing characters based on the results of the initial programmatic investigation…); determining a character text encoding mismatch between two text encoding standards that caused the mojibake characters in the string of characters (Bostick; p. 0030 - document processing program 115 determines whether the document has been saved using an incorrect code page (character text encoding mismatch) based on the presence of mojibake within the document…); determining remaining mojibake characters in the string of characters and implementing a character prediction mojibake correction process to replace each of the remaining mojibake characters in the string of characters with a respective predictive corrected character (Bostick; p. 0042-0043 - In process 230, document processing program 115 replaces missing characters with the document. Document processing program 115 accesses the most recently updated version of the document included in document repository 117 and applies probabilistic modeling (character prediction) using a confusion matrix, included in library 119, to determine what the best probable character is to substitute for a given missing character); and searching the string of characters for a set of known mistranslations and, in response to determination that the string of characters contains one of the known mistranslations of the set of known mistranslations, replacing the one of the known mistranslations in the string of characters with a corrected translation (Bostick; p. 0038 - In this embodiment, in process 225, document processing program 115 identifies a code page to be applied to the document based on a comparison between the logged mojibake of the document and known patterns of mojibake, which are included as part of library 119. If there is a pattern match, then document processing program 115 determines that the document has been saved using the wrong code page. For example, a document created using code page “AE” is known to generate a mojibake replacing the letter combination “pp” with “(?)” if that document is read using code page “AG”. In other words, a document created using code page “AE” is known to generate a type of mojibake, if that document is read using code page “AG”).
Bostick, however, fails to disclose implementing a reverse byte mapping process using the two text encoding standards as a first level of mojibake correction on the string of characters. Additionally, Bostick fails to disclose that every process of the recited three processes of mojibake correction is performed one after the other, in a sequential manner. Ramam does teach implementing a reverse byte mapping process using the two text encoding standards as a first level of mojibake correction on the string of characters (Ramam; Col. 8, lines 7-36 - To cause the obfuscated text to be visually represented as the original text, the client device 110 can access a character map 112 that correlates characters in computer code with glyphs that are graphical representations of the characters in the computer code—where such correlation represents a “reverse” or “inverse” of the mapping that occurred to the content before it was served). Therefore, it would have been obvious to one of ordinary skill to modify the method and engine of Bostick to include implementing a reverse byte mapping process using the two text encoding standards as a first level of mojibake correction on the string of characters, as taught by Ramam, because one common area of computer fraud involves attempts by organizations to infiltrate and compromise computers of ordinary people, and by that action to elicit confidential information or manipulate otherwise legitimate transactions. Various forms of malware are programmed to facilitate these fraudulent actions, for example, by analyzing sensitive information from textual content of webpages and other documents on client computing devices. To determine the content of a webpage, malware can identify strings of text that are arranged for display on the page. Characters in the strings of text may be encoded according to certain standards that assign unique numeric values to characters (e.g., the common ASCII character set or the newer Unicode character set), and these values can be understood across multiple computing platforms that execute the webpage so that the characters may be properly processed and displayed according to their original meaning (Ramam; Col. 1, lines 10-26). Additionally, although Bostick fails to disclose that every level of the recited three levels of mojibake correction is performed one after the other in a sequential manner, one of ordinary skill in the art would have found it “obvious to try” as the utilization of these processes, in sequential order, are performing for the purpose of yielding a predictable result, such as correcting mojibake text. See MPEP 2144.05:
“However, in KSR International Co. V. Teleflex Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007), the Supreme Court held that 'obvious to try' was a valid rationale for an obviousness finding, for example, when there is a 'design need' or 'market demand' and there are a 'finite number' of solutions. 550 U.S. at 421, 82 USPQ2d at 1397 ('The same constricted analysis led the Court of Appeals to conclude, in error, that a patent claim cannot be proved obvious merely by showing that the combination of elements was '[o]bvious to try.' When there is a design need or market pressure to solve a problem and there are a finite number of identified, predictable solutions, a person of ordinary skill has good reason to pursue the known options within his or her technical grasp. If this leads to the anticipated success, it is likely the product not of innovation but of ordinary skill and common sense. In that instance the fact that a combination was obvious to try might show that it was obvious under $103.'). Thus, after KSR, the presence of a known result-effective variable would be one, but not the only, motivation for a person of ordinary skill in the art to experiment to reach another workable product or process.”
Furthermore, the sequential ordering of the recited processes for correcting mojibake text shows a product of ordinary skill and common sense because a person of ordinary skill would have been able to place the processes in any sequential order to yield the same predictable results. Thus, a person of ordinary skill has good reason to pursue the known options, such as sequential performing of multiple processes for correction of mojibake text, within his or her own technical grasp, that would yield in a finite number of predictable results.
As per claims 3 and 13, Bostick in view of Ramam disclose:
The method and engine of claims 1 and 11, wherein a first of the two text encoding standards is a first text encoding standard native to an application being used to read the string of characters from storage, and the second of the two text encoding standards is a second text encoding standard different from the first text encoding standard (Bostick; p. 0012 - For example, document alpha created by system “A” includes a number of transcription errors, in this case missing characters. System “A” uses code page “ABC” (first text encoding standard) as its default to process documents and system “B” uses code page “EFG” ” (second text encoding standard) as its default. System “B” receives document alpha from system “A” but document alpha is not tagged with the code page used to create that document. As such, System “B” applies code page “EFG” to document alpha and the resulting document includes several instances of mojibake in addition to the missing characters).
As per claims 4 and 14, Bostick in view of Ramam disclose:
The method and engine of claims 3 and 13, wherein determining the character text encoding mismatch between the two text encoding standards that caused the mojibake characters in the string of characters comprises reading the characters using the first text encoding standard and identifying, from the string of characters, the second text encoding standard (Bostick; p. 0038 - In this embodiment, in process 225, document processing program 115 identifies a code page to be applied to the document based on a comparison between the logged mojibake of the document and known patterns of mojibake, which are included as part of library 119. If there is a pattern match, then document processing program 115 determines that the document has been saved using the wrong code page).
As per claims 5 and 15, Bostick in view of Ramam discloses:
The method and engine of claims 4 and 14, wherein identifying the second text encoding standard comprises searching the string of characters for default mojibake characters used by the different second text encoding standards to represent unknown characters, and upon identifying a default mojibake character used by one of the different second text encoding standards, determining that the second text encoding standard is the one of the different second text encoding standards that uses the identified default mojibake character (Bostick; p. 0038 - In this embodiment, in process 225, document processing program 115 identifies a code page to be applied to the document based on a comparison between the logged mojibake of the document and known patterns of mojibake, which are included as part of library 119. If there is a pattern match, then document processing program 115 determines that the document has been saved using the wrong code page. For example, a document created using code page “AE” is known to generate a mojibake replacing the letter combination “pp” with “(?)” if that document is read using code page “AG” (default mojibake characters). In other words, a document created using code page “AE” is known to generate a type of mojibake, if that document is read using code page “AG”. However, the number of words in the average document that use “pp” is predictable. There are approximately 1,868 common words used in written American English that use the letter combination “pp”. Dictionary 119 includes each of those words along with a statistical usage of each per document length. Document processing program 115 combines these values to generate a general statistical occurrence for “pp”, which in turn represents the statistical occurrence of a mojibake that results from the use of “pp”. In some embodiments, document processing program 115 also identifies a type of document to which the document being processed belongs. In such embodiments, the type of document is used to refine statistical analysis and predicted occurrence of mojibake and/or missing characters. For example, a seventh grade essay with 150,000 words that has been saved to nine different file formats during its creation is statistically more likely to have missing characters when compared to a 10,000 word legal document prepared and proofread for submission to a government agency using a single file format).
As per claims 6 and 16, Bostick in view of Ramam disclose:
The method and engine of claims 1 and 11, upon which claims 6 and 16 depend. And further, Ramam teaches wherein implementing the reverse byte mapping process using the two text encoding standards comprises encoding the string of characters using the second text encoding standard and decoding the string of characters using the first text encoding standard (Ramam; Col. 8, lines 7-36 - To cause the obfuscated text to be visually represented as the original text, the client device 110 can access a character map 112 that correlates characters in computer code with glyphs that are graphical representations of the characters in the computer code—where such correlation represents a “reverse” or “inverse” of the mapping that occurred to the content before it was served). Therefore, it would have been obvious to one of ordinary skill to modify the method and engine of Bostick to include wherein implementing the reverse byte mapping process using the two text encoding standards comprises encoding the string of characters using the second text encoding standard and decoding the string of characters using the first text encoding standard, as taught by Ramam, because one common area of computer fraud involves attempts by organizations to infiltrate and compromise computers of ordinary people, and by that action to elicit confidential information or manipulate otherwise legitimate transactions. Various forms of malware are programmed to facilitate these fraudulent actions, for example, by analyzing sensitive information from textual content of webpages and other documents on client computing devices. To determine the content of a webpage, malware can identify strings of text that are arranged for display on the page. Characters in the strings of text may be encoded according to certain standards that assign unique numeric values to characters (e.g., the common ASCII character set or the newer Unicode character set), and these values can be understood across multiple computing platforms that execute the webpage so that the characters may be properly processed and displayed according to their original meaning (Ramam; Col. 1, lines 10-26).
As per claims 7 and 17, Bostick in view of Ramam disclose: The method and engine of claims 1 and 11, wherein implementing the character prediction mojibake correction process to replace each of the remaining mojibake characters in the string of characters with a respective predictive corrected character comprises, for each remaining mojibake character in the string of characters: identifying known characters in the string of characters adjacent to the remaining mojibake character, and using a mojibake character prediction table to predict a replacement character for the remaining mojibake character based on the identified adjacent known characters (Bostick; p. 0042-0043 - In process 230, document processing program 115 replaces missing characters with the document. Document processing program 115 accesses the most recently updated version of the document included in document repository 117 and applies probabilistic modeling (character prediction) using a confusion matrix, included in library 119, to determine what the best probable character is to substitute for a given missing character).
As per claims 8 and 18, Bostick in view of Ramam disclose:
The method and engine of claims 7 and 17, wherein the adjacent known characters are nearest characters ahead of the remaining mojibake character and behind the remaining mojibake character in the string of characters (Bostick; p. 0042-0043 - …document processing program 115 identifies a sequence of words and the resulting root words that are generated if various letters are used to join the sequence of words (ahead and behind). If a given letter or combination of letters results in a nonsensical word, i.e., a word that does not exist in the dictionary included in document processing program 115, then that combination is assigned a low probability. In contrast, if a given letter or combination of letters results in a root word, i.e., a word that does exist in the dictionary included in document processing program 115, then that combination is assigned a respectively higher probability when compared to the probability of the combination that resulted in a nonsensical word…).
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Bostick in view of Ramam and further in view of McCormick et al. (US Patent 11,423,208; hereinafter “McCormick”).
As per claims 2 and 12, Bostick in view of Ramam disclose: The method and engine of claims 1 and 11, upon which claims 2 and 12 depend. Bostick in view of Ramam, however, fail to teach wherein detecting mojibake characters in the string of characters comprises determining a respective hexadecimal value of each character in the string of characters, and comparing the respective hexadecimal value of each character with a set of ranges of hexadecimal values used to represent characters in a first of the text encoding standards. McCormick does teach wherein detecting mojibake characters in the string of characters comprises determining a respective hexadecimal value of each character in the string of characters, and comparing the respective hexadecimal value of each character with a set of ranges of hexadecimal values used to represent characters in a first of the text encoding standards (McCormick; Col. 3, lines 34-57 - …In the depicted example, the first electronic document 110 includes the word “más”, and when the first electronic document 110 is decoded using the Windows-1252 format, this results in the mojibake “mÃcustom characters”. More specifically, in the UTF-8 encoding format, the word “más” is represented using the hexadecimal values “6D C3 A1 73”, where the character “m” is represented as “6D”, “á” is represented as “C3 A1” and “s” is represented as “73”. However, when this hexadecimal string is decoded using the Windows-1252 encoding, the hexadecimal values “C3” corresponds to the character “Ô and “A1” corresponds to the character “custom character”…). Therefore, it would have been obvious to one of ordinary skill to modify the method and engine of Bostick and Ramam to include wherein detecting mojibake characters in the string of characters comprises determining a respective hexadecimal value of each character in the string of characters, and comparing the respective hexadecimal value of each character with a set of ranges of hexadecimal values used to represent characters in a first of the text encoding standards, as taught by McCormick, in order to provide for the processing of a large corpus of documents (e.g., an ever-expanding set of documents containing sub-title text for an online video streaming site) which may have been previously encoded (and erroneously decoded) in any number of different formats and languages (McCormick; Col. 1, lines 34-48).
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bostick in view of Ramam and further in view of Scarpino (US PG Pub 20140270153).
As per claims 9 and 19, Bostick in view of Ramam disclose:
The method of claim 1, wherein searching the string of characters for the set of known mistranslations comprises comparing the string of characters with entries of a dictionary of known mistranslations, the dictionary of known mistranslations including a plurality of entries (Bostick; p. 0038 - In this embodiment, in process 225, document processing program 115 identifies a code page to be applied to the document based on a comparison between the logged mojibake of the document and known patterns of mojibake, which are included as part of library 119. If there is a pattern match, then document processing program 115 determines that the document has been saved using the wrong code page. For example, a document created using code page “AE” is known to generate a mojibake replacing the letter combination “pp” with “(?)” if that document is read using code page “AG”. In other words, a document created using code page “AE” is known to generate a type of mojibake, if that document is read using code page “AG”). Bostick in view of Ramam, however, fail to disclose that each entry including a key/value pair, where the key of the key/value pair corresponds to one of the known mistranslations and the value of the key/value pair corresponds to a correct translation of the one of the known mistranslations. Scarpino does teach each entry including a key/value pair, where the key of the key/value pair corresponds to one of the known mistranslations and the value of the key/value pair corresponds to a correct translation of the one of the known mistranslations (Scarpino; p. 0017 - The different cypher texts (mojibake) can then be decrypted using a deterministic decryption algorithm (corresponding to the deterministic encryption algorithm) with the corresponding encryption keys to retrieve the same original key of the data block. The system may store the generated encryption keys 108, for example in a mapping table that maps the encryption keys 108 to clients. The encryption keys 108 may be kept from the clients by the system and used to decrypt the stored and encrypted key/value pair (stored data block) when the client requests the data block). Therefore, it would have been obvious to one of ordinary skill to modify the method and engine of Bostick and Ramam to include that each entry including a key/value pair, where the key of the key/value pair corresponds to one of the known mistranslations and the value of the key/value pair corresponds to a correct translation of the one of the known mistranslations, as taught by Scarpino, in order to provide protection against unauthorized users or access (Scarpino; p. 0002).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art made of record and not relied upon includes:
Salwan (US PG Pub 20070075879) discloses character conversion methods for converting characters from a source character code set to a destination character code. set. The source and destination character code sets are analyzed to establish a mapping table indicating relationships therebetween. A target character encoded in the source character code set is converted to destination code encoded in the destination character code set by searching the mapping table (Salwan; Abstract).
Kellum (https://github.com/dekellum/mojibake) discloses mojibake occurs in English most frequently due to misinterpreting and bad-transcoding between Windows-1252, ISO-8859-1, and UTF-8. This module provides a mojibake sequence to original character mapping table, and utility to recover mojibake’d text (Kellum; Desription).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Rodrigo A Chavez whose telephone number is (571)270-0139. The examiner can normally be reached Monday - Friday 9-6 ET.
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, Richemond Dorvil can be reached at 5712727602. 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.
/RODRIGO A CHAVEZ/Examiner, Art Unit 2658
/RICHEMOND DORVIL/Supervisory Patent Examiner, Art Unit 2658
Prosecution Insights