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 .
The prior 35 USC 101 rejections are withdrawn in view of applicant’s amendments.
The following rejections are withdrawn in view of applicant’s amendments:
Claim(s) 2-4 rejected under 35 U.S.C. 103 as being unpatentable over Bott et al (“Managing and Arranging Windows”, published: March 2021, pages: Npl Pages 1-4 ) in view of Beek et al (US Application: US 2008/0178126, published: Jul. 24, 2008, filed: Jan. 24, 2007).
The following rejections are maintained:
Claim(s) 1, 5-9, 12-17, 19 and 20 remain rejected under 35 U.S.C. 103 as being unpatentable over Bott et al (“Managing and Arranging Windows”, published: March 2021, pages: Npl Pages 1-4 ) in view of Beek et al (US Application: US 2008/0178126, published: Jul. 24, 2008, filed: Jan. 24, 2007).
Claim(s) 10 and 11 remain rejected under 35 U.S.C. 103 as being unpatentable over Bott et al (“Managing and Arranging Windows”, published: March 2021, pages: Npl Pages 1-4 ) in view of Beek et al (US Application: US 2008/0178126, published: Jul. 24, 2008, filed: Jan. 24, 2007) in view of Kaufthal et al (US Application: 2015/0277682, published: Oct. 1, 2015, filed: Jul. 22, 2014).
Claim(s) 18 remains rejected under 35 U.S.C. 103 as being unpatentable over Bott et al (“Managing and Arranging Windows”, published: March 2021, pages: Npl Pages 1-4 ) in view of Beek et al (US Application: US 2008/0178126, published: Jul. 24, 2008, filed: Jan. 24, 2007) in view of StackOverflow (“Application does not support the current display size”, published: Dec. 2017, page: 1).
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.
Claim(s) 1, 5-9, 12-17, 19 and 20 remain rejected under 35 U.S.C. 103 as being unpatentable over Bott et al (“Managing and Arranging Windows”, published: March 2021, pages: Npl Pages 1-4 ) in view of Beek et al (US Application: US 2008/0178126, published: Jul. 24, 2008, filed: Jan. 24, 2007).
With regards to claim 1, Bott et al teaches an interface processing method, applied to an electronic apparatus, and comprising:
receiving a … command based on a target application program (NPL Page 2, Fig. 3-12: a user can apply a gesture drag command associated with a target window application state - “Drag the title bar to the top of the screen to maximize the window, or drag
the title bar away from the top edge to restore it to its previous window size”); and
switching a display state of the target application program from a first display state to a second display state in response to that the touch command conforms to a preset rule (NPL Page 2, Fig. 3-12: a rule to switch an application from full maximized size to a non-maximized-prior-window-size (interpreted as less than full maximized) size ) is applied by a gesture that includes select and drag the title bar of the target application away and below the top edge of a displayed screen (interpreted as dragged into an area below the top edge)) – “Drag the title bar to the top of the screen to maximize the window, or drag the title bar away from the top edge to restore it to its previous window size”), wherein a window layout of the first display state is different from a window layout of the second display state (NPL Page 2, Fig. 3-12: the first display state is interpreted as the maximized state of the target window application and the second display state is a non-maximized (less than maximum and prior window size) – “Drag the title bar to the top of the screen to maximize the window, or drag the title bar away from the top edge to restore it to its previous window size);
wherein receiving the … command based on the target application program comprises: receiving a drag command based on the target application program (NPL Page 2, Fig. 3-12: a select and drag gesture command is applied to the target application’s title bar); wherein switching the display state of the target application program from the first display state to the second display state in response to that the … command conforms to the preset rule comprises: switching the display state of the target application program from the first display state to the second display state, in response to that an endpoint of a motion trajectory corresponding to the drag command is in a preset area of a screen of the electronic apparatus ( NPL Page 2, Fig. 3-12: the target application is switched from a maximized /full screen state to a smaller non-maximized prior-sized state when the user applies a drag gesture command of the title bar to a point below the top edge of the screen (also see Fig. 3-12 which shows windows can have a prior ratio of length and width size)); wherein the interface processing method further comprises prompting the window layout of the second display state, in response to that the motion trajectory corresponding to the drag command enters the preset area (NPL Page 2, Fig. 3-12: the drag enters an area below and away from the top edge and a second display state of applying a prior-sized window layout is applied/visually-prompted).
However although Bott et al teaches receiving a command based on a target application program, Bott et al does not explicitly teach a touch command …
Yet Beeck et al teaches receiving a touch command based on a target application program … (Fig. 4c, paragraphs 0019, 0042: a computer embodiment (which uses at least a memory and computing processor to execute instructions) to identify and process a user gesture/command to select and drag a window to a desired area/position is implemented).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Bott et al’s ability to process a gesture command based on target application program’s rendering state, such that the gesture command could have been a touch gesture command as taught by Beeck et al. The combination would have allowed support of touch technology to make it more intuitive and efficient to interact with windows.
With regards to claim 5. The interface processing method according to claim 1, Bott et al and Beek et al teaches further comprising:
displaying the window layout of the second display state through a mask layer area of a first preset dimension (as similarly explained in the rejection of claim 1, the gesture applied causes the target window layout to transition to a second positioned window that has a smaller (not maximized) prior-sized window (and a rendered area of the prior sized window is interpreted as a defined (mask) area of having the prior-sized window dimensions (a rendered window having the dimensions is also interpreted as having length by width dimensions, and an example of a window capable of having length and width dimensions is shown in Fig. 3-12)), and is rejected under similar rationale).
With regards to claim 6. The interface processing method according to claim 5, Bott et al and teaches wherein a size of the first preset dimension is associated with the window layout of the second display state, as similarly explained in the rejection of claim 5 (a first dimension could be for example a length dimension of the prior-sized-window (an example of a window capable of having length and width dimensions is shown in Fig. 3-12)), and is rejected under similar rationale.
With regards to claim 7. The interface processing method according to claim 1, Bott et al teaches further comprising:
displaying the target application program in a second preset dimension in response to executing the touch command, as similarly explained in the rejection of claim 5 (a second dimension could be for example a width dimension of the prior-sized-window), and is rejected under similar rationale.
With regards to claim 8. The interface processing method according to claim 1, Bott et al teaches wherein receiving the drag command based on the target application program comprises:
receiving the drag command of a control displayed on the target application program (as similarly explained in the rejection of claim 1, the user drags a title bar (interpreted as an interactive control), which then resizes the application associated with the title bar to a smaller (non-maximized) window having prior-size dimensions, and is rejected under similar rationale); or receiving the drag command of a control on an icon of the target application program.
With regards to claim 9. The interface processing method according to claim 1, Bott et al teaches further comprising: setting the window layout of the first display state and the window layout of the second display state according to the target application program (as similarly explained in the rejection of claim 1, the target window layout of first display state is according to a maximized configuration/setting of the target application and the window layout of a second display state is according to a prior-sized-configuration/setting of the target application).
With regards to claim 12. The interface processing method according to claim 1, Bott et al and teaches wherein: an interface comprises a plurality of preset areas, different preset areas corresponding to different display states; the first display state is that the target application program is in a closed mode, a small window mode, a split screen mode, or a full screen mode (as explained in the rejection of claim 1, the first display state is a maximized /full-screen mode, and is rejected under similar rationale); and the second display state is that the target application program is in a small window mode, a split screen mode, or a full screen mode (as similarly explained in the rejection of claim 1, the second display state is a non-maximized/smaller-prior-sized-window, and is rejected under similar rationale).
With regards to claim 13. The interface processing method according to claim 12, Bott et al teaches wherein: the interface comprises a first area (as similarly explained in the rejection of claim 1 above, a first area can an area below a top edge of a title bar area indicated by a drag down gesture), a second area (Bott et al, Fig. 3-12: a second area can be a left split screen area where the target application is dragged to a left edge of a display screen area), and a third area (Bott et al, NPL Page 2 and 3: a third area can be a top edge screen area where the target application is dragged to a top of a display screen area - “Maximize window”); the first area is a preset area corresponding to the small window mode (Bott et al, NPL Page 2: the first area corresponds to a non-maximized prior-sized window (smaller window) -“ drag the title bar away from the top edge to restore it to its previous window size”) ; the second area is a preset area corresponding to the split screen mode (Bott et al, NPL Page 2: the second area is a split screen mode; and the third area is a preset area corresponding to the full screen mode (Bott et al, NPL Page 2 and 3: a third area can be a top edge screen area where the target application is dragged to a top of a display screen area - “Maximize window”).
With regards to claim 14. The interface processing method according to claim 13, Bott et al and Beek et al teaches wherein switching the display state of the target application program from the first display state to the second display state, in response to that the endpoint of the motion trajectory corresponding to the drag command is in the preset area of the screen of the electronic apparatus comprises: switching the display state of the target application program into the small window mode, in response to that the endpoint of the motion trajectory corresponding to the drag command is in the first area of the screen of the electronic apparatus (as explained in the rejection of claim 1, Bott et al teaches the drag motion towards a point below the top edge of the screen is identified and the display state of the target application goes from maximized/full-screen to a smaller window having a prior-size); or switching the display state of the target application program into the split screen mode, in response to that the endpoint of the motion trajectory corresponding to the drag command is in the second area of the screen of the electronic apparatus; or switching the display state of the target application program into the full screen mode, in response to that the endpoint of the motion trajectory corresponding to the drag command is in the third area of the screen of the electronic apparatus.
With regards to claim 15. The interface processing method according to claim 13, Bott et al and Beek et al teaches further comprising: switching a display state of a non-target application program from a third display state to a fourth display state in response to that the endpoint of the motion trajectory corresponding to the drag command is in the preset area of the screen of the electronic apparatus, wherein a window layout of the third display state is different from a window layout of the fourth display state (Bott et al, NPL Page 2, Fig 3-12: teaches another app separate from the target app gets switched to a different split area than the target app’s split area in response to the user dragging the target window application to a particular side area (such as left edge area of screen)).
With regards to claim 16. The interface processing method according to claim 15, Bott et al and Beek et al teaches wherein the third display state is that the non-target application is in the small window mode, the split screen mode, or the full screen mode, and the fourth display state is that the non-target application is in the small window mode, the split screen mode, the full screen mode, or the closed mode (Bott et al, NPL Page 2, Fig. 3-12: Bott et al teaches the non-target application is displayed in a split area screen mode different from the target applications area for split screen).
With regards to claim 17. The interface processing method according to claim 16, Bott et al and Beek et al teaches wherein switching the display state of the non-target application program from the third display state to the fourth display state in response to that the endpoint of the motion trajectory corresponding to the drag command is in the preset area of the screen of the electronic apparatus comprises: switching the display state of the non-target application program into a non-small window mode, in response to that the endpoint of the motion trajectory corresponding to the drag command is in the first area of the screen of the electronic apparatus; or switching the display state of the non-target application program into the small window mode or the split screen mode, in response to that the endpoint of the motion trajectory corresponding to the drag command is in the second area of the screen of the electronic apparatus; or switching the display state of the non-target application program into the closed mode, in response to that the endpoint of the motion trajectory corresponding to the drag command is in the third area of the screen of the electronic apparatus (Bott et al , NPL Pages 2 and 3: teaches maximize target application will close the non-target application’s display, as the target application is maximized (takes up entire area of the screen). Also an additional gesture is available to minimize the non-target window by applying a subsequent gesture to shake the target window which minimizes the non-target window(s)).
With regards to claim 19. Bott et al and Beek et al teaches An electronic apparatus, comprising: a processor; and a memory for storing an instruction executable by the processor; wherein the processor is configured to: receive a touch command based on a target application program; and switch a display state of the target application program from a first display state to a second display state in response to that the touch command conforms to a preset rule, wherein a window layout of the first display state is different from a window layout of the second display state; wherein the processor is configured to receive a drag command based on the target application program; switch the display state of the target application program from the first display state to the second display state, in response to that an endpoint of a motion trajectory corresponding to the drag command is in a preset area of a screen of the electronic apparatus; wherein the processor is further configured to prompt the window layout of the second display state, in response to that the motion trajectory corresponding to the drag command enters the preset area, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
With regards to claim 20. Bott et al and Beek et al teaches A non-transitory computer-readable storage medium having stored therein an executable instruction that, when executed by a processor, implements: receiving a touch command based on a target application program; and switching a display state of the target application program from a first display state to a second display state in response to that the touch command conforms to a preset rule, wherein a window layout of the first display state is different from a window layout of the second display state; wherein the processor is configured to receive a drag command based on the target application program; switch the display state of the target application program from the first display state to the second display state, in response to that an endpoint of a motion trajectory corresponding to the drag command is in a preset area of a screen of the electronic apparatus; wherein the processor is further configured to prompt the window layout of the second display state, in response to that the motion trajectory corresponding to the drag command enters the preset area, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
Claim(s) 10 and 11 remain rejected under 35 U.S.C. 103 as being unpatentable over Bott et al (“Managing and Arranging Windows”, published: March 2021, pages: Npl Pages 1-4 ) in view of Beek et al (US Application: US 2008/0178126, published: Jul. 24, 2008, filed: Jan. 24, 2007) in view of Kaufthal et al (US Application: 2015/0277682, published: Oct. 1, 2015, filed: Jul. 22, 2014).
With regards to claim 10. The interface processing method according to claim 1, the combination of Bott et al and Beek et al teaches further comprising: setting the window layout of the first display state and the window layout of the second display state, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
However the combination does not teach … according to a type of the electronic apparatus.
Yet Kaufthal et al teaches … according to a type of the electronic apparatus (paragraph 0041: the amount of display space/area available to an application is considered (based on display screen size/type) before a display state/configuration/region is implemented).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Bott et al and Beek et al’s ability to change/set a window layout to be a first and/or display state/configuration, such that the configuration being considered is based upon a type of the electronic apparatus, as taught by Kaufthal et al The combination would have allowed implemented a software application that can adapt to devices of all shapes and sizes (Kaufthal et al, paragraph 0001).
With regards to claim 11. The interface processing method according to claim 1, the combination of Bott et al, Beek et al and Kaufthal et al further comprising: determining a size of the preset area according to a type of the electronic apparatus, as similarly explained in the rejection of claim 10 (the size of the area is considered for a device type having a particular screen size), and is rejected under similar rationale.
Claim(s) 18 remains rejected under 35 U.S.C. 103 as being unpatentable over Bott et al (“Managing and Arranging Windows”, published: March 2021, pages: Npl Pages 1-4 ) in view of Beek et al (US Application: US 2008/0178126, published: Jul. 24, 2008, filed: Jan. 24, 2007) in view of StackOverflow (“Application does not support the current display size”, published: Dec. 2017, page: 1).
With regards to claim 18. The interface processing method according to claim 1, Bott et al and Beek et al teaches further comprising: … the target application program … the second display state … the electronic apparatus … switching the display state of the target application program from the first display state to the second display state, as similarly explained in the rejection of claim 1, and is rejected under similar rationale.
However the combination does not expressly teach … prompting that the target application program does not support the second display state, in case that the electronic apparatus does not support switching the display state.
Yet StackOverflow teaches … prompting that the target application program does not support the … display state, in the case that the electronic apparatus does not support switching the display state …. (Page 1: the device/apparatus with a particular configuration does not support a switch to a display state for a target application and a prompt is provided to indicate a such).
It would have been obvious to one of ordinary skill in the art before the effective filing of the invention to have modified Bott et al and Beek et al’s ability to switch between display states, such that a prompt is provided when an unsupported display state is switched to for a target application, as taught by StackOverflow. The combination would have provided sufficient reasons/information to the user when an issue of support is encountered.
Response to Arguments
Applicant's arguments filed 04/27/2026 have been fully considered but they are not persuasive.
With regards to claim 1, the applicant argues Bott only discloses that a user can apply a gesture drag command associated with a target window application state … and a rule to switch an application from full maximized size to a non maximized-prior window size, that is , directly maximize the present window or restore the size of the present window to its previews window size when dragging the title bar to a preset area, rather than prompting the window layout of the second display state. It is noted that the examiner interprets ‘prompting’ to encompasses a visual display of the window layout showing a visually updated/resulting second-state , and page 2, Fig. 3-12 of Bott et al is maintained to teach what is required by the scope of this limitation. More importantly, the applicant appears to be requiring limitations not present in the claim language and might be trying to require a specific type of prompting (based on looking at the instant application’s specification, it appears the applicant might have been specifically requiring a prompt message that is displayed within an additional prompt window, where the message describes a second state (see paragraphs 0161 and 0162 of the instant application’s specification)). Yet, the claim language does NOT require this particular aspect of prompting and only requires a display (of a window layout); and as explained above, the ‘prompt’ in the limitation is interpreted as is any visual indication/result of the window layout of the second state. Should the applicant require the more specific type of message prompt that is displayed within an additional prompt window, then the examiner suggests the applicant consider clarifying the claim language to include this non-claimed feature.
The applicant argues the other independent claim(s) are allowable for reasons presented by the applicant for claim 1 above. However this argument is not persuasive since claim 1 has been explained/shown to be rejected above.
The applicant argues that the claims that depend upon the independent claims are allowable by virtue of their dependency upon them. However the independent claims have been shown/explained to be rejected, and thus, this argument is not persuasive.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILSON W TSUI whose telephone number is (571)272-7596. The examiner can normally be reached Monday - Friday 9 am -6 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, Adam Queler can be reached at (571) 272-4140. 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.
/WILSON W TSUI/Primary Examiner, Art Unit 2172
Prosecution Insights