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
The Amendment filed 7/27/2026 has been entered. Claims 1-3, 6-22 remain pending in the application.
Response to Arguments
Applicant’s arguments, see pages 12-16 of remarks/arguments, filed 7/23/2026, with respect to the rejection(s) of claims 1-20 under 35 USC 102(a)(1) and 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Ben-Aharon (US 20160371312 A1) and Davis (US 20130106907 A1).
While it is agreed that Kilpatrick lacks the proper language to teach differentiating between different data types, the amended claim language refers to a “scaling coefficient”, a not previously introduced requirement of the claims. As a coefficient for scaling based on the data type of content that is to be scaled has not been previously introduced, content outside the scope of the first list of claims has introduced.
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 22 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because it claims a computer program product which can be a program, a program itself does not fall into any one of the four-patent eligible subject matter categories.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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, 20-22 are rejected under 35 U.S.C. 103 as being anticipated by Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) and further in view of Davis (US 20130106907 A1)
Regarding claims 20, 1, 22,
Kilpatrick teaches:
A terminal comprising: a memory configured to store instructions; and one or more processors coupled to the memory (Kilpatrick ¶100 “The processor 810 may include one or more processing devices, such as one or more ARM-type processors, one or more digital signal processors (DSPs), other processors, or any combination thereof. The processor 810 can access one or more computer readable media, Such as the representative memory”) and configured to execute the instructions to cause the terminal to: detect a trigger event, determining, in response to the trigger event, (Kilpatrick ¶125 “a single internal sensor 1834, and two hinge sensors 1812 and 1822, enabling the electronic device 1801 to detect a first parameter, Such as an orientation, position, momentum, or acceleration using the internal sensor 1834, and to further detect a folded, unfolded, or partially folded configuration of the panels 1802, 1804, 1806 via the hinge sensors” Note: A folding action of the device that alters its orientation and position is an example of a trigger event in Kilpatrick, we know it is a trigger event as multiple sensors exist to detect events of this type.) that a first application is in a large-screen display mode;(Kilpatrick ¶5 “A multi-fold mobile device with a configurable interface is disclosed. When fully extended, the device may provide a panorama view, similar to widescreen televisions. When fully folded, the device may provide a small form factor with an abbreviated view similar to cellular telephones. In addition, the user interface (UI) displayed on the device may change based on the folding configuration of the device.” Note: Kilpatrick teaches that for a folding mobile device a “large-screen display mode”, referred to in Kilpatrick as a panorama view similar to a widescreen television, may be presented when the device is fully extended/unfolded. As described by the claims this happens in response to a trigger event, the unfolding of the device.) obtaining, in response to the trigger event, a first internal element of a first control on a first user interface; (Kilpatrick ¶199 “For example, the graphical user interface element may be an application icon Such as the icon 3206 displayed in FIG. 34 as having a first portion displayed at the leftmost display Surface and having a second portion displayed at the center display Surface during the movement 3412 across the gap 3414. As another example, the graphical user interface element may be an application window Such as the window 3516 displayed in FIG. 36 as having a first portion displayed at the left-most display Surface and having a second portion displayed at the center display Surface during the movement 3618 across the gap 3414.”Note: The application’s specifications define a “control” in this context as ¶101 “In computer programming, a control (or a component, an assembly, a widget, or a control) is a graphical user interface element, and arrangement of displayed information such as a window or a text box may be changed by a user … A control is configured to lay out an element (or an object or data) on a user interface. In embodiments of this disclosure, if the control is considered as a container, an object (for example, a text or an image) placed in the container is referred to as an element. Because controls can be nested in use, an element in a child control (or a child view) is called a sub-element relative to a parent control (or a parent view). FIG. 3 is still used as an example. An image 35 may be further set on the child view 34 by using the ImageView control.” A “control” as defined by the specifications refers to a broad number of GUI elements that can display content, in the example described a control can be a simple window view element allowing an application, image, or other content to be displayed. This is clearly taught by Kilpatrick which teaches GUI elements to provide windows for displaying content like an application.)
wherein the first internal element is an image, the image is associated with a subtype of a plurality of subtypes each associated with a respective range of aspect ratios of an image; obtaining, based on the subtype, a scaling strategy corresponding the subtype; (Kilpatrick ¶188 “when the sensor input 4202 or 4302 indicates the device is in the fully extended configuration and the active application is a video player, the video may be displayed across all three screens when the device is detected to be in a landscape orientation … the video may be stretched to cover the available display area, while in another embodiment an aspect ratio of the video may be preserved during display.” Note: When scaling up a video to fit a full wide screen configuration the image frame can be stretched to the full display size, or since the aspect ratio is taught to be known the video can be sized up while keeping the aspect ratio. This shows Kilpatrick teaches how scaling is handled is determined by the aspect ratio of the image content being displayed. As these varying aspect ratios are what the claim defines as subtypes, Kilpatrick teaches that the scaling strategy can correspond to the subtype.) determining, in response to the first application being in the large-screen display mode and based on the scaling strategy, a first scaling size of the first internal element;
wherein determining the first scaling size comprises: computing a target height of the first internal element as a product of a first height of a display region of the first application in the large-screen display mode; and computing a target width of the first internal element based on the target height and a ratio of a width of the first internal element to a second height of the first internal element prior to scaling; (Kilpatrick ¶188 “when the sensor input 4202 or 4302 indicates the device is in the fully extended configuration and the active application is a video player, the video may be displayed across all three screens when the device is detected to be in a landscape orientation … the video may be stretched to cover the available display area, while in another embodiment an aspect ratio of the video may be preserved during display.” Note: This portion of the claim states that the height to width ratio of an element remains the same even when it is scaled up, that is to say the aspect ratio is preserved when scaling which is directly taught as an available scaling option in Kilpatrick.)
determining, based on the first scaling size and a first size of the first control in the large-screen display mode, a layout of the first internal element; (Kilpatrick ¶182 “Where the device is determined to be in the fully extended configuration, if the application Supports the fully extended configuration, an application window may be displayed across all three screens, at 4320.” Note: Previously it was shown how a control can define a GUI element such as an application window. Kilpatrick teaches that when its device is unfolded and fully extended an application window can be sized to fit the new wider display. The application itself is the “internal element”, the content playing inside its “first control” the application window. Thus, Kilpatrick teaches determining the size of an internal element and control when in “large-screen display mode” analogous to the fully extended configuration.) displaying a second user interface based on the first scaling size and the layout. (Kilpatrick ¶82 “By enabling the electronic device 101 to be positioned in multiple foldable configurations, a user of the electronic device 101 may elect to have a small form factor for easy maneuverability and functionality or may elect an expanded, larger form factor for displaying rich content and to enable more significant interaction with one or more software applications via expanded user interfaces.” ¶138 “For example, the software controller may initiate a change of a size of an application, such as an application window or user interface element, initiate a change of an orientation of an application, initiate an auto-launch of an application, initiate an auto-exit of an application, initiate a state change of an application, or a combination of action” Note: This portion of the claim simply states that a new, “second”, UI will be displayed based on the new wide-screen size discussed previously. This is taught as Kilpatrick clearly teaches the ability to update its UI around trigger events that expand the size of the display.)
While Kilpatrick teaches that an image’s “subtype”, referring to an image’s aspect ratio where there are multiple possible aspect ratios, is used in determining the scaling strategy it does not teach that a first internal element is evaluated by its data type on whether it is a text or image type. This is taught by Ben-Aharon which teaches obtain a type of the element, wherein the type is a text type or an image type, (Ben-Aharon ¶449 “In such a scenario, system 100 may review the data for the current page, and create a signature based on the data types of the imported data. Such data type determination may be based on actual specified data types (e.g. database field types, XML entity types etc.), data types determined by analysis of the content of the imported data (e.g. recognizing text field or type and format of included media files) and data types specified by the user through” ¶89 “Each signature may include a count of the number of semantic component types at various level of details (e.g. [1 text, 2 images, 1 gallery] or [3 visuals, 1 gallery]) as discussed in more detail herein below.” Note: Ben-Aharon teaches accepting multiple pieces of data, where each data has its type determined to make a signature based on the type. As seen by examples provided in ¶89, possible types include text and image.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Ben-Aharon where a first internal element is determined to be a text or image data type.
There are several reasons that would motivate one to do so, different types of data have to be handled and displayed differently. For example, formatting and spacing text requires more overhead than simply inserting an image, to handle the displaying of a text type vs an image type requires different considerations, determining what type an element to display is as soon as an element is received guarantees we always know how to handle the element.
Neither Kilpatrick nor Ben-Aharon teaches determining how to scale the content based on its type which involves setting a scaling coefficient, this is taught by Davis which teaches obtain, based on the type or the subtype, a scaling strategy corresponding to the type or the subtype; and a scaling coefficient associated with the type (Davis ¶3 “An object is zoomed upon selection. A scaling factor is calculated for zooming the object based on current viewing properties of a document and properties of the object. The determined viewing properties may include a current zoom level of the document and/or a font size of text within the document. The determined object properties (e.g. a font size in the object) are used to calculate the scaling factor to zoom the object such that after the object is zoomed, the object is similar to a viewing experience for the rest of the document. As well, text of the document may be displayed to increase the readability of the document. For example, the text may be displayed such that each line of displayed text averages out to a predetermined number of characters (e.g. 50-75 characters) per line.” ¶66 “Flowing to operation 830, properties of the object to zoom are determined. For example, is the object an image, not an image, a current text size used for text within the object, a current zoom level on the object and the like. [0067] Transitioning to operation 840, a scaling factor to zoom the object to an initial zoom state is calculated.” Note: Davis teaches a scaling factor, analogous to the claims scaling coefficient, that is used to scale object being displayed. Davis teaches that this factor will be set whenever scaling the object, and that this will be done differently for images and non-images, like text. Thus, Davis has been shown to teach setting a scaling coefficient and performing scaling differently based on an element’s type, text or image.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Davis where determining whether first internal element is an image type or text type, and then the sub type if the type is image, determines a scaling strategy for the element and a scaling coefficient associated with the type.
There are several reasons that would motivate one to do so, scaling text data that is composed of multiple differently sized individual parts poses a different challenge than scaling an image, a fixed dimensional area. One way ensure that scaling properly considers the different implicit nature of data is to set a scaling strategy and determining a scaling factor respective to the type.
Regarding claim 2, 21,
Kilpatrick teaches:
The method of claim 1, wherein the first size comprises a width of the first control in the large-screen display mode, and wherein the width is associated with a screen width in the large-screen display mode, the width is associated with a window width of the first application in the large-screen display mode,(
PNG
media_image1.png
446
604
media_image1.png
Greyscale
Kilpatrick ¶165 “In FIG. 39, the electronic device 3801 is depicted in a landscape mode 3900 where a web browser application image is displayed as a landscape-type display across all three display surfaces” Note: In Fig. 39 we can see that the application window display is fit to the complete large-screen display width when the device is being used in a large-screen display mode, referred to as a “landscape mode” by Kilpatrick) or the first control is nested in a second control as a child control and the width is associated with a scaling width that is of the child control and that is based on the second control in the large-screen display mode. (
PNG
media_image2.png
929
720
media_image2.png
Greyscale
Kilpatrick ¶152 “When the device 3201 is extended from the fully folded configuration 3200 of FIG. 32 to the fully extended configuration 3300 of FIG.33, a display screen 3308 of the center panel and a display screen 3310 of the right-most panel are exposed and viewable by a user. The display screens 3308 and 3310 may show a desktop area while the left-most panel may continue to show an icon panel including the representative application icon 3206. 0153 FIG. 34 depicts a movement of the representative application icon 3206 toward a gap 3414 between a left-most display surface and the center display surface 3308 in response to a user input … As illustrated in FIG. 35, in a particular embodiment, when application icon 3206 of FIGS. 32-34 is pulled across the gap 3414 with Sufficient speed, … the application window 3516 may extend to cover both the center display surface 3308 and the right-most display surface 3310, which may be configured to operate as a 2-panel effective display SCC.” Note: This portion of the claims states that rather having a “first control”, aka GUI element, span the entire width of the display in large-screen display mode that the GUI element/control is a nested child element inside a “second control” where the “second control” is being displayed in the large-screen display set up. This is clearly taught by Kilpatrick, two GUI parent containers analogous to the “second control” are taught, the first is the smaller GUI element that contains an icon panel holding interactable application icons. These icons can be dragged to the left into the control that takes up two displays where the application can be opened and viewed in an application window. Both exist in the large-screen display configuration as seen in Fig. 32 unfolding to Fig. 33. Interacting with the icon panel and sliding one to the application window to the left can be seen in Fig. 34.)
Regarding claim 3,
Kilpatrick teaches:
The method of claim 1, wherein the first user interface comprises a first pop-up window, and wherein the method further comprises: obtaining a second internal element of a second control in the first pop-up window; determining a second scaling size of the second internal element; determining, based on the second scaling size, a third scaling size of the second control; determining, based on the third scaling size, a fourth scaling size of the first pop-up window;(Kilpatrick ¶107 “The processor 810 may be responsive to the wireless controller 840 to display call indicia, Such as a caller identification or a caller number, at one or more of the displays 802, 804, and 806 when the device 800 receives an incoming call. The processor 810 may determine a size, position, and orientation, as well as a particular display 802, 804, and 806, to display the call indicia at least partially based on the folding configuration of the device 800 that is determined based on input from the sensors 874 and 876. For example the call indicia may be displayed as a pop-up window or text over one or more other applications having a size, location, and orientation based on the folding configuration.” Note: Kilpatrick teaches a pop-up window displaying a “second control”. It has been established previously that a “control” can refer simply to a UI window displaying content such as text, images, an application, etc… Thus the inside of the pop-up that displays the call indicia info is the “second control”. Kilpatrick teaches the size and position of the “second control”, the call info, is determined first. Once the size and orientation of the call indicia is found then the pop-up window size and orientation is found respective to the device’s folding configuration.) determining, based on the fourth scaling size, a location of a scaled first pop-up window; (Kilpatrick ¶107, cited above, teaches that alongside size being determined for a pop-up window and its inner content “size, position, and orientation” are also found, teaching that the location of the pop-up window is determined.) and drawing, based on a second size of the first pop-up window and the location, a second pop-up window on the second user interface, wherein the second pop-up window comprises an element obtained through scaling based on the second scaling size. (Kilpatrick ¶107 “For example the call indicia may be displayed as a pop-up window or text over one or more other applications having a size, location, and orientation based on the folding configuration.” Note: As defined in claim 1 the “second user interface” referenced here refers to the user interface after it has been updated to fit the new width of the full screen display. That is to say, we make a “second pop-up window” sized to our new, larger display based on the first instance of the pop-up window. In Kilpatrick ¶5 it is taught that the fully unfolded device allows for user interface elements, analogous to the claims “controls”, to be updated to fit the new display size. Here in Kilpatrick ¶107 it is taught that a pop-up window size and location can be updated based on the folding configuration. This clearly teaches the ability for a “second pop-up window” in a “second user interface” that is a larger sized version of a “first pop-up window” from a “first user interface” referring to the UI before it was updated to be wider.)
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of Peterson (The Fastest Way to Scroll Through Your iPhone's Home Screen Pages & Folders) and further in view of La (US 20160187994 A1).
Regarding claim 6,
Kilpatrick teaches:
The method of claim 1, wherein a control in large-screen display mode
While Kilpatrick teaches UI controls and elements in a large-screen display mode and other configurations it does not teach a “flipping control” which allows UI elements to be flipped between like pages. This is instead taught in Peterson’s description of iOS’s home screen which teaches wherein the first control is a view flipping control, obtaining a first quantity of internal elements of the view flipping control, a second view flipping control, and a display effect of the view flipping control large-screen display mode. (
PNG
media_image3.png
808
896
media_image3.png
Greyscale
Note: As seen in the before/after of the UI being flipped in response to user input the current “page” or view of the UI is flipped to a second view where a different number internal UI elements are shown. This is also stated by the description in the image provide above detailing that swiping through the pages, aka flipping them, presents the user with a new page of application icons. The UI view present in the image above takes up the entire screen of the device, teaching that the display of UI elements happens over a “large-screen display mode”.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Peterson where a control in large-screen display mode is a flipping control that can switch between a first view with a first quantity of internal elements to a second view flipping control in the large-screen display mode.
There are several reasons that would motivate one to do so, rather than slowly traversing through a UI by swiping or scrolling which gradually introduces new information a user may wish for new UI content to be presented with more speed and efficiency depending on the task. Allowing the UI to be flipped through to revel an entire new second view provides a means to do so.
While Peterson teaches a flipping control for a UI it does not teach that its control determines the number of UI elements being displayed based on the current size of the interactable UI control. This is instead taught in La which teaches wherein the first control is a view control, and wherein determining the first scaling size comprises: obtaining a first quantity of internal elements of the view control;(La ¶166 “For example, referring to FIG. 11A, when the foldable device 100 displays an icon that corresponds to an application, if the foldable device 100 is in a state of being folded at a predetermined angle or a lesser angle, the controller 180 may display only a predetermined number of icons on the edge display area a1.” ¶204 “FIG. 21 illustrates a diagram for explaining an example of the foldable device 100 in which a foldable cover 300 is equipped, according to an exemplary embodiment … The foldable device 100 may determine an area of the flexible display unit 115 which is covered by the foldable cover 300, by sensing a location and a number of magnets that contact the flexible display unit 115 … Additionally, referring to a center portion of FIG. 21, as the foldable cover 300 is opened in correspondence with a predetermined area, the foldable device 100 may activate the floating display area b2 of the flexible display unit 115.” Note: La teaches a foldable device display that is partially unfolded at an angle displaying icons, the icons are the claims “internal elements” of a “view control”, the icon viewer seen below in Fig. 11A and B. La teaches that when the device is first unfolded at a lesser angle a fixed number of icons is shown, teaching obtaining a first quantity of internal elements. An analogous scenario is described in ¶204 which describes that a viewable area of the device can be increased as it is unfolded, in this case a magnetic cover is being unfolded rather than the device itself.) and determining a second quantity of internal elements of the view control on the second user interface and the first scaling size of each element based on the first quantity,(Maintaining the first scaling size of elements while increasing their quantity to fit the “second” larger view is seen below in Fig. 21 and described in La ¶208 ) a second size of the view control in the large-screen display mode, and a display effect of the view flipping control. (
PNG
media_image4.png
858
619
media_image4.png
Greyscale
La ¶167 “Referring to FIG. 11B, as an angle at which the foldable device 100 is unfolded is increased, if the angle at which the foldable device 100 is unfolded is greater than or equal to a certain angle, the controller 180 may activate the floating display area a2 and further display additional icons that correspond to the application on the floating display area a2.”
PNG
media_image5.png
1174
922
media_image5.png
Greyscale
¶208 “Additionally, as shown in a bottom portion of FIG. 21, as the foldable cover 300 is opened at maximum, the foldable device 100 may activate a whole area of the main display area b3 that includes the floating display area b2 of the flexible display unit 115” Note: The “second size” of the view control, referring to the larger unfolded size of the icon view, contains a “second quantity” of internal elements, the larger number icons displayed in the space a2 that is larger than the first view control a1. As seen in Fig. 21 the display area/control view that causes the number of displayed elements to increase with it maintains the scaling size for the elements, as icons in b2 to b3 remain the same as the space increases while allowing for more icons to be viewed.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with La where a flipping view control on a display in a large-screen display mode can increase the amount of UI elements displayed when the display area containing them increases as well.
There are several reasons that would motivate one to do so, many modern UI systems including the ones described here allow the size and location of UI elements like views and windows to be changed, the idea to automatically increase the amount of displayed content in a given view as it expands provides an easy way to guarantee available UI space is used.
Claims 7, 8, 9, are rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of Crow (US 6262724 B1).
Regarding claim 7,
Kilpatrick teaches:
The method of claim 1,
Kilpatrick does not however teach checking internal elements size against a threshold to determine how to handle scaling. This is taught in Crow which teaches wherein a second size of the first internal element is either not of a specified type or is less than or equal to a threshold, and wherein before determining the first scaling size, the method further comprises abandoning scaling on the first internal element. (Crow Col. 21 Line 61 “The video display window 202 may also have a minimum size, which in one embodiment is equal to 320x240. It will be appreciated that alternative embodiments may incorporate various other minimum or default sizes or may not incorporate a minimum size. In one embodiment, when the resize control 208 is dragged, two animated rectangles are displayed: one animated rectangle represents the Size of the display window 202 (any image displayed therein) and the other animated rectangle represents the size of the media player 200 window (which contains the window 202) … if the user attempts to shrink the media player 200 window below the default minimum size, only the display window 202 (and its animated rectangle) will shrink, and the size of the media player 200 window will remain unchanged from the minimum size.” Note: The claim states that an internal UI element, contained within another UI control, is less than a threshold then scaling the internal element is abandoned. In Crow the “internal element” is the media player 200 which shows a video or image, it is nested inside window 202 which acts as its UI control. The claims threshold is also taught, in this case a size of 320x240 is used with the option to change it. If the internal element is less than the threshold as taught by the claims, or in other words if the user attempts to make the video being played smaller than 320x240, then scaling is abandoned and rather than scaling the video down by making it smaller its size is preserved as taught by Crow.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Crow where a UI will abandon the scaling on an internal element if there is an attempt to size it below a threshold.
There are several reasons that would motivate one to do so, on a handheld device like the one described by the application and Kilpatrick if a UI component is too small it may be difficult or impossible for a user to interact with it via a touch screen, thus enforcing a threshold that we will not scale elements below ensures we will never have a UI element be inaccessible or unviewable because it is too small.
Regarding claim 8,
Kilpatrick teaches:
The method of claim 1,
Kilpatrick does not teach evaluating the size of an internal UI elements to determine if they should be scaled up. This is instead taught in Crow which teaches wherein a second size of the first internal element is less than or equal to a threshold,(Crow Col. 10 Line 40, cited below, defines a minimum scaling size as a threshold) and wherein the method further comprises: determining to scale up the first internal element; further determining, based on the threshold, the first scaling size; and scaling up, based on the first scaling size, the first internal element to a third size, wherein the third size is not less than the threshold. (Crow Col. 10 Line 40 “As such, the resize control 208 may be “dragged” by the cursor to resize the motion video display window 202 (and any image displayed thereby) without changing the size of the window 200 until the size of window 202 increases to a threshold size, which in one embodiment, corresponds to substantially the edges of the media player 200 or a window 202 of dimensions 320×240 pixels. When this occurs, an attempt to further enlarge the motion video display window 202 will enlarge the media player 200 window and the window 202 together. In other words, if the outer window rectangle is larger than the minimum (default size), the two rectangles grow and shrink proportionally together.” Note: Crow teaches that if an internal element, in this case the media player, is enlarged above the minimum threshold, seen here and previously in Col. 21 Line 61 to be 320x240 then the media player will properly grow with window 202 that it is contained in. The new size the internal element is scaled up to, which can be any size chosen by the user with the resize control via dragging, is the claims new “third size” that is greater than the threshold.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Crow where an internal element can be scaled up to be greater than a threshold, in which case it maintains its new scaled up size.
There are several reasons that would motivate one to do so, one is to provide the UI with more customization and functionality by allowing users to determine the size of UI elements they are interacting with.
Regarding claim 9,
Kilpatrick teaches:
The method of claim 1, wherein after determining the first scaling size, the method further comprises:
Kilpatrick does not teach abandoning scaling for an internal element based on a threshold size comparison, or changing the size of an element to exceed a threshold. This is instead taught in Crow which teaches abandoning scaling on the first internal element when the first scaling size is less than or equal to a threshold; (Crow Col. 21 Line 61, cited in claim 7, teaches abandoning scaling of an internal element when its size is below a threshold) and when the first scaling size is less than or equal to the threshold: adjusting, based on the threshold, the first scaling size to obtain an adjusted scaling size; and scaling up, based on the adjusted scaling size, the first internal element to a second size, wherein the second size is not less than the threshold. As the remainder of this claim is nearly identical to claim 8 without introducing any new content it is rejected using Crow Col. 10 Line 40 cited in claim 8. The only difference present is renaming the new scaled up size to an “adjusted scaling size” as opposed to claim 8’s directly analogous “third scaling size”.
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Crow where an internal element can have its size set to an adjusted scaling size, where the adjusted scaling size is greater than a minimum threshold and the new size is kept and updated to the internal element, and otherwise abandoning scaling on the element if it its size is set to below the threshold.
There are several reasons that would motivate one to do so, one is to provide the UI with more customization and functionality by allowing users to determine the size of UI elements they are interacting with. By enforcing a minimum scaling size threshold situations where a UI element is too small to reasonably interact with or view can be avoided.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of La (US 20160187994 A1).
Regarding claim 10
Kilpatrick teaches:
The method of claim 1,
Kilpatrick does not directly teach the changing of a quantity of internal UI elements based on whether they are in a “first”, smaller UI, or a “second” wide-screen larger UI. This is instead taught in La which teaches wherein the first scaling size is less than a second size of the first internal element on the first user interface, and wherein a first quantity of elements on the second user interface is greater than a second quantity of elements on the first user interface. (La Fig. 21
PNG
media_image5.png
1174
922
media_image5.png
Greyscale
Note: The claims state that a larger, second UI has more internal elements than the first, smaller UI. This is seen in Fig. 21 as the larger extended UI space of area b3 has more app icons, internal elements, than the smaller UI configuration of b2.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with La where a UI changing from a smaller state to a larger state includes altering the quantity of displayed UI elements.
There are several reasons that would motivate one to do so, one is to make efficient use of available UI space. If we are changing the UI to cover a larger area of space one could easily present more info to the user at once by increasing the quantity of UI elements shown.
Claims 11, 13, are rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of SoByte (Building Android interfaces for any screen size)
Regarding claim 11,
Kilpatrick teaches:
The method of claim 1, wherein determining that the first application is in the large-screen display mode comprises:
While Kilpatrick teaches a large-screen display mode for its device which is recognized via a trigger event it does not teach recognizing that a device is in a large-screen display mode based on UI window width. This is instead taught in SoByte which teaches obtaining a window width of the first application; and determining that the first application is in the large-screen display mode when the window width is greater than or equal to a threshold. (Sobyte “There are three window size categories, Smaller, Medium and Expanded, which are designed to balance simplicity and flexibility of layout to optimise your application for specific situations …Considering the layout from a device and configuration perspective, we have made each window size category representative of a number of typical device configurations (shown below), which will be a useful reference when you are considering designing layouts based on breakpoints. Where smaller represents the typical pattern of a phone in portrait mode, medium represents the size of most tablets and larger foldable devices, and expanded represents the display of a tablet or larger foldable device, or a desktop device in landscape mode.”
PNG
media_image6.png
800
1428
media_image6.png
Greyscale
Note: SoByte’s description of Android’s size classes teaches the claim language that checking window width against a threshold determines whether or not we are in large-screen display mode. As seen above, if the width of a window is below or over the specific 600 or 840 dp thresholds then it is classified into compact, medium, or expanded screen layout, analogous to the claims large-screen display.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with SoByte where determining if a device is in large-screen display mode is done by checking the width of a UI window.
There are several reasons that would motivate one to do so, rather than relying on sensors or other physical means which could increase device cost and complexity simply checking the software data on window width provides an easy means to determine display mode without needing further steps or components.
Regarding claim 13,
Kilpatrick teaches:
The method of claim 1, wherein before determining that the first application is in the large-screen display mode, the method further comprises:
Kilpatrick does not however teach determining whether an application is allowed to perform UI adjustments in a large-screen display mode and whether the application is in large-screen display mode. This is found in Sobyte which teaches determining whether the first application is allowed to perform a user interface adjustment in the large-screen display mode; and determining whether the first application is in the large-screen display mode when the first application is allowed to perform the user interface adjustment in the large-screen display mode. (Sobyte “There are three window size categories, Smaller, Medium and Expanded, which are designed to balance simplicity and flexibility of layout to optimise your application for specific situations …Considering the layout from a device and configuration perspective, we have made each window size category representative of a number of typical device configurations (shown below), which will be a useful reference when you are considering designing layouts based on breakpoints. Where smaller represents the typical pattern of a phone in portrait mode, medium represents the size of most tablets and larger foldable devices, and expanded represents the display of a tablet or larger foldable device, or a desktop device in landscape mode.”
PNG
media_image6.png
800
1428
media_image6.png
Greyscale
Note: The claim states that we can determine if the UI is in large-screen display mode simply by checking if the application has met its allowance condition which allows it to change the UI to large-screen display mode. That is to say that the app will always enter large-screen display mode if it meets its allowance condition, meaning when the condition is met the UI is automatically changed to large-screen mode. SoByte teaches this clearly, as applications will automatically switch their UI mode based on whether or not they meet an allowance condition, in this case the allowance is based on the width of 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 combine Kilpatrick with SoByte where determining if a device is in large-screen display mode is done by checking the if the software will allow it.
There are several reasons that would motivate one to do so, rather than relying on sensors or other physical means which could increase device cost and complexity simply checking the software allowance for the window provides an easy means to determine display mode without needing further steps or components.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of Zhang (US 20160191876 A1).
Regarding claim 12,
Kilpatrick teaches:
The method of claim 1, wherein the trigger event comprises: a terminal switching from a folded state to an unfolded state; (Kilpatrick ¶127 “The second panel 1804 is also substantially coplanar with the third panel 1806. As illustrated, the first sensor 1812 may detect that the first hinge is in a fully extended configuration position, and the second sensor 1822 may detect that the second hinge is in a fully extended configuration position. In addition, the internal sensor 1834 may detect that the second panel 1804 is in a substantially flat or horizontal position or alignment. Based on the sensors 1812, 1822, and 1834, the electronic device 1801 may recognize that it is in a fully extended position, and may configure Software or graphical user interfaces to display in a landscape configuration across one or more display surfaces of the adjacent panels” Note: Kilpatrck teaches that the device can sense when it is unfolded based on the hinge extensions and internal sensors which report the position of the device. If it is detected that the device is fully unfolded then UI changes are triggered to place the UI into landscape mode.) the terminal switching from a portrait mode to a landscape mode; (Kilpatrick ¶162 “. The processor 3830 is responsive to the inclinometer 3810 and the accelerometer 3820 to redraw an image displayed at the first display surface … The controller may hold the content in place as the device 3801 turns around the content. Because the display may change positions compared to an original position of the display, the controller may continually redraw the content until the acceleration stops. For example, this would enable a user of the device 3801 to lay the device 3801 on a desk and to spin the device 3801 clockwise or counterclockwise to switch the display from portrait to land-scape or any position in between.” Note: Kilpatrick teaches that the orientation and motion of the device is leveraged to switch the UI from portrait to landscape and vice versa.) an entire screen of the terminal is lighting up; (Kilpatrick ¶169 “The method 4200 illustrates a default state of an electronic device when no user interfaces for executing applications are displayed, such as after the device is powered on.”
PNG
media_image7.png
1269
966
media_image7.png
Greyscale
Note: Kilpatrick teaches that once a device is first powered on it is in state 4200, seen above in Fig. 42. The citation details that no application UI content is shown as the user has yet to select an app, however as seen in Fig. 42 there is still UI content displayed to the newly powered on screen/terminal as seen by the flow chart. Depending on the folding configuration it is determined how many screens/terminals the UI icon panel will be displayed to.) data of the first application updating when the first application is in the large-screen display mode; (Kilpatrick ¶186 “In a particular embodiment, the device may perform other operations based on detecting a configuration change. For example, as will be discussed with respect to FIG. 48, when a browser window is open and displays content from a particular website, the device may automatically request the website to resend content based on an available screen size or resolution increasing or decreasing due to a configuration change.” Note: Kilpatrick teaches the ability to change an application’s data based on the change in screen size ore resolution due to a configuration change, which includes operations like unfolding into large-screen display mode or folding up into a smaller screen.) a screen operation event of a user being detected when the first application is in the large-screen display mode; (Kilpatrick ¶103 “the processor 810 may be responsive to a user input indicating a double-tap at an application icon on the first display 802 and may launch an application and display an application window at one or more of the displays 802, 804, or 806 in response to the user input” Note: Kilpatrick teaches that the UI can be updated based on a screen operation event, in this case a user double-tapping an application, to display an application to one or more of the three displays, where the displaying to all 3 screens teaches the large-screen display mode.) or a multi-window display mode cancelling and the first application displaying in a full screen when the terminal is in a large-screen state, wherein at least two windows are displayed on the screen of the terminal in the multi-window display mode, and wherein one of the at least two windows displays the first application.(
PNG
media_image8.png
280
390
media_image8.png
Greyscale
Kilpatrick ¶146 “FIG. 28 depicts the electronic device 2701 of FIG. 27 in a thumbing configuration 2800. In the thumbing con figuration 2800, the bottom panel has a display surface displaying a larger keyboard area 2802 than the smaller key board area 2702 depicted in FIG. 27. A first display surface 2804 of a middle panel, and a second display surface 2806 of a top panel may form two separate display windows, or may be combined to form a 2-panel effective screen.” Kilpatrick ¶250 “As another example, when the device 5900 is in a fully extended configuration, the display controllers 5962, 5964, and 5966 may control the displays 5902, 5904, and 5906 to each display a respective portion of an image to operate as a single effective screen spanning all three displays 5902,5904, and 5906.” Note: The claims describe a scenario where a “multi-window display mode” has at least two windows displaying content with one displaying the application. In the scenario the “multi-window display mode” is cancelled and the window showing the application takes up the all the displays and enters large-screen mode. This is taught by Kilpatrick, as in ¶146 and Fig. 28 it is shown that a multi-window display mode is possible as one screen displays a keyboard UI and the other two screens can show two separate contents or the same content. Kilpatrick also teaches that the three display controllers for the three displays can display a single coherent view, teaching the ability for a multi-window display to be transitioned into a large-screen display.)
While Kilpatrick teaches a number of different events and combinations of them which trigger a UI update to its displays it does not teach that one of these triggers is projecting the devices content to a larger device screen. This is taught in Zhang which teaches a screen of the terminal projecting onto a large screen; (Zhang ¶03 “When using the projection function, the user can also connect one electronic device having the projection function to another electronic device that generally has a larger display screen, for example, a smart phone having the projection function can be connected to an LCD TV, so that a display interface of the smart phone is displayed via the LCD TV, as such, the user projects the display interface onto a larger display screen, which can get better visual viewing experience.” Note: Zhang teaches a trigger event which shifts the UI on a small mobile device to be displayed on a larger screen such as a TV)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Zhang where the folding, orientation change, and many other trigger events also includes projecting the display to a larger screen.
There are several reasons that would motivate one do to so, projecting or mirroring the display of a small device to a larger one is a common practice for sharing information and overcoming size limitations of a small device, Kilpatrick’s device could easily handle this scenario with its existing UI if its trigger events were extended to include a projection scenario.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of AbhiAndroid (Linear Layout Tutorial With Examples In Android).
Regarding claim 14,
Kilpatrick teaches:
The method of claim 1, and wherein the method further comprises: determining, in response to the first application being in the large-screen display mode, the first scaling size; determining, based on the first scaling size and a second size of the control in the large-screen display mode
While Kilpatrick teaches that UI elements and controls can be displayed in a large-screen display mode with proper scaling sizes it does not however teach the use of a linear layout control to format the UI in a linear manner. This is taught in AbhiAndroid which teaches wherein the first control comprises a linear layout control and,a linear layout of the first internal element. (AbhiAndroid “Linear layout is a simple layout used in android for layout designing. In the Linear layout all the elements are displayed in linear fashion means all the childs/elements of a linear layout are displayed according to its orientation. The value for orientation property can be either horizontal or vertical.”
PNG
media_image9.png
850
784
media_image9.png
Greyscale
Note: AbhiAndroid teaches that linear layout control can be used to easily format UI elements to produce a linear layout of them. As seen in the screen shot provided, the width and height of the element can be passed to LinearLayour in the layout_width and layout_height values. Additionally the sizes of internal elements can be altered with the weight variable, as seen in the image provided button 2 has a higher weight than 1 and is made large in the linear layout.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with AbhiAndroid where a device that displays and scales its UI controls and elements to its display mode includes a pop-up window with content as a possible UI control it can display.
There are several reasons that would motivate one to do so, one could gain the benefits of pop-up windows, a common staple of UIs for showing alerts and important info, in modern devices which change display orientation and size like Kilpatrick’s .
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of Chan (RecyclerView: Autofit grid)
Regarding claim 15,
Kilpatrick teaches:
The method of claim 1, wherein the first control comprises a recycler view control, and wherein the method further comprises: determining, in response to the first application being in the large-screen display mode, the first scaling size;
Kilpatrick teaches that its system is aware of its UI elements sizes, and that its device can be in large-screen mode. Kilpatrick does not however teach the use of Android’s recycler view control which allows for lists to be handled automatically. This is instead taught in Chan which teaches and determining, based on a scaling width of the first internal element and a width of the recycler view control in the large-screen display mode, a quantity of columns of internal elements and a spacing between the columns. (Chan “We extend RecyclerView to get access to its width. As for the width of each item, when GridView has android:numColumns=”auto_fit”, it uses android” columnWidth to compute the number of columns. In the constructor, we read the value of android:columnWidth and save it in a member variable. Later in onMeasure will use it to determine the span count … With that, the span count changes the width of the RecyclerView. One thing to note: we are using the column width to compute the span count, and once that is given to the RecyclerView it will turn around and compute the width of each item. So, for instance if your RecyclerView is 320dp wide and you use a column width of 72dp, a span count of 4 (320dp/72dp = 4.4444)”
PNG
media_image10.png
1104
634
media_image10.png
Greyscale
Note: Chan teaches that the width of the RecyclerView controller and the width of the internal elements, referred to by Chan as items, that make up the columns, and the size of the screen are all used to calculate the quantity of columns that can fit on the screen. As seen in the screen shots above, as the devices orientation is changed from portrait to landscape the column quantity is recalculated to increase, reflecting that the size of the RecyclerView controller has increased with the screen width allowing for more columns to be shown with the same element width. As seen in the image the elements are spaced equally apart, teaching that the space left over from our calculation determines how far apart each column item is spaced from eachother.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Chan where a column display of items in a UI system that adapts to a device changing orientation and display size will automatically change the item quantity of a column UI control as the available area of the UI changes.
There are several reasons that would motivate one to do so, previously it was shown how more UI space increase the quantity of internal elements displayed within it, allowing the UI to automatically make the best use of it space by showing more content when it can. These same benefits could be gained for more complex UI structures like in column structures of elements by determining the item quantity in columns based on item size and spacing.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of Chan (RecyclerView: Autofit grid) and further in view of Microsoft (How to Add List-View Columns)
Regarding claim 16,
Kilpatrick teaches:
The method of claim 1,
Kilpatrick does not however Microsoft teach the use of a list view controller. This is taught in Microsoft wherein the first control comprises a list view control, and wherein the method further comprises: (Microsoft “How to Add List-View Columns This topic demonstrates how to add columns to a list-view control. Columns are used to display the items and subitems when a list-view control is in report (details) view. Text from selected columns can also be displayed in tile view.” Note: Microsoft teaches the use of a list view control to create columns to display “internal elements”, simply referred to as items and sub items, within the UI column.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Microsoft where a first control comprises a list view control.
There are several reasons that would motivate one to do so, one benefit of a list view control in UI is It allows for lots of content to be formatted and ordered even if it does not fit directly on the screen, where actions like scrolling allow more of the list content to be seen. This is especially useful for the present invention, as if a display is extended in the direction of the list the new display area could be easily filled with the list content.
While Microsoft clearly teaches leveraging a list view controller, it does not teach determining column quantity based on the controller width and size of its internal elements. This is clearly taught by Chan which teaches determining, in response to the first application being in the large-screen display mode, the first scaling size; and determining, based on the first scaling size and a width of the control in the large-screen display mode, a quantity of columns of internal elements and a spacing between the columns. (Chan “We extend RecyclerView to get access to its width. As for the width of each item, when GridView has android:numColumns=”auto_fit”, it uses android”columnWidth to compute the number of columns. In the constructor, we read the value of android:columnWidth and save it in a member variable. Later in onMeasure will use it to determine the span count … With that, the span count changes the width of the RecyclerView. One thing to note: we are using the column width to compute the span count, and once that is given to the RecyclerView it will turn around and compute the width of each item. So for instance if your RecyclerView is 320dp wide and you use a column width of 72dp, a span count of 4 (320dp/72dp = 4.4444)”
PNG
media_image10.png
1104
634
media_image10.png
Greyscale
Note: Chan clearly teaches that the width of a control, in this case RecyclerView, and the size of internal elements is used to calculate the quantity of columns.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Chan where a UI that uses a list view control uses the width of its control and size of its internal elements to determine how many columns should be presented within the control.
There are several reasons that would motivate one to do so, both list view and recycler view are similar controls which allow one to easily show columns of UI elements, it would be obvious to optimize list views functionality to automatically determine column quantity similar to how recycler view can. This would allow one to efficiently use the controllers space without hard coding values, allowing the list view control to work well in any screen size or situation.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of AbhiAndroid (GridView Tutorial With Examples In Android) and further in view of Chan (RecyclerView: Autofit grid).
Regarding claim 17,
Kilpatrick teaches:
The method of claim 1,
Kilpatrick does not however teach the use of a grid view controller. This is instead taught by AbhiAndroid which teaches wherein the first control comprises a grid view control, and wherein the method further comprises: (“In android GridView is a view group that display items in two dimensional scrolling grid (rows and columns), the grid items are not necessarily predetermined but they are automatically inserted to the layout … numColumns property has to be specified otherwise GridView behaves like a ListView with just singleChoice. In the above image numColumns property specified that there is 3 columns to show, if we set it to auto_fit then it automatically display as many column as possible to fill the available space of the screen. Even if the phone is in portrait mode or landscape mode it automatically fill the whole space.” Note: AbhiAndroid teaches the use of GridView control to display UI info in columns. If the user sets the column number to auto_fit then the grid view control will fill as many as it can within the screen width, teaching that changing from portrait to landscape will automatically update the column quantity.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with AhbiAndroid where a first control comprises a grid view control.
There are several reasons that would motivate one to do so, Kilpatrick has already been shown to teach a list view control, a common type of UI formatting that allows a single column or row of items to be viewed. As the present application’s device can significantly expand its usable display area, rather than simply extending a single list’s content into a larger display area a user may wish to view a large grid view of new content to better take advantage of the display size change.
While AhbiAndroid teaches that the column quantity can be automatically determined based on the available space it does not directly state that the controller’s width itself is leveraged to determine the quantity of columns. determining, in response to the first application being in the large-screen display mode, the first scaling size; and determining, based on the first scaling size and a width of the control in the large-screen display mode, a quantity of columns of internal elements and a spacing between the column. The remainder of this claim is identical to claims 16, and 15, as the Chan citation provided in both clearly teaches leveraging width information of the control, internal elements, and screen to determine a quantity of columns.
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Chan where a UI that uses a grid view control uses the width of its control and size of its internal elements to determine how many columns should be presented within the control.
There are several reasons that would motivate one to do so, as RecyclerView and GridView are both existing UI controls present in android, grid view control space could be easily filled with the most amount of data by using the control width to find how many internal elements can fit inside.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of Peterson (The Fastest Way to Scroll Through Your iPhone's Home Screen Pages & Folders) and further in view of Chan (RecyclerView: Autofit grid)
Regarding claim 18,
Kilpatrick teaches:
The method of claim 1 comprises determining, in response to the first application being in the large-screen display mode, the first scaling size;
Kilpatrick does not however teach a “flipping control” which enables a user to flip between pages or screens of content displayed to the UI. This is instead taught by Peterson which teaches wherein the first control comprises a view flipping control, and wherein the method further comprises: and determining, based on a display effect of the view flipping control in the large-screen display mode, the layout. (Peterson
PNG
media_image3.png
808
896
media_image3.png
Greyscale
Note: As seen in the images and text description provided by the screen shot above, Peterson teaches that a UI can be flipped left and right. It can be seen that in response to the user’s swipe/flip interaction that the UI performs the claims “display effect of the view flipping control” as the UI page flips to the second view displaying new UI controls and elements, thus changing the layout of the UI.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Peterson where a control in large-screen display mode is a flipping control that has a display effect that a layout change will be based on.
There are several reasons that would motivate one to do so, while content could be displayed in a list view control without a display effect, UI updates that are too quick may appear jittery or too sensitive to inputs, and generally less pleasant for a user to interact with. These problems can be solved by basing the layout update and flipping control changes on the display effect.
While Peterson details a flipping control that allows the layout of the UI to be changed as new content is flipped to it does not detail changing the layout of the UI in response to things such as the quantity or size of UI elements. This is instead taught by Chan which teaches determining, based on a quantity of internal elements, the first scaling size, and a second size in the large-screen display mode, the layout. Chan “We extend RecyclerView to get access to its width. As for the width of each item, when GridView has android:numColumns=”auto_fit”, it uses android”columnWidth to compute the number of columns. In the constructor, we read the value of android:columnWidth and save it in a member variable. Later in onMeasure will use it to determine the span count … With that, the span count changes the width of the RecyclerView. One thing to note: we are using the column width to compute the span count, and once that is given to the RecyclerView it will turn around and compute the width of each item. So for instance if your RecyclerView is 320dp wide and you use a column width of 72dp, a span count of 4 (320dp/72dp = 4.4444)”
PNG
media_image10.png
1104
634
media_image10.png
Greyscale
Note: Chan clearly teaches that the width of a control, in this case RecyclerView, and the size of internal elements is used to calculate the quantity of columns. As seen in the image above, the column quantity determines how the multiple internal elements, or items, it has will be laid out. This shows that Chan teaches a quantity of internal elements and their sizes determines the layout of a UI.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Chan where a layout that is determined based on the display effect of a flipping control is also based on a quantity of internal elements and their sizes.
There are several reasons that would motivate one to do so, when new UI content is flipped to we may arrive on a new display area that has a different quantity of UI elements with different sizes that needs a new approach to handling their layout. By changing the layout in response to not only a flip operation but also the quantity of elements a new page could be easily flipped to and have its layout properly formatted with respect to size and amount of new content being displayed.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Kilpatrick (US 20100064244 A1) in view of Ben-Aharon (US 20160371312 A1) in view of Davis (US 20130106907 A1) in view of Holgado (A guide for Android ImageView)
Regarding claim 19,
Kilpatrick teaches:
The method of claim 1, and wherein the method further comprises: determining, in response to the first application being in the large-screen display mode, the first scaling size;
Kilpatrick does not however teach the use of an image view control which sets a control height for images to display and handles the layout of displaying an image. This is described in Holgado which teaches wherein the first control comprises an image view control, adjusting, based on a scaled internal element, a control height; and determining, based on the scaled internal element, the layout. (Holgado “Below is part of the code from our ImageView. We are trying to say that we want to resize our logos to always have an 18dp height and then use whatever width they need. We also had set scaleType to fitXY.
android:layout_width="wrap_content"android:layout_height="18dp"
… Fortunately there is a really simple way to preserve the aspect ratio of the image while keeping control of one dimension (in our case the height). When we set adjustViewBounds to true we are telling the ImageView (not the drawable) to adjust its bounds to preserve the aspect ratio of its drawable.” Note: Holgado teaches that we enforce a consistent height of 18dp in the image view control, teaching the claims control height. The internal elements, in this case logo images, are all taught to have an aspect ratio which is used to determine scaling up and down as to preserve the aspect ratio. As image view determines the image layout, and image view is taught to not just randomly size images up/down but with respect to their aspect ratio, this teaches that the layout is determined based on a scaled internal element.)
It would have been obvious to a person having ordinary skill in the art before the effective filing
date of the claimed invention to combine Kilpatrick with Holgado where an application in large-screen display mode formats its UI with an image view control that determines its layout based on a control height, scaled internal elements, and other relevant UI factors.
There are several reasons that would motivate one to do so, many UI functions require multiple images to be displayed at once like in an app icon view, photo or video thumbnail viewer, etc… Having a dedicated control of the UI that allows for consistent image views to be shown with a controlled height and layout provides an easy way to implement UI functionality.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN GREGORY HAKALA whose telephone number is (571)272-7863. The examiner can normally be reached 8:00am-5:00pm.
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, King Poon can be reached at (571) 270-0728. 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.
/ALAN GREGORY HAKALA/Examiner, Art Unit 2617
/KING Y POON/Supervisory Patent Examiner, Art Unit 2617
