DETAILED ACTION
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 .
This action is in response to response filed on 12/17/2025. This action is NON-FINAL.
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 16 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites, “generating design programming logic”, “generating… behavior programming logic” and “generating widget programming logic”. The limitations of “generating”, “generating” and “generating” as drafted are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The claim recites the following additional elements “serving a first browser application implementing a design interface”, “serving a second browser application implementing a collaborative whiteboard”, “accessing design workspace data” and “receiving, via the second browser application, second user input”. The additional elements of “serving” and “serving” are insignificant pre solution activities. The additional elements of “accessing” and “receiving”, do nothing more that add insignificant extra solution activity to the judicial exception of merely gathering data (MPEP 2106.05(g)). Further, the limitation “A network computer system” is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, MPEP 2106.05(f). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “A network computer system” amounts to no more than mere instructions, or generic computer/computer components to carry out the exception, for the limitations of “serving” and “serving” are identified as well-understood, routine, conventional activities (2106.05(d)) and for the limitations of “accessing” and “receiving” the courts have identified mere data gathering as well-understood, routine and conventional activities. See MPEP 2106.05(d) and MPEP 2106.05(f). The recitation of generic computer instruction and computer components to apply the judicial exception, and the well-understood, routine, conventional activities do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, claim 16 is not patent eligible under 35 USC 101.
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.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Gerkin et al. (US 20120137227) and further in view of Allington et al. (US 2021/0208775 A1), Hill et al. (“Awareness Support in a Groupware Widget Toolkit”, 2003) and Khosropour et al. (US 2014/01089936 A1).
As per claim 16 (New), Gerkin et al. teaches the invention as claimed including, “A network computer system comprising:
one or more processors; and
at least one memory storing instructions executable by the one or more processors for:
serving a first browser application implementing a design interface including storing a design object for the design interface, the first browser application being executable by one or more first browsers;”
Gerkin et al. teaches, A Widget Assembly Application (WAA) is employed to create or edit templates (design object) that may be later used for assembling widgets or generating them for use across multiple environments. The templates may be created by a programmer or administrator of the WAA. The WAA stores multiple templates (0027). Widget templates include, a topic reader for a blog feed, a chart that displays data, a map that renders data (0022). Also see 0030 and 0059. WAA may function in a web browser (0021-0022). Also see figures 4-5.
“serving a second browser application implementing a collaborative whiteboard, the second browser application being executable by one or more second browsers; and
responsive to receiving, via the second browser application, first user input identifying the design object:
accessing design workspace data describing the design object;
using the design workspace data, generating design programming logic usable to instantiate the design object in the collaborative whiteboard;
receiving, via the second browser application, second user input indicating at least one user interaction with the design object;
based on the at least one user interaction with the design object, generating behavior programming logic describing how the design object is modified and responds to the at least one user interaction; and
generating widget programming logic for creating a widget object in the collaborative whiteboard, the widget programming logic including the design programming logic and the behavior programming logic.”
Gerkin et al. teaches, users can select a template from a list (design object), customize it by interacting with real-time property editors, save the finished widget instance and deploy it to a specified location (0022). Widgets have functionality (0022). Also see 0027-0029. A user may select between various templates organized by categories. The categories indicate the functionality of a collection of widgets types, such as the type of content acceptable to the widget, such textual or numeric feeds, existing web contents such as a java applet or flash movie, or exiting widgets; the type of display used to render the content: such as charts, maps, scatter plots, photo gallery, etc. A user may select from the menu to first select a widget type, and may then select from various drop-down options for the widget type. Remote existing widgets may also be offered (0030). A user may then customize the template entry using the WAA. The user can adjust parameters (design elements) such as size of the widget, specific URL feeds that would be rendered within the widget (programming logic), specific fields defining how data in the feeds are to be rendered (programming logic), specific fields for placement withing the widget, and other changes as well (0031-0033). As the widget is created, the underlying parameters, representing the user’s selections, may be stored in conjunction with the underlying template selected by the user (0033). The data forms in embodiments may be used to populate the widget an for real-time updates once the widget is generated and instantiated on a platform (0034). The generator receives inputs from a widget type skeleton, template embedding files, instance metadata and generated artifacts. These files and data may be used by the generator in response to a request servlet request to generate a widget (widget programming logic). Upon gathering the needed files and data, the generator may generate a widget with content in the form requested (0039-0043). The WAA can be added into a mash-up canvas therefore allowing it to incorporate the widgets in to the mash-up canvas (0038).
Regarding the limitation “usable to instantiate the design object in the collaborative whiteboard”. The examiner states that this limitation is intended use and does not hold an patentable weight.
Gerkin et al. does not explicitly appear to teach, “second user input indicating at least one user interaction with the design object”.
Khosropour et al. teaches users customizing widget templates. This includes allowing a user to assign any command, combination of commands, menu shortcuts, programming scripts, multiple strings, or key sequences to a single widget’s UI object (e.g., buttons, icons, images, etc). A user can drag or drop buttons (design elements) into an existing widget (paragraphs 0175-0183).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Gerkin et al. with Khorropour et al. because both teach the customization of widget templates. Gerkin et al. teaches a user may then customize the template entry using the WAA. The user can adjust parameters (design elements) such as size of the widget, specific URL feeds that would be rendered within the widget (programming logic), specific fields defining how data in the feeds are to be rendered (programming logic), specific fields for placement withing the widget, and other changes as well (0031-0033). Khosropour et al. teaches user customizing widget templates. This includes allowing a user to assign any command, combination of commands, menu shortcuts, programming scripts, multiple strings, or key sequences to a sing widget’s UI object (e.g., buttons, icons, images, etc). A user can drag or drop buttons (design elements) into an existing widget (paragraphs 0175-0183). Therefore, it would have been obvious for the customizations of Khosopour et al. to be the other changes of Gerkin et al. This is nothing more than a design choice and would have been obvious to try.
However, Gerkin et al. and Khosropour et al. do not explicitly appear to teach, “serving a second browser application implementing a collaborative whiteboard, the second browser application being executable by one or more second browsers; and” and “generating widget programming logic for creating a widget object in the collaborative whiteboard”.
Allington et al. teaches a whiteboard application that enables users to place content on a canvas (0001). A digital whiteboard application is configured to present a user interface (UI) that includes a whiteboard canvas upon which heterogenous objects can be place in a free-form manner. The canvas can accept, text or shapes, sicky notes, images, documents, and other types of digital objects (0006). The canvas can also present dynamic templates that provide structure to the objects contained withing. A template can be placed within the canvas (0007). Also see 0034-0035 and 0046. The UI includes a toolbar that includes tools for selecting objects (0036). Also see 0059 and figure 6A. Users can add, edit or remove objects from the canvas (0037). A data source can store data for synchronizing the content of the canvas between multiple user computing devices. Data can be synchronized in real time (0038). A visual representation of the objects is generated (0051). Also see figure 2.
Hill et al. teaches a tool kit that allows easy integration with IDEs, and drag and drop creation of working group-aware interfaces (collaborative whiteboard) (abstract). All groupware systems must maintain a shared state in order to allow collaboration over a common set of data (3.1 Interface coupling). MAUI toolkit supports both single-state and multi-state version of most widgets; it provides run-time customization that can be controlled either by the user or the by the application program (3.2 Groupware-specific displays and widgets). Visual widgets can be added to groupware interface though an application builder that collects, distributes and visualizes group awareness information (4.1 MAUI interface components).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Gerkin et al. and Khosropour et al. with Allington et al. and Hill et al. Gerkin et al. teaches a widget assembly application (WAA) that allow a developer to create a widget template that can be later customized and instantiated/rendered on a platform. The WAA can be added into a mash-up canvas therefore allowing it to incorporate the widgets in to the mash-up canvas (0038). Allington et al. teaches a collaborative white board application that allows users to add objects from a toolbar to its canvas. This includes templates and any of the objects. Hill et al. teaches a widget tool kit that allows widgets to be generated for collaboration-aware interfaces. Therefore, it would have been obvious to one of ordinary skill in the art for the widget templates generated in Gerkin et al. to be widgets for collaboration-aware interfaces such as the collaborative white board application of Allington. This will allow the templates to be selected and configured on a canvas in order to instantiate/render the widget in the whiteboard and would have been obvious to try.
Allowable Subject Matter
Claims 1-14 are allowed.
Response to Arguments
Applicant's arguments filed 12/17/2025 have been fully considered but are moot due to amendments. Please see above rejections.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6: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, Lewis Bullock can be reached at 571-272-3759. 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.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199