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 .
DETAILED ACTION
This action is responsive to communications regarding the applicant’s amendments and arguments, filed on 09/03/2026.
Claims 1-20 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/03/2026 has been entered.
Notice of Pre-AIA or AIA Status
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 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.
Response to Arguments and Amendments
Applicant's arguments filed on 09/03/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s main argument is that Liu does not disclose or suggest “based on a second application of the user device, corresponding to a first user action selected from among the predicted one or more possible next user actions, displaying a second screen associated with the second application”, at least because “Claim 1 recites that, after a first screen is displayed for a first application tied to the user's current action, the device predict one or more possible next user actions based on that first screen and the determined relationships, and that a second screen be displayed for a second application only once a first user action is selected from among those predicted next actions. Liu et al. does not show this, and in the very passage the Office Action relies on for the displaying limitations, Liu et al. says essentially the opposite.”
Examiner respectfully disagrees with the above argument.
In response to Applicant’s above argument, it is noted that Liu teaches the amended claimed features in par. 0097, i.e. “[0097] Turning now to FIG. 7B, the GUI 702 may now predict an auto-fill content request, as in block 716. That is, a prefill request may be predicted. On a second application 750 (e.g., a target application), the predicted, auto-fill request may fill in a name associated with context of a first application 720 (e.g., a source application), as in block 718. A phone number may also be filled from a list of communications and/or audio text (e.g., a contact list), as in block 721. A shipping address may be auto-filled based on the communication, as in block 722.” Specifically, Liu teaches based on a second application of the user device (2nd app 750), corresponding to a first user action selected from among the predicted one or more possible next user actions (“On a second application 750 (e.g., a target application), the predicted, auto-fill request may fill in a name associated with context of a first application 720 (e.g., a source application), as in block 718”), displaying a second screen associated with the second application (“A phone number may also be filled from a list of communications and/or audio text (e.g., a contact list), as in block 721. A shipping address may be auto-filled based on the communication, as in block 722”.)
For the above reasons, Examiner believed that rejection of the last Office action was proper and within their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 and 12 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by U.S. Patent Application Publication No. 20190188251 to Liu et al. (hereinafter “Liu”).
As to claim 1, Liu teaches a method comprising (computer implemented method in a system comprising processor and non-transitory computer readable storage medium, par. 0103-0108):
collecting at least one content from a plurality of sources on a user device (par. 0057-0059, multiple data sources, i.e. “Multiple data sources 401-405 may be provided by one or more different applications and/or computing devices. The data sources 401-405 may be provided as a corpus or group of data sources defined and/or identified. The data sources 401-405 may include, but are not limited to, data sources relating to one or more emails, short message service (“SMS”) messages, interne of things (IoT) service, social media data (e.g., a post), online journals, journals, articles, drafts, audio data, image data (e.g., a screen shot of a graphical user interface displaying information), video data, video chatting threads, channels, protocols, formats, and/or other various data sources capable of being processed, published, displayed, interpreted, transcribed, or reduced to text data. The data sources 401-405 may be all of the same type, for example, pages or articles in a wiki or pages of a blog. Alternatively, the data sources 401-405 may be of different types, such as word documents, SMS messages, emails, inputs of one or more internet of things (IoT) devices, chat threads, wikis, web pages, power points, printable document format, or any document capable of being analyzed by a natural language processing system.”);
identifying a plurality of data types of the collected at least one content (par. 0059-0069, identifying plurality of types of data such as data pattern, behaviors, topics, content, related subjects, class, concept, i.e. “In one aspect, the database 420 may be a knowledge domain that may store, maintain, update, and provide data relating to the knowledge domain. In one aspect, the knowledge domain may be an ontology of concepts representing a domain of knowledge such as, for example, learned data, data pattern, behaviors, user interaction patterns, topics, content, or even feedback learned or received using the machine learning component. A thesaurus or ontology may be used as the domain knowledge and may also be used to identify semantic relationships between observed and/or unobserved variables. In one aspect, the term “domain” is a term intended to have its ordinary meaning. In addition, the term “domain” may include an area of expertise for a system or a collection of material, information, content and/or other resources related to a particular subject or subjects. A domain can refer to information related to any particular subject matter or a combination of selected subjects. The term ontology is also a term intended to have its ordinary meaning. In one aspect, the term ontology in its broadest sense may include anything that can be modeled as ontology, including but not limited to, taxonomies, thesauri, vocabularies, and the like. For example, an ontology may include information or content relevant to a domain of interest or content of a particular class or concept. The ontology can be continuously updated with the information synchronized with the sources, adding information from the sources to the ontology as models, attributes of models, or associations between models within the ontology” );
determining one or more relationships among the plurality of data types (par. 0088-0093, determining relationships, i.e. “The logic list may be a list of events ordered based on a logical relationship such as, for example: 1) receive a request, 2) identify source application and field, 3) find information in the source application and field, and 4) copy the information from the source application and field. The user-screen interaction pattern repository may be a centralized database to store the patterns of interaction for serving multiple devices such as, for example, device 1, device 2, device 3, device 4 and so on”);
displaying a first screen associated with a first application of the user device corresponding to a current user action for using the user device (Fig. 5, par. 0013, 0046, 0057, 0073-0076, 0082-0083, 0096, displaying applications on user device);
predicting, by the user device, one or more possible next user actions for using the user device based on the first screen and the determined one or more relationships (Fig. 5, par. 0082-0083, 0088-0093, predict and providing recommendations based on application/relationships, using User-screen Interaction Analyzer);
based on a second application of the user device, corresponding to a first user action selected from among the predicted one or more possible next user actions, displaying a second screen associated with the second application (Fig. 5, 7A-7B, par. 0013, 0046, 0057, 0073-0076, 0082-0083, 0093, 0096-0097, i.e. “[0097] Turning now to FIG. 7B, the GUI 702 may now predict an auto-fill content request, as in block 716. That is, a prefill request may be predicted. On a second application 750 (e.g., a target application), the predicted, auto-fill request may fill in a name associated with context of a first application 720 (e.g., a source application), as in block 718. A phone number may also be filled from a list of communications and/or audio text (e.g., a contact list), as in block 721. A shipping address may be auto-filled based on the communication, as in block 722.” Specifically, Liu teaches based on a second application of the user device (2nd app 750), corresponding to a first user action selected from among the predicted one or more possible next user actions (“On a second application 750 (e.g., a target application), the predicted, auto-fill request may fill in a name associated with context of a first application 720 (e.g., a source application), as in block 718”), displaying a second screen associated with the second application (“A phone number may also be filled from a list of communications and/or audio text (e.g., a contact list), as in block 721. A shipping address may be auto-filled based on the communication, as in block 722”.));
detecting at least one input field requiring at least one user input in the second screen (Fig. 5, par. 0082-0083, 0088-0093, predict and providing recommendations in the screen based on application, using User-screen Interaction Analyzer, i.e. “Moving to block 638, an auto-filling target locator may locate potential filling objects or input fields of a target application and also assist with screening and analyzing where a “blank space” may be identified in a communication. A recommendation generator may generate one or more recommended auto-fill candidate lists according to target potential filling objects, as in block 640. Moving to block 642, an auto-fill recommendation agent may recommend auto-fill candidate lists into the located objects and accept a user's selection to fill out the correlated fields in the target application. A service profile may be used, as in block 646. The service profile may be a file for including service criteria (e.g., focused application types, fields, conversion types, auto filled types) such as, for example, an address, name, phone number, and the like. In one aspect, the service criteria may be a set of rules which can be used by other modules (e.g., User-screen Interaction Analyzer). The User-screen Interaction Analyzer may determine, identify, and/or know the types of applications that may be selected as source applications and which applications can be selected as a target application(s). Therefore, the service criteria can be defined as follows. 1) Focused source application types may be, for example, an email reader and/or personal contact manager. 2) The SMS automated filled application type may be, for example, social media applications and/or email readers. Also, the system may need to know which fields on those applications shall be focused. The criteria shall be defined as name, address, email address, and telephone number”);
fetching at least one candidate content, wherein the at least one candidate content is based on the at least one input field and analysis of the collected at least one content (Fig. 5, par. 0082-0083, 0088-0093, detecting and providing recommendations based on inputs/analysis, i.e. “Moving to block 638, an auto-filling target locator may locate potential filling objects or input fields of a target application and also assist with screening and analyzing where a “blank space” may be identified in a communication. A recommendation generator may generate one or more recommended auto-fill candidate lists according to target potential filling objects, as in block 640. Moving to block 642, an auto-fill recommendation agent may recommend auto-fill candidate lists into the located objects and accept a user's selection to fill out the correlated fields in the target application. A service profile may be used, as in block 646. The service profile may be a file for including service criteria (e.g., focused application types, fields, conversion types, auto filled types) such as, for example, an address, name, phone number, and the like. In one aspect, the service criteria may be a set of rules which can be used by other modules (e.g., User-screen Interaction Analyzer). The User-screen Interaction Analyzer may determine, identify, and/or know the types of applications that may be selected as source applications and which applications can be selected as a target application(s). Therefore, the service criteria can be defined as follows. 1) Focused source application types may be, for example, an email reader and/or personal contact manager. 2) The SMS automated filled application type may be, for example, social media applications and/or email readers. Also, the system may need to know which fields on those applications shall be focused. The criteria shall be defined as name, address, email address, and telephone number”); and
recommending the at least one fetched candidate content (par. 0088-0093, detecting and providing recommendations based on inputs, i.e. “Moving to block 638, an auto-filling target locator may locate potential filling objects or input fields of a target application and also assist with screening and analyzing where a “blank space” may be identified in a communication. A recommendation generator may generate one or more recommended auto-fill candidate lists according to target potential filling objects, as in block 640. Moving to block 642, an auto-fill recommendation agent may recommend auto-fill candidate lists into the located objects and accept a user's selection to fill out the correlated fields in the target application. A service profile may be used, as in block 646. The service profile may be a file for including service criteria (e.g., focused application types, fields, conversion types, auto filled types) such as, for example, an address, name, phone number, and the like. In one aspect, the service criteria may be a set of rules which can be used by other modules (e.g., User-screen Interaction Analyzer). The User-screen Interaction Analyzer may determine, identify, and/or know the types of applications that may be selected as source applications and which applications can be selected as a target application(s). Therefore, the service criteria can be defined as follows. 1) Focused source application types may be, for example, an email reader and/or personal contact manager. 2) The SMS automated filled application type may be, for example, social media applications and/or email readers. Also, the system may need to know which fields on those applications shall be focused. The criteria shall be defined as name, address, email address, and telephone number”).
Regarding claim 12, is essentially the same as claim 1, except that it sets forth the claimed invention as user device rather than method and rejected for the same reasons as applied hereinabove.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 2-6, 9-11, 13-17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20190188251 to Liu et al. (hereinafter “Liu”), and further in view of U.S. Patent Application Publication No. 20160335316 to Riva et al. (hereinafter “Riva”).
As to claim 2, Liu teaches the method as claimed in claim 1, further comprising:
analyzing at least one content captured from the plurality of sources displayed on a screen of the user device (par. 0057-0059, multiple data sources, i.e. “Multiple data sources 401-405 may be provided by one or more different applications and/or computing devices. The data sources 401-405 may be provided as a corpus or group of data sources defined and/or identified. The data sources 401-405 may include, but are not limited to, data sources relating to one or more emails, short message service (“SMS”) messages, interne of things (IoT) service, social media data (e.g., a post), online journals, journals, articles, drafts, audio data, image data (e.g., a screen shot of a graphical user interface displaying information), video data, video chatting threads, channels, protocols, formats, and/or other various data sources capable of being processed, published, displayed, interpreted, transcribed, or reduced to text data. The data sources 401-405 may be all of the same type, for example, pages or articles in a wiki or pages of a blog. Alternatively, the data sources 401-405 may be of different types, such as word documents, SMS messages, emails, inputs of one or more internet of things (IoT) devices, chat threads, wikis, web pages, power points, printable document format, or any document capable of being analyzed by a natural language processing system.”);
generating at least one provide data relating to the knowledge domain. In one aspect, the knowledge domain may be an ontology of concepts representing a domain of knowledge such as, for example, learned data, data pattern, behaviors, user interaction patterns, topics, content, or even feedback learned or received using the machine learning component. A thesaurus or ontology may be used as the domain knowledge and may also be used to identify semantic relationships between observed and/or unobserved variables. In one aspect, the term “domain” is a term intended to have its ordinary meaning. In addition, the term “domain” may include an area of expertise for a system or a collection of material, information, content and/or other resources related to a particular subject or subjects. A domain can refer to information related to any particular subject matter or a combination of selected subjects. The term ontology is also a term intended to have its ordinary meaning. In one aspect, the term ontology in its broadest sense may include anything that can be modeled as ontology, including but not limited to, taxonomies, thesauri, vocabularies, and the like. For example, an ontology may include information or content relevant to a domain of interest or content of a particular class or concept. The ontology can be continuously updated with the information synchronized with the sources, adding information from the sources to the ontology as models, attributes of models, or associations between models within the ontology”); and
fetching the at least one candidate content from the at least one service profile may be a file for including service criteria (e.g., focused application types, fields, conversion types, auto filled types) such as, for example, an address, name, phone number, and the like. In one aspect, the service criteria may be a set of rules which can be used by other modules (e.g., User-screen Interaction Analyzer). The User-screen Interaction Analyzer may determine, identify, and/or know the types of applications that may be selected as source applications and which applications can be selected as a target application(s). Therefore, the service criteria can be defined as follows. 1) Focused source application types may be, for example, an email reader and/or personal contact manager. 2) The SMS automated filled application type may be, for example, social media applications and/or email readers. Also, the system may need to know which fields on those applications shall be focused. The criteria shall be defined as name, address, email address, and telephone number”).
Liu does not explicitly teach logical tree structure as claimed.
Riva teach logical tree structure (Riva, Fig. 1, 2, 3B, par. 0006-0007, 0034-0036, 0052, logical tree structure, i.e. “The analytics service 340 may comprise suitable circuitry, interfaces, logic and/or code and may be operable to log user interactions with one or more of the apps 110a, . . . , 110b, analyze the user interactions using the templates 328, and extract one or more user data items 350, which may be stored in the store 346. The analytics service 340 may include a tracer component 342, an analyzer component 344, and a store component 346. The tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348), which may include one or more events 304 (e.g., user action such as button click, pressing a Like button, etc.) and a UI tree 306 with one or more text strings 307 (the UI tree may include the content consumed by a user in a given page class of an app, including text strings in that page class; e.g., a user may like a restaurant showing on a given restaurant app page, and the restaurant name will be a text string 307, the like action can be the event 304, and the page class where the Like action was entered can be the UI tree 306). The tracer 342 communicates the in-app data 348 to the analyzer 344 for further processing and generation of the user data item (UDI) 350, using one or more of the templates 328. The UDI may be also referred to as a Behavioral Data Item (BDI)”.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Liu with the teaching of Riva because they are in the same field of endeavor. One of ordinary skill in the art at the time of the invention would have been motivated to do so because the teaching of Riva would allow Liu to improve system efficiency and avoid the situation such as “…known methods and systems for tracking and/or analyzing user interaction, particularly when done with little to no developer effort, are computation-heavy and require a large amount of memory when stored locally or impose network overhead and potentially violate user privacy when executed on remote servers.” (Riva, par. 0003-0005)
As to claim 3, the rejection of claim 2 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 2, wherein the at least one fetched candidate content is generated by the analyzing at least one content captured from the plurality of sources displayed on the user device, wherein the at least one fetched candidate content is recommended based on information regarding the user action (par. 0088-0093, detecting and providing recommendations based on inputs, i.e. “Moving to block 638, an auto-filling target locator may locate potential filling objects or input fields of a target application and also assist with screening and analyzing where a “blank space” may be identified in a communication. A recommendation generator may generate one or more recommended auto-fill candidate lists according to target potential filling objects, as in block 640. Moving to block 642, an auto-fill recommendation agent may recommend auto-fill candidate lists into the located objects and accept a user's selection to fill out the correlated fields in the target application. A service profile may be used, as in block 646. The service profile may be a file for including service criteria (e.g., focused application types, fields, conversion types, auto filled types) such as, for example, an address, name, phone number, and the like. In one aspect, the service criteria may be a set of rules which can be used by other modules (e.g., User-screen Interaction Analyzer). The User-screen Interaction Analyzer may determine, identify, and/or know the types of applications that may be selected as source applications and which applications can be selected as a target application(s). Therefore, the service criteria can be defined as follows. 1) Focused source application types may be, for example, an email reader and/or personal contact manager. 2) The SMS automated filled application type may be, for example, social media applications and/or email readers. Also, the system may need to know which fields on those applications shall be focused. The criteria shall be defined as name, address, email address, and telephone number”), wherein the at least one logical tree structure is generated by determining the one or more relationships among the plurality of data types (Riva, Fig. 1, 2, 3B, par. 0006-0007, 0034-0036, 0052), and wherein the at least one input field requiring at least one user input is detected based on the outcome of the determined one or more relationships (par. 0067, 0074-0076, relationship in data mashup model, i.e. “The cognitive auto-fill content recommendation system 430 may also include an analyzing component 437 for determining and/or analyzing the various communications. The analyzing component 437 may work in conjunction with the auto-fill content recommendation component 432 for compiling a list of contents to automatically fill one or more target inputs in a target application or device. More specifically, the analyzing component 437 may analyze user-screen interaction (including the chronological order such as, for example, a timeline of the communication and also logical relationships between running applications) according to defined service criteria (auto-fill content rules) and personal characteristics defined in profiles. The analyzer shall be able to determine: 1) the source application and target applications, 2) target fields, target objects, or target sections to auto-fill content in the target application, 3) the objects, contents, and elements that may be selected and copied from the source application to the target application, 4) the objects, contents, and elements that may be proactively filled into recommended target fields, target objects, or target sections of the target application, and/or 5) a selected time period to display (e.g., show) the recommended proactive filled contents. In an additional aspect, the analyzing component 437 may analyze user interaction and reaction patterns on a GUI pertaining to the communications or auto-fill content. The analyzing component 437 may be used to analyze communication and user interaction patterns and reactions to the communications and/or auto-fill content.”).
As to claim 4, the rejection of claim 3 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 3, wherein the at least one fetched candidate content is recommended based on previously-generated information regarding the user action and analyzing of the at least one content captured on the user device (par. 0067, 0074-0076, user interaction patterns and reactions, i.e. “The cognitive auto-fill content recommendation system 430 may also include an analyzing component 437 for determining and/or analyzing the various communications. The analyzing component 437 may work in conjunction with the auto-fill content recommendation component 432 for compiling a list of contents to automatically fill one or more target inputs in a target application or device. More specifically, the analyzing component 437 may analyze user-screen interaction (including the chronological order such as, for example, a timeline of the communication and also logical relationships between running applications) according to defined service criteria (auto-fill content rules) and personal characteristics defined in profiles. The analyzer shall be able to determine: 1) the source application and target applications, 2) target fields, target objects, or target sections to auto-fill content in the target application, 3) the objects, contents, and elements that may be selected and copied from the source application to the target application, 4) the objects, contents, and elements that may be proactively filled into recommended target fields, target objects, or target sections of the target application, and/or 5) a selected time period to display (e.g., show) the recommended proactive filled contents. In an additional aspect, the analyzing component 437 may analyze user interaction and reaction patterns on a GUI pertaining to the communications or auto-fill content. The analyzing component 437 may be used to analyze communication and user interaction patterns and reactions to the communications and/or auto-fill content.”).
As to claim 5, the rejection of claim 2 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 2, wherein generating the at least one logical tree structure based on the at least one analyzed content comprises: receiving at least one screen of the user device, retrieving at least one content capture event, dynamically creating a segmented screen tree, identifying and associating an identifier based on screen type or categories, dynamically traversing the segmented screen tree using the associated identifier, and providing a structured interpretation of screen content (Riva, Fig. 1, 2, 3B, 6, par. 0006-0007, 0034-0036, 0052, 0074-0076, logical tree structure based on screen of the user device, including associated identifier and providing a structural interpretation of the screen content, i.e. “The analytics service 340 may comprise suitable circuitry, interfaces, logic and/or code and may be operable to log user interactions with one or more of the apps 110a, . . . , 110b, analyze the user interactions using the templates 328, and extract one or more user data items 350, which may be stored in the store 346. The analytics service 340 may include a tracer component 342, an analyzer component 344, and a store component 346. The tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348), which may include one or more events 304 (e.g., user action such as button click, pressing a Like button, etc.) and a UI tree 306 with one or more text strings 307 (the UI tree may include the content consumed by a user in a given page class of an app, including text strings in that page class; e.g., a user may like a restaurant showing on a given restaurant app page, and the restaurant name will be a text string 307, the like action can be the event 304, and the page class where the Like action was entered can be the UI tree 306). The tracer 342 communicates the in-app data 348 to the analyzer 344 for further processing and generation of the user data item (UDI) 350, using one or more of the templates 328. The UDI may be also referred to as a Behavioral Data Item (BDI)… The entity template of an app is a collection of templates, one for each page class of the app. Each template is essentially an annotated UI tree. As shown in FIG. 6, each UI element in the tree is represented with its leaf-to-root path and annotated with an entity type (e.g., Restaurant) and an entity group identifier (e.g., Group 14). A null value of entity type or group identifier indicates that the content of the UI element could not be classified as a known entity type (e.g., the text “Copyright”). The group identifiers allow clustering entities such that address and cuisine type entities are attributed to the correct restaurant entity. Similarly, UI elements such as Buttons (not shown in the figure) that contain user actions are annotated with their types and groups. To generate an entity template such as the one just described, the analytics service 340 needs to (1) generate content for the app pages, and (2) recognize entities in those pages. In an example embodiment, group identification (and group identifiers) may be used broadly, so that two or more entities may be placed in the same group if these entities are somehow related to each other. For example, a “Like” button and a restaurant name can be in the same group since the “Like” button refers to the restaurant, an address and a restaurant name are in the same group if the address belongs to the restaurant, etc.”.)
As to claim 6, the rejection of claim 2 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 2, wherein the at least one input field is classified by identifying information from at least one input type of at least one screen of the user device, retrieving tags, and preparing at least one term and at least one field list (Fig. 7B, 0096-0097, tracking content in fist app, detecting “shipping address” as input type in the first app, and preparing “shipping address” as a field in the second app at step 716 “predict a prefill request”).
As to claim 9, the rejection of claim 2 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 2, wherein the at least one candidate content is recommended based on extracting a relationship and at least one interest on at least one screen of the user device (par. 0088-0093, detecting and providing recommendations based on inputs and relationship).
As to claim 10, the rejection of claim 9 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 9, wherein extracting the relationship and at least one interest on at least one screen is based on resolving co-references within at least one screen, and extracting an interest region of at least one screen associated with a structured interpretation of at least one screen of the user device (Riva, Fig. 6, par. 0074-0076, resolving co-references within at least one screen, i.e. “The entity template of an app is a collection of templates, one for each page class of the app. Each template is essentially an annotated UI tree. As shown in FIG. 6, each UI element in the tree is represented with its leaf-to-root path and annotated with an entity type (e.g., Restaurant) and an entity group identifier (e.g., Group 14). A null value of entity type or group identifier indicates that the content of the UI element could not be classified as a known entity type (e.g., the text “Copyright”). The group identifiers allow clustering entities such that address and cuisine type entities are attributed to the correct restaurant entity. Similarly, UI elements such as Buttons (not shown in the figure) that contain user actions are annotated with their types and groups. To generate an entity template such as the one just described, the analytics service 340 needs to (1) generate content for the app pages, and (2) recognize entities in those pages. In an example embodiment, group identification (and group identifiers) may be used broadly, so that two or more entities may be placed in the same group if these entities are somehow related to each other. For example, a “Like” button and a restaurant name can be in the same group since the “Like” button refers to the restaurant, an address and a restaurant name are in the same group if the address belongs to the restaurant, etc.”).
As to claim 11, the rejection of claim 9 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 9, wherein extracting the relationship on at least one screen of the user device is based on identifying at least one interest region of at least one screen of the user device (Riva, Fig. 6, par. 0074-0076, identifying and collecting at least one interest region of at least one screen, i.e. “The entity template of an app is a collection of templates, one for each page class of the app. Each template is essentially an annotated UI tree. As shown in FIG. 6, each UI element in the tree is represented with its leaf-to-root path and annotated with an entity type (e.g., Restaurant) and an entity group identifier (e.g., Group 14). A null value of entity type or group identifier indicates that the content of the UI element could not be classified as a known entity type (e.g., the text “Copyright”). The group identifiers allow clustering entities such that address and cuisine type entities are attributed to the correct restaurant entity. Similarly, UI elements such as Buttons (not shown in the figure) that contain user actions are annotated with their types and groups. To generate an entity template such as the one just described, the analytics service 340 needs to (1) generate content for the app pages, and (2) recognize entities in those pages. In an example embodiment, group identification (and group identifiers) may be used broadly, so that two or more entities may be placed in the same group if these entities are somehow related to each other. For example, a “Like” button and a restaurant name can be in the same group since the “Like” button refers to the restaurant, an address and a restaurant name are in the same group if the address belongs to the restaurant, etc.”).
Regarding claims 13-17 and 20, are essentially the same as claim 2-6 and 9, except that it sets forth the claimed invention as user device rather than method and rejected for the same reasons as applied hereinabove.
Claim(s) 7-8 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 20190188251 to Liu et al. (hereinafter “Liu”), U.S. Patent Application Publication No. 20160335316 to Riva et al. (hereinafter “Riva”), and further in view of U.S. Patent Application Publication No. 20170357716 to Bellegarda et al. (hereinafter “Bellegarda”)
As to claim 7, the rejection of claim 6 is hereby incorporated by reference, the combination of Liu and Riva teaches the method as claimed in claim 6, wherein the classifying at least one input field is based on dynamically preparing a screen-field matrix (Fig. 7B, 0096-0097, tracking content in fist app, detecting “shipping address” as input type in the first app, and preparing “shipping address” as a field in the second app at step 716 “predict a prefill request”).
The combination of Liu and Riva does not explicitly teach associating and updating weights for at least one term and at least one field list as claimed.
Bellegarda teaches associating and updating weights for at least one term and at least one field list (Bellegarda, Fig. 7C-11H, par. 0254-0269, 0293-0295, 0319-0321, 0324-0325, 0342, 0357-0369, weight matrix for determining for word sequences and context units, i.e. “[0260] As described, hidden layer 940 includes a plurality of first-context units 942. In some examples, a first-context unit 942 (e.g., h(t)) is represented as a vector having a dimension of H×1. In a uni-directional RNN such as first network 920, generating first-context units 942 includes, for example, weighting a current input unit using a first weight matrix, weighting a preceding first-context unit using a second weight matrix, and determining a current first-context unit based on the weighting of the current input unit and the weighting of the preceding first-context unit… [0295] In some embodiments, to determine first-level event type output 1034, first-level event type classifier 1202 concatenates a trailing first-context unit and a leading second-context unit, weights the concatenation of the trailing first-context unit and the leading second-context unit, and determines the first-level event type output 1034 based on the weighting of the concatenation”.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of combination of Liu and Riva with the teaching of Bellegarda because they are in the same field of endeavor. One of ordinary skill in the art at the time of the invention would have been motivated to do so because the teaching of Bellegarda would allow combination of Liu and Riva to facilitate “more efficient methods for detecting and classifying events based on unstructured natural language information” (Bellegarda, par. 0003)
As to claim 8, the rejection of claim 7 is hereby incorporated by reference, the combination of Liu, Riva and Bellegarda teaches the method as claimed in claim 7, wherein the classifying at least one input field is based on the screen-field matrix (Bellegarda, Fig. 7C-11H, par. 0254-0269, 0293-0295, 0319-0321, 0324-0325, 0342, 0357-0369, weight matrix for determining for word sequences and context units, i.e. “[0260] As described, hidden layer 940 includes a plurality of first-context units 942. In some examples, a first-context unit 942 (e.g., h(t)) is represented as a vector having a dimension of H×1. In a uni-directional RNN such as first network 920, generating first-context units 942 includes, for example, weighting a current input unit using a first weight matrix, weighting a preceding first-context unit using a second weight matrix, and determining a current first-context unit based on the weighting of the current input unit and the weighting of the preceding first-context unit… [0295] In some embodiments, to determine first-level event type output 1034, first-level event type classifier 1202 concatenates a trailing first-context unit and a leading second-context unit, weights the concatenation of the trailing first-context unit and the leading second-context unit, and determines the first-level event type output 1034 based on the weighting of the concatenation”.)
Regarding claims 18-19, are essentially the same as claims 7-8, except that it sets forth the claimed invention as user device rather than method and rejected for the same reasons as applied hereinabove.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANHTAI V TRAN whose telephone number is (571)270-5129. The examiner can normally be reached on Monday through Thursday from 8:00 AM to 4:00 PM.
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, Charles Rones can be reached on (571)272-4085. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANHTAI V TRAN/Primary Examiner, Art Unit 2168
Prosecution Insights