DETAILED ACTION
This action is in response to the RCE and Amendment dated 08 May 2026. Claims 1, 9-11, 14 and 22 are amended. No claims have been added or cancelled. Claims 1, 3-11, 14 and 16-24 remain pending and have been considered below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Based on applicant’s amendment, the 35 U.S.C. 112(b) rejection of claims 9 and 22 is withdrawn.
Claim Objections
Claim 7 is objected to because of the following informalities: a previously struck-out phrase (from the 14 November 2025 amendment) was left in this current claim set (e.g. “. Appropriate correction is required.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 6, 8, 10, 11, 14, 16, 19, 21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over by Lewin et al (US 2014/0310611 A1) in view of Choi et al. (US 2020/0304883 A1).
As for independent claim 1, Lewin teaches a method comprising:
receiving a screen projection instruction that is used to instruct the first terminal device to perform screen projection to the second terminal device [(e.g. see Lewin paragraphs 0062, 0063) ”The first mobile device 10 participates in a pairing procedures at 84 with the second mobile device 18 that also participates in the pairing procedure at 86. For example, after discovering that they are near to each other, the first and second mobile devices 10, 18 may participate in a Bluetooth pairing procedure … Once the first and second mobile devices 10, 18 are near each other and paired, they are capable of communicating with each other over a short-range communications channel thus established and may exchange data. At 88 and 90, the first mobile device 10 and second mobile device 18 may then establish a virtual screen space. The operations performed at 88 and 90 may vary depending on which device initiates the pairing. For example, one of the devices sharing data may have an application 38 running that intends on sharing data and therefore initiates the establishment of the virtual screen that incorporates the display screens 16 and 20. In the example shown in FIG. 11, it is assumed that the first mobile device 10 is sharing data or otherwise utilizing the combined virtual screen and may be designated as the "master" device while the second mobile device 18 is designated the "slave" device”].
generating, in accordance with the screen projection instruction and based on interface information of a first interface and second device information, a second interface to be displayed on the second terminal [(e.g. see Lewin paragraphs 0058, 0064) ”the first mobile device 10 can communicate with the UI framework 36b of the second mobile device 18 in order to determine the screen size, among other things that may be relevant to the rendering of the UI … By establishing the first mobile device 10 as the master device, the first mobile device 10 is capable of taking over the display screen 20 of the second mobile device 18 and sends one or more UI elements to the second mobile device at 92, e.g., the 2.sup.nd UI portion 64 as shown in FIG. 8. The UI framework 36 of the second mobile device 18 receives the one or more UI elements at 94 and the first mobile device 10 displays the first UI portion 62 at 96 and the second mobile device displays the second UI portion 64 at 98”].
wherein the first interface is an interface displayed on the first terminal device [(e.g. see Lewin paragraph 0025 and Fig. 1 numeral 16) ”FIG. 1 illustrates a first mobile device 10 that includes a display screen 16. The screen 16 in the example shown in FIG. 1 displays a first UI element 12 (A) and a second UI element 14 (B)”].
wherein the second device information is used to indicate a screen size and a screen status of the second terminal device [(e.g. see Lewin paragraphs 0058, 0065, 0070 and Fig. 12) ”the first mobile device 10 can communicate with the UI framework 36b of the second mobile device 18 in order to determine the screen size, among other things that may be relevant to the rendering of the UI … establishing a virtual screen space utilizing screens of multiple mobile devices, e.g., during operations 88 and 90 in FIG. 11. At 110 the first mobile device 10 sends a request for screen dimensions to the second mobile device 18. The second mobile device 18 receives the request at 112 and determines the screen dimensions available to be shared. It can be appreciated that the second mobile device 18 may have dual screens or portions of a single screen that cannot be shared and thus may allocate screen space available to be shared according to predetermined constraints. The second device 18 generates and sends a response to the request at 114, which includes the screen dimensions that the UI rendering engine 40b on the second mobile device 18 can utilize in rendering the second UI portion 64 … determining that a second display screen on a second electronic device is available via a connection between the first and second electronic devices”].
wherein the generating the second interface to be displayed on the second terminal device comprises: obtaining the interface information of the first interface and the second device information, wherein the interface information of the first interface comprises element information of at least one interface element in the first interface, and wherein the element information is used to indicate: a name and a type of the interface element; a location of the interface element in the first interface [(e.g. see Lewin paragraph 0043, 0053) ”The elements are the building blocks of the UI. The elements of the UI component tree 44 represent the basic UI elements, lists, menus, tab lists, soft keys, etc. Elements are typically specified in a declarative language such as XML or JSON (currently QML which is JSON based), and given different attributes to make them behave as desired … Rendered attributes refer to any attribute that specifies how a UI element is rendered. Examples of rendered attributes can include color, opacity/transparency, the position on the display, orientation, shape, and size. In various embodiments, the position on the display 34 can be described with any suitable coordinate system including (x,y) coordinates or (x,y,z) coordinates. It can be appreciated however that the position or size of a UI element relative to the virtual screen space may be specified based on a relative dimension such as % length, etc … enables an application 38 on the first mobile device 10 to utilize the screen space of the second mobile device 18 by having the UI framework 36 on the first mobile device 10 communicate with a second UI rendering engine 40b on the second mobile device 18”].
Lewin does not specifically teach determining an interface category by performing recognition based on the element information of the at least one interface element, by using a pre-trained interface recognition model; and obtaining, subsequent to the determining the interface category, the second interface by arranging the at least one interface element based on both the interface category and the second device information. However, in the same field of invention or solving similar problems, Choi teaches:
determining an interface category by performing recognition based on the element information of the at least one interface element, by using a pre-trained interface recognition model; and obtaining, subsequent to the determining the interface category, the second interface by arranging the at least one interface element based on both the interface category and the second device information [(e.g. see Choi paragraphs 0025, 0027, 0048, 0082) ”the method of executing content may further include capturing the screen of the electronic device, wherein the determining of the type of the content may include determining the type of the UI displayed on the screen of the electronic device, by using output data obtained as a result of inputting the captured screen to a pre-generated learning network model, and the learning network model may be generated as a result of the training of criteria for determining the type of UI based on at least one UI running on a plurality of external electronic devices … the determining of the type of the content may include determining the content as a game, when the UI displayed on the screen does not include the menu UI and the external electronic device is recognized as a game console, and the determining of the image quality control mode may include determining the image quality control mode as a first mode in which image quality control is not performed … when the recognized external electronic device does not provide a game, the electronic device may apply the second mode, in which image quality control is performed, to the content … select an image quality control mode for controlling a color, an edge, or the like of the screen such that text or the like may be clearly viewed”].
Therefore, considering the teachings of Lewin and Choi, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add determining an interface category by performing recognition based on the element information of the at least one interface element, by using a pre-trained interface recognition model; and obtaining, subsequent to the determining the interface category, the second interface by arranging the at least one interface element based on both the interface category and the second device information, as taught by Choi, to the teachings of Lewin because it allows the quality for each piece of content to be maximized (e.g. see Choi paragraph 0118).
As for dependent claim 3, Lewin and Choi teach the method as described in claim 1 and Lewin further teaches:
wherein the interface information of the first interface further comprises an interface attribute, wherein the interface attribute is used to indicate: an interface size of the first interface; an interface direction of the first interface [(e.g. see Lewin paragraph 0043) ”Rendered attributes refer to any attribute that specifies how a UI element is rendered. Examples of rendered attributes can include color, opacity/transparency, the position on the display, orientation, shape, and size. In various embodiments, the position on the display 34 can be described with any suitable coordinate system including (x,y) coordinates or (x,y,z) coordinates. It can be appreciated however that the position or size of a UI element relative to the virtual screen space may be specified based on a relative dimension such as % length, etc”].
Lewin does not specifically teach wherein the performing recognition comprises: performing feature extraction on at least one piece of the element information based on the interface attribute, to obtain interface feature data, inputting the interface feature data into the interface recognition model, or recognizing the interface feature data by using the interface recognition model, to obtain the interface category output from the interface recognition model. However, Choi teaches:
wherein the performing recognition comprises: performing feature extraction on at least one piece of the element information based on the interface attribute, to obtain interface feature data; inputting the interface feature data into the interface recognition model and recognizing the interface feature data by using the interface recognition model, to obtain the interface category output from the interface recognition model [(e.g. see Choi paragraph 0025, 0046, 0076) ”determine the type of the content by analyzing image features of a content execution screen captured after executing the content. For example, the first electronic device 100 may determine the type of the content by using a learning network model that is pre-generated based on the image features of the content execution screen. In the present embodiment, the image features may include, but are not limited to, a color, an edge, a polygon, saturation, and brightness constituting the captured screen, the type and position of text shown in the screen, the type and arrangement of an object included in the screen, and the like … the method of executing content may further include capturing the screen of the electronic device, wherein the determining of the type of the content may include determining the type of the UI displayed on the screen of the electronic device, by using output data obtained as a result of inputting the captured screen to a pre-generated learning network model, and the learning network model may be generated as a result of the training of criteria for determining the type of UI based on at least one UI running on a plurality of external electronic devices … The electronic device according to another embodiment may determine the type of the content by applying the captured content execution screen, as an input value, to a learning network model that is pre-generated as a result of training of image features of each type of content The electronic device according to another embodiment may determine the type of the content by applying the captured content execution screen, as an input value, to a learning network model that is pre-generated as a result of training of image features of each type of content”].
The motivation to combine is the same as that used for claim 1.
As for dependent claim 6, Lewin and Choi teach the method as described in claim 1 and Lewin further teaches:
wherein after the generating, the method further comprises: sending the second interface to the second terminal device, so that the second terminal device displays the second interface [(e.g. see Lewin paragraph 0064) ”By establishing the first mobile device 10 as the master device, the first mobile device 10 is capable of taking over the display screen 20 of the second mobile device 18 and sends one or more UI elements to the second mobile device at 92 … The UI framework 36 of the second mobile device 18 receives the one or more UI elements at 94 and the first mobile device 10 displays the first UI portion 62 at 96 and the second mobile device displays the second UI portion 64 at 98”].
As for dependent claim 8, Lewin and Choi teach the method as described in claim 1 and Lewin further teaches:
wherein before the generating, the method further comprises: performing interface element extraction in the first interface based on an extraction operation triggered by a user, to obtain a plurality of interface elements [(e.g. see Lewin paragraphs 0039, 0063) ”Once the first and second mobile devices 10, 18 are near each other and paired, they are capable of communicating with each other over a short-range communications channel thus established and may exchange data. At 88 and 90, the first mobile device 10 and second mobile device 18 may then establish a virtual screen space. The operations performed at 88 and 90 may vary depending on which device initiates the pairing. For example, one of the devices sharing data may have an application 38 running that intends on sharing data and therefore initiates the establishment of the virtual screen that incorporates the display screens 16 and 20. In the example shown in FIG. 11, it is assumed that the first mobile device 10 is sharing data or otherwise utilizing the combined virtual screen and may be designated as the "master" device … Each UI client engine 42 is responsible for providing UI data from its associated application 38 to the UI rendering engine 40. The UI client engine 42 is responsible for setting up UI component trees 44 and informing the UI rendering engine 40 of the tree structure 44. In the example shown in FIG. 6 the UI component tree 44 includes an item 46 as a parent node, with two data items 48a, 48b as child nodes. The UI client engine 42 gets this information from the application 38. For example, the application code could specify the creation of elements, such as buttons and containers … The UI rendering engine 40 mirrors the tree 44 set up by UI client engine 42 to create a mirrored tree 50. The UI rendering engine 40 sets up visual node trees 52, 54a, and 54b for each UI element 46, 48a, 48b of the UI component tree 44. To set up the visual node trees 50, the UI rendering engine 40 has predefined visual node trees 50 for each UI component that the UI client engine 42 provides. For example if the UI client engine 42 sets up a Button, the UI rendering engine 42 will have a predefined visual node tree 50 for Button which it will use”].
generating element information of the plurality of interface elements based on a supplementing operation triggered by the user [(e.g. see Lewin paragraphs 0048, 0067) ”When the UI rendering engine 40 detects a user input in the UI, it communicates the user input to the UI client engine 42 for further processing. In addition, if necessary, the UI rendering engine 40 re-renders the UI in response to the user input independently of further input from the UI client engine 42. For example, if the user input is a button press, the UI rendering engine 40 re-renders to animate a button associated with the button press. If the UI client engine 42 determines that the user input received from the UI rendering engine 40 requires new data, i.e. a "modification" to the UI, the UI client engine 42 sends further data items invoking the modification to the UI rendering engine 40, which then re-renders UI in accordance with the further data items and their associated visual node tree 50 … having the UI frameworks 36a, 36b on the paired devices handle the UI decisions such as how to update the respective UI spaces based on detected interactions”].
As for independent claim 10, Lewin and Choi teach a terminal. Claim 10 discloses substantially the same limitations as claims 1 and 6. Therefore, it is rejected with the same rational as claims 1 and 6.
As for independent claim 11, Lewin and Choi teach a system. Claim 11 discloses substantially the same limitations as claims 1. Therefore, it is rejected with the same rational as claims 1.
As for independent claim 14, Lewin and Choi teach a terminal. Claim 14 discloses substantially the same limitations as claims 1. Therefore, it is rejected with the same rational as claims 1.
As for dependent claim 16, Lewin and Choi teach the terminal as described in claim 14; further, claim 16 discloses substantially the same limitations as claim 3. Therefore, it is rejected with the same rational as claim 3.
As for dependent claim 19, Lewin and Choi teach the terminal as described in claim 14; further, claim 19 discloses substantially the same limitations as claim 6. Therefore, it is rejected with the same rational as claim 6.
As for dependent claim 21, Lewin and Choi teach the terminal as described in claim 14; further, claim 21 discloses substantially the same limitations as claim 8. Therefore, it is rejected with the same rational as claim 8.
As for dependent claim 23, Lewin and Choi teach the terminal as described in claim 10; further, claim 23 discloses substantially the same limitations as claim 3. Therefore, it is rejected with the same rational as claim 3.
Claims 4, 5, 17, 18 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Lewin et al (US 2014/0310611 A1) in view of Choi et al. (US 2020/0304883 A1), as applied to claim 1 above, and further in view of Moore et al. (US 2014/0013271 A1).
As for dependent claim 4, Lewin and Choi teach the method as described in claim 1, but do not specifically teach wherein the arranging comprising: dividing, based on the interface category, a display area of the second terminal device, to obtain a plurality of sub-areas, wherein the display area is indicated by the second device information; determining an interface element arranged in each sub-area; adjusting each interface element in each sub-area based on: a size of the display area indicated by the second device information; and a quantity of interface elements arranged in each sub-area. However, in the same field of invention, Moore teaches:
wherein the arranging comprising: dividing, based on the interface category, a display area of the second terminal device, to obtain a plurality of sub-areas, wherein the display area is indicated by the second device information; determining an interface element arranged in each sub-area; adjusting each interface element in each sub-area based on: a size of the display area indicated by the second device information; and a quantity of interface elements arranged in each sub-area [(e.g. Moore paragraphs 0051, 0062, 0064) ”Display size and design, for example, may be used to determine an appropriate minimum tile size for display by the mobile device 100 … Each of the tiles is allocated to a distinct region on the activity screen, according to a specified layout. The layout may vary according to the number of tiles allocated in the activity screen. The content displayed for each tile is selected, at least in part, based on the size of the allocated region (i.e., tile). Content for each possible size of the tile can be pre-defined … a number of layouts, one for each possible arrangement of regions accommodating any number of tiles up to the maximum number of tiles that can be displayed on the activity screen, are predefined and stored at the mobile device 100. Thus, layouts defining the positions and sizes of regions 0 to 1, 0 to 2, and 0 to 3 as depicted in FIGS. 7A to 7C are stored and retrieved as necessary depending on the number of multitasking applications to be represented by tiles on the activity screen. Additional layouts are also predefined and stored and so on to accommodate five, six, and seven tiles, as depicted in FIGS. 7D to 7F, are also stored and retrieved as necessary”].
Therefore, considering the teachings of Lewin, Choi and Moore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add wherein the arranging comprising: dividing, based on the interface category, a display area of the second terminal device, to obtain a plurality of sub-areas, wherein the display area is indicated by the second device information; determining an interface element arranged in each sub-area; adjusting each interface element in each sub-area based on: a size of the display area indicated by the second device information; and a quantity of interface elements arranged in each sub-area, as taught by Moore, to the teachings of Lewin and Choi because it maximizes the amount of legible detail that can be presented to the user and makes optimal usage of the available screen space (e.g. see Moore paragraph 0073).
As for dependent claim 5, Lewin, Choi and Moore teach the method as described in claim 4, but Lewin and Choi do not specifically teach the following limitation. However, Moore teaches:
wherein adjusting each interface element comprises: determining the quantity of interface elements in each sub-area; adjusting a size and direction of each interface element in each sub-area based on: the size of the display area, a preset arrangement rule, and the quantity of interface elements in the sub-area; and adjusting, in each sub area, a location of an adjusted interface element in the sub-area based on the quantity of interface elements in the sub-area [(e.g. Moore paragraphs 0051, 0062, 0063, 0064) ”Display size and design, for example, may be used to determine an appropriate minimum tile size for display by the mobile device 100 … Each of the tiles is allocated to a distinct region on the activity screen, according to a specified layout. The layout may vary according to the number of tiles allocated in the activity screen. The content displayed for each tile is selected, at least in part, based on the size of the allocated region (i.e., tile). Content for each possible size of the tile can be pre-defined … a number of layouts, one for each possible arrangement of regions accommodating any number of tiles up to the maximum number of tiles that can be displayed on the activity screen, are predefined and stored at the mobile device 100. Thus, layouts defining the positions and sizes of regions 0 to 1, 0 to 2, and 0 to 3 as depicted in FIGS. 7A to 7C are stored and retrieved as necessary depending on the number of multitasking applications to be represented by tiles on the activity screen. Additional layouts are also predefined and stored and so on to accommodate five, six, and seven tiles, as depicted in FIGS. 7D to 7F, are also stored and retrieved as necessary … The layout is therefore altered by splitting region 3 in two, so as to accommodate a further region with index 4 such that regions 3 and 4 occupy the space previously occupied by region 3 in FIG. 7C. The tiles allocated to regions 3 and 4 are therefore reduced in size to a second size; each are now approximately half the size of previous region 3, again subject to considerations such as margins or padding, which may result in the area of new regions 3 and 4 not being exactly one-half of previous region 3 in FIG. 7C. Since the region with index 3 has now been resized, a new tile for the application associated with that index must now be allocated, or else the previously allocated tile must be resized to fit the new region size and shape. The activity screen is then re-rendered with the new layout”].
The motivation to combine is the same as that used for claim 4.
As for dependent claim 17, Lewin and Choi teach the terminal as described in claim 14; further, claim 17 discloses substantially the same limitations as claim 4. Therefore, it is rejected with the same rational as claim 4.
As for dependent claim 18, Lewin, Choi and Moore teach the terminal as described in claim 17; further, claim 18 discloses substantially the same limitations as claim 5. Therefore, it is rejected with the same rational as claim 5.
As for dependent claim 24, Lewin and Choi teach the terminal as described in claim 10; further, claim 24 discloses substantially the same limitations as claim 4. Therefore, it is rejected with the same rational as claim 4.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lewin et al (US 2014/0310611 A1) in view Choi et al. (US 2020/0304883 A1), as applied to claim 6 above, and further in view of Moran et al. (US 2016/0085430 A1).
As for dependent claim 7, Lewin and Choi teach the method as described in claim 6, but do not specifically teach wherein after the sending the second interface to the second terminal device, the method further comprises: obtaining feedback information that is input by a user on the second interface displayed on the second terminal device; and updating, in accordance with the feedback information meeting a preset update condition, the interface recognition model based on the feedback information. However, in the same field of invention, Moran teaches:
wherein after the sending the second interface to the second terminal device, the method further comprises: obtaining feedback information that is input by a user on the second interface displayed on the second terminal device; and updating, in accordance with the feedback information meeting a preset update condition, the interface recognition model based on the feedback information [(e.g. see Moran paragraph 0099) ”the artificial neural network 1202 may be invoked to evaluate a selected set of interaction component properties 302 and interaction criteria 306 for a particular user interface 110, and to identify the selection 1204 of a presentation 308 therefor. Moreover, feedback may be utilized to refine and maintain the accurate output of the artificial neural network 1202; e.g., the user interaction 304 of the user 102 with the application 106 through the selected presentation 308 may be monitored and the proficiency automatically evaluated, such that a first presentation 308 that reflects a suitable user interaction 304 (e.g., a low error rate) may prompt positive feedback 1206 that increases the selection 1204 of the first presentation 308, while a second presentation 308 that reflects an unsuitable user interaction 304 (e.g., a high error rate, or a request from the user 102 to choose a different interaction component 106) may prompt negative feedback 1208 that decreases the selection 1204 of the second presentation 308. Many such techniques may be utilized to choose a presentation 308 of a user interface element 112 for a user interface 110 in accordance with the techniques presented herein”].
Therefore, considering the teachings of Lewin, Choi and Moran, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add wherein after the sending the second interface to the second terminal device, the method further comprises: obtaining feedback information that is input by a user on the second interface displayed on the second terminal device; and updating, in accordance with the feedback information meeting a preset update condition, the interface recognition model based on the feedback information, as taught by Moran, to the teachings of Lewin and Choi because it provides a user interface composition that allows for a significantly improved user experience by presenting elements that are respectively suitable for particular interaction component properties for a particular device (e.g. see Moran paragraphs 0018, 0032, 0070).
As for dependent claim 20, Lewin and Choi teach the terminal as described in claim 19; further, claim 20 discloses substantially the same limitations as claim 7. Therefore, it is rejected with the same rational as claim 7.
Claims 9 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Lewin et al (US 2014/0310611 A1) in view Choi et al. (US 2020/0304883 A1) and further in view of Moore et al. (US 2014/0013271 A1), as applied to claim 5 above, and further in view of Moran et al. (US 2016/0085430 A1).
As for dependent claim 9, Lewin, Choi and Moore teach the method as described in claim 5, but do not specifically teach wherein after the generating, the method further comprises: recording an adjustment operation triggered by a user on at least one interface element in the second interface; and adjusting the preset arrangement rule based on the adjustment operation. However, in the same field of invention, Moran teaches:
wherein after the generating, the method further comprises: recording an adjustment operation triggered by a user on at least one interface element in the second interface; and adjusting the preset arrangement rule based on the adjustment operation [(e.g. Moran paragraph 0046) ”a device 104 utilizing the techniques presented herein may adapt the user interface 102 to the interaction criteria 306 of the user interaction 304 between the user 102 and the application 108. That is, the user interface 110 of the application 102 may automatically adapt to the user context in which the user 102 is utilizing the application 108, and to the particular type of content presented by the application 108. Such user interfaces 110 may also be dynamically updated to reflect changes in such interaction criteria 306”].
Therefore, considering the teachings of Lewin, Choi, Moore and Moran, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to add wherein after the generating, the method further comprises: recording an adjustment operation triggered by a user on at least one interface element in the second interface; and adjusting the preset arrangement rule based on the adjustment operation, as taught by Moran, to the teachings of Lewin, Choi and Moore because it provides a user interface composition that allows for a significantly improved user experience by presenting elements that are respectively suitable for particular interaction component properties for a particular device (e.g. see Moran paragraphs 0018, 0032, 0070).
As for dependent claim 22, Lewin, Choi and Moore teach the terminal as described in claim 18; further, claim 22 discloses substantially the same limitations as claim 9. Therefore, it is rejected with the same rational as claim 9.
Response to Arguments
Applicant's arguments, filed 08 May 2026, have been fully considered but they are not persuasive.
Applicant argues that [“[the amendments] clearly distinguish Applicant’s claimed invention over the teachings of the cited references.” (Page 11).].
The argument described above, in paragraph number 11, with respect to the newly added limitations to the independent claims has been considered, but is moot in view of the new grounds of rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. PGPub 2018/0349730 A1 issued to Dixon et al. on 06 December 2018. The subject matter disclosed therein is pertinent to that of claims 1, 3-11, 14 and 16-24 (e.g. machine learning to detect components from a UI).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER J FIBBI whose telephone number is (571)-270-3358. The examiner can normally be reached Monday - Thursday (8am-6pm).
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, William Bashore can be reached at (571)-272-4088. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHRISTOPHER J FIBBI/Primary Examiner, Art Unit 2174
Prosecution Insights