DETAILED ACTION
Applicant amends claims 1-20 by preliminary amendment dated 04/21/2023.
Drawings are objected to for informalities.
Claims 10 and 11 objected to for minor informalities.
Claim 20 rejected under 35 USC § 101 as directed to signals per se.
Claims 1-20 rejected under 35 USC § 103.
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 .
Drawings
Drawings comprising black and white photographs "must be of sufficient quality so that all details in the photographs are reproducible in the printed patent." 37 CFR 1.84(b). Lines, numbers, and letters "must be made by a process which will give them satisfactory reproduction characteristics." 37 CFR 1.84(l). Shading is encouraged "if it does not reduce legibility." 37 CFR 1.84(m). Figures 5-7 and 9-11 filed 05/16/2023 are objected to because the shading reduces text legibility.
Claim Objections
Claims 10 and 11 are objected to because of the following informalities: The first position and first size should be established before reciting the second position and second size. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 20
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim is drawn to signals per se. A transitory signal, while physical and real, "does not possess concrete structure" and "is not composed of matter." MPEP 2106.03. The present specification defines the medium as any “medium that can be configured to carry or store expected program code in a form of instructions or a data structure.” Specification, ¶ 137. Accordingly, claim 20 is directed to non-statutory subject matter because the claimed “computer program product” is interpreted to include transitory signal embodiments.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Walkin et al., U.S. PG-Publication No. 2020/0326839 A1, in view of Shin et al., U.S. PG-Publication No. 2014/0164957 A1.
Claim 1
Walkin discloses a task start method, comprising invoking a window start interface of a system when a first task of a first application runs on a screen, when the first task triggers a task jump for a second task, and when a window is required to display the second task. Walkin discloses “a method for performing window-switching within a subset of windows (e.g., a set of slide-over applications or windows) that are configured to be displayed concurrently with another full-screen window.” Walkin, ¶ 30. In one embodiment, "when a request to open an application in a concurrent-display configuration is received, the application is displayed in the concurrent-display configuration if the application is not associated with multiple windows, and a window-selector user interface is displayed in the respective concurrent display configuration if the application is associated with multiple windows.” Id. at ¶ 34.
Walkin discloses wherein the window start interface … is configured to generate a first floating window. Walkin discloses that the method uses a “split-screen” display configuration, wherein at least two applications are concurrently displayed together; and a “slide-over view” to “display one of the at least two applications as overlaying the other,” wherein the slide-over window is an overlay “for a background full-screen window or a pair of split-screen windows” (slide-over window → floating window). Id. at ¶ 200.
Walkin discloses starting, based on the window start interface, based on a current unchanged display status of the first task, and when the second task supports a floating window display, the second task, wherein the current unchanged display status comprises a full-screen display, a split-screen display, or the floating window display. In one embodiment, a drag operation causes the method to display “a visual feedback (e.g., the representation 4012 of the second application is elongated), as shown in FIG. 4A6, indicating that, if the input ends at the current location within the first predefined portion of the touch screen, a window of the second application will be displayed with the first window of the first application in a respective concurrent-display configuration ( e.g., a slide-over display configuration, with the window of the second application overlaying a portion of the first window of the first application).” Id. at ¶ 205. The visual feedback indicates that the second task supports a floating window display. In one embodiment, "when the representation of a slide-over window (e.g., the window 4010, the window 4020, the window 4040, or the window 4042) is activated in the application-switcher user interface 4032, the slide-over window is recalled to the display with another full-screen or split screen window ( e.g., the window 4002, the window 4034, or a pair of windows in the split-screen configuration) underlying the slide-over window." The window underlying the slide-over window “is the full-screen window or the pair of split-screen windows that was on display immediately prior to the display of the application-switcher user interface 4032” (i.e., unchanged display status comprising a full-screen or split-screen display). Id. at ¶ 214; FIGS. 4A1-4A50.
Walkin discloses creating, based on the window start interface, the first floating window; and displaying, using the first floating window, the second task. Walkin discloses that "a second application window (e.g., window 4010 in FIG. 4A7) of a second application (e.g., the online video application) is displayed overlaying the first application window (e.g., window 4002) of the first application, in a slide-over display configuration.” Id. at ¶ 207; FIG. 4A7.
Walkin discloses that the method is used for performing “system-level operations” such as “navigating between applications, switching between slide-over windows, converting between display configurations, opening a document across applications, etc.” Id. at ¶¶ 208, 221. However, Walkin does not disclose wherein the window start interface is a system-level common standard application programming interface (API).
Shin discloses a window start interface that is a system-level common standard application programming interface (API). Shin discloses a display device comprising a “mode switch button 228” used to “display a plurality of applications that are being executed on the main screen 210,” wherein “a plurality of application may be switched between a free style mode and a split mode.” A plurality of applications are displayed “partially overlapped with one another in the free style mode” (i.e., floating windows) whereas “the plurality of applications are displayed separately in different areas … in the split mode” (i.e., split-screen windows). Shin, ¶ 80. This multi-window framework 280 “may be invoking an Application Program Interface (API),” wherein the framework 280 includes “a multi-window manager 281 and a multi-window service 282.” The multi-window service 282 “tracks the life cycles of applications executed in multiple windows and manages states of each application such as the size and position of the application,” wherein an “invoked API may manage the size, position, and visibility of each window.” Id. at ¶¶ 92-100; FIG. 3B; See Also ¶¶ 112, 120 (invoke an API to “check window information about each window” and “an execution state of an application executed in the window”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the window-switching method of Walkin to incorporate the API managing multiple windows as taught by Shin. One of ordinary skill in the art would be motivated to integrate the API managing multiple windows into Walkin, with a reasonable expectation of success, in order to improve user convivence (i.e., enhance user experience) by enabling execution of “a plurality of application simultaneously in a mobile device,” using a technique “that changes the sizes or positions of a plurality of windows in which a plurality of application are executed respectively, as intended by a user.” See Shin, ¶¶ 7-8.
Claim 2
Shin discloses wherein when displaying the second task, the task start method further comprises resuming lifecycle statuses of displayed content of the first task and the second task at the same time. Shin discloses a display device comprising a “mode switch button 228” used to “display a plurality of applications that are being executed on the main screen 210,” wherein “a plurality of application may be switched between a free style mode and a split mode.” A plurality of applications are displayed “partially overlapped with one another in the free style mode” (i.e., floating windows) whereas “the plurality of applications are displayed separately in different areas … in the split mode” (i.e., split-screen windows). Shin, ¶ 80. This multi-window framework 280 “may be invoking an Application Program Interface (API),” wherein the framework 280 includes “a multi-window manager 281 and a multi-window service 282.” The multi-window service 282 “tracks the life cycles of applications executed in multiple windows and manages states of each application such as the size and position of the application,” wherein an “invoked API may manage the size, position, and visibility of each window.” Id. at ¶¶ 92-100; FIG. 3B.
Claim 3
Walkin discloses wherein operation controls in first displayed content of the first task and second displayed content of the second task both are in an available status when displaying the second task, and wherein the task start method further comprises switching an operation focus based on an operation of a user between the first displayed content and the second displayed content. Walkin discloses that in a first concurrent-display configuration (e.g., a slide-over configuration), “that includes concurrent display of a main application and one or more auxiliary applications, where the user interfaces of the auxiliary application(s) is overlaid on a portion, less than all, of the user interface of the main application, and where the user interface of at least one of the auxiliary applications (e.g., the top one in a stack of auxiliary applications) and the user interface of the main application are responsive to user inputs to perform operations within those applications (e.g., user interface objects within the user interfaces function as they normally would in a full-screen standalone display mode, and direct copy and paste and/or drag and drop functions are available across the two or more concurrently displayed applications))" (i.e., both windows are in an available status). Walkin, ¶ 379.
Claim 4
Walkin discloses wherein the second task is of the first application. The examples in Walkin “refer to different application being displayed in the split-screen mode and the slide-over mode,” however “many of the examples are also valid if the windows of the different applications are replaced with different windows of the same application displayed in the split-screen or the slide-over mode.” Walkin, ¶ 200. In one embodiment, “the application-switcher user interface displays windows of different configurations (e.g., full-screen windows, slide-over windows, and split-screen windows, minimized windows, and/or draft windows, etc.) that may correspond to the same or different applications.” Id. at ¶ 203.
Claim 5
Walkin discloses wherein the second task is of a second application different from the first application. The examples in Walkin “refer to different application being displayed in the split-screen mode and the slide-over mode,” however “many of the examples are also valid if the windows of the different applications are replaced with different windows of the same application displayed in the split-screen or the slide-over mode.” Walkin, ¶ 200. In one embodiment, “the application-switcher user interface displays windows of different configurations (e.g., full-screen windows, slide-over windows, and split-screen windows, minimized windows, and/or draft windows, etc.) that may correspond to the same or different applications.” Id. at ¶ 203.
Claim 6
Walkin discloses wherein after displaying the second task, the start method further comprises: identifying that the full-screen display for the second task is triggered and the first task supports the floating window display; and in response to identifying that the full screen display for the second task is triggered and the first task supports the floating window display: closing the first floating window, displaying the second task in a full-screen manner, creating a second floating window, and displaying the first task based on the second floating window. Walkin discloses an embodiment comprising “detecting a fifth input that corresponds to a request to drag the second user interface relative to the first user interface; and in response to detecting that the fifth input meets swapping criteria ... swapping positions of the first user interface and the second user interface, and displaying the navigation affordance in the second user interface instead of the first user interface." Walkin, ¶ 446.
Claim 7
Walkin discloses wherein after displaying the second task, the task start method further comprises: identifying that a current display status of the first task is the full-screen display, the split-screen display for the second task is triggered, and the first task supports the split-screen display; and in response to identifying the that the current display status of the first task is the full-screen display, the split-screen display for the second task is triggered, and the first task supports the split-screen display. Figures 4E1-4E28 “illustrate user interface behaviors in response to an input ragging a representation of a window across the display to different locations and releasing it into different drop zones on the display.” Walkin, ¶ 339. Starting configurations include Figure 4E2, wherein a slide-over window is concurrently displayed with a full-screen window (i.e., after displaying the second task in first floating window). Id. at ¶ 343. Figure 4E8 illustrates “the different drop zones that are predefined … and that correspond to different final display configurations for the dragged window when the input ends” (dragged window → trigger new window configuration). Id. at ¶ 349. Figure 4E16 illustrates an intermediate state where “the dragged window started as a slide-over window 4614.” Id. at ¶ 359. Figure 4E18 illustrates a final state using drop zone A, wherein the dragged window is displayed in split-screen window 4602 and the full-screen application is converted into a split-screen window 4604. Id. at ¶ 362.
Claim 8
Walkin discloses wherein after displaying the second task, the task start method further comprises: identifying that a current display status of the first task is the split-screen display with a third task, the split-screen display for the second task is triggered, and the third task supports the floating window display; and in response to identifying that the current display status of the first task is the split-screen display with the third task, the split-screen display for the second task is triggered and the third task supports the floating window display: closing the first floating window; displaying the first task and the second task in a split-screen manner. Figures 4E1-4E28 “illustrate user interface behaviors in response to an input ragging a representation of a window across the display to different locations and releasing it into different drop zones on the display.” Walkin, ¶ 339. Starting configurations include Figure 4E2, wherein a slide-over window is concurrently displayed with a full-screen window (i.e., after displaying the second task in first floating window). Id. at ¶ 343. Figure 4E8 illustrates “the different drop zones that are predefined … and that correspond to different final display configurations for the dragged window when the input ends” (dragged window → trigger new window configuration). Id. at ¶ 349. Figure 4E16 illustrates an intermediate state where “the dragged window started as a slide-over window 4614.” Id. at ¶ 359. Figure 4E18 illustrates a final state using drop zone A, wherein the dragged window is displayed in split-screen window 4602 and the full-screen application is converted into a split-screen window 4604 (i.e., disapplying the first and second task in a split-screen manner). Id. at ¶ 362.
Walkin discloses creating a second floating window; and displaying the third task based on the second floating window. Starting configurations include Figure 4E1, wherein a split-screen application is concurrently displayed with another split-screen window. Figure 4E9 illustrates an intermediate state where “the dragged email window will be displayed as a split-screen window on the left-side of the display, concurrently with another split-screen window of the messages application.” Id. at ¶ 351. Figure 4E19 illustrates a final state using drop zone B, wherein the dragged window of the email application is a slide-over window 4614 (i.e., displaying third task in floating window).
Claim 9
Walkin discloses wherein after displaying the second task, the task start method further comprises: identifying that a current display status of the first task is the floating window display, the split-screen display for the second task is triggered, and the first task supports the split-screen display; and in response to identifying that the current display status of the first task is the floating window display, the split-screen display for the second task is triggered, and the first task supports the split-screen display: closing a second floating window of the first task and the first floating window; and displaying the first task and the second task in a split-screen manner. Figures 4E1-4E28 “illustrate user interface behaviors in response to an input ragging a representation of a window across the display to different locations and releasing it into different drop zones on the display.” Walkin, ¶ 339. Starting configurations include Figure 4E2, wherein a slide-over window is concurrently displayed with a full-screen window (i.e., after displaying the second task in first floating window). Id. at ¶ 343. Figure 4E8 illustrates “the different drop zones that are predefined … and that correspond to different final display configurations for the dragged window when the input ends” (dragged window → trigger new window configuration). Id. at ¶ 349. Figure 4E16 illustrates an intermediate state where “the dragged window started as a slide-over window 4614.” Id. at ¶ 359. Figure 4E18 illustrates a final state using drop zone A, wherein the dragged window is displayed in split-screen window 4602 and the full-screen application is converted into a split-screen window 4604 (i.e., disapplying the first and second task in a split-screen manner). Id. at ¶ 362.
Claim 10
Walkin discloses wherein after displaying the second task, the task start method further comprises: identifying that a current display status of the first task is the full-screen display, a display status exchange for the second task is triggered, and the task supports the floating window display; and in response to identifying that the current display status is the full-screen display, the display status exchange for the second task is triggered, and the first task support the floating window display: closing the first window, displaying the second task in a full-screen manner, creating a second floating window, wherein a second size of the second floating window and a second position of the second floating window are consistent with a first size of the first floating window and a first position of the first floating window, and displaying the first task based on the second floating window. Walkin discloses an embodiment comprising “detecting a fifth input that corresponds to a request to drag the second user interface relative to the first user interface; and in response to detecting that the fifth input meets swapping criteria ... swapping positions of the first user interface and the second user interface, and displaying the navigation affordance in the second user interface instead of the first user interface." Walkin, ¶ 446.
Claim 11
Walkin discloses wherein after displaying the second task, the task start method further comprises: identifying that a current display status of the first task is the split-screen display with a third task, a display status exchange for the second task is triggered, and the first task supports the floating window display, and in response to identifying that the current display status of the first task is the split-screen display with the third task ,the display status exchange for the second task is triggered, and the first task supports the floating window display: closing the first floating window, displaying the third task and the second task in a split-screen manner. Figures 4E1-4E28 “illustrate user interface behaviors in response to an input ragging a representation of a window across the display to different locations and releasing it into different drop zones on the display.” Walkin, ¶ 339. Starting configurations include Figure 4E2, wherein a slide-over window is concurrently displayed with a full-screen window (i.e., after displaying the second task in first floating window). Id. at ¶ 343. Figure 4E8 illustrates “the different drop zones that are predefined … and that correspond to different final display configurations for the dragged window when the input ends” (dragged window → trigger new window configuration). Id. at ¶ 349. Figure 4E16 illustrates an intermediate state where “the dragged window started as a slide-over window 4614.” Id. at ¶ 359. Figure 4E18 illustrates a final state using drop zone A, wherein the dragged window is displayed in split-screen window 4602 and the full-screen application is converted into a split-screen window 4604 (i.e., disapplying the first and second task in a split-screen manner). Id. at ¶ 362.
Walkin discloses creating a second floating window, wherein a second size of the second floating window and a second position of the second floating window are consistent with a first size of the first floating window and a first position of the first floating window, and displaying the first task based on the second floating window. Starting configurations include Figure 4E1, wherein a split-screen application is concurrently displayed with another split-screen window. Figure 4E9 illustrates an intermediate state where “the dragged email window will be displayed as a split-screen window on the left-side of the display, concurrently with another split-screen window of the messages application.” Id. at ¶ 351. Figure 4E19 illustrates a final state using drop zone B, wherein the dragged window of the email application is a slide-over window 4614 (i.e., creating a second slide-over window).
Claim 12
Walkin disclose wherein after displaying the second task, the task start method further comprises: identifying that a current display status of the first task is the floating window display and a display status exchange for the second task is triggered, and exchanging, in response to identifying that the current display status of the first task is the floating window display and the display status exchange for the second task is triggered, positions and window size settings of a second floating window of the first task and the first floating window to be displayed. The method uses interactions “with an overlay-switcher user interface that concurrently displays multiple slide-over windows corresponding to different applications.” Walkin, ¶ 202. The behavior of the overlay-switcher user interface 4054 is analogous to an application-switcher user interface (e.g., application-switcher user interface 4032 in FIG. 4A18) in that, tapping on a representation of a slide-over window in the overlay-switcher user interface 4054 causes that slide-over window to be displayed” (i.e., exchange the task/application in the slide-over window). Id. at ¶ 221.
Claim 13
Walkin discloses identifying that the second task does not support the floating window display, and in response to identifying that the second task does not support the floating window display, starting the second task, exiting the first task, and displaying the second task in a full-screen manner. Walkin discloses that “each application 136-1 stores multitasking data 176. In some embodiments, multitasking data 176 includes a compatibility flag (e.g., a flag accessed by compatibility module 184 to determine whether a particular application is compatible with multitasking mode), a list of compatible sizes for displaying the application 136-1 in the multitasking mode (e.g., ¼, ⅓, ½, or full-screen).” Walkin, ¶ 128. In some embodiments, “other operation may be performed” based on where the drag input ends. If the predefined region for slide-over windows “presents an acceptable drop location for the document, the document will be inserted into the drop location in the slide-over window,” or “returned to the original location if no acceptable drop location is available” (i.e., does not support the floating window display). Id. at ¶ 232. The appearance of the window representation may indicate “that no acceptable drop location is available at this location, and no operation will be performed with respect to the document if the input were to end at the current location.” Id. at ¶ 296. Figure 4E24 illustrates a final state using drop zone G, wherein ”the window of the email application is a standalone full-screen window” and “previously concurrently displayed window is no longer displayed” (e.g., exiting first task; running first task in background).
Claim 14
Walkin discloses identifying that the second task does not support the floating window display; and in response to identifying that the second task does not support the floating window display: starting the second task, running the first task in a background, and displaying the second task in a full-screen manner. Walkin discloses that “each application 136-1 stores multitasking data 176. In some embodiments, multitasking data 176 includes a compatibility flag (e.g., a flag accessed by compatibility module 184 to determine whether a particular application is compatible with multitasking mode), a list of compatible sizes for displaying the application 136-1 in the multitasking mode (e.g., ¼, ⅓, ½, or full-screen).” Walkin, ¶ 128. In some embodiments, “other operation may be performed” based on where the drag input ends. If the predefined region for slide-over windows “presents an acceptable drop location for the document, the document will be inserted into the drop location in the slide-over window,” or “returned to the original location if no acceptable drop location is available” (i.e., does not support the floating window display). Id. at ¶ 232. The appearance of the window representation may indicate “that no acceptable drop location is available at this location, and no operation will be performed with respect to the document if the input were to end at the current location.” Id. at ¶ 296. Figure 4E24 illustrates a final state using drop zone G, wherein ”the window of the email application is a standalone full-screen window” and “previously concurrently displayed window is no longer displayed” (e.g., exiting first task; running first task in background).
Claim 15
Walkin discloses identifying that the first task is displayed in a full-screen manner and the task jump for the second task is triggered, and determining using the first application and in response to identifying that the first task is displayed in the full-screen manner and the task jump for the second task is triggered, whether the window is required to display the second task. Figures 4E1-4E28 “illustrate user interface behaviors in response to an input ragging a representation of a window across the display to different locations and releasing it into different drop zones on the display.” Walkin, ¶ 339. Starting configurations include Figure 4E2, wherein a slide-over window is concurrently displayed with a full-screen window (i.e., after displaying the second task in first floating window). Id. at ¶ 343. Figure 4E8 illustrates “the different drop zones that are predefined … and that correspond to different final display configurations for the dragged window when the input ends” (dragged window → trigger new window configuration). Id. at ¶ 349. Figure 4E16 illustrates an intermediate state where “the dragged window started as a slide-over window 4614.” Id. at ¶ 359. Figure 4E18 illustrates a final state using drop zone A, wherein the dragged window is displayed in split-screen window 4602 and the full-screen application is converted into a split-screen window 4604 (i.e., disapplying the first and second task in a split-screen manner). Id. at ¶ 362.
Claims 16-19
Claims 16-19 are rejected utilizing the aforementioned rationale for Claims 1-4; the claims are directed to a system performing the method.
Claim 20
Claim 20 is rejected utilizing the aforementioned rationale for Claim 1; the claim is directed to a medium storing instructions corresponding to the method.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Dunning et al., U.S. PG-Publication No. 2019/0278431 A1 (abstract describing “method for controlling display of application windows” including “automated switching to the picture-in-picture display”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3172. The examiner can normally be reached M-F 10-6 ET.
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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 November 29, 2025