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 .
This action is responsive to the Applicant’s amendments filed on 11/24/2025. Claims 1-20 remain pending in the application. Claims 1-2, 5, 7-9, 12, 16-17, and 20 have been amended. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 8-9, 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 20160092405 A1) hereafter Lee in view of Boyd (US 20130325525 A1), further in view of Romero et al. (US 20240129402 A1) hereafter Romero, further in view of Lim et al. (US 20240143347 A1) hereafter Lim.
Regarding claim 1, Lee teaches:
A computing system configured to provide a user interface, the computing system comprising: at least one processor (Paragraph 197, processor 2102) programmed to execute operations comprising:
executing a software application comprising a plurality of source objects, the plurality of source objects comprising a first source object that is renderable with at least one text string (Paragraph 40; “execute a number of modules” corresponds to executing a software application. It may include various content data elements which correspond to source objects that are renderable, including “text, images, videos”, etc. Paragraph 41 further discloses “When providing content data elements, the author 102 may type in text, upload images, or upload an existing file that contains the content data elements through a user interface presented to the author 102 by the content collection/generation module” which corresponds to the at least one text string);
executing a verticalization application programming interface (API) (Paragraph 41; “The author 102 may also provide other data, such as the metadata for the content data elements, through the user interface. Alternatively, or additionally, the author 102 may submit content elements and/or any other data associated therewith through the user computing device 130 by utilizing an application programming interface (“API”) exposed by the layout generation services.”, where the use of an API for generation of graphical elements, corresponding to a verticalization API, must be executing in order to be utilized);
receiving, by the verticalization API, a verticalization object associated with the first source object and a first terminology (Paragraph 44; where the system, which may utilize an API as discussed above, takes “content data 114”, corresponding to the source object, and “intent data 116”, corresponding to the terminology, as inputs for rendering in any fashion including vertical, which corresponds to receiving a verticalization object associated with the first source object and first terminology);
receiving, by the software application, a request for the first source object (Paragraph 100, Fig. 9A; “FIG. 9A illustrates an authoring user interface 900A that may be utilized by an author 102 to input content data 114, specify user intent data 116, and/or request a layout 304 to be generated for the input content data 114”, where the authoring UI, corresponding to the software application, receives a request tied to content data, corresponding to the first source object);
displaying, by the software application, the rendered first source object at a hardware display (Paragraph 47; “The rendering device 110 may be a PC, a desktop workstation, a laptop or tablet, a notebook, a PDA, an electronic-book reader, a smartphone, a wearable computing device (such as a smart watch, a smart glass, a virtual reality head-mounted display), a game console, a set-top box, a consumer electronics device, a server computer, or any other computing device having a display associated therewith and capable of rendering content according to content and layout data 122.”, where the rendering device necessarily includes a hardware display in accordance with the list of rendering devices of Lee. In order to be presented to a consumer, it must necessarily be displayed to a consumer).
Lee does not teach calling, by the API, a source plug-in to import the verticalization object; calling, by the API, a source plug-in to update a verticalization data structure based on the verticalization object associated with the first source object and the first terminology; receiving, by a verticalization layer executing at the computing system, a request to modify a terminology used by the software application to render source objects from a first terminology to a second terminology; querying the verticalization data structure, by the software application, for a first terminology text string to be included with the first source object when the first source object is rendered, the verticalization data structure describing an association between the first source object, the first terminology, and the first terminology text string and an association between the first source object, a second terminology, and a second terminology text string; rendering, by the software application, the first source object to generate a rendered first source object, the rendered first source object comprising the first terminology text string; accessing, by the verticalization layer, a verticalization object associated with the first source object and the second terminology to obtain at least one second terminology text string associated with the first source object and the second terminology; and replacing, by the verticalization layer, the at least one text string at the verticalization data structure with the at least one second terminology text string.
However, Boyd teaches:
calling, by the verticalization API, a source to import the verticalization object (Paragraph 97; enterprise management system comprises “an API that serves as a protocol format abstraction layer” and that API is used to enable interfaces to communicate with system components through an application protocol layer. The API supports communication via various methods including GET and POST. The use of GET and POST inherently involves invoking, corresponding to calling, functionality through the API to perform operations. “as well as allowing terminology to be modified responsive to customer requests” confirms the verticalization aspect of the API and object. Paragraph 65 further discloses that data is acquired in an input stage and can enter or exit via a push/pull basis. The input stage interacts with existing data repositories and structured external sources. Retrieving data from data sources or external feeds corresponds to importing objects from a source into the system.);
calling, by the verticalization API, a source to update a verticalization data structure based on the verticalization object associated with the first source object and the first terminology (Paragraphs 65, 97; an API abstraction layer communicates with system core components via GET/POST and plugins. The API is used to invoke functionality on core components when transmitting serialized objects. This corresponds to the verticalization calling a source plugin because API mediated requests necessarily call upon an underlying component to carry out the requested action. Paragraph 65 discloses retrieval of data from external sources to integrate into the system. The verticalization data structure is analogous to the system internal data store that holds the mappings of UI elements to terminology/text strings. Paragraph 97 further teaches terminology modification responsive to customer requests. A command may differ depending on user context, thereby corresponding to a verticalization object that associates a source object, the command, with a particular terminology, the title of the command.);
receiving, by a verticalization layer executing at the computing system, a request to modify a terminology used by the software application to render source objects from a first terminology to a second terminology (Paragraphs 65, 97; where Paragraph 97 discloses an API that serves as a protocol abstraction layer to perform operations. The API layer functions as the abstraction layer which corresponds to the verticalization layer. Receiving a client request at this layer corresponds to receiving, by a verticalization layer executing at the computing system. Paragraph 97 further explicitly teaches “allowing terminology to be modified responsive to customer requests”. A request to change the terminology of commands or UI elements corresponds to a request to modify a terminology. Paragraph 97 further teaches the first terminology corresponds to the existing command or UI label and the second terminology corresponds to the updated or customer-preferred label, and further teaches changing the command title while preserving functionality, corresponding to rendering source objects from a first terminology to a second terminology.);
accessing, by the verticalization layer, a verticalization object associated with the first source object and the second terminology to obtain the second terminology text string associated with the first source object and the second terminology (Paragraphs 65, 97; the API abstraction layer acts as middleware executing on the computing system, corresponding to the verticalization layer. Paragraph 97 further teaches terminology modification responsive to customer requests, which represents a mapping of a source object to a terminology specific label, corresponding to the verticalization object. Paragraph 65 further discloses retrieving data from external sources for system integration. This teaches that the system is capable of accessing stored objects corresponding to a source object. Paragraph 97 teaches changing command or UI terminology ensures that the system retrieves the label corresponding to the requested, corresponding to the second, terminology. When the API receives a request to change terminology, it must access the stored mapping, the verticalization object, to obtain the appropriate text string for rendering.);
and replacing, by the verticalization layer, the at first terminology text string at the verticalization data structure with the second terminology text string (Paragraph 97; the API abstraction layer corresponds to the verticalization layer. Updating stored information such as command labels, which are shown as strings as evidenced by “may have a title of "GetMediaList" when used in developing an online media player, or may be given a title of "GetMessageList"”, through the API is equivalent to replacing a text string at the verticalization data structure. Paragraph 65 further discloses the retrieval of data from external sources into internal structures through input stage 302. These internal structures correspond to stored objects. Paragraph 97 further teaches terminology modification response to customer requests. Updating the stored label of the first terminology to the new terminology string corresponds to replacing the original text string with the second terminology text string.).
Lee and Boyd are considered to be analogous to the claimed invention because they are in the same field of text rendering. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lee to incorporate the teachings of Boyd and utilize a verticalization API to import an object and update a data structure based on source object information and terminology, and to further receive a request to modify the terminology, access a new terminology, and replace the text string at the verticalization data structure with the new terminology text string. A person of ordinary skill in the art would have been motivated by the use of an API to import and update objects allowing extensibility and maintainability. Further, a person of ordinary skill in the art would recognize that replacing old text strings associated with previous terminology with new ones automatically reduces the risk of human error and would support enterprise applications which are widely deployed in multi-language contexts.
Lee in view of Boyd does not teach a plug-in; querying the verticalization data structure, by the software application, for a first terminology text string to be included with the first source object when the first source object is rendered, the verticalization data structure describing an association between the first source object, the first terminology, and the first terminology text string and an association between the first source object, a second terminology, and a second terminology text string; rendering, by the software application, the first source object to generate a rendered first source object, the rendered first source object comprising the first terminology text string.
However, Romero teaches:
plug-ins (Paragraph 123, element 512; “The mobile device 160 interacts with the builder tools by transmitting a metadata request on a path 510 from a native builder plugin 512”).
Lee, Boyd, and Romero are considered to be analogous to the claimed invention because they are in the same field of text rendering. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lee in view of Boyd to incorporate the teachings of Romero and utilize a plug-in mechanism, which would allow for modular extension and reusability to enable importing and updating objects through an API.
Lee in view of Boyd further in view of Romero does not teach querying the verticalization data structure, by the software application, for a first terminology text string to be included with the first source object when the first source object is rendered, the verticalization data structure describing an association between the first source object, the first terminology, and the first terminology text string and an association between the first source object, a second terminology, and a second terminology text string; rendering, by the software application, the first source object to generate a rendered first source object, the rendered first source object comprising the first terminology text string.
However, Lim teaches:
querying the verticalization data structure, by the software application (Paragraphs 114, 117, 133; the generated dataset corresponds to a data structure. Paragraph 117 discloses retrieval of a set of information for the runtime session for reporting. Paragraph 133 discloses transmitting a request for the GUI state and the back-end receiving that request. Retrieving stored dataset information in response to a request corresponds to querying a stored data structure by the software application.), for a first terminology text string to be included with the first source object when the first source object is rendered (Paragraphs 113, 121; the dataset includes data structures for identified GUI elements, including multiple text element data structures, which encodes the textual content associated with the GUI element. Because the dataset arranges data structures in rendering order, the encoded text element is included when the GUI is rendered. Retrieval of the dataset must then include retrieval of the text string associated with the source object for rendering.), the verticalization data structure describing an association between the first source object, the first terminology, and the first terminology text string (Paragraphs 113-114; each GUI element has a respective data structure in the dataset, and the dataset describes an association between a specific GUI element, corresponding to the first source object, and its corresponding text element data structure, corresponding to the text string. Paragraph 114 confirms that this is stored in structured storage. The particular GUI state captured for a given state corresponds to a first terminology, a first textual representation associated with that particular GUI state.) and an association between the first source object, a second terminology, and a second terminology text string (Paragraphs 113-116; multiple such datasets including data structures may exist. Paragraph 115 further discloses that the client application may generate and store datasets encoding GUI states with different conditions or states. Paragraph 116 discloses reporting such datasets corresponding to different contextual information. Thus the stored datasets collectively describe associations between the same source object and multiple text string representations corresponding to different contextual states, corresponding to first and second terminologies.);
rendering, by the software application, the first source object to generate a rendered first source object, the rendered first source object comprising the first terminology text string (Paragraph 113; dataset 520 comprises respective data structures for identified GUI elements arranged in order corresponding to a rendering order of identified GUI elements, tying the data structure to element rendering, corresponding to the first source object. Further, Paragraph 121 discloses determining information for rendering a visual representation and encoding information for rendering into a data structure. The client application determines rendering info for GUI elements and produces rendered visual representations based on those associated data structures, thus corresponding to rendering the first source object to generate a rendered first source object. Paragraph 113 discloses the first terminology text string. “text element 410”, “text element 414b”, and “text element 414c” correspond to text strings associated with particular GUI elements. The rendered GUI element comprises the text string in its corresponding data structure.).
Lee, Boyd, Romero, and Lim are considered to be analogous to the claimed invention because they are in the same field of rendering. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Lee in view of Boyd, further in view of Romero to incorporate the teachings of Lim and configure the data structure of Lee in view of Boyd further in view of Romero to associate a GUI element with alternative text strings corresponding to different terminologies and to query the data structure for a selected terminology text string at render time as disclosed in Lim. A person of ordinary skill in the art would have recognized the use of storing alternative textual representations as a known method in the art for supporting configurable user interfaces. Implementation of such would have yielded the predictable result of enabling the same GUI element to be rendered with different text strings depending on context without modifying application logic.
Claim 8 recites similar limitations as those of claim 1. Claim 8 is rejected for similar reasons as those of claim 1.
Claim 16 recites similar limitations as those of claim 1, additionally reciting a non-transitory computer-readable storage medium. Boyd teaches:
a non-transitory computer-readable storage medium (Paragraph 22; “In another aspect, there is provided a computer program product that includes a non-transitory computer readable storage medium”).
Claim 16 is rejected for similar reasons as those of claim 1.
Regarding claim 2, Lee in view of Boyd, further in view of Romero, further in view of Lim teaches the system of claim 1. Lim teaches:
the replacing of the first terminology text string at the verticalization data structure with the second terminology text string comprising writing the second terminology text string over the first terminology text string (Paragraphs 114-115; generated datasets are written to local data storage and permits updating or overwriting stored data. The client application may generate and store datasets encoding GUI states at different conditions during a runtime session, thereby updating stored GUI-state information as the application continues execution. Updating stored GUI element data structures to reflect a different GUI state corresponds to replacement of previously stored text element data with different text element data corresponding to a subsequent state.).
Claim 9 recites similar limitations as those of claim 2. Claim 9 is rejected for similar reasons as those of claim 2.
Claim 17 recites similar limitations as those of claim 2. Claim 17 is rejected for similar reasons as those of claim 2.
Regarding claim 15, Lee in view of Boyd, further in view of Romero, further in view of Lim teaches the method of claim 8. Lee teaches:
receiving, by a verticalization application programming interface (API) executing at the computing system, a new verticalization object associated with the first source object and a third terminology (Paragraph 44; where the system, which may utilize an API as discussed above, takes “content data 114”, corresponding to the source object, and “intent data 116”, corresponding to the terminology, as inputs for rendering in any fashion including vertical, which corresponds to receiving a verticalization object associated with the first source object and first terminology).
Boyd teaches:
calling, by the verticalization API, a source to import the verticalization object (Paragraph 97; enterprise management system comprises “an API that serves as a protocol format abstraction layer” and that API is used to enable interfaces to communicate with system components through an application protocol layer. The API supports communication via various methods including GET and POST. The use of GET and POST inherently involves invoking, corresponding to calling, functionality through the API to perform operations. “as well as allowing terminology to be modified responsive to customer requests” confirms the verticalization aspect of the API and object. Paragraph 65 further discloses that data is acquired in an input stage and can enter or exit via a push/pull basis. The input stage interacts with existing data repositories and structured external sources. Retrieving data from data sources or external feeds corresponds to importing objects from a source into the system.);
and calling, by the verticalization API, a source to update a verticalization data structure based on the verticalization object associated with the first source object and the first terminology (Paragraphs 65, 97; an API abstraction layer communicates with system core components via GET/POST and plugins. The API is used to invoke functionality on core components when transmitting serialized objects. This corresponds to the verticalization calling a source plugin because API mediated requests necessarily call upon an underlying component to carry out the requested action. Paragraph 65 discloses retrieval of data from external sources to integrate into the system. The verticalization data structure is analogous to the system internal data store that holds the mappings of UI elements to terminology/text strings. Paragraph 97 further teaches terminology modification responsive to customer requests. A command may differ depending on user context, thereby corresponding to a verticalization object that associates a source object, the command, with a particular terminology, the title of the command.).
Romero teaches:
plug-ins (Paragraph 123, element 512; “The mobile device 160 interacts with the builder tools by transmitting a metadata request on a path 510 from a native builder plugin 512”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have performed the same processing for the first source object on an additional terminology, corresponding to the third terminology. Lee in view of Boyd, further in view of Romero, further in view of Lim already teaches performing the same technique on two such terminologies, and an extension of the same operation on an additional third terminology represents a predictable use of existing prior art elements according to their established functions, yielding the predictable result of allowing the system to display terminologies in more varied user contexts. Such a modification represents an obvious duplication or repetition of known elements to obtain predictable results.
Claims 3-5, 10-12, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Boyd, further in view of Romero, further in view of Lim, further in view of Dreisen et al. (US 20100138821 A1) hereafter Dreisen.
Regarding claim 3, Lee in view of Boyd, further in view of Romero, further in view of Lim teach the system of claim 1. Lee teaches:
source text strings and terminology text strings (Paragraph 44; where the system, which may utilize an API as discussed above, takes “content data 114”, corresponding to the source object, and “intent data 116”, corresponding to the terminology, as inputs for rendering in any fashion including vertical, which corresponds to an object associated with the first source object and first terminology)
Lee in view of Boyd further in view of Romero further in view of Lim does not teach the verticalization data structure comprising a view data structure generated from a source table and a first delta table.
However, Dreisen teaches:
the verticalization data structure comprising a view data structure generated from a source table and a first delta table, the source table comprising a set of source text strings, and the first delta table comprising a set of first terminology text strings associated with the first terminology (Paragraph 43; “table structure definitions… deployed from the delta software upgrade package… [and] imported into the shadow repository tables” corresponds to a delta-based table representation used with a shadow repository, corresponding to a source repository, which represents a structure comprising a source and delta table which is conceptually similar to a view data structure generated using the tables).
Lee, Boyd, Romero, Lim, and Dreisen are considered to be analogous to the claimed invention because they are in the same field of text rendering. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Lee in view of Boyd, further in view of Romero, further in view of Lim with Dreisen to have a data structure comprising a view data structure generated from a source table and a first delta table, and have utilized the source text strings and terminology text strings of Lee in the tables. A person of ordinary skill in the art would recognize that maintaining delta tables as overlays would be a conventional method to manage incremental changes while preserving the base dataset, thus allowing the modular separation to reduce maintenance costs and ensure efficient switches between terminologies.
Claim 10 recites similar limitations as those of claim 3. Claim 10 is rejected for similar reasons as those of claim 3.
Claim 18 recites similar limitations as those of claim 3. Claim 18 is rejected for similar reasons as those of claim 3.
Regarding claim 4, Lee in view of Boyd, further in view of Romero, further in view of Lim, further in view of Dreisen teach the system of claim 3. Dreisen teaches:
the operations further comprising generating the view data structure from the source table and the first delta table (Paragraph 43; “programs can use this table definition to compare the current table structure[...] with the target structure and compute the mechanism to adjust to the new structure of the shadow tables” corresponds to generating a usable structure by combining the current structure, corresponding to the source table, with delta information, corresponding to the first delta table, whose combination results in a target structure corresponding to the view data structure).
Claim 11 recites similar limitations as those of claim 4. Claim 11 is rejected for similar reasons as those of claim 4.
Claim 19 recites similar limitations as those of claim 4. Claim 19 is rejected for similar reasons as those of claim 4.
Regarding claim 5, Lee in view of Boyd, further in view of Romero, further in view of Lim, further in view of Dreisen teach the system of claim 3. Lee teaches:
the replacing of the first terminology text string at the verticalization data structure with the second terminology text string comprising:
terminology and verticalization object (Paragraph 44; where the system, which may utilize an API as discussed above, takes “content data 114”, corresponding to the source object, and “intent data 116”, corresponding to the terminology, as inputs for rendering in any fashion including vertical, which corresponds to receiving a verticalization object associated with the first source object and first terminology).
Dreisen teaches:
replacing the first delta table with a second delta table associated with the second terminology, the second delta table being based at least in part on the verticalization object (Paragraph 43; “create a new table… drop original and rename the new table… [tables] are switched (e.g., replaced)” corresponds to replacing the first delta table with a second delta table);
and generating an updated view data structure from the source table and the second delta table (“programs can use this table definition to compare… and compute the mechanism to adjust the new structure… a conversion may be used to create a new table with the target structure” corresponds to generating a new/updated table structure using the source and new delta/target structure).
Claim 12 recites similar limitations as those of claim 5. Claim 12 is rejected for similar reasons as those of claim 5.
Claim 20 recites similar limitations as those of claim 5. Claim 20 is rejected for similar reasons as those of claim 5.
Claims 6-7 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Boyd, further in view of Romero, further in view of Lim, further in view of Willekes et al. (US 20100313155 A1) hereafter Willekes.
Regarding claim 6, Lee in view of Boyd, further in view of Romero further in view of Lim teaches the system of claim 1. Boyd teaches:
terminology text strings (Paragraph 57; “instrumentation engine 110 may retrieve a dictionary containing the names of the existing flows” and “the words included in the name of a user interface may be tokenized… [and] embedded into a word vector” whose word vector containing words correspond to terminology text strings).
Lee in view of Boyd, further in view of Romero, further in view of Lim does not teach the verticalization object comprising a header table and a content table, the header table comprising an indication of the first source object and the second terminology.
However, Willekes teaches:
the verticalization object comprising a header table and a content table, the header table comprising an indication of the first source object and the second terminology (Paragraph 106; “the processing structure then replaces the content of the target table object with data obtained from the source graphic object. The table header is set to the axes labels of the source graph object”, explicitly distinguishes between content of the target table object and the table header, corresponding to the header table and content table. The header contains “axes labels of the source graph object” and that a link to the source object is recorded, corresponding to an indication of the first source object. It further discloses “the processing structure then replaces the content of the target table” in which it replaces the content of the table with data derived from another object, corresponding to a content table comprising the second text string).
Lee, Boyd, Romero, Lim, and Willekes are considered to be analogous to the claimed invention because they are in the same field of text rendering. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Lee in view of Boyd further in view of Romero further in view of Lim with Willekes to have a verticalization object comprise a header table and content table on which the header table contains an indication of the first source object and second terminology and to have the content table comprise terminology text strings as taught by Boyd. A person of ordinary skill in the art would have been motivated by standard relational database practices of separation of identifying information into a header table and content table, allowing efficient indexing and retrieval and providing normalization and reduced redundancy as the same metadata would not need to be stored with each entry in the table.
Claim 13 recites similar limitations as those of claim 6. Claim 13 is rejected for similar reasons as those of claim 6.
Regarding claim 7, Lee in view of Boyd, further in view of Romero, further in view of Lim further in view of Willekes teach the system of claim 6. Lee teaches:
receiving, by the verticalization API, a request to create a new verticalization object associated with the first source object and a third terminology (Paragraphs 41 and 100; “the author may submit content elements and/or any other data… by utilizing an application programming interface” corresponds to receiving a request at the API. The content object created when content and related data are submitted through the API correspond to the new verticalization object. Further, “the author 102 may input content data 114, specify user intent data 116…”, where the content data corresponds to the first source object, and the intent data corresponds to the terminology, both of which are associated with the resulting content object, corresponding to the new verticalization object associated with the first source object and third terminology);
and receiving, by the verticalization API, a new text string to the new verticalization object (Paragraph 161; “Next, at operation 1708, the content collection module 206 obtains the related content 1604 from the selected content resources 126 using the identification of the selected content resources 126.”, where Paragraph 40 further discloses “the content data elements through a user interface presented to the author 102 by the content collection/generation module” which corresponds to the at least one text string).
Boyd teaches:
calling, by the verticalization API, the source to return a name for the new verticalization object (Paragraph 97; API abstraction layer corresponds to the verticalization API. Calling a source component to retrieve data or labels is a conventional function of a basic API layer. Paragraph 65 discloses retrieving data from external sources which can provide structured data or labels associated with objects. Paragraph 97 discloses the API plugin mechanism which retrieves or modifies command and UI labels. In combination, it demonstrates that the system is capable of accessing a source to obtain a name or label for a system object. A newly defined terminology mapping is analogous to a new verticalization object and the API calls the underlying source/plugin to return or assign a name to it. The usage of a GET request as taught in Paragraph 97 causes the component to return data to the calling API.).
Romero teaches:
plug-ins (Paragraph 123, element 512; “The mobile device 160 interacts with the builder tools by transmitting a metadata request on a path 510 from a native builder plugin 512”).
Claim 14 recites similar limitations as those of claim 7. Claim 14 is rejected for similar reasons as those of claim 7.
Response to Arguments
Applicant's arguments filed 11/24/2025 have been fully considered but they are not persuasive. Applicant’s arguments are summarized below:
None of the cited references of record teach or suggest the amended limitations of the independent claims.
Dependent claims ae submitted as allowable for at least the above reasons.
Examiner’s response:
The Examiner agrees that the cited references of record do not teach or suggest the amended limitations of the independent claims. Therefore, the previous rejections of claims 1, 8, and 16 under 35 U.S.C. 103 have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Lee, Boyd, Romero, and Lim under 35 U.S.C. 103.
Independent claims 1, 8, and 16 remain rejected for the reasons stated above. Therefore, contrary to Applicant's arguments, because the dependent claims depend from an unpatentable claim and does not add limitations that overcome the rejection, it likewise remains rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Cornell (US 20130002678 A1) discusses an image rendering system utilizing vector data forming objects that receive text strings providing labels the for objects following a line which may be rendered vertically.
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 KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
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, April Blair can be reached at (571) 270-1014. 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.
/KENNETH P TRAN/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196