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 .
Response to Amendment
The Amendments filed March 12th, 2026 have been entered and made of record. Claims 1, 2, 9 and 13 have been amended. Claims 1-16 remain pending and rejected. Examiner appreciates the applicant providing an updated and corrected IDS and applicant’s amendments to the specifications and claims have overcome each and every objection previously set forth in the Non-Final Office Action mailed December 16th, 2025 and have therefore been withdrawn.
Response to Arguments
Applicant’s arguments with respect to claims 1 and 9 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. The prior art of Kuhlmann et al., has been incorporated into the rejection of the independent claims and therefore teaches the newly amended claim language (see claims 1 and 9 below),
In regards to any additional arguments regarding the dependent claims 2-8 and 10-16 for the virtue of their dependency are moot because the independent claims are not allowable.
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.
Claims 1-3, 6-7, 9-11 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Everett et al. (Pub. No.: US 2004/0119715 A1), hereinafter Everett, in view of Constable et al. (Pub. No.: US 2017/0249292 A1), hereinafter Constable and further in view of Kuhlmann et al. (Pub. No.: US 2020/0026947 A1), hereinafter Kuhlmann.
Regarding claim 1, Everett discloses a system comprising a computer including a processor and memory (FIG. 1 and paragraph 47 teach that with reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. Components of computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120.), the memory storing instructions executable by the processor to:
receive a parameter from the memory that includes an identifier representing a variable font (Paragraph 60 teaches that a text engine 250 is an important feature of the layout engine 202. Text engine 250 supplies inputs to reading metrics engine 240 that add language specific data concerning text values. Text engine 250 receives a font family identifier 364 and a language identifier 366. Additionally, FIG. 15 and paragraph 90 teach that referring now to FIG. 15, a system 1500 for adjusting text in a font for optimal readability on a viewing medium is shown. The system includes a client application 200 including a data structure holding one or more text parameters 1510. The system further includes reading metrics engine 240 coupled to the client application 200, reading metrics engine 240 being configured to receive the one or more parameters of the text 1510. Reading metrics engine 240 includes a module configured to determine a character density for the font 1520, and a module configured to multiply the character density by a sharpest focus area of an eye to produce an optimal size of the font for readability 1530.). However, Everett fails to teach a weight of the variable font, and a width of the variable font.
Constable teaches a weight of the variable font, and a width of the variable font (Paragraph 71 teaches that at 208, the default GSUB/GPOS lookups can be cached in association with the context of the string of text 102. For example, the string of text 102 can be associated with a font type, one or more font design variations (e.g., weight, style, width, x-height, cap-height, style, formality, serif length, friendliness, wonkiness, etc.), a layout direction, and so on.). Since Everett teaches a system for receiving parameters and identifiers related to different font types for displaying strings of text and Constable teaches a system for displaying strings of text and can associate text depending on the different characteristics of the font, including the font weight and width, it would have been obvious to a person having ordinary skill in the art to combine the features together so that the received font parameters and identifiers could also include a font’s weight and width, among other characteristics as well.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Everett to incorporate the features of Constable so that by incorporating a font’s weight and width within the received parameters, this would allow for improved readability and precision when eventually rendering the font/character string onto a display.
Furthermore, Everett in view of Constable disclose compute a pixel length of a received first character string to be rendered via a display utilizing the identified variable font, the weight of the variable font, and the width of the variable font (Paragraph 67 of Everett teaches that after receiving the font family identifier and language identifier, as shown in block 610, text engine 250 measures ratios of black to total pixels in a plurality of pixel rows in the representative line of type. In one embodiment, text engine 250 measures the ratio of black to total pixels in each row of pixels in the rendered line of type. Additionally, paragraph 137 of Everett teaches that referring to block 2254, reading metrics engine 240 computes an actual font size (FS.sub.A) using inputs from blocks 2252, 2212, 2214 and 2230. In one embodiment, the actual font size is performed by computing a recommended font size (FS.sub.r) for the layout, and then checking the recommended font size against the minimum font size and maximum font size to insure that the font size is within the range that was computed earlier. The first is also a conditional process determining if the line is too long or too short to use the optimum font size due to the number of clusters that would appear on the line. Only when the range of the number of clusters is exceeded at the optimum font size does the font change sizes.) However, Everett in view of Constable fail to disclose compute, in a horizontal dimension, a pixel length of a received first character string by determining a number of horizontal pixels consumed when the received first character string is rendered.
Kuhlmann discloses compute, in a horizontal dimension, a pixel length of a received first character string by determining a number of horizontal pixels consumed when the received first character string is rendered (Paragraph 67 teaches that the pixel sum 306 may include a sum of all of the black or darkened pixels at each of a plurality of vertical positions of the text line image 302. For example, the pixel sum 306 may be determined by summing all of the pixels values horizontally for each vertical pixel of the text line image 302. The pixel gradient 308 may be a calculation of a difference of the pixel sum 306 at each vertical comparison, as compared to nearby vertical positions. For example, the pixel gradient 308 may be calculated by first calculating the pixel sum 306 of the text line image 302. ... The text line image dimensions 311 may include one or more dimensions of the text line image 302. For example, the text line image dimensions 311 may include a measure of the length of the text line image 302 (e.g., the length of the text line image in centimeters, inches, or pixels).). Since Everett in view of Constable teaches a system for being able to compute the total amount of pixels related to character strings to be rendered and Kuhlmann teaches a system for computing the pixel values of text lines in a horizontal dimension and then determining the length of the rendered text line in relation to the amount of pixels, it would have been obvious to a person having ordinary skill in the art to combine the features together so that when computing the total amount of pixels in a character string and/or text line, the pixel length of the character string could be determined and computed along the horizontal dimension if needed.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Everett in view of Constable to incorporate the features of Kuhlmann so that when computing any pixel values in relation to the length of a character string, the horizontal dimension could also be taken into account, which would provide better overall accuracy and fitting of character strings to be rendered for a display.
Furthermore, Everett in view of Constable and Kuhlmann disclose and control the display to render the received first character string based on the identifier of the variable font, the weight of the variable font, or the width of the variable font (Paragraph 165 of Everett teaches that application 200 can supply data to layout engine in one language and receive back data allowing application 200 to display multiple languages of the text that are formatted for the display for each language desired and appropriate for the individual languages (block 2630). Application 200 can also be running on different displays, each display having a different size and each display receiving the same text in a different language formatted for that display and that language. Thus, for example, if application 200 is running on a server that serves client machines in several countries, each display in the server group will receive text in an appropriate language, sized and formatted appropriately for that language and for the appropriate display.).
Regarding claim 2, Everett in view of Constable and Kuhlmann disclose everything claimed as applied above (see claim 1), in addition, Everett in view of Constable and Kuhlmann disclose wherein the instructions to control the display include instructions to:
obtain from the memory an available number of pixels in a horizontal dimension of the display (Paragraph 54 of Everett teaches that it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. The manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data and paragraph 76 of Everett teaches that another measurement returned can be measurements in relation to an em. In text engine 250 and in the reading metrics engine 240, an em is used to establish both horizontal and vertical measurements. Another measurement that can be returned by text engine 250 is the cluster per em, which can also be a measurement returned to reading metrics engine 240. Clusters per em are equivalent to a ratio of the height of the font to the average cluster width.);
translate the received first character string from a first language to a second language (FIGS. 24 and 25 and paragraph 164 of Everett teach that referring to FIG. 25 in combination with FIG. 24, in an embodiment, external international translates text created by or received into application 200, block 2510. The property changes that occur due to external international translator 2460 are provided either to application 200 to alter elements in property sheet 210 or property values 220 or provided directly to layout engine 202, as shown in block 2520. Layout engine 202, can have, but does not require for this embodiment, an international translator 2462. If present, external international translator 2460 can send and receive data from international translator 2462, which provides compatibility components to enable seamless interaction between an external international translator 2460 and layout engine 202 (block 2520). In one embodiment, external international translator 2460 provides translated text in a language and basic text to application 200, which then sends relevant data via connection 280 to layout engine 202 (block 2520). Layout engine 202 then operates on the data as discussed above to provide readability parameters to application 200 (block 2530). More specifically, layout engine 202, using reading metrics engine 240 and text engine 250, operates on the data received by application 200 and/or directly from external international translator 2460 to provide translated text in a readable format with column, line height, font size and the like appropriate for the language to which text is translated.);
and modify the weight of the variable font or the width of the variable font (FIG. 3C and paragraph 79 of Constable teaches that in the left side of FIG. 3C, the condition is not satisfied because either or both of the weight value of the string of text 102 is not within the predefined range of weight values and/or the style is not italicized. Thus, the process 200 proceeds from 204 to 206 where a default GPOS lookup is performed to apply a kerning feature by decreasing the advance width of the glyph ID for the “V” character by a distance of “k1.”) based on the computed pixel length of the translated character string exceeding the available number of pixels in the horizontal dimension (Paragraph 73 of Everett teaches that in one embodiment, text engine 250 returns measurements to reading metrics engine 240, including one or more of a black to total ratio of the darkest row of pixels, an average black to total ratio of the entire representative line of type, a width of the before shallows, a black to total ratio of the before shallows, a width of the channel, a black to total ratio of the channel, a width of the after shallows, and a black to total ratio of the after shallows.).
Regarding claim 3, Everett in view of Constable and Kuhlmann disclose everything claimed as applied above (see claim 1), in addition, Everett in view of Constable and Kuhlmann disclose wherein the instructions to control the display include instructions to:
obtain an available number of pixels in a vertical dimension of the display (Paragraph 69 of Everett teaches that block 630 provides for identifying the font height using the measured ratios of black and total pixels. In block 640, text engine uses the font height and identifies a first portion, referred to herein as a "channel" including the row with the highest ratio of black to total, the first portion including a first row of pixels and a last row of pixels that are darker than an average pixel row. In Latin texts, the channel equates to the x-height. In other script types there is no direct equivalent of an x-height. Because each font in each language rendered in a line of text will have a dark part in the line of text, instead of an x-height, embodiments herein refer to a channel and measurements relative to the channel. In many embodiments described herein, the channel is an important measurement for determining the appropriate line height and other settings for a line of text in a script.);
translate the received first character string from a first language to a second language (FIGS. 24 and 25 and paragraph 164 of Everett teach that referring to FIG. 25 in combination with FIG. 24, in an embodiment, external international translates text created by or received into application 200, block 2510. The property changes that occur due to external international translator 2460 are provided either to application 200 to alter elements in property sheet 210 or property values 220 or provided directly to layout engine 202, as shown in block 2520. Layout engine 202, can have, but does not require for this embodiment, an international translator 2462. If present, external international translator 2460 can send and receive data from international translator 2462, which provides compatibility components to enable seamless interaction between an external international translator 2460 and layout engine 202 (block 2520). In one embodiment, external international translator 2460 provides translated text in a language and basic text to application 200, which then sends relevant data via connection 280 to layout engine 202 (block 2520). Layout engine 202 then operates on the data as discussed above to provide readability parameters to application 200 (block 2530). More specifically, layout engine 202, using reading metrics engine 240 and text engine 250, operates on the data received by application 200 and/or directly from external international translator 2460 to provide translated text in a readable format with column, line height, font size and the like appropriate for the language to which text is translated.);
and modify the weight of the variable font or the width of the variable font (FIG. 3C and paragraph 79 of Constable teach that in the left side of FIG. 3C, the condition is not satisfied because either or both of the weight value of the string of text 102 is not within the predefined range of weight values and/or the style is not italicized. Thus, the process 200 proceeds from 204 to 206 where a default GPOS lookup is performed to apply a kerning feature by decreasing the advance width of the glyph ID for the “V” character by a distance of “k1.”) based on the computed pixel length of the translated character string exceeding the available number of pixels in the vertical dimension (Paragraph 73 of Everett teaches that in one embodiment, text engine 250 returns measurements to reading metrics engine 240, including one or more of a black to total ratio of the darkest row of pixels, an average black to total ratio of the entire representative line of type, a width of the before shallows, a black to total ratio of the before shallows, a width of the channel, a black to total ratio of the channel, a width of the after shallows, and a black to total ratio of the after shallows. When a language is written vertically, such as certain Asian languages, the same measurements can be made by measuring columns of vertical type for the vertical language instead of measuring rows of horizontal type for horizontal languages.).
Regarding claim 6, Everett in view of Constable and Kuhlmann disclose everything claimed as applied above (see claim 1), in addition, Everett in view of Constable and Kuhlmann disclose wherein the instructions further include instructions to:
generate an instance of the weight of the variable font that is between endpoints of a first range of permissible weights for the variable font (FIG. 3A and paragraph 74 of Constable teach that in the example of FIG. 3A, the context of the string of text 102 under evaluation at 204 comprises a weight value 300(1) on a weight axis 302. Although “weight” is used in the example of FIG. 3A, it is to be appreciated that any instance value for any font design variation axis can be evaluated in a similar manner. The condition under evaluation at 204 can be defined in terms of a predefined range of values 304 such that the context satisfies the condition if the weight value 300(1) is within the predefined range of values 304 on the font design variation axis 302. The left side of FIG. 3A illustrates an example glyph 306(1) that can be rendered at 210 when the condition is not satisfied (e.g., the weight value 300(1) is not within the predefined range of values 304.);
store the generated instance in the memory (Paragraph 30 of Constable teaches that the computer-readable memory 110 can include a rendering engine 112 that is used by a font-using application to render the string of text 102 on a target device in accordance with a font format. For example, the OpenType font format can be used to configure the rendering engine 112 to process data structures and information within a plurality of font tables 114 or similar data structures for purposes of rendering the string of text 102 as a sequence of glyphs on a target device. In general, the font tables 114 store glyph information, which can include, without limitation, glyph identifiers (IDs), glyph metrics, outline data (e.g., points that make up a Bezier curve) usable for rendering glyphs, character map (cmap) tables for mapping characters to glyph IDs, script tables, language system (LangSys) tables, feature tables, lookup tables, and so on.);
and control the display to render a second received character string based on the generated instance (Paragraph 67 of Constable teaches that at 202, the rendering engine 112 receives a string of text 102. The string of text 102 can be received from a local memory resource, or from a computing device over a network(s). The string of text 102 can comprise a sequence of characters associated with a language. For example, the sequence of characters can comprise the character “o”, followed by the character “f”, followed by the character “f”, followed by the character “i”, followed by the character “c”, followed by the character “e” to form the word “office.” Additionally, paragraph 72 of Constable teaches that at 210, the string of text 102 is rendered on a display 106 as a sequence of glyphs with a typographical feature applied to the sequence of glyphs. For example, if a default GSUB lookup is executed at 206 to apply a standard ligature feature to the string of text 102, the string of text 102 is rendered at 208 with the standard ligature feature applied, which involves replacing multiple glyph IDs in the sequence of glyph IDs with a standard ligature glyph ID (e.g., replacing “f” and “i” glyph IDs with the “fi” ligature glyph ID).).
Regarding claim 7, Everett in view of Constable and Kuhlmann disclose everything claimed as applied above (see claim 1), in addition, Everett in view of Constable and Kuhlmann disclose wherein the instructions further include instructions to:
generate an instance of the width of the variable font that is between endpoints of a second range of permissible widths for the variable font (Paragraph 4 of Constable teaches that to support font variations, the single font file uses a mechanism that interpolates different font design parameters between two endpoint values. For example, a weight parameter value can be interpolated between a lighter weight used for regular “Arial” and a heavier weight used for “Arial Black” to generate a unique Arial font with an intermediate weight. Of course, weight is but one example of a font design attribute that can be varied in this manner. Other font design attributes (e.g., width, height, style, etc.) can be varied alone or in combination to achieve a desired font design. Additionally, paragraph 71 of Constable teaches that at 208, the default GSUB/GPOS lookups can be cached in association with the context of the string of text 102. For example, the string of text 102 can be associated with a font type, one or more font design variations (e.g., weight, style, width, x-height, cap-height, style, formality, serif length, friendliness, wonkiness, etc.), a layout direction, and so on. Thus, the rendering engine 112 can cache the default GSUB/GPOS lookups in association with such information at 208 so that subsequent strings of text received by the rendering engine 112 can be processed with the default GSUB/GPOS lookups at 206 without evaluating conditions at 204.);
store the generated instance in the memory (Paragraph 30 of Constable teaches that the computer-readable memory 110 can include a rendering engine 112 that is used by a font-using application to render the string of text 102 on a target device in accordance with a font format. For example, the OpenType font format can be used to configure the rendering engine 112 to process data structures and information within a plurality of font tables 114 or similar data structures for purposes of rendering the string of text 102 as a sequence of glyphs on a target device. In general, the font tables 114 store glyph information, which can include, without limitation, glyph identifiers (IDs), glyph metrics, outline data (e.g., points that make up a Bezier curve) usable for rendering glyphs, character map (cmap) tables for mapping characters to glyph IDs, script tables, language system (LangSys) tables, feature tables, lookup tables, and so on.);
and control the display to render a second received character string based on the generated instance (Paragraph 67 of Constable teaches that at 202, the rendering engine 112 receives a string of text 102. The string of text 102 can be received from a local memory resource, or from a computing device over a network(s). The string of text 102 can comprise a sequence of characters associated with a language. For example, the sequence of characters can comprise the character “o”, followed by the character “f”, followed by the character “f”, followed by the character “i”, followed by the character “c”, followed by the character “e” to form the word “office.” Additionally, paragraph 72 of Constable teaches that at 210, the string of text 102 is rendered on a display 106 as a sequence of glyphs with a typographical feature applied to the sequence of glyphs. For example, if a default GSUB lookup is executed at 206 to apply a standard ligature feature to the string of text 102, the string of text 102 is rendered at 208 with the standard ligature feature applied, which involves replacing multiple glyph IDs in the sequence of glyph IDs with a standard ligature glyph ID (e.g., replacing “f” and “i” glyph IDs with the “fi” ligature glyph ID).).
Regarding claim 9, the method steps correspond to and are rejected similarly to the system steps of claim 1 (see claim 1 above).
Regarding claim 10, the method steps correspond to and are rejected similarly to the system steps of claim 2 (see claim 2 above).
Regarding claim 11, the method steps correspond to and are rejected similarly to the system steps of claim 3 (see claim 3 above).
Regarding claim 14, the method steps correspond to and are rejected similarly to the system steps of claim 6 (see claim 6 above).
Regarding claim 15, the method steps correspond to and are rejected similarly to the system steps of claim 7 (see claim 7 above).
Claims 4-5 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Everett in view of Constable and Kuhlmann, as applied to claim 1 above, and further in view of Awaida et al. (Pub. No: US 2012/0035910 A1), hereinafter Awaida.
Regarding claim 4, Everett in view of Constable and Kuhlmann disclose everything claimed as applied above (see claim 1), in addition, Everett in view of Constable and Kuhlmann disclose wherein the instructions to control the display include instructions to:
obtain an available number of pixels in a horizontal dimension of the display (Paragraph 76 of Everett teaches that another measurement returned can be measurements in relation to an em. In text engine 250 and in the reading metrics engine 240, an em is used to establish both horizontal and vertical measurements. Another measurement that can be returned by text engine 250 is the cluster per em, which can also be a measurement returned to reading metrics engine 240. Clusters per em are equivalent to a ratio of the height of the font to the average cluster width.). However, Everett in view of Constable and Kuhlmann fail to disclose transliterate the received first character string from a first character set to a second character set.
Awaida discloses transliterate the received first character string from a first character set to a second character set (Paragraph 21 teaches that preferably, the transliteration database includes a number of data sets greater than two, thus allowing the user to first select a language to be transliterated and then set the selected language to be transliterated as the first language. The user then selects a language for phonetic representation, and the selected language for phonetic representation is set as the second language. Additionally, paragraph 22 teaches that as shown in FIG. 1, the characters in the first language preferably are displayed in a font size that is greater than that of the phonetic characters of the second language, thus allowing a reader of the first language to read the words printed in the transliteration font without the characters in the first language being obscured by the phonetic characters in the second language. For similar reasons, the phonetic characters of the second language are also preferably positioned above and adjacent to the corresponding characters in the first font (as shown in FIG. 1).). Since Everett in view of Constable and Kuhlmann teach a system for measuring, adjusting and displaying different font types, with the capabilities to translate and display a character string of one language into a character string of another language and Awaida teaches the functionality of generating a transliteration font that can be displayed in one language and then transliterated into a second language, it would have been obvious to a person having ordinary skill in the art to combine the functions together so that in addition to being able to translate a character string from one language into another, that character string could also be transliterated as well.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Everett in view of Constable and Kuhlmann to incorporate the features of Awaida so that in addition to being able to translate the font of a character string from one language into another language, the font could also be transliterated as well, which would help improved overall readability and proper pronunciation of the transliterated character string.
Furthermore, Everett in view of Constable, Kuhlmann and Awaida disclose and modify the weight of the variable font or the width of the variable font (FIG. 3C and paragraph 79 of Constable teach that in the left side of FIG. 3C, the condition is not satisfied because either or both of the weight value of the string of text 102 is not within the predefined range of weight values and/or the style is not italicized. Thus, the process 200 proceeds from 204 to 206 where a default GPOS lookup is performed to apply a kerning feature by decreasing the advance width of the glyph ID for the “V” character by a distance of “k1.”) based on the computed pixel length of the transliterated character string exceeding the available number of pixels in the horizontal dimension (Paragraph 73 of Everett teaches that in one embodiment, text engine 250 returns measurements to reading metrics engine 240, including one or more of a black to total ratio of the darkest row of pixels, an average black to total ratio of the entire representative line of type, a width of the before shallows, a black to total ratio of the before shallows, a width of the channel, a black to total ratio of the channel, a width of the after shallows, and a black to total ratio of the after shallows.).
Regarding claim 5, Everett in view of Constable and Kuhlmann disclose everything claimed as applied above (see claim 1), in addition, Everett in view of Constable and Kuhlmann disclose wherein the instructions to control the display include instructions to:
obtain an available number of pixels in a vertical dimension of the display (Paragraph 69 of Everett teaches that block 630 provides for identifying the font height using the measured ratios of black and total pixels. In block 640, text engine uses the font height and identifies a first portion, referred to herein as a "channel" including the row with the highest ratio of black to total, the first portion including a first row of pixels and a last row of pixels that are darker than an average pixel row. In Latin texts, the channel equates to the x-height. In other script types there is no direct equivalent of an x-height. Because each font in each language rendered in a line of text will have a dark part in the line of text, instead of an x-height, embodiments herein refer to a channel and measurements relative to the channel. In many embodiments described herein, the channel is an important measurement for determining the appropriate line height and other settings for a line of text in a script.). However, Everett in view of Constable and Kuhlmann fail to disclose transliterate the first character string from a first language to a second language.
Awaida discloses transliterate the first character string from a first language to a second language (Paragraph 21 teaches that preferably, the transliteration database includes a number of data sets greater than two, thus allowing the user to first select a language to be transliterated and then set the selected language to be transliterated as the first language. The user then selects a language for phonetic representation, and the selected language for phonetic representation is set as the second language. Additionally, paragraph 22 teaches that as shown in FIG. 1, the characters in the first language preferably are displayed in a font size that is greater than that of the phonetic characters of the second language, thus allowing a reader of the first language to read the words printed in the transliteration font without the characters in the first language being obscured by the phonetic characters in the second language. For similar reasons, the phonetic characters of the second language are also preferably positioned above and adjacent to the corresponding characters in the first font (as shown in FIG. 1).). Since Everett in view of Constable and Kuhlmann teach a system for measuring, adjusting and displaying different font types, with the capabilities to translate and display a character string of one language into a character string of another language and Awaida teaches the functionality of generating a transliteration font that can be displayed in one language and then transliterated into a second language, it would have been obvious to a person having ordinary skill in the art to combine the functions together so that in addition to being able to translate a character string from one language into another, that character string could also be transliterated as well.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Everett in view of Constable and Kuhlmann to incorporate the features of Awaida so that in addition to being able to translate the font of a character string from one language into another language, the font could also be transliterated as well, which would help improved overall readability and proper pronunciation of the transliterated character string.
Furthermore, Everett in view of Constable, Kuhlmann and Awaida disclose and modify the weight of the variable font or the width of the variable font (FIG. 3C and paragraph 79 of Constable teach that in the left side of FIG. 3C, the condition is not satisfied because either or both of the weight value of the string of text 102 is not within the predefined range of weight values and/or the style is not italicized. Thus, the process 200 proceeds from 204 to 206 where a default GPOS lookup is performed to apply a kerning feature by decreasing the advance width of the glyph ID for the “V” character by a distance of “k1.”) based on the computed pixel length of the transliterated character string exceeding the available number of pixels in the vertical dimension (Paragraph 73 of Everett teaches that in one embodiment, text engine 250 returns measurements to reading metrics engine 240, including one or more of a black to total ratio of the darkest row of pixels, an average black to total ratio of the entire representative line of type, a width of the before shallows, a black to total ratio of the before shallows, a width of the channel, a black to total ratio of the channel, a width of the after shallows, and a black to total ratio of the after shallows. When a language is written vertically, such as certain Asian languages, the same measurements can be made by measuring columns of vertical type for the vertical language instead of measuring rows of horizontal type for horizontal languages.).
Regarding claim 12, the method steps correspond to and are rejected similarly to the system steps of claim 4 (see claim 4 above).
Regarding claim 13, the method steps correspond to and are rejected similarly to the system steps of claim 5 (see claim 5 above).
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Everett in view of Constable and Kuhlmann, as applied to claim 1 above, and further in view of Fisher et al. (Pub. No: US 2021/0073323 A1), hereinafter Fisher.
Regarding claim 8, Everett in view of Constable and Kuhlmann disclose everything claimed as applied above (see claim 1), however, Everett in view of Constable and Kuhlmann fail to disclose wherein the computer and the memory are included in a vehicle.
Fisher discloses wherein the computer and the memory are included in a vehicle (Paragraph 29 teaches that user devices 102a through 102n can be any type of computing device capable of being operated by a user. For example, in some implementations, user devices 102a through 102n are the type of computing device described in relation to FIG. 11. By way of example and not limitation, a user device may be embodied as a personal computer (PC), a laptop computer, a mobile device, a smartphone, a tablet computer, a smart watch, a wearable computer, a personal digital assistant (PDA), an MP3 player, a global positioning system (GPS) or device, a video player, a handheld communications device, a gaming device or system, an entertainment system, a vehicle computer system, an embedded system controller, a remote control, an appliance, a consumer electronic device, a workstation, any combination of these delineated devices, or any other suitable device.). Since Everett in view of Constable and Kuhlmann teach a system for generating and displaying different types of fonts in relation to strings of text and those strings of text can be displayed on many different types of suitable electronic devices and Fisher teaches generating captured font types onto different display devices, including a vehicle computer system, it would have been obvious to a person having ordinary skill in the art to combine the features together so that the list of suitable electronic devices to display the different font types of strings of text would include a vehicle display .
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Everett in view of Constable and Kuhlmann to incorporate the features of Fisher so that additional suitable displays and devices, such as a vehicle’s display, could be utilized when displaying the different types of fonts related to strings of text.
Regarding claim 16, the method steps correspond to and are rejected similarly to the system steps of claim 8 (see claim 8 above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chin (U.S. Patent: #11,461,077 B2) teaches a method for displaying data related to characters in tables and cells.
Kobayashi (Pub. No.: US 2009/0254813 A1) teaches techniques for analyzing data related to characters and tracking the pixel counts of the characters in width and height direction.
Dhanuka et al. (Pub. No.: US 2022/0335667 A1) teaches a glyph sizing system that determines and can adjust the size of a glyph (text character) in relation to its pixel values in height and width.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to George Renze whose telephone number is (703)756-5811. The examiner can normally be reached Monday-Friday 9:00am - 6:00pm EST.
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, Xiao Wu can be reached at (571) 272-7761. 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.
/G.R./Examiner, Art Unit 2613
/XIAO M WU/Supervisory Patent Examiner, Art Unit 2613
Prosecution Insights