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 the amendment/remarks filed on 01/20/2026. Claims 1-129 have been canceled. Claims 130-150 are new claims.
Claim Interpretation
Examiner’s interpretation of certain terminologies and phrases as recited in new claims 130-150 are provided below for convenience.
A logical hierarchical data space is a method of organizing information in a tree-like, parent-child structure where data is grouped in nested, logical levels, rather than a flat, unstructured format. It is a conceptual model that arranges entities—ranging from a root node down to various leaves—to reflect relationships, such as an organizational chart or a file system.
A “subdivision” is described in par. [0007]-
“In still another aspect, a computer readable device, which when loaded and executed by a processor, causes the processor to perform operations for executing a data operation including determining at least one subdivision of the at least one logical hierarchical data space. The at least one logical hierarchical data space may have a plurality of subdivisions. The operations may further include determining at least one file corresponding to the at least one subdivision of the at least one logical hierarchical data space. The operations may further include reading at least one tuple from the at least one file.” Based in this description, the “subdivision” is equated with a “node” in a tree or graph.
The meaning of “writing at least one first tuple to the first file” and “writing at least one second tuple to the at least one second file,” is derived from applicants disclosure, par. [0033], a description of Fig. 8C, “ FIG. 8C shows the results of merging the corresponding subdivisions of a first file and a second file into a third file organized using hierarchical data spaces according to various embodiments;”
“[0081] The at least one tuple may be stored in the at least one file corresponding to the subdivision of the at least one LHDS by appending the at least one tuple to the at least one file and by appending the location of the at least one tuple and at least one HPId to at least one second file. The location may include the length of the stored tuple. An advantage of this approach is also append-only writing of the tuples and hierarchical path identifiers. Tuples corresponding to the same subdivision may not be stored together within the at least one file. To perform an operation, all the associated hierarchical path identifiers can be scanned by accessing the at least one second file. The location stored with any matching hierarchical path identifiers can then be used to retrieve the corresponding tuple from the set of first files. Instead of operating on tuples by value, they can be operated upon first probabilistically as shown in step 112 using logical hierarchical data spaces. Since the HPId preserves the hierarchy of the subdivisions of the hierarchical data space, operations such as range, bounding, joins, and intersection query can be performed probabilistically.”
“[0159] FIG. 8C shows the results of merging the corresponding subdivisions of a first file and a second file into a third file organized using hierarchical data spaces. To perform this merge data operation, the physical hierarchical data spaces and their associated logical hierarchical data spaces were chosen. The subdivisions were determined by coordinated traversal of the hierarchical data spaces. The tuples were read from the subdivisions of each physical hierarchical data space, which also correspond to the subdivisions of the logical hierarchical data spaces. These subdivisions also correspond to the data blocks of a file. The tuples from each physical hierarchical data space were written into the new hierarchical data space.
As for the claim limitations, “creating …… a first or second file,” the “first and second files” were defined only in the claims that have been canceled in this amendment.
The invention generates a hierarchical data space by merging at least two files. The disclosure does not provide the details of how the files are read and written. The steps of reading and writing are defined only by the claims 1-129 that have been canceled. For the purpose of examination, the generation of a hierarchical data space implies that the flat/relational records/rows/files have been read and written when they were merged, and the hierarchical space was generated as a result of the merging.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 130-150 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claims 130-150 are directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claims 130-150 are directed to the abstract idea for executing a data operation. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Independent claims 130, 137 and 144
Step 1
Claim 130, 137 and 144 are directed to an apparatus, a method and a computer program product respectively and therefore claims 130-144 are directed to statutory classes.
Judicial exception/abstract ideas and/or additional elements found in the independent claim 130, 137 and 144 are highlighted and comments have been added within the parentheses for convenience.
130. (New) A system for executing a merge data operation, the system comprising: a memory (additional elements and generic computer components and/or tools) that stores instructions; and a processor (additional elements and generic computer components and/or tools) that executes the instructions to perform operations, the operations comprising:
creating a first file (mental step when a user can create a row for a table by utilizing a plurality of elements in an order);
writing at least one first tuple (mental step when a user can create a row for a table by utilizing a plurality of elements in an immutable order) to the first file; wherein the at least one first tuple is associated with at least one subdivision (mental step when a user divides a hierarchical path or the node of a tree/graph in multiple segments) for each of a plurality of different logical hierarchical data spaces;
creating at least one second file;
writing at least one second tuple to the at least one second file; wherein the at least one second tuple is associated with at least one subdivision for each of the plurality of different logical hierarchical data spaces (a hierarchical data structure and/or mathematical relation) ;
merging the first file with the at least one second file to create (mental step using computer as a generic tool/component when a user identifies a common element of two or more rows in one or more table and combine the rows) at least one third file comprising:
reading the at least one first tuple from the first file;
writing the at least one first tuple to the at least one third file; and
organizing (mental step when a user combines two or more rows of tables to derive a combined hierarchical record wherein there is at least one common element) the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces.
Step 2A Prong One: Claim 130 includes the steps of creating, writing and combining files wherein two files are combined to generate a third file, and then organizing the derived third file in a hierarchical structure. Claim 130 is therefore directed to one or more abstract ideas and/or judicial exceptions. Under its broadest reasonable interpretation, claim 130 covers performance of the limitation in the mind, but for the recitation of generic computer components. Other than the generic computer components are a memory, a processor, a computer readable device, nothing in the claims elements preclude the step from practically being performed in a human mind. Note that the limitations are done by the generically recited computer under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer, then it falls within the "Mental Processes" grouping of abstract ideas (concepts performed in the human mind including an observation, evaluation, judgment, and opinion).
Step 2A Prong Two:
The judicial exception is not integrated into a practical application. In particular, the claims recite the additional limitations: creating and combining/merging files; the limitation is mere data identification (see MPEP 2106.05(g)). Further, the additional limitation is recited as being performed by a memory, a processor, a computer readable device, provide nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words "apply it" (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception.
Examiner notes that claim 130 merges two files to derive a third file in the form of a hierarchical data structure. However, there are no claim limitations in the claim providing the specificity about the resulting hierarchical structure and indicating the improvement of computer environment and/or technology. For instance, Claim 130 does not reflect the benefits of converting two flat files into a hierarchical structure. Claim 130 merely recite a hierarchical structure that was derived, however, does not provide the details or specificity as to how the hierarchical structure in being used in conjunction with generic components recited in the claims to highlight the benefits that might have been disclosed in applicants’ disclosure.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; TLI Communications provides an example of a claim invoking computers and other machinery merely as a tool to perform an existing process. The court stated that the claims describe steps of recording, administration and archiving of digital images, and found them to be directed to the abstract idea of classifying and storing digital images in an organized manner. 823 F.3d at 612, 118 USPQ2d at 1747. The court then turned to the additional elements of performing these functions using a telephone unit and a server and noted that these elements were being used in their ordinary capacity (i.e., the telephone unit is used to make calls and operate as a digital camera including compressing images and transmitting those images, and the server simply receives data, extracts classification information from the received data, and stores the digital images based on the extracted information). 823 F.3d at 612-13, 118 USPQ2d at 1747-48. In other words, the claims invoked the telephone unit and server merely as tools to execute the abstract idea. Thus, the court found that the additional elements did not add significantly more to the abstract idea because they were simply applying the abstract idea on a telephone network without any recitation of details of how to carry out the abstract idea. For claim limitations that add insignificant extra-solution activity to the judicial exception (e.g., mere data gathering in conjunction with a law of nature or abstract idea), or that generally link the use of the judicial exception to a particular technological environment or field of use, examiners should explain why they do not meaningfully limit the claim. For example, adding a final step of storing data to a process that only recites computing the area of a two dimensional space (a mathematical relationship) does not add a meaningful limitation to the process of computing the area. As another example, employing well-known computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not integrate the exception into a practical application or add significantly more, similar to how limiting the computer implemented abstract idea in Flook to petrochemical and oil-refining industries was insufficient. See e.g., Parker v. Flook, 437 U.S. 584, 588-90, 198 USPQ 193, 197-98 (1978) (limiting use of mathematical formula to use in particular industries did not amount to an inventive concept). See MPEP § 2106.05(g) for more information about insignificant extra-solution activity, and MPEP § 2106.05(h) for more information about generally linking use of a judicial exception to a particular technological environment or field of use.
Step 2B:
The claims do not include additional element(s) that are sufficient to amount to significantly more than the judicial exception. The limitations: creating files is recognized by the courts as well understood, routine, and conventional activities when they are claimed in a merely generic manner (see MPEP 2106.05(d)(II)(iv) identification data, Versata Dev. Group Inc.). As explained with respect to Step 2A, Prong Two, the additional elements performing by a memory, a processor, a computer readable device, in limitation "searching..." is at best mere instructions to "apply" the abstract ideas, which cannot provide an inventive concept. See MPEP 2106.05(f). Generally linking the use of the judicial exception to a particular technological environment or field of use, e.g., a claim describing how the abstract idea of hedging could be used in the commodities and energy markets, as discussed in Bilski V. Kappos, 561 U.S. 593, 595, 95 USPQ2d 1001, 1010 (2010) or a claim limiting the use of a mathematical formula to the petrochemical and oil-refining fields, as discussed in Parker V. Flook, 437 U.S. 584, 588-90, 198 USPQ 193, 197-98 (1978) (MPEP § 2106.05(h)). Since, claims 109, 116 and 123 are directed to abstract ideas; thus, the claims are not patent eligible. Claims 110-115, 117-122 and 124-129 The limitations as recited in claims 110-115, 117-122 and 124-129 are simply describe the concepts for executing a data operation. The claims do not include additional element(s) that is sufficient to amount to significantly more than the judicial exceptions. The claims cannot provide an inventive concept. Therefore, claims 130-150 are directed to abstract ideas and are not patent eligible.
Claims 131-137 further limits the subject matter of claim 130 as highlighted below.
Claims 131. (New) The system of claim 130 wherein the merging the first file with the at least one second file to create at least one third file further comprises: reading the at least one second tuple from the at least one second file; and writing the at least one second tuple to the at least one third file.
Claim 132. (New) The system of claim 130 wherein the merging the first file with the at least one second file to create at least one third file further comprises: determining if the at least one first tuple and the at least one second tuple are associated with a common subdivision in each of the plurality of different logical data spaces; merging the at least one first tuple with the at least one second tuple into at least one merged tuple; and writing the at least one merged tuple to the at least one third file.
Claim 133. (New) The system of claim 130 wherein the merging the first file with the at least one second file to create at least one third file further comprises coordinated traversal of the first file and the at least one second file.
Claim 134. (New) The system of claim 130 wherein the organizing the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces further comprises organizing the at least one third file for depth-first traversal of the plurality of different logical hierarchical data spaces.
Claim 135. (New) The system of claim 130 wherein the organizing the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces further comprises organizing the at least one third file for pre-order traversal of the plurality of different logical hierarchical data spaces.
Claim 136. (New) The system of claim 130 wherein the organizing the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces further comprises organizing the at least one third file for post-order traversal of the plurality of different logical hierarchical data spaces.
Claims 131-136 further limit claim 130 by including (reading the at least one second tuple from the at least one second file) in claim 131, (associated with a common subdivision) in claim 132, (coordinated traversal) in claim 133, (depth-first traversal) in claim 134, (pre-order traversal) in claim 135 and (post-order traversal) in claim 136. None of these limitations provides the specificity discussed in the analysis of claim 130 and /or amount to additional elements that integrates the abstract ideas of claim 130 in a practical application and inventive concept.
Claims 131-136 are rejected under the same rationale applied to claim 130.
Claims 137-143, and 144-150 are essentially the same as claims 130-136 except that they are directed to a method and a computer program product and are rejected under the same rationale as applied to claims 130-163 above.
Claims 130-150 are therefore rejected under 35 USC 101 as being directed to a subject matter that is not patent eligible.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 130-132, 137-139 and 144-146 are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by US PG-PUB 20130198237 published 2013-08-01 issued to Serban, hereinafter “Serban.”
With respect claim 130, Serban teaches, a system for executing a merge data operation (Fig. 2 of Serban shows merging data from multiple tables with rows), the system comprising: a memory (Serban, Fig. 4, 402) that stores instructions; and a processor (404) that executes the instructions to perform operations, the operations comprising:
creating a first file (Serban, Fig 2, each of the elements 204a, b or c can be a “file” as recited in the claims. See also [0021]);
PNG
media_image1.png
676
598
media_image1.png
Greyscale
(Serban teaches, [0022] As used herein, the term "hierarchal data structure" is used to refer to a storage model where the data schema includes storing objects as nodes organized according to a hierarchy. A node can be a container for the data of an object in a hierarchical data structure. Each node can store attributes of an object as properties of the node. Properties have values, which represent the actual data stored in the hierarchical data structure. Nodes can be organized in a according to a hierarchy based on one or more parent/child relationships between nodes. Each parent node can have one more child nodes. Each child node can have a single parent node. Each node in a hierarchal data structure can have attributes that are different from other nodes of the tree structure. Each node can include a relationship to another node and properties of the node. Nodes of a hierarchical data structure can be accessed through paths. A path can be a description of a relationship between nodes, such as "Root/Parent/Child." Such paths can include absolute paths starting from a root node or relative paths to other nodes.)
writing at least one first tuple to the first file; wherein the at least one first tuple
(Serban, Fig 2 shows writing “model1” from tuple 204a to a file 210a. Additionally, Serban, in par. [0070] teaches, “…a JPA function call may be a query to retrieve instances of an object, such as "SELECT e FROM Employee e WHERE e.salary>:baseSalary." Examiner equates the “instance of an object” with the “tuple” recited in the claim. In a relational database, a tuple is a single row in a table that represents a unique record or data item...”) is associated with at least one subdivision for each of a plurality of different logical hierarchical data spaces;
creating at least one second file (Fig. 2, element 204b);
writing at least one second tuple to the at least one second file (Fig. 2, element 204b); wherein the at least one second tuple is associated with at least one subdivision (Fig. 2 shows writing the nodes 212, 208, 210a-c; each of these nodes are equated with the “subdivision” as claimed) wherein for each of the plurality of different logical hierarchical data spaces;
merging the first file with the at least one second file to create at least one third file comprising:
reading (Fig. 2, tuples 204a-c are read to derive the values in object 110) the at least one first tuple from the first file;
writing the at least one first tuple to the at least one third file (in Fig. 2, at least each of the elements 210a-c are equated with the third file as claimed);
see also ([0024], …the mapping application can transform a function call modifying the value of a column labeled "Manufacturer" for a row "Car1" in a table "Cars" into a function call modifying a property labeled "Manufacturer" of the node "Car1.");
See also, Serban, [0039] Accessing an object stored as one of the rows 204a-c of in the relational database 108 can include identifying the table 202a in which the object is stored and identifying that one or more of the columns 206a-c of the table 202a has a value corresponding to the object. For example, to access objects having a Manufacturer_Id of ManufacturerB, an application may provide a query to the relational database 108 identifying table 202a and selecting the rows from the table 202a where Manufacturer_Id=ManufacturerB.
[0041] The node 208 can be a child of node 212, labeled "Vehicles." Accessing an object in the hierarchical data structure 110 can include identifying a path to the node corresponding to the object. For example, to access objects having a Manufacturer_Id of ManufacturerB, an application would submit a query to the relational database 108 identifying the path from root node 212 to node 208 and selecting the child nodes of node 208 where Manufacturer_Id=ManufacturerB.
and
organizing the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces (Serban teaches, [0022] As used herein, the term "hierarchal data structure" is used to refer to a storage model where the data schema includes storing objects as nodes organized according to a hierarchy. A node can be a container for the data of an object in a hierarchical data structure. Each node can store attributes of an object as properties of the node. Properties have values, which represent the actual data stored in the hierarchical data structure. Nodes can be organized in a according to a hierarchy based on one or more parent/child relationships between nodes. Each parent node can have one more child nodes. Each child node can have a single parent node. Each node in a hierarchal data structure can have attributes that are different from other nodes of the tree structure. Each node can include a relationship to another node and properties of the node. Nodes of a hierarchical data structure can be accessed through paths. A path can be a description of a relationship between nodes, such as "Root/Parent/Child." Such paths can include absolute paths starting from a root node or relative paths to other nodes.)
Claims 131-137 further limits the subject matter of claim 130 as highlighted below.
Claims 131. (New) The system of claim 130 wherein the merging the first file with the at least one second file to create at least one third file further comprises: reading the at least one second tuple from the at least one second file; and writing the at least one second tuple to the at least one third file. Claim 131 is rejected under the same rationale as applied to claim 130 because writing a second tuple instead of a first tuple would be performed the same way without requiring a different configuration and/or mode.
Claim 132. (New) The system of claim 130 wherein the merging the first file with the at least one second file to create at least one third file further comprises: determining if the at least one first tuple and the at least one second tuple are associated with a common subdivision in each of the plurality of different logical data spaces; merging the at least one first tuple with the at least one second tuple into at least one merged tuple; and writing the at least one merged tuple to the at least one third file. Claim 131 is rejected under the same rationale as applied to claim 130 because Fig. 2 of Serban shows root, intermediate and leaf nodes, wherein the intermediate node includes common elements. See element 208 of Fig. 2.
Claims 137-139, and 144-146 are essentially the same as claims 130-132 except that they are directed to a method and a computer program product and are rejected under the same rationale as applied to claims 130-132 above.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 133-136, 140-143, and 147-150 are rejected under 35 U.S.C. 103 as being unpatentable over US PG-PUB 20130198237 published 2013-08-01 issued to Serban, further in view of US Patent No. 5530957 issued to Koenig.
Claims 131-136 further limit claim 130 by including (reading the at least one second tuple from the at least one second file) in claim 131, (associated with a common subdivision) in claim 132, (coordinated traversal) in claim 133, (depth-first traversal) in claim 134, (pre-order traversal) in claim 135 and (post-order traversal) in claim 136.
Claim 133. (New) The system of claim 130 wherein the merging the first file with the at least one second file to create at least one third file further comprises coordinated traversal of the first file and the at least one second file.
Claim 134. (New) The system of claim 130 wherein the organizing the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces further comprises organizing the at least one third file for depth-first traversal of the plurality of different logical hierarchical data spaces.
Claim 135. (New) The system of claim 130 wherein the organizing the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces further comprises organizing the at least one third file for pre-order traversal of the plurality of different logical hierarchical data spaces.
Claim 136. (New) The system of claim 130 wherein the organizing the at least one third file to preserve the hierarchy of each of the plurality of different logical hierarchical data spaces further comprises organizing the at least one third file for post-order traversal of the plurality of different logical hierarchical data spaces.
Claims 133-136, 140-143, and 147-150 are not directed to generating a hierarchical data structure but to how a tree or a hierarchical data structure can be traversed.
With respect to claims 133-136, 140-143, and 147-150 , Serban does not explicitly indicate how its hierarchical data structure of tree can be traversed, However, US Patent 5530957 issued to Koenig (see col. 1, line 59 through col. 2, line 6) teaches well-known pre-order and post-order traversal methods of a tree as a general knowledge.
“Operations which programs perform on trees include traversal, in which, beginning at the root, each node of the tree is visited in some order; locating the parent of a given node; locating a specific child of a given node; and moving to the next node to be visited in the course of a traversal. Two important types of traversals are preorder traversals and postorder traversals. In a preorder traversal of tree 101, the nodes are visited in the order 103, 105, 107, 109, 111. In a postorder traversal, the nodes are visited in the order 105, 109, 111, 107, 103. As for the other operations, the operation of locating the parent of node 111 would locate node 107; the operation of locating the second child of node 103 would locate node 107; and in the case of a preorder traversal, the operation of advancing to the next node performed on node 107 would locate node 109..”
It would have been obvious to a person of ordinary skill in the art before the filing date of this application to incorporate the general knowledge of tree traversal in Serban to improve the versatility of the system.
Claims 137-143, and 144-150 are essentially the same as claims 130-136 except that they are directed to a method and a computer program product and are rejected under the same rationale as applied to claims 130-163 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
With respect to claim 130, Weller (US PG-PUB 20160306869 A1 Date Published 2016-10-20 issued to Weller) teaches a business intelligence tool that processes relational data records for hierarchical visualization and more specifically teaches (see [0054])processing the tuples (see Fig. 8) to generate a hierarchical data space (see Fig 3). Weller identifies, “…(the) needed tuples and to build them the following a process such as that in diagram 800 of FIG. 8 can be used. If a hierarchical member (leaf or node) is reached, a recursive function can be used to iterate through the parent elements of this member to create tuples for all parent nodes respectfully finding the already existing (i.e. already created) parent tuple (for one dimension on the axis tuple elements are basically identical to the tuples). As a result all required tuple elements can be created and the corresponding tuples are created afterwards.” The iteration taught by Weller is equated with the “merging” of tuples/records/files as indicated in claim 130.
Weller teaches that “[0007] The subject matter described herein provides many technical advantages. For example, unlike conventional BI clients that do not support hierarchical workflows on the top of relation data, the current subject matter allows such workflows which, in turn, enables complex modelling for a variety of data sources. [0022] The current subject matter provides a way to use hierarchies in business intelligence (BI) tools on top of simple and flat relational data sources such as CSV-files. Hierarchies, “as used herein, refers to hierarchy workflows supported in most BI tools such as hierarchical value help and filtering, hierarchical result sets and hierarchical navigations within this result set (as will be described in more detail below). In particular, the current subject matter describes how to define such hierarchies, how to build the hierarchical structure, compute the values and perform interactions (filtering and navigations) on top of these hierarchies. [0049] With reference now to diagram 400 of FIG. 4, if the recursion advances from a first record (405) to a field (410) that has a hierarchy that is known to be the current value is a leaf of the hierarchy, the process checks what is the next level of this hierarchy (in the example “Product Subgroup”) (415-430). The cursor is then moved to the field related to the next level (435) and this value is parsed (440). Thereafter, it can be checked whether a node with this key is already available in the hierarchy (445). If not, then the cursor moves to the next higher level (here “Product Group”) until an already existing node is reached or the top level of the hierarchy is reached (450). Then all nodes are created (455-470) from top to bottom and connected and finally the leaf is created (475). Then, the cursor can move to the next records line (405). As a result in the end, a hierarchical tree is available starting from the root nodes down to all leaves. This hierarchical tree can be used to display a hierarchical value help
Applicant’s remarks on the new claims have been considered. The new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOSAIN T ALAM whose telephone number is (571)272-3978. The examiner can normally be reached Mon-Thu, 8:00 - 4:30.
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.
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.
/HOSAIN T ALAM/Supervisory Patent Examiner, Art Unit 2132
Prosecution Insights