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 01/16/2026.
Claims 1-20 are pending.
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 01/16/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 “displaying a first screen associated with a first application of a user device corresponding to a current user action for using the user device, predicting one or more possible next user actions for using the user device based on the first screen and the determined one or more relationships; and, based on a second application of the user device, corresponding to a first user action among the one or more possible next user actions, being selected, displaying a second screen associated with the second application”.
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. 0093, i.e. “[0093] 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.” As such, Liu clearly teaches the same features as claimed in the amended claim 1 and according to the disclosed Specification “[110]Referring to FIG. 8C, at step 900, the method includes analyzing the contents of one or more screens displayed on the user device 102. At step 902, the method includes generating at least one logical tree structure of the analyzed contents for each screen. At step 904, the method includes classifying interest portion of the screen from the at least one logical tree structure. At step 906, the method includes detecting and classifying at least one input field requiring user input in a screen displayed on the device. At step 908, the method includes fetching candidate contents to fill the detected input field from the logical tree structure, based on the detected interest portion of the screen. At step 910, the method includes providing the recommendation, the corresponding to fetched contents, for the input by the user.” It is further noted that Liu teaches displaying of applications in Fig. 5, par. 0013, 0046, 0057, 0073-0076, 0082-0083, 0096.
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.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-13 of U.S. Patent No. 12026209. Although the conflicting claims are not identical, they are not patentably distinct from each other because the claimed feature of the claims 1-13 of U.S. Patent No. 12026209 can also be interpreted as features as claimed in the claims 1-20 of the present application. Further, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims 1-13 of U.S. Patent No. 12026209 to arrive at the claims 1-20 of the instant application because the person would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U. S. Court of Customs and Patent Appeals.
Claim comparison: Claimed subject matter is paralleled for the purpose of comparison
Present Application
US. Patent No. 12026209
1. (Currently Amended) A method comprising: collecting at least one content from a plurality of sources on a user device; identifying a plurality of data types of the collected at least one content; determining one or more relationships among the plurality of data types; displaying a first screen associated with a first application of the user device corresponding to a current user action for using the 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; based on a secondee application of the user device, corresponding to a first user action among the one or more possible next user actions, being selected, displaying a second screen associated with the second application; detecting at least one input field requiring at least one user input in the second screen; 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; and recommending the at least one fetched candidate content.
2. 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; generating at least one logical tree structure based on the at least one analyzed content; and fetching the at least one candidate content from the at least one logical tree structure.
3. The method as claimed in claim 2, wherein the at least one fetched candidate content is generated by 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, wherein the at least one logical tree structure is generated by determining the one or more relationships among the plurality of data types, 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.
4. 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.
5. 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.
6. 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.
7. The method as claimed in claim 6, wherein the classifying at least one input field is based on dynamically preparing a screen-field matrix, and associating and updating weights for at least one term and at least one field list.
8. The method as claimed in claim 7, wherein the classifying at least one input field is based on the screen-field matrix.
9. 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.
10. 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.
11. 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.
Claims 12-20 are similar to claims 1-10
1. A method for providing at least one recommendation, the method comprising: collecting, by a user device, at least one content from a plurality of sources on the user device; feeding, by the user device, the collected at least one content to a data mashup model; identifying, by the user device, a plurality of data types of the collected at least one content using the data mashup model; determining, by the user device, one or more relationships among the data types using the data mashup model; predicting, by the user device, one or more possible recommendations to be performed by a user as an outcome of the determined relationships using the data mashup model; detecting, by the user device, at least one input field requiring at least one user input in the plurality of sources displayed on the user device, wherein the at least one input field is classified based on a screen-field matrix storing weights of input fields across different screens; fetching, by the user device, at least one candidate content, wherein the at least one candidate content is based on the at least one detected input field; and recommending, by the user device, the at least one fetched candidate content to the user of the user device.
2. The method as claimed in claim 1, further comprising: analyzing, by the user device, at least one content captured from the plurality of sources displayed on a screen of the user device; generating, by the user device, at least one logical tree structure based on the at least one analyzed content; and fetching, by the user device, at least one candidate content from the logical tree structure.
3. The method as claimed in claim 2, wherein the recommended at least one fetched candidate content is generated by analyzing at least one content captured from the plurality of sources displayed on the user device, wherein the recommended at least one fetched candidate content is recommended based on information regarding at least one action performed by the user of the user device, wherein the at least one logical tree structure is generated by determining one or more relationships among the data types using the data mashup model, and wherein the at least one input field requiring at least one user input in the plurality of sources displayed on the user device is detected based on the outcome of the determined relationships using the data mashup model.
7. The method as claimed in claim 3, wherein the recommended at least one fetched candidate content is recommended based on previously-generated information regarding at least one action of the user and analyzing of at least one content captured on the user device.
4. 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 the screen content.
5. 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.
1. A method for providing at least one recommendation, the method comprising: collecting, by a user device, at least one content from a plurality of sources on the user device; feeding, by the user device, the collected at least one content to a data mashup model; identifying, by the user device, a plurality of data types of the collected at least one content using the data mashup model; determining, by the user device, one or more relationships among the data types using the data mashup model; predicting, by the user device, one or more possible recommendations to be performed by a user as an outcome of the determined relationships using the data mashup model; detecting, by the user device, at least one input field requiring at least one user input in the plurality of sources displayed on the user device, wherein the at least one input field is classified based on a screen-field matrix storing weights of input fields across different screens; fetching, by the user device, at least one candidate content, wherein the at least one candidate content is based on the at least one detected input field; and recommending, by the user device, the at least one fetched candidate content to the user of the user device.
6. 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.
8. The method as claimed in claim 6, 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, extracting an interest region of at least one screen associated with a structured interpretation of at least one screen of the user device.
9. The method as claimed in claim 6, 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.
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 among the one or more possible next user actions, being selected, displaying a second screen associated with the second application (Fig. 5, par. 0013, 0046, 0057, 0073-0076, 0082-0083, 0093, 0096, displaying a screen recommending a user actions for user’s selection, i.e. “[0093] 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.”);
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 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 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.
Conclusion
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.
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