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 .
All objections/rejections not mentioned in this Office Action have been withdrawn by the Examiner.
Status of the Claims
Prior to entry of the amendment(s) and/or consideration of the argument(s), the status of the claims is as follows.
Claim(s) 1-20 is/are pending.
Claim 1-10 and 12-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lachwani (U.S. Pat. No. 8,826,240, hereinafter Lachwani) in view of Stuehler (U.S. Pat. App. Pub. No. 2021/0165855, hereinafter Stuehler).
Claims 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lachwani and Stuehler as applied to claim 8 above, and further in view of Multer (U.S. Pat. App. Pub. No. 2002/0029227, hereinafter Multer).
Response to Amendments
Applicant’s amendment filed on 20 April 2026 has been entered.
In view of the amendment to the claim(s), the amendment of claim(s) 1, 6, 14, 18, and 20 and the cancellation of claim(s) 2 and 15 have been acknowledged and entered.
In view of the amendment of claim(s) 1, 6, 14, 18, and 20 and the cancellation of claim(s) 2 and 15, the rejection of claims 1-20 under 35 U.S.C. §103 is withdrawn.
In light of the amended claims, new grounds for rejection under 35 U.S.C. §103 and 35 U.S.C. §112 are provided in the action below.
Response to Arguments
Applicant’s arguments regarding the prior art rejections under 35 U.S.C. §103, see pages 7-11 of the Response to Non-Final Office Action dated 21 November 2025, which was received on 20 April 2026 (hereinafter Response and Office Action, respectively), have been fully considered.
With respect to the rejection(s) of claim(s) 1 under 35 U.S.C. §103 in light of Lachwani in view of Stuehler, applicant asserts that the cited references fail to teach or suggest “retrieving one or more previously accepted screenshots, one or more previously accepted hierarchy files, or both, wherein the one or more previously accepted screenshots and the one or more previously accepted hierarchy files are from a last translation and verification for the same user interface of the software application; comparing the one or more new screenshots with the one or more previously accepted screenshots, or the one or more new hierarchy files with the one or more previously accepted hierarchy files; locating text that has changed based on an output of the comparison; and in response to locating text that has changed: (i) highlighting the text that has changed in the one or more new screenshots, the one or more new hierarchy files, or both; presenting a translation of the text that has changed to a translator for acceptance or rejection of the translation; and storing the one or more new screenshots, the one or more new hierarchy files, or both, when the translation has been accepted,” as recited in amended claim 1. As best as can be understood by the Office, in light of the provided emphasis, applicant argues that the cited references fail to teach or suggest “retrieving one or more previously accepted screenshots…, wherein the one or more previously accepted screenshots and the one or more previously accepted hierarchy files are from a last translation and verification for the same user interface of the software application… [and] highlighting the text that has changed in the one or more new screenshots, the one or more new hierarchy files, or both.” Applicant's arguments are addressed below.
First, it should be noted that applicant arguments are prefaced on claim language for an asserted amendment which does not correspond to the amendments actually filed. In the Response, applicant indicates that claims 2, 6, 15, and 18 are cancelled. Further, applicant asserts that claim 1, 14, and 20 are amended as described in pgs. 7-8 of the Response. However, this is inaccurate.
Applicant has cancelled claims 2 and 15, and amended claims 1, 6, 14, 18, and 20. Further, the amended claim language of claim 1, and mutatis mutandis claims 14 and 20, differs from the asserted language, in relevant part, as “retrieving one or more previously accepted screenshots, one or more previously accepted hierarchy files, or both, wherein the one or more previously accepted screenshots, the one or more previously accepted hierarchy files, or both, are from a last translation and verification for a same user interface of the software application “. Applicant is reminded that the claims as presented in the amendments to the claims takes priority over asserted amendments in other areas of the response. (See MPEP 714(II)(A) explaining requirements for amendments and remarks to each begin on a separate page)) As such, all further discussion will be directed to the claims as amended in the amendments to the claims.
As applicant has incorporated a permutation of the language of claims 2 and 6 and focuses their discussion on screenshots embodiment, which does not correspond to the embodiments which were mapped to the alternative arrangement as part of the rejection, it appears that the applicant is arguing that the rejection under 103 requires rejecting all alternative embodiments in light of original claim 2. Amended claim 1, from which claim 2 depends, recites, in relevant part, “retrieving one or more previously accepted screenshots, one or more previously accepted hierarchy files, or both”. Applicant's argument regarding the emphasized text is unclear. However, the argument that the rejection requires that all possible alternative combinations of the limitations must be disclosed, is not persuasive.
It is agreed that “A claim is anticipated only if each and every element as set forth in the claim is found, either expressly or inherently described, in a single prior art reference.” Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). However, “when a claim covers several structures or compositions, either generically or as alternatives, the claim is deemed anticipated if any of the structures or compositions within the scope of the claim is known in the prior art.” Brown v. 3M, 265 F.3d 1349, 1351, 60 USPQ2d 1375, 1376 (Fed. Cir. 2001) (claim to a system for setting a computer clock to an offset time to address the Year 2000 (Y2K) problem, applicable to records with year date data in “at least one of two-digit, three-digit, or four-digit” representations, was held anticipated by a system that offsets year dates in only two-digit formats). (See MPEP § 2131).
As explained in the Office Action, Lachwani discloses “At 1002, a first object level hierarchy is compared to a second object level hierarchy,” and, as such, Lachwani teaches “comparing… the one or more new hierarchy files with the one or more previously accepted hierarchy files.” The claim limitations which are in question are written in the alternative, where the limitations are met by finding the first embodiment, the second embodiment, or both. Thus, by mapping the limitations of the second embodiment (the hierarchy files) to Lachwani, the described alternative limitations are met. Applicant is invited to amendment the claims, during normal prosecution and based on specification support such that the claims recited the desired limitations and such limitations can be substantively reviewed.
Applicant further asserts that “The combination lacks (1) the claimed screenshot/hierarchy comparison for change detection in a translation context, (2) presentation of a translation with highlighting of changed text, (3) baselines from the 'last translation ... same user interface,' and (4) storage only when the translation has been accepted” and “The claimed system solves the specific problem of frequent UI text changes by translating/verifying only deltas with full visual/structural context and updating baselines conditionally-problems neither of the cited references recognizes or solves (see, Applicant's specification at 1 [0017]-[0020], [0023]-[0029]).” Respectfully, the claims as presented are broader than applicant's interpretation.
Regarding applicant’s continuing argument that the claim is to be understood as limited to a “translation context,” the preamble to the claim 1 refutes the above argument. Applicant's claim 1 is directed to “A computer-implemented method for translating or verifying text of a software application” (emphasis added). The preamble alone prevents the argument that these claims should be viewed as limited to “comparison for change detection in a translation context”. However, it is further noted that the claims merely describe the presentation of a translation. Claim 1 contains no limitations directed to translating anything. Verification of localized text, where localization includes translated text, reads on the cited limitations as previously presented in the Office Action. As such, though a translation must exist such that a translation may be presented, applicant's arguments that the steps of the method be performed “to locate only the text that has changed for translation purposes” is without merit. Once more, applicant is invited to amend the claim, in light of specification support, such that the claims recite the desired limitations.
Applicant contends that Lachwani fails to teach or suggest at least “wherein the one or more previously accepted screenshots and the one or more previously accepted hierarchy files are from a last translation and verification for the same user interface of the software application” as recited in original claim 2. As such, we turn to the broadest reasonable interpretation of the above limitation. It is noted that applicant’s claims were interpreted, where possible and reasonable, to avoid rejections based on lack of antecedent basis and lack of clarity.
As originally presented, “for the same user interface of the software application” is understood as referring to fitness for use with a type of kind of user interface (i.e., a stock version of a system having a user interface as implemented in two separate devices is understood as “the same” between two devices). In support of this conclusion, it is noted that the limitation starts with a description of what the “last translation and verification” is “for”, which is not described with reference to any particular device. It is noted that “for” describes purpose of something, not origin as implied by the applicants arguments. Further, the phrase “the same user interface” lacks proper antecedent basis for use as a specific claim part. Further, applicant doesn't recite any specific relationship to a “user interface” in the steps described in claim 1, such that the word “same” in “same user interface” has the necessary context. Further, the phrase “last translation and verification” as the phrase “the last translation and verification” doesn't correspond to any particular result as a first/prior “translation and verification” such that the word “last” in “last translation and verification” has the necessary context. It is noted that the word verification does not show up in any other context, other than this “last translation and verification”.
As such, the entire limitation “and the one or more previously accepted hierarchy files are from a last translation and verification for the same user interface of the software application” relies on an initial component “a last translation and verification,” which lacks a clear relationship to the remaining components of the claim. As best as can be understood in light of the unclear relationship, and in the context of the second object level hierarchy of Lachwani, the broadest reasonable interpretation of “one or more previously accepted hierarchy files are from a last translation and verification” is a hierarchy file which is somehow derived from or used in a verification of a translation of some kind (“translation and verification” can include the process described in claim 1 but is not limited to such). The BRI of the limitation “for the same user interface of the software application” is fitness for and/or corresponding to the user interface of the software application.
At least in light of the BRI, said limitation is taught in Lachwani. As explained in the Office Action, Lachwani recites selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108.” As further explained in Lachwani, “the second object level hierarchy may be considered a baseline hierarchy, and comparison of the current hierarchy to this baseline enables the identification” of “differences in the relationships between the objects, or differences in one or more attributes associated with the objects,” such as text attributes. As well, Lachwani discloses “comparison of a current object level hierarchy to a previously generated object level hierarchy” for “analysis of text attributes of objects in the object level hierarchy, to verify a localization of the application.” Thus, Lachwani discloses selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108,” {retrieving …one or more previously accepted hierarchy files} where the “object level hierarchy is generated based at least in part on the determined relationships for the objects associated with the application(s) for validation 110.” As the “previously generated object level hierarchy” is, as the name suggests, previously generated, it was also “generated based at least in part on the determined relationships for the objects associated with the application(s) for validation” which includes validation of localization (translations). As such, the “previously generated object level hierarchy” is “from a last translation and verification” where a translation occurs in the localization process and said localization is verified. Further, as can be clearly seen in the example of FIG. 4, shown below, the baseline object level hierarchy 404 (corresponding to the “previously generated object level hierarchy”) corresponds to an earlier version of the same “MusicApp” application as the Current Object Level Hierarchy 406, thus the same user interface.
PNG
media_image1.png
1108
903
media_image1.png
Greyscale
As well, as Lachwani explains “Examples of such validation … may include comparison of a current object level hierarchy to a previously generated object level hierarchy (e.g., for regression testing of an application), or analysis of text attributes of objects in the object level hierarchy, to verify a localization of the application.” As such, the examples described in the context of application validation are equally applicable to localization validation.
Regarding the highlighting, the Lachwani provides for the highlighting of differences both in the baseline version and the current version. FIG. 4 of Lachwani and the accompanying description includes “Baseline Object Level Hierarchy 404” and “Current Object Level Hierarchy 406” where the differences “between the two object level hierarchies may be highlighted, differently colored or otherwise indicated”, which is understood to include highlighting both of the different portions of 404 and 406. The highlighting here is described as highlighting the differences “between the two object level hierarchies.” Highlighting the differences between two objects is understood as different from directional indications of highlighting, such as “identified character sets that differ from the target character set may be highlighted or otherwise indicated to the user,” which appears to indicate that only the differences in the identified character set is highlighted in this example. As such, the description from Lachwani, that differences “between the two object level hierarchies may be highlighted” includes highlighting the differences between the two, both in Hierarchy 404 and in Hierarchy 406, as well as in components thereof, such as the detailed object data 408. Therefore, in light of the above arguments, the rejection of claims 1, 14, and 20, in light of Lachwani and Stuehler is maintained with regards to the cited references. However, as the amendments require remapping of specific limitations for logical flow, the rejection of claims 1, 14, and 20 are withdrawn as previous presented.
For purposes of compact prosecution and for clarity of the record, it is noted that the limitation “previously accepted” is not interpreted as necessarily being acceptance through the “acceptance or rejection” in the described process of claim 1. “Though understanding the claim language may be aided by explanations contained in the written description, it is important not to import into a claim limitations that are not part of the claim. For example, a particular embodiment appearing in the written description may not be read into a claim when the claim language is broader than the embodiment.” (MPEP 2111.02(II) citing Superguide Corp. v. DirecTV Enterprises, Inc., 358 F.3d 870, 875, 69 USPQ2d 1865, 1868 (Fed. Cir. 2004).) More specifically, applicant has not established any particular meaning to “previously accepted” and, in fact, the first recitation of “previously accepted” in the claim occurs before the description of any arguable acceptance within the claim. Further, at no point is the presented translation, the translation which would be subject to the “acceptance or rejection” described in claim 1, ever referred to as “accepted”, such that the phrase “previously accepted” would have descriptive context to rely on. Finally, though applicant's specification does relate the “previous acceptance” to a previous performance of the described process (see paragraph [0042]), applicant also indicates that the described embodiments are optional on nearly all described aspects of that argument. As such, since “previous acceptance” is not clearly defined or limited in the specification to acceptance in a previous iteration of the method, the usage in the claims is also not so limited. Applicant is advised that, if such an interpretation is desired, the claims should be amended such that specific acceptance steps or components are clearly associated with the phrase “previously accepted” as part of the claim language.
Claims 2 and 15 are cancelled in this response. Therefore, the rejections of claims 2 and 15 are withdrawn. Applicant further argues that the rejection(s) of dependent claims 3-13 and 16-19 should be withdrawn for at least the same reasons as independent claims 1, 14, and 20. Applicant’s arguments in light of the above described remapping due to the amendments to the claims are persuasive. As such, the rejections of claims 3-13 and 16-19 under 35 U.S.C. §103 are withdrawn as previously presented and maintained as to the cited art.
The Applicant has not provided any further statement and therefore, the Examiner directs the Applicant to the below rationale.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, and mutatis mutandis claims 14 and 20, the phrase “a last translation and verification” lacks clarity. Claim 1 recites “a last translation and verification” at line 7-8. As indicated previously, applicant does not recite a first “translation and verification” such that a “last translation and verification” has the necessary context for the phrase to have clear meaning. Applicant recites presenting a translation. However, this is not the performance of a translation. Further, the claim recites “acceptance or rejection” of the presented translation. However, the translation as either accepted or rejected, is not described as verified and such an action is not tantamount to the same, without further explanation. As such, the limitations “last translation and verification” lacks clarity and is rejected.
Regarding claims 3-13 and 16-19, claims 3-13 and 16-19 depend from claims 1 and 14, and incorporate all limitations therefrom. Therefore, claims 3-13 and 16-19 are rejected for at least the same reasons as claims 1 and 14.
Appropriate correction is required.
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.
Claim 1, 3-10, 12-14, and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lachwani (U.S. Pat. No. 8,826,240, hereinafter Lachwani) in view of Stuehler (U.S. Pat. App. Pub. No. 2021/0165855, hereinafter Stuehler).
Regarding claim 1, Lachwani discloses A computer-implemented method for translating or verifying text of a software application (Systems and methods for “validating an application based on an object level hierarchy for the application”; Lachwani, ¶ Col. 15, lines 50-58;), the method comprising: receiving one or more new screenshots, one or more new hierarchy files, or both, of the software application (“the first object level hierarchy is an object level hierarchy generated based on a current version of the application under validation 110”; Lachwani, ¶ Col. 15, lines 59-67;); retrieving one or more previously accepted screenshots, one or more previously accepted hierarchy files, or both, (“second object level hierarchy is previously generated based on a previous version of the application.”; Lachwani, ¶ Col. 15, lines 59-67;) wherein the one or more previously accepted screenshots, the one or more previously accepted hierarchy files, or both, are from a last translation and verification for a same user interface of the software application (Discloses selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108,” where “the second object level hierarchy may be considered a baseline hierarchy, and comparison of the current hierarchy to this baseline enables the identification” of “differences in the relationships between the objects, or differences in one or more attributes associated with the objects,” such as text attributes, resulting in “comparison of a current object level hierarchy to a previously generated object level hierarchy” for “analysis of text attributes of objects in the object level hierarchy, to verify a localization of the application.” Thus, Lachwani discloses selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108,” {retrieving …one or more previously accepted hierarchy files} where the “object level hierarchy is generated based at least in part on the determined relationships for the objects associated with the application(s) for validation 110.” As the “previously generated object level hierarchy” is, as the name suggests, previously generated, it was also “generated based at least in part on the determined relationships for the objects associated with the application(s) for validation” which includes validation of localization (translations). As such, the “previously generated object level hierarchy” is “from a last translation and verification” where a translation occurs in the localization process and said localization is verified.; Lachwani, ¶ Col. 3, lines 1-5; Col. 9, lines 23-37; Col. 10, lines 30-61; Col. 15, lines 59-67); comparing the one or more new screenshots with the one or more previously accepted screenshots, or the one or more new hierarchy files with the one or more previously accepted hierarchy files (“At 1002, a first object level hierarchy is compared to a second object level hierarchy.”; Lachwani, ¶ Col. 15, lines 59-67;); locating text that has changed based on an output of the comparison (The comparison method of FIG. 10 is used to identify differences “in the objects, relationships, or attributes”. This is done in the context of FIG. 11, where “At 1104, an object level hierarchy for the application may be analyzed to determine” changes in “one or more text attributes included in objects associated with the application.”; Lachwani, ¶ Col. 16, lines 16-30, and 45-53; FIGS. 10-11); and in response to locating text that has changed: highlighting the text that has changed in the one or more new screenshots, the one or more new hierarchy files, or both (In FIG. 4 and the accompanying description includes “Baseline Object Level Hierarchy 404” and “Current Object Level Hierarchy 406” where the differences “between the two object level hierarchies may be highlighted, differently colored or otherwise indicated”, which is understood to include highlighting both of the different portions of 404 and 406. The highlighting here is described as highlighting the differences “between the two object level hierarchies.” Highlighting the differences between two objects is understood as different from directional indications of highlighting, such as “identified character sets that differ from the target character set may be highlighted or otherwise indicated to the user,” which appears to indicate that only the differences in the identified character set is highlighted in this example. As such, the description from Lachwani, that differences “between the two object level hierarchies may be highlighted” includes highlighting the differences between the two, both in Hierarchy 404 and in Hierarchy 406, as well as in components thereof, such as the detailed object data 408.; Lachwani, ¶ Col. 9, lines 7-14; Col. 17, lines 23-35; FIG. 4); presenting a translation of the text that has changed to a translator for acceptance or rejection of the translation (The method “report[s] the text attributes” in a “report”, depicted at FIG. 12, that is “reviewed by a user to verify that localization… has been performed accurately” where a report to a user for localization is presenting to a translator for acceptance or rejection of the translation; Lachwani, ¶ Col. 17, lines 23-35; Col. 3, lines 13-25); and storing the one or more new screenshots, the one or more new hierarchy files, or both… (“the first and second hierarchies are stored as part of the object level hierarchy data 120 on the validation server 108”; Lachwani, ¶ Col. 16, lines 1-5). However, Lachwani fails to expressly recite storing the one or more new screenshots, the one or more new hierarchy files, or both, when the translation has been accepted.
Stuehler teaches systems and methods for “facilitating the process of translating strings between human languages.” (Stuehler, ¶ [0001]). Regarding claim 1, Stuehler teaches storing the one or more new screenshots, the one or more new hierarchy files, or both, when the translation has been accepted (“One or more of the saved segments are displayed to a user at 1616. At 1620, user input is received from the user providing a translation for the displayed one or more saved segments. The stored one or more saved segments are updated with the translation at 1624.”; Stuehler, ¶ [0135]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the application/localization validation through object level hierarchy analysis of Lachwani to incorporate the teachings of Stuehler to include storing the one or more new screenshots, the one or more new hierarchy files, or both, when the translation has been accepted. The facilitated translations described in Stuehler provide for an automated solution to the problem of manual translations from Lachwani, which can overcome the tedious and time consuming task of manual translation and avoid unnecessary delays, as recognized by Stuehler. (Stuehler, ¶ [0003], [0024]).
Regarding claim 3, the rejection of claim 1 is incorporated. Lachwani disclose all of the elements of the current invention as stated above. However, Lachwani fail(s) to expressly recite further comprising: applying one or more exceptions to the comparison, the one or more exceptions excluding at least one text from the output of the comparison.
The relevance of Stuehler is described above with relation to claim 1. Regarding claim 3, Stuehler teaches further comprising: applying one or more exceptions to the comparison, the one or more exceptions excluding at least one text from the output of the comparison (“The properties file 500 is formatted such that a plurality of segments 508 are defined, where a given segment includes a tag 512, a key 516, and a value 520. The tags 512 can be used to indicate whether a given segment should be translated or not. For example, tags 512 a, having the notation “NOTR,” can be used to designate segments that are not to be translated. While tag 512 b, “TRANSLATE,” indicates that the segment should be translated.”; Stuehler, ¶ [0094]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the application/localization validation through object level hierarchy analysis of Lachwani to incorporate the teachings of Stuehler to include further comprising: applying one or more exceptions to the comparison, the one or more exceptions excluding at least one text from the output of the comparison. The facilitated translations described in Stuehler provide for an automated solution to the problem of manual translations from Lachwani, which can overcome the tedious and time consuming task of manual translation and avoid unnecessary delays, as recognized by Stuehler. (Stuehler, ¶ [0003], [0024]).
Regarding claim 4, the rejection of claim 1 is incorporated. Lachwani further discloses wherein the comparing the one or more new hierarchy files with the one or more previously accepted hierarchy files comprises: parsing the one or more new hierarchy files; and parsing the one or more previously accepted hierarchy files (“the application validation module 112 may iteratively request portions of the assembly code data 118 to analyze address data for objects listed in the assembly code data 118, determine parent-child relationships among the objects, or generate one or more object level hierarchies based on the objects and their relationships. “; Lachwani, ¶ Col. 5, lines 20-28); wherein the comparing the one or more new hierarchy files with the one or more previously accepted hierarchy files comprises performing a plain text comparison of the parsed one or more new hierarchy files and the parsed one or more previously accepted hierarchy files (“At 1104, an object level hierarchy for the application may be analyzed to determine one or more text attributes included in objects associated with the application” where “this step includes searching the object level hierarchy for attributes that have a text value, such as “ID=‘TOP STORIES’” in the object 904 of FIG. 9.” which is a plain text comparison; Lachwani, ¶ Col. 16, lines 40-54).
Regarding claim 5, the rejection of claim 1 is incorporated. Lachwani further discloses wherein the comparing comprises determining differences in page structure, element structure, or images (The comparison “identif[ies] one or more of differences in the number or identity of objects in the hierarchy, differences in the relationships between the objects, or differences in one or more attributes associated with the objects.”; Lachwani, ¶ Col. 2, lines 65-Col. 3, line 7).
Regarding claim 6, the rejection of claim 1 is incorporated. Lachwani further discloses further comprising, in response to locating the text that has changed, highlighting previous text in the one or more previously accepted screenshots, one or more previously accepted hierarchy files, or both (In FIG. 4 and the accompanying description includes “Baseline Object Level Hierarchy 404” and “Current Object Level Hierarchy 406” where the differences “between the two object level hierarchies may be highlighted, differently colored or otherwise indicated”, which is understood to include highlighting both of the different portions of 404 and 406 where the highlighting of the differences in both “Baseline Object Level Hierarchy 404” and “Current Object Level Hierarchy 406” are in response to locating any component, including text, that has changed (the system cannot highlight a component as being different without recognizing that said difference exists); Lachwani, ¶ Col. 9, lines 7-14; Col. 17, lines 23-35; FIG. 4).
Regarding claim 7, the rejection of claim 1 is incorporated. Lachwani further discloses further comprising: presenting a change history of the one or more new screenshots to the translator (The UI includes one or more controls 410 that enable a user to “select a baseline version… for comparison” from a “list of available baseline versions based on the object level hierarchy data stored” this list is a change history.; Lachwani, ¶ Col. 9, lines 22-30).
Regarding claim 8, the rejection of claim 1 is incorporated. Lachwani further discloses further comprising: collecting and capturing the one or more new screenshots, the one or more new hierarchy files, or both, of the software application (The system “instructs the host device to execute an assembly code generation module” This module “generates assembly code data” which the “application validation module...builds an object level hierarchy for the application”, which is collecting and capturing.; Lachwani, ¶ Col. 2, lines 35-47).
Regarding claim 9, the rejection of claim 8 is incorporated. Lachwani further discloses wherein the one or more new screenshots collected are not for all languages of interest (The localization validation process described in FIG. 11 involves checking text attributes against a single “target character set”, which is understood as the capture being for a single language context.; Lachwani, ¶ Col. 16, lines 31-45).
Regarding claim 10, the rejection of claim 8 is incorporated. Lachwani further discloses wherein the collecting and capturing comprises iterating through every user interface of the software application (The capture process involves a “recursive traversal of a view hierarchy for the main window”, which is “iterating through” the UI.; Lachwani, ¶ Col. 15, lines 20-25).
Regarding claim 12, the rejection of claim 1 is incorporated. Lachwani disclose all of the elements of the current invention as stated above. However, Lachwani fail(s) to expressly recite further comprising: submitting a translation request of the text that has changed to the translator; and receiving the translation of the text that has changed from the translator.
The relevance of Stuehler is described above with relation to claim 1. Regarding claim 12, Stuehler teaches further comprising: submitting a translation request of the text that has changed to the translator (The method includes “generat[ing] a translation request to a translation service”; Stuehler, ¶ [0135]); and receiving the translation of the text that has changed from the translator (“receiving…user input… providing a translation for the displayed one or more saved segments”; Stuehler, ¶ [0135]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the application/localization validation through object level hierarchy analysis of Lachwani to incorporate the teachings of Stuehler to include further comprising: submitting a translation request of the text that has changed to the translator; and receiving the translation of the text that has changed from the translator. The facilitated translations described in Stuehler provide for an automated solution to the problem of manual translations from Lachwani, which can overcome the tedious and time consuming task of manual translation and avoid unnecessary delays, as recognized by Stuehler. (Stuehler, ¶ [0003], [0024]).
Regarding claim 13, the rejection of claim 12 is incorporated. Lachwani further discloses wherein the submitting the translation request comprises sending one or more files to the translator (The method includes “generat[ing] a translation request to a translation service”; Stuehler, ¶ [0135]), the one or more files including only the text that has changed (Further, the method includes “a translator can be presented only with text requiring translation”, which is the delta. The method generates a request “including the first set” of strings “designated to be translated”; Stuehler, ¶ [0135], [0140]).
Regarding claim 14, Lachwani discloses A system for translating text of a software application (Systems and methods for “validating an application based on an object level hierarchy for the application”; Lachwani, ¶ Col. 15, lines 50-58;), the system comprising: a memory that stores one or more previously accepted screenshots, one or more previously accepted hierarchy files, or both (“second object level hierarchy is previously generated based on a previous version of the application” stored as part of the “memory 210” which “provides storage of computer readable instructions, data structures, program modules, and other data for the operation of the validation server(s) 108.”; Lachwani, ¶ Col. 15, lines 59-67; Col. 6, lines 60-63); a processor that: receives one or more new screenshots, one or more new hierarchy files, or both, of the software application (“the first object level hierarchy is an object level hierarchy generated based on a current version of the application under validation 110” using “one or more processors 202 configured to execute one or more stored instructions.”; Lachwani, ¶ Col. 15, lines 59-67; Col. 6, lines 21-24); retrieves the one or more previously accepted screenshots, the one or more previously accepted hierarchy files, or both from the memory, (“second object level hierarchy” as “previously generated based on a previous version of the application” is retrieved from the memory of the computing system.; Lachwani, ¶ Col. 15, lines 59-67;) wherein the one or more previously accepted screenshots, the one or more previously accepted hierarchy files, or both, are from a last translation and verification for a same user interface of the software application (Discloses selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108,” where “the second object level hierarchy may be considered a baseline hierarchy, and comparison of the current hierarchy to this baseline enables the identification” of “differences in the relationships between the objects, or differences in one or more attributes associated with the objects,” such as text attributes, resulting in “comparison of a current object level hierarchy to a previously generated object level hierarchy” for “analysis of text attributes of objects in the object level hierarchy, to verify a localization of the application.” Thus, Lachwani discloses selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108,” {retrieving …one or more previously accepted hierarchy files} where the “object level hierarchy is generated based at least in part on the determined relationships for the objects associated with the application(s) for validation 110.” As the “previously generated object level hierarchy” is, as the name suggests, previously generated, it was also “generated based at least in part on the determined relationships for the objects associated with the application(s) for validation” which includes validation of localization (translations). As such, the “previously generated object level hierarchy” is “from a last translation and verification” where a translation occurs in the localization process and said localization is verified.; Lachwani, ¶ Col. 3, lines 1-5; Col. 9, lines 23-37; Col. 10, lines 30-61; Col. 15, lines 59-67); compares the one or more new screenshots with the one or more previously accepted screenshots, or the one or more new hierarchy files with the one or more previously accepted hierarchy files (“At 1002, a first object level hierarchy is compared to a second object level hierarchy.”; Lachwani, ¶ Col. 15, lines 59-67;); locates text that has changed based on an output of the comparison (The comparison method of FIG. 10 is used to identify differences “in the objects, relationships, or attributes”. This is done in the context of FIG. 11, where “At 1104, an object level hierarchy for the application may be analyzed to determine” changes in “one or more text attributes included in objects associated with the application.”; Lachwani, ¶ Col. 16, lines 16-30, and 45-53; FIGS. 10-11); and in response to locating text that has changed, highlights the text that has changed in the one or more new screenshots, the one or more new hierarchy files, or both (In FIG. 4 and the accompanying description includes “Baseline Object Level Hierarchy 404” and “Current Object Level Hierarchy 406” where the differences “between the two object level hierarchies may be highlighted, differently colored or otherwise indicated”, which is understood to include highlighting both of the different portions of 404 and 406. The highlighting here is described as highlighting the differences “between the two object level hierarchies.” Highlighting the differences between two objects is understood as different from directional indications of highlighting, such as “identified character sets that differ from the target character set may be highlighted or otherwise indicated to the user,” which appears to indicate that only the differences in the identified character set is highlighted in this example. As such, the description from Lachwani, that differences “between the two object level hierarchies may be highlighted” includes highlighting the differences between the two, both in Hierarchy 404 and in Hierarchy 406, as well as in components thereof, such as the detailed object data 408.; Lachwani, ¶ Col. 9, lines 7-14; Col. 17, lines 23-35; FIG. 4); and a display that presents a translation of the text that has changed to a translator for acceptance or rejection of the translation (The method “report[s] the text attributes” in a “report”, depicted at FIG. 12, that is “reviewed by a user to verify that localization… has been performed accurately” where a report to a user for localization is presenting to a translator for acceptance or rejection of the translation; Lachwani, ¶ Col. 17, lines 23-35; Col. 3, lines 13-25); wherein the processor further stores the one or more new screenshots, the one or more new hierarchy files, or both… (“the first and second hierarchies are stored as part of the object level hierarchy data 120 on the validation server 108”; Lachwani, ¶ Col. 16, lines 1-5). However, Lachwani fail(s) to expressly recite wherein the processor further stores the one or more new screenshots, the one or more new hierarchy files, or both, in response to acceptance of the translation of the text that has changed by the translator.
The relevance of Stuehler is described above with relation to claim 1. Regarding claim 14, Stuehler teaches wherein the processor further stores the one or more new screenshots, the one or more new hierarchy files, or both, in response to acceptance of the translation of the text that has changed by the translator (“One or more of the saved segments are displayed to a user at 1616. At 1620, user input is received from the user providing a translation for the displayed one or more saved segments. The stored one or more saved segments are updated with the translation at 1624,” where the saved segment is the updated segment, and wherein the resulting combination of the saved segment and the update is the acceptance of the translation of the text from the translator (the user corresponding to the user input); Stuehler, ¶ [0135]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the application/localization validation through object level hierarchy analysis of Lachwani to incorporate the teachings of Stuehler to include wherein the processor further stores the one or more new screenshots, the one or more new hierarchy files, or both, in response to acceptance of the translation of the text that has changed by the translator. The facilitated translations described in Stuehler provide for an automated solution to the problem of manual translations from Lachwani, which can overcome the tedious and time consuming task of manual translation and avoid unnecessary delays, as recognized by Stuehler. (Stuehler, ¶ [0003], [0024]).
Regarding claim 16, the rejection of claim 14 is incorporated. Claim 16 is substantially the same as claim 3 and is therefore rejected under the same rationale as above.
Regarding claim 17, the rejection of claim 14 is incorporated. Claim 17 is substantially the same as claim 4 and is therefore rejected under the same rationale as above.
Regarding claim 18, the rejection of claim 14 is incorporated. Claim 18 is substantially the same as claim 6 and is therefore rejected under the same rationale as above.
Regarding claim 19, the rejection of claim 14 is incorporated. Claim 19 is substantially the same as claim 7 and is therefore rejected under the same rationale as above.
Regarding claim 20, Lachwani discloses A non-transitory computer readable medium, the computer readable medium including instructions that, when executed, perform a method for translating or verifying text of a software application (Systems and methods for “validating an application based on an object level hierarchy for the application” as implemented using “one or more computer-readable storage media (“CRSM”)” which “provides storage of computer readable instructions, data structures, program modules, and other data for the operation of the validation server(s) 108.”; Lachwani, ¶ Col. 15, lines 50-58; Col. 6, lines 53-62), the method comprising: receiving one or more new screenshots, one or more new hierarchy files, or both, of the software application (“the first object level hierarchy is an object level hierarchy generated based on a current version of the application under validation 110”; Lachwani, ¶ Col. 15, lines 59-67;); retrieving one or more previously accepted screenshots, one or more previously accepted hierarchy files, or both, (“second object level hierarchy is previously generated based on a previous version of the application.”; Lachwani, ¶ Col. 15, lines 59-67;) wherein the one or more previously accepted screenshots, the one or more previously accepted hierarchy files, or both, are from a last translation and verification for a same user interface of the software application (Discloses selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108,” where “the second object level hierarchy may be considered a baseline hierarchy, and comparison of the current hierarchy to this baseline enables the identification” of “differences in the relationships between the objects, or differences in one or more attributes associated with the objects,” such as text attributes, resulting in “comparison of a current object level hierarchy to a previously generated object level hierarchy” for “analysis of text attributes of objects in the object level hierarchy, to verify a localization of the application.” Thus, Lachwani discloses selecting the “baseline version of the application for comparison” from “a list of available baseline versions based on the object level hierarchy data 120 stored on the validation server(s) 108,” {retrieving …one or more previously accepted hierarchy files} where the “object level hierarchy is generated based at least in part on the determined relationships for the objects associated with the application(s) for validation 110.” As the “previously generated object level hierarchy” is, as the name suggests, previously generated, it was also “generated based at least in part on the determined relationships for the objects associated with the application(s) for validation” which includes validation of localization (translations). As such, the “previously generated object level hierarchy” is “from a last translation and verification” where a translation occurs in the localization process and said localization is verified.; Lachwani, ¶ Col. 3, lines 1-5; Col. 9, lines 23-37; Col. 10, lines 30-61; Col. 15, lines 59-67); comparing the one or more new screenshots with the one or more previously accepted screenshots, or the one or more new hierarchy files with the one or more previously accepted hierarchy files (“At 1002, a first object level hierarchy is compared to a second object level hierarchy.”; Lachwani, ¶ Col. 15, lines 59-67;); locating text that has changed based on an output of the comparison (The comparison method of FIG. 10 is used to identify differences “in the objects, relationships, or attributes”. This is done in the context of FIG. 11, where “At 1104, an object level hierarchy for the application may be analyzed to determine” changes in “one or more text attributes included in objects associated with the application.”; Lachwani, ¶ Col. 16, lines 16-30, and 45-53; FIGS. 10-11); and in response to locating text that has changed: highlighting the text that has changed in the one or more new screenshots, the one or more new hierarchy files, or both (In FIG. 4 and the accompanying description includes “Baseline Object Level Hierarchy 404” and “Current Object Level Hierarchy 406” where the differences “between the two object level hierarchies may be highlighted, differently colored or otherwise indicated”, which is understood to include highlighting both of the different portions of 404 and 406. The highlighting here is described as highlighting the differences “between the two object level hierarchies.” Highlighting the differences between two objects is understood as different from directional indications of highlighting, such as “identified character sets that differ from the target character set may be highlighted or otherwise indicated to the user,” which appears to indicate that only the differences in the identified character set is highlighted in this example. As such, the description from Lachwani, that differences “between the two object level hierarchies may be highlighted” includes highlighting the differences between the two, both in Hierarchy 404 and in Hierarchy 406, as well as in components thereof, such as the detailed object data 408.; Lachwani, ¶ Col. 9, lines 7-14; Col. 17, lines 23-35; FIG. 4); presenting a translation of the text that has changed to a translator for acceptance or rejection of the translation (The method “report[s] the text attributes” in a “report”, depicted at FIG. 12, that is “reviewed by a user to verify that localization… has been performed accurately” where a report to a user for localization is presenting to a translator for acceptance or rejection of the translation; Lachwani, ¶ Col. 17, lines 23-35; Col. 3, lines 13-25); and storing the one or more new screenshots, the one or more new hierarchy files, or both… (“the first and second hierarchies are stored as part of the object level hierarchy data 120 on the validation server 108”; Lachwani, ¶ Col. 16, lines 1-5). However, Lachwani fail(s) to expressly recite and storing the one or more new screenshots, the one or more new hierarchy files, or both, when the translation has been accepted.
The relevance of Stuehler is described above with relation to claim 1. Regarding claim 20, Stuehler teaches storing the one or more new screenshots, the one or more new hierarchy files, or both, when the translation has been accepted (“One or more of the saved segments are displayed to a user at 1616. At 1620, user input is received from the user providing a translation for the displayed one or more saved segments. The stored one or more saved segments are updated with the translation at 1624.”; Stuehler, ¶ [0135]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the application/localization validation through object level hierarchy analysis of Lachwani to incorporate the teachings of Stuehler to include and storing the one or more new screenshots, the one or more new hierarchy files, or both, when the translation has been accepted. The facilitated translations described in Stuehler provide for an automated solution to the problem of manual translations from Lachwani, which can overcome the tedious and time consuming task of manual translation and avoid unnecessary delays, as recognized by Stuehler. (Stuehler, ¶ [0003], [0024]).
Claims 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lachwani and Stuehler as applied to claim 8 above, and further in view of Multer (U.S. Pat. App. Pub. No. 2002/0029227, hereinafter Multer).
Regarding claim 11, the rejection of claim 8 is incorporated. Lachwani and Stuehler disclose all of the elements of the current invention as stated above. However, Lachwani and Stuehler fail to expressly recite further comprising: determining that at least one screenshot does not have the text that has changed; and discarding the at least one screenshot, a corresponding at least one hierarchy file, or both.
Multer teaches systems and methods for data comparison and synchronization. (Multer, ¶ [0003]). Regarding claim 11, Multer teaches further comprising: determining that at least one screenshot does not have the text that has changed (Describes a “pull” synchronization process (FIG. 15) where the system checks for new data. “Once the engine server lock is acquired, the storage server will be checked to determine whether a new version of the data exists on the storage server at step 1430. If no new version exists, the synchronization process ends.”; Multer, ¶ [0190]); and discarding the at least one screenshot, a corresponding at least one hierarchy file, or both (“Differencing transmitter 100... converts the information extracted into difference information Δ.” and “Difference information Δ comprises only the changes to System B’s data which have occurred on System B and instructions for implementing those changes.” where creatin a package comprising only the changes, the system has, by definition, discarded all components that were determined to be unchanged.; Multer, ¶ [0044], [0190]).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the application/localization validation through object level hierarchy analysis of Lachwani, as modified by the translation facilitation systems of Stuehler, to incorporate the teachings of Multer to include further comprising: determining that at least one screenshot does not have the text that has changed; and discarding the at least one screenshot, a corresponding at least one hierarchy file, or both. Lachwani and Multer share the same fundamental technical challenge of comparing a baseline version of data with a new version to find the difference. Though, Lachwani teaches finding differences, it fails to address what to do with files that don’t have changes. Multer teaches a well-known solution as applied to the challenge shared between Multer and Lachwani, describing a differencing engine which solves the problem by creating a change log that may only include new components, changed components, and deleted components, providing an efficient solution to the handling of low value data points, as recognized by Multer. (Multer, ¶ [0044]-[0045]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Yu (U.S. Pat. App. Pub. No. 2018/0107580) teaches systems and methods are provided for identifying changes in a user interface between versions of an application, web page, or other product/service that includes the user interface including matching changes in the visual appearance of the user interface with changes in the text strings presented in the user interface.
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 Sean E. Serraguard whose telephone number is (313)446-6627. The examiner can normally be reached 07:00-17:00 M-F.
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, Daniel C. Washburn can be reached at (571) 272-5551. 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.
/Sean E Serraguard/Primary Examiner, Art Unit 2657
Prosecution Insights