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 .
Terminal Disclaimer
The terminal disclaimer filed on 12/05/2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of the full statutory term of prior patent number(s) 11,983,490 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Amendment
The Amendment filed on 12/05/2025 has been entered. Claims 1-20 remain pending in the application.
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-4, 7-14 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Krappe, US 10366156 B1, in view of Rothschiller et al. (hereinafter Rothschiller), US 20060004844 A1.
Regarding independent claim 1, Krappe teaches a system (Fig. 1, 102; Col 2, lines 51-56: FIG. 1 shows a deployment scenario 100 in accordance with one embodiment of the invention. The scenario 100 shows a template building system 102, which includes a builder application 104 that may be used to build a spreadsheet template 106 based on inputs by a human template builder 108) comprising:
a transaction management platform (Fig. 2, 208; Col 2, lines 64-66; Col 3, lines 1-2: the end user 204 uses template 104 executing on the device 202 to instantiate or create a spreadsheet 206. The spreadsheet 206 may be configured to connect with a remote or enterprise application 208, to facilitate an exchange of data with a database 210 associated with the remote application 208); and
a plug-in for a spreadsheet program (Fig. 6, 606; Col 4, lines 11-15: FIG. 6 shows the components of a spreadsheet template 600, in one embodiment. Referring to FIG. 6, the template 600 includes a repeating data range 602 and a save map 604. Record construction logic 606 performs operations to construct records based on potential record cells), wherein the plug-in comprises program code that, when executed by one or more processors, causes the one or more processors to perform operations (Col 5, lines 42-51: FIG. 12 shows exemplary hardware 1200, for the template building system and the user device. The hardware 1200 may include at least one processor 1202 coupled to a memory 1204. The processor 1202 may represent one or more processors (e.g., microprocessors), and the memory 1204 may represent random access memory (RAM) devices comprising a main storage of the hardware, as well as any supplemental levels of memory e.g., cache memories, non-volatile or back-up memories (e.g. programmable or flash memories), read-only memories, etc; Col 6, lines 14-31: In general, the routines executed to implement the embodiments of the invention, may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects of the invention) comprising:
creating a list of transactions within the transaction management platform, wherein each respective transaction in the list of transactions is associated with a respective workbook in the spreadsheet program (Col 3, lines 63-67 FIG. 5A shows a table 500 that defines the repeating data range for the spreadsheet 400, in one embodiment. The table 500 specifies that the data area 406 includes cells H11 to O11 corresponding to line items that are repeated below cell H11 based on line numbers; Col 4, lines 32-45 FIG. 8. The spreadsheet 800 was created based on the spreadsheet template 106, and is used to capture budget information from the end user 204. In use, the end user 204 enters values for a fiscal period and an organization unit, when promoted to do so. In the example of FIG. 8, the end user 204 has entered “FY13” for the fiscal period, and “Marketing/UK” for the organization unit. Based on these inputs, the spreadsheet 800 retrieves values for “fiscal periods”, and “accounts” associated with a budget for the “Marketing/UK” organization from the remote application 208. Thus, the end user 204 only has to enter values into the area 802. Initially all cells in the area 802 are potential record cells);
allowing a user of the spreadsheet program to select, via the first control, a transaction from the list of transactions for the transaction management platform (Col. 8, lines 26-33: the selective conversion of each identified potential record cell into the actual record cell comprises retrieval of data in plurality of cells in the spreadsheet based on a save map component associated with the spreadsheet and based on at least one user input corresponding to a selection from a list of predefined records associated with a plurality of predefined tables included in the remote application; Fig. 8; Col 4, lines 32-44: consider the spreadsheet 800 shown in FIG. 8. The spreadsheet 800 was created based on the spreadsheet template 106, and is used to capture budget information from the end user 204. In use, the end user 204 enters values for a fiscal period and an organization unit, when promoted to do so. In the example of FIG. 8, the end user 204 has entered “FY13” for the fiscal period, and “Marketing/UK” for the organization unit. Based on these inputs, the spreadsheet 800 retrieves values for “fiscal periods”, and “accounts” associated with a budget for the “Marketing/UK” organization from the remote application 208. Thus, the end user 204 only has to enter values into the area 802);
displaying data fields associated with the selected transaction within a mapping sheet of a workbook associated with the selected transaction (Fig. 5A; Col 3, lines 63-67: FIG. 5A shows a table 500 that defines the repeating data range for the spreadsheet 400, in one embodiment. The table 500 specifies that the data area 406 includes cells H11 to O11 corresponding to line items that are repeated below cell H11 based on line numbers; Fig. 5B; Col 4, lines 1-3: FIG. 5B shows a table 502 corresponding to a save map 502 for the spreadsheet 400. The table 502 indicates the save record attributes for each row within the data area 406; Col 3, lines 49-62: FIG. 4 shows an exemplary spreadsheet 400 generated based on the spreadsheet template 106. The spreadsheet 400 is for generating a quote. As will be seen, the spreadsheet 400 includes areas 402, 404, and 406. The area 402 is for a title. The area 404 displays non-line item information pertaining to the quote, and the area 406 displays line item information. Cells H11 to O11 form a repeating range. Said repeating range displays line item information. Cell H11 is a potential record cell. Moreover, each cell equivalent to the cell H11 in another repeating row within the line item data range (area 406) is also a potential record cell. The condition for a potential record cell to become an actual record cell may be that the quantity in the line item data range is greater than zero; Col 4, lines 59-66: Table 1000 shown in FIG. 10A shows the repeating data range for the spreadsheet 800, whereas table 1002 shown in FIG. 10B shows the mapping of ranges names to particular cells in the spreadsheet 800. Finally, table 1004 shows a save map for the spreadsheet 800. Using the values input into the cells of the area 802, the save map of table 1004, inserts records to or updates records in the budget header table (see table 904), and the budget line item table (see table 906); Fig. 10C; Col 3, lines 35-43: The save map component 306 provides the template builder 108 a capability to define record attributes for any cell determined to be an actual record cell during execution of a spreadsheet based on the spreadsheet template 106. In one embodiment, the record attributes may be based on other cells in the current spreadsheet, other spreadsheets, or other data sources. The record attributes for each record cell are saved in a save map, in one embodiment. FIG. 10C shows an exemplary save map 1004; Fig. 6; Col 4, lines 11-13: FIG. 6 shows the components of a spreadsheet template 600, in one embodiment. Referring to FIG. 6, the template 600 includes a repeating data range 602 and a save map 604).
Krappe does not explicitly disclose
creating, in the respective workbook, a respective mapping sheet for the respective transaction, wherein the respective mapping sheet is a respective first spreadsheet within the respective workbook;
creating, in the respective workbook, a respective second spreadsheet including a respective model for the respective transaction;
wherein the respective first spreadsheet, including the respective mapping sheet, and the respective second spreadsheet, including the respective model, are both displayable in the spreadsheet program;
displaying at least one of a custom ribbon or a custom panel within the spreadsheet program including a first control for selecting a transaction from the list of transactions for the transaction management platform;
allowing the user to map, within the mapping sheet of the workbook associated with the selected transaction rather than a separate application, the data fields associated with the selected transaction to corresponding cells of a second spreadsheet of the workbook associated with the selected transaction including a first model; and
updating the data fields associated with the selected transaction with data values from the corresponding cells of the second spreadsheet of the workbook associated with the selected transaction including the first model in response to a user command or a change in the data values of the corresponding cells or at predetermined intervals.
However, in the same field of endeavor, Rothschiller teaches
creating, in the respective workbook, a respective mapping sheet for the respective transaction, wherein the respective mapping sheet is a respective first spreadsheet within the respective workbook (Fig. 1, Maps Collection, Map1, Map2);
creating, in the respective workbook, a respective second spreadsheet including a respective model for the respective transaction (Fig. 1, Worksheet1, Worksheet2, Map Xpaths; [0037] Accordingly, the map is a collection of XPATH markers that define a relationship between the spreadsheet application grid and a particular elements defined in an XML schema file where the XPATH is a pointer back to the XML node in a valid XML data file. For example, if cell B1 has an XPATH marker that points to the <date> element in an associated XML data file, the relationship between cell B1 and the <date> element of the associated schema file is maintained when an XML data file containing the element <date> is imported to a spreadsheet document 150 via a spreadsheet application. For example, if the imported XML data file includes a <date> element with value "2003-01-02", and the map in the spreadsheet document specifies that cell B1 of the document 150 is related to the <date> element (by an XPATH referencing the <date> element), then cell B1 will contain "2003-01-02" once the import is finished);
wherein the respective first spreadsheet, including the respective mapping sheet, and the respective second spreadsheet, including the respective model, are both displayable in the spreadsheet program via respective tabs of the respective workbook (Fig. 3; [0038] a spreadsheet application grid (hereafter "grid") 310 is illustrated for entering, manipulating, and calculating data including text and numeric data. On the right hand side of the screen display 300, a tree view 320 of a generalized instance of an XML schema file is presented in a task pane 315. The tree view structure 320 includes a root element 325, and child elements 330 and 340 and a plurality of child elements 335 and 345 under the elements 330 and 340, respectively. The tree view 320, illustrated in FIG. 3, represents a generalized instance of an XML schema file attached to or associated with the spreadsheet document illustrated in the spreadsheet grid 310; [0025] each data map has its own tree view. When there are multiple maps in the workbook, multiple entries are shown in the workbook map management dialog box (FIG. 4), as well as, a dropdown control above the tree view to select which map tree view will be rendered in the tree view. Each map is rendered in the tree view one at a time, based on the map the user has selected in the dropdown (i.e. via a respective tab);
displaying at least one of a custom ribbon or a custom panel within the spreadsheet program including a first control for selecting a transaction from the list of transactions for the transaction management platform (Fig. 3; [0038] FIG. 3 illustrates a computer screen display of a typical spreadsheet application worksheet and an associated tree view pane showing a generalized instance of an XML schema file associated with the spreadsheet document. Further, FIG. 3 illustrates a mapping of XML elements or attributes of the XML schema file to a spreadsheet application workspace grid. According to the exemplary screen display 300 illustrated in FIG. 3, a spreadsheet application grid (hereafter "grid") 310 is illustrated for entering, manipulating, and calculating data including text and numeric data. On the right hand side of the screen display 300, a tree view 320 of a generalized instance of an XML schema file is presented in a task pane 315. The tree view structure 320 includes a root element 325, and child elements 330 and 340 and a plurality of child elements 335 and 345 under the elements 330 and 340, respectively. The tree view 320, illustrated in FIG. 3, represents a generalized instance of an XML schema file attached to or associated with the spreadsheet document illustrated in the spreadsheet grid 310. Cells 355, 360, and 365 illustrate single non-repeating elements dragged to the grid 310 from the tree view structure 320. The list objects 370 illustrate repeating elements, <description>, <amount> and <date>, dragged from the tree view structure 320 to the grid 310. As illustrated in FIG. 3, data associated with those elements is also illustrated);
allowing the user to map, within the mapping sheet of the workbook associated with the selected transaction rather than a separate application, the data fields associated with the selected transaction to corresponding cells of a second spreadsheet of the workbook associated with the selected transaction including a first model ([0049] At step 560, the spreadsheet application instantiates the tree view 320, and at step 570, the tree view 320 is populated into the tree view pane 315 for presentation to the user. As should be understood, the tree view 320 populated into the pane 315 at step 570 is a tree view structure representative of the generalized instance structure comprised of all of the schema files collected by the XML module 120 at steps 517-524. After the tree view has been populated, as described, at step 575, the user may now drag and drop elements and attributes from the tree view 320 onto the worksheet grid of the workbook 150); and
updating the data fields associated with the selected transaction with data values from the corresponding cells of the second spreadsheet of the workbook associated with the selected transaction including the first model in response to a user command or a change in the data values of the corresponding cells or at predetermined intervals ([0036] In order to import an XML data file to a spreadsheet document and in order to export an XML data file from a spreadsheet document, the spreadsheet application "remembers" the relationships between cells and list objects fields in the spreadsheet application grid and corresponding elements or attributes of an associated XML schema file defining the structure/blueprint of XML data documents corresponding to that schema file. In order to remember the relationship between the cells and/or list objects fields and elements or attributes of the associated XML schema file, cells and/or list objects fields are mapped to associated elements or attributes in the schema file; [0037] Accordingly, the map is a collection of XPATH markers that define a relationship between the spreadsheet application grid and a particular elements defined in an XML schema file where the XPATH is a pointer back to the XML node in a valid XML data file. For example, if cell B1 has an XPATH marker that points to the <date> element in an associated XML data file, the relationship between cell B1 and the <date> element of the associated schema file is maintained when an XML data file containing the element <date> is imported to a spreadsheet document 150 via a spreadsheet application. For example, if the imported XML data file includes a <date> element with value "2003-01-02", and the map in the spreadsheet document specifies that cell B1 of the document 150 is related to the <date> element (by an XPATH referencing the <date> element), then cell B1 will contain "2003-01-02" once the import is finished).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of a spreadsheet document containing elements and attributes defined for and used by or associated with one or more schema files associated with the document as suggested in Rothschiller into Krappe’s system because both of these systems are addressing the use of structured data formats to allow users to annotate a software application document to give the document a useful structure apart from the normal functionality of the software application responsible for creating the document or apart from the visible formatting associated with the document. This modification would have been motivated by the desire to allow the user to have control over how the data is laid out in the mapping file to map to the spreadsheet workbook (Rothschiller, [0005], [0045]).
Regarding dependent claim 2, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 1 that is incorporated. Krappe further teaches wherein displaying the data fields comprises displaying the mapping sheet in response to selecting a tab corresponding to the mapping sheet in the workbook (Fig. 5B; Col 4, lines 1-3: FIG. 5B shows a table 502 corresponding to a save map 502 for the spreadsheet 400. The table 502 indicates the save record attributes for each row within the data area 406; Fig. 10C; Col 3, lines 35-43: The save map component 306 provides the template builder 108 a capability to define record attributes for any cell determined to be an actual record cell during execution of a spreadsheet based on the spreadsheet template 106. In one embodiment, the record attributes may be based on other cells in the current spreadsheet, other spreadsheets, or other data sources. The record attributes for each record cell are saved in a save map, in one embodiment. FIG. 10C shows an exemplary save map 1004).
Regarding dependent claim 3, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 2 that is incorporated. Krappe further teaches wherein the mapping sheet comprises a first column including names of the data fields and a second column including references to the corresponding cells within the second spreadsheet including the first model (Fig. 5B illustrates column “Field” including the names of data fields, e.g. “Line_Number”, “Opportunity_id”, “Product_id”, “Qty” and “Price” and column “Cell” including refences to the corresponding cells).
Regarding dependent claim 4, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 1 that is incorporated. Rothschiller further teaches wherein the at least one of the custom ribbon or the custom panel within the spreadsheet program includes a second control for publishing data from the spreadsheet program to the transaction management platform ([0022] Referring now to FIG. 1, a simplified block diagram illustrating the management of a plurality of extensible markup language (XML) data maps and schema files available to a given spreadsheet application workbook is described. XML schema files 100 are identified for application to a given spreadsheet application workbook 150. As described in detail below, these identified XML schema files may be selected individually by a user via a user interface or the schema files may be selected indirectly by opening a workbook document that is already associated one or more schema files or XML data mappings. Schema files may also be provided by a schema inference engine that infers a schema from a given set of XML data not associated with a particular schema file or that is associated with a defective schema file. Any schema files selected by the user or associated with a workbook or XML data document opened by the user are parsed by a schema file parser 110 to find any additional schema files that are pointed to or associated with selected schema files), and wherein the operations include updating, in response to activation of the second control, the data fields associated with the selected transaction with the data values from the corresponding cells of the second spreadsheet of the workbook associated with the selected transaction including the first model ([0033] As is understood by those skilled in the art, developers of XML schemas determine the names of XML elements and the associated data types and data structures allowed for those elements. Then, all users of documents annotated with XML structure according to a given schema may utilize the data contained within the XML structure without regard to the overall type and structure of the document. For example, if a "purchase order" document, described above, is transmitted to a purchaser of the goods, the purchaser may develop software applications for parsing the document to locate specific types of data within the document for use by the purchaser. The purchaser may, for example only wish to print serial numbers and associated prices for certain goods. Using the schema attached to the document, the purchaser will know that the data associated with the XML elements have been prepared according to the schema governing the document. Accordingly, the purchaser may develop a software application or an Extensible Stylesheet Language Transformation (XSLT) file for locating the <price> element and for extracting the data associated therewith for insertion into the purchaser's own documents; [0034] Following with this example, a number of different purchasers may subscribe to the same schema for dictating the rules associated with the "purchase order" document so that each purchaser may then receive the "purchase order" document from the author of the document and use the data contained in the purchase order according to the XML elements structuring the data. That is, a first purchaser may only be interested in the data contained within the <price> element, while a second purchaser may be interested in extracting only the data contained in a <shipmentterms> element).
Regarding dependent claim 7, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 1 that is incorporated.
Rothschiller further teaches wherein updating comprises:
within the spreadsheet program:
serializing the workbook; and pushing the serialized workbook from the spreadsheet program to the transaction management platform ([0036] In order to import an XML data file to a spreadsheet document and in order to export an XML data file from a spreadsheet document, the spreadsheet application "remembers" the relationships between cells and list objects fields in the spreadsheet application grid and corresponding elements or attributes of an associated XML schema file defining the structure/blueprint of XML data documents corresponding to that schema file. In order to remember the relationship between the cells and/or list objects fields and elements or attributes of the associated XML schema file, cells and/or list objects fields are mapped to associated elements or attributes in the schema file.); and
within the transaction management platform: deserializing the serialized workbook ([0037] Accordingly, the map is a collection of XPATH markers that define a relationship between the spreadsheet application grid and a particular elements defined in an XML schema file where the XPATH is a pointer back to the XML node in a valid XML data file. For example, if cell B1 has an XPATH marker that points to the <date> element in an associated XML data file, the relationship between cell B1 and the <date> element of the associated schema file is maintained when an XML data file containing the element <date> is imported to a spreadsheet document 150 via a spreadsheet application).
Krappe further teaches reading the mapping sheet from the workbook; and saving values of cells of the second spreadsheet of the workbook containing the model to corresponding fields of the transaction management platform according to the mapping sheet (Col 5, lines 1-25 (34) By way of summary, the template builder 108 may perform the following steps to create a template that can be using to dynamically assemble data into records for the remote application 208: (a) Using the repeating data range capability, identify which cells comprise a range whose behavior will repeat as like data (same attributes, possibly different values) is retrieved from an outside source or as spreadsheet rows are copied/pasted elsewhere in the spreadsheet. In the example of FIG. 4, H11:O11 would be marked as a repeating range. It is to be noted that this step is optional in some embodiments (b) Using the Record Cell Tagging Component: 1. Mark cell H11 as being a Potential Record Cell. This also means that as new repeating rows are created or retrieved based on 1 above, that they would inherit the Potential Cell tag as well (including 2 below) 2. Create a condition that if K11>0, it should become an Actual Record Cell (c) Using Save Map Component: Define the attributes that would need to be assembled into a record for an actual record cell. This step is optional as in some embodiments no condition is associated with a Potential Record Cell. In the latter case all Potential Record Cells are converted into Actual Record Cells).
Regarding dependent claim 8, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 1 that is incorporated. Rothschiller further teaches the operations further comprising: updating one or more cells of the workbook with data values from corresponding data fields of the selected transaction ([0036] In order to import an XML data file to a spreadsheet document and in order to export an XML data file from a spreadsheet document, the spreadsheet application "remembers" the relationships between cells and list objects fields in the spreadsheet application grid and corresponding elements or attributes of an associated XML schema file defining the structure/blueprint of XML data documents corresponding to that schema file. In order to remember the relationship between the cells and/or list objects fields and elements or attributes of the associated XML schema file, cells and/or list objects fields are mapped to associated elements or attributes in the schema file. In order to map a cell or list object field with an associated element or attribute of the XML schema file, markers known as XPATHs are stored in the spreadsheet document to point a given cell or list object field to a corresponding element or attribute in an associated XML data file; [0037] Accordingly, the map is a collection of XPATH markers that define a relationship between the spreadsheet application grid and a particular elements defined in an XML schema file where the XPATH is a pointer back to the XML node in a valid XML data file. For example, if cell B1 has an XPATH marker that points to the <date> element in an associated XML data file, the relationship between cell B1 and the <date> element of the associated schema file is maintained when an XML data file containing the element <date> is imported to a spreadsheet document 150 via a spreadsheet application. For example, if the imported XML data file includes a <date> element with value "2003-01-02", and the map in the spreadsheet document specifies that cell B1 of the document 150 is related to the <date> element (by an XPATH referencing the <date> element), then cell B1 will contain "2003-01-02" once the import is finished).
Regarding dependent claim 9, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 1 that is incorporated. The combination of Krappe and Rothschiller does not explicitly disclose wherein the first model is an underwriting model for the selected transaction.
However, Krappe teaches
wherein the first model is an underwriting model for the budget transaction (Fig. 8; Col 4, lines 32-34: The spreadsheet 800 was created based on the spreadsheet template 106, and is used to capture budget information from the end user 204).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have utilized the concept of constructing a save map to dynamically transfer data from a spreadsheet to a remote application. One would have been motivated to facilitate an exchange of data between the spreadsheet application and a remote application for a real estate organization.
Regarding dependent claim 10, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 1 that is incorporated. The combination of Krappe and Rothschiller does not explicitly disclose wherein:
the transaction comprises a real estate transaction; and
the transaction management platform provides document management and workflow management features.
However, Krappe teaches
the transaction comprises a budget transaction (Fig. 8; Col 4, lines 36-39: the end user 204 enters values for a fiscal period and an organization unit, when promoted to do so. In the example of FIG. 8, the end user 204 has entered “FY13” for the fiscal period, and “Marketing/UK” for the organization unit),
the transaction management platform provides document management and workflow management features (Fig. 8; Col 4, lines 40-43: Based on these inputs, the spreadsheet 800 retrieves values for “fiscal periods”, and “accounts” associated with a budget for the “Marketing/UK” organization from the remote application 208)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have utilized the concept of constructing a save map to dynamically transfer data from a spreadsheet to a remote application. One would have been motivated to facilitate an exchange of data between the spreadsheet application and a remote application for a real estate organization.
Regarding independent claim 11, it is a medium claim that corresponding to the system of claim 1. Therefore, it is rejected for the same reason as claim 1 above.
Regarding dependent claim 12, it is a medium claim that corresponding to the system of claim 2. Therefore, it is rejected for the same reason as claim 2 above.
Regarding dependent claim 13, it is a medium claim that corresponding to the system of claim 3. Therefore, it is rejected for the same reason as claim 3 above.
Regarding dependent claim 14, it is a medium claim that corresponding to the system of claim 4. Therefore, it is rejected for the same reason as claim 4 above.
Regarding dependent claim 17, it is a medium claim that corresponding to the system of claim 7. Therefore, it is rejected for the same reason as claim 7 above.
Regarding dependent claim 18, it is a medium claim that corresponding to the system of claim 8. Therefore, it is rejected for the same reason as claim 8 above.
Regarding dependent claim 19, it is a medium claim that corresponding to the system of claim 9. Therefore, it is rejected for the same reason as claim 9 above.
Regarding independent claim 20, it is a method claim that corresponding to the system of claim 1. Therefore, it is rejected for the same reason as claim 1 above.
Claims 5-6 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Krappe, in view of Rothschiller as applied in claims 1 and 11, further in view of ROMATIER et al (hereafter ROMATIER), US 20100262900 A1.
Regarding dependent claim 5, the combination of Krappe and Rothschiller teaches all the limitations as set forth in the rejection of claim 1 that is incorporated. The combination of Krappe and Rothschiller does not explicitly disclose the operations further comprising: saving metadata of the selected transaction in a hidden sheet of the workbook.
However, in the same field of endeavor, ROMATIER teaches the operations further comprising: saving metadata of the selected transaction in a hidden sheet of the workbook ([0061] FIG. 4 is an illustration of a sample eSim user interface 400 in accordance with an embodiment of the inventive arrangements disclosed herein. Sample eSim user interface 400 can be utilized by systems 100, 200, and/or method 300; [0062] The sample eSim user interface 400 can be presented within a spreadsheet application window 405 of the spreadsheet application utilized by the eSim interface. The spreadsheet application window 405 can be a template for a spreadsheet workbook customized for integration with the process simulation system. A worksheet name can be customized as desired and additional worksheets can be inserted by a user as needed. In one embodiment, color coding can be established so that color-filled cells appearing on the main sheet are reserved. That is, a user may only be able to modify cells of the worksheet without a previously established background color. In one embodiment, a hidden worksheet (e.g., an application control template) can exist which stores eSim options. This hidden worksheet is intended to be preserved and remain hidden).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of providing a hidden worksheet to store eSim options as suggested in ROMATIER into Krappe and Rothschiller’s system because both of these systems are addressing the integration tool that can map application objects and properties to spreadsheet application objects, can convey information between mapped objects, can perform case management functions, and can perform orchestrated calculation functions. This modification would have been motivated by the desire to enable users to access the functionality of a process system utilizing tools and/or interfaces with which they are inherently familiar, such as utilizing user interfaces of conventional spreadsheet applications (ROMATIER, [0003]).
Regarding dependent claim 6, the combination of Krappe, Rothschiller and ROMATIER teaches all the limitations as set forth in the rejection of claim 5 that is incorporated. ROMATIER further teaches wherein the metadata includes a transaction identifier and an indication of a last time and date that the transaction management platform has been updated with data from the workbook ([0067] The simulation data items 430 can represent a variety of fields that present and/or accept data regarding the execution of the simulation by the process simulation system. Examples of simulation data items 430 shown in the sample eSim user interface 400 can include, but are not limited to, the name of the flowsheet corresponding to the process being simulated, the quantity of cases to run the simulation, a description of the simulation, the use of an optimizer during simulation and the name of the optimizer, and the like; [0068] The case data areas 435 can represent sections of the worksheet 420 that collectively identify all data associated with the simulation of a single case. For example, all data associated with the simulation of case 1 will be located in column B of the worksheet 420, case 2 in column C, and so on. This format of case data areas 435 within the worksheet 420 can allow a user to easily compare data values side-by-side for multiple simulations).
Regarding dependent claim 15, it is a medium claim that corresponding to the system of claim 5. Therefore, it is rejected for the same reason as claim 5 above.
Regarding dependent claim 16, it is a medium claim that corresponding to the system of claim 6. Therefore, it is rejected for the same reason as claim 6 above.
Response to Arguments
Applicant's arguments filed 12/05/2025 have been fully considered. Each of applicant’s remarks is set forth, followed by examiner’s response.
(1) Applicant alleges Rothschiller does not teach or suggest "creating, in the respective workbook, a respective mapping sheet for the respective transaction, wherein the respective mapping sheet is a respective first spreadsheet within the respective workbook," or "wherein the respective first spreadsheet, including the respective mapping sheet, and the respective second spreadsheet, including the respective model, are both displayable in the spreadsheet program via respective tabs of the respective workbook." First, an XML schema file is not a "spreadsheet," much less a "mapping sheet" that maps “the data fields associated with the selected transaction to corresponding cells of a second spreadsheet of the workbook associated with the selected transaction including a first model," as claimed. Second, even if an XML schema was a spreadsheet (which it is not), Rothschiller's XML schema files are edited via a workbook map management dialog box 400, shown below in FIG. 4 of Rothschiller.
As to point (1), Examiner respectfully disagrees. Rothschiller illustrates in Fig. 1, the mapping sheets, Map 1 and Map 2, are created in a Workbook where an overall data map collection comprised of all available data maps and schema files for use in subsequent application to the spreadsheet application workbook is created. A generalized instance of what all possible XML data instance files might look like according to the collection of schemas is defined. In effect, the GI is the "model" around which all data instances associated with any schemas making up the collection of schemas are built. All XML data files valid for unified schema definition for the collection of schemas will look somewhat like this generalized instance structure. Once a generalized instance structure is constructed that defines the structure of an instance document that is structurally valid to a specific "root" element definition within the specified XML schema or XML schema associated to the selected workbook, a tree view representation of the generalized instance structure may be provided for applying XML data represented by the generalized instance structure to the spreadsheet workbook including individual cells, cell ranges, individual or multiple worksheets contained in the workbook. Each data map has its own tree view. When there are multiple maps in the workbook, multiple entries are shown in the workbook map management dialog box (FIG. 4), as well as, a dropdown control above the tree view to select which map tree view will be rendered in the tree view. Each map is rendered in the tree view one at a time, based on the map the user has selected in the dropdown ([0022]; [0024]-[0025]). FIG. 3 illustrates a computer screen display of a typical spreadsheet application worksheet and an associated tree view pane showing a generalized instance of an XML schema file associated with the spreadsheet document ([0038]). Thus, Rothschiller is considered to teach “creating, in the respective workbook, a respective mapping sheet for the respective transaction, wherein the respective mapping sheet is a respective first spreadsheet within the respective workbook”; “creating, in the respective workbook, a respective second spreadsheet including a respective model for the respective transaction”; “wherein the respective first spreadsheet, including the respective mapping sheet, and the respective second spreadsheet, including the respective model, are both displayable in the spreadsheet program via respective tabs of the respective workbook” as recited in claims 1, 11 and 20. Thus, the combination of Krappe and Rothschiller is considered to teach claims 1, 11 and 20, and consequently, claims 2-10 and 12-19 are rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
Dykema (US 11514229 B2) discloses novel data structures and techniques provided to permit the use of advanced version control, collaboration techniques and team workflows.
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331, 1332-33, 216 U.S.P.Q. 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 U.S.P.Q. 275, 277 (C.C.P.A. 1968)).
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 AMY P HOANG whose telephone number is (469)295-9134. The examiner can normally be reached M-TH 8:30-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, JENNIFER WELCH can be reached at 571-272-7212. 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.
/AMY P HOANG/Examiner, Art Unit 2143
/JENNIFER N WELCH/Supervisory Patent Examiner, Art Unit 2143