Just like a million or more of others, who have done the same, I have personally, singlehandedly used the same exact principles and techniques to construct in a dynamic manner, not only visual representations of parent/child relationships as visual trees, but created entire systems that relied on these concepts for both, reporting and control.
I am absolutely capable of displaying my work, results of my work, people using result of my work, my work used in production on daily basis. I built a retail management system back in 2009-2013 and it is in use today as well, where data was described as master product (a representation of what a product is), an actual product instance (sku), incoming product orders and incoming product order items, etc.etc.etc.etc.etc. it is large and complex enough to spend many hours to go over it.
In any case, to be able to see data from all sorts of different perspectives, to analyze it, to understand what must be ordered, what sells, what doesn't, to filter data, to report, to control it for purposes of ordering, changing prices, creating lists of discounts, everything that a retail chain needs to do to be able to survive in a retail chain market.
A master product can be labeled with a record called 'label'. A label can be typified, because we may want to create *dynamic* representations and views. So for example labels can be of type 'supplier' or of type 'brand' or of type 'subbrand', etc.
A filtering system was created that allowed *LEVELS* of filters to be arranged, creating *DYNAMIC* ordering of *NODES* within *TREES* of labels and then master products or product instances (sku) could be selected from the database in a way that corresponded to the tree representation of the labels.
So a tree of labels became a template, with levels of the nodes being grouped by label types and then the products were arranged based on this template and all of a sudden you could use this grouping to understand the flow of products and the flow of money, purchases (incoming orders), sales (receipts), numbers of receipts and of individual products bought or returned or lost or whatever.
On the webpage or in an excel file this data was represented in either table format (very very similar to the figures and pictures attached in this story) or in an actual *TREE* format, where one could drill down as deep as needed.
I kid you not, I would be perfectly happy to participate in any lawsuit against any patent office or a company to prevent any such patent from being issued. ANY FUCKING PROGRAMMER would figure this out if they are mildly awake or even slight less than creative, it is absolute nonsense that we even have to entertain a possibility that this stuff can be patented, this is bullshit. Search trees, sort trees, visual trees, whatever trees, they are obvious simple data constructs and must be left alone without assholes trying to make money on suing people for stuff that is as obvious as the air we all breath (together with these assholes, unfortunately).
Before 2009-2013 I had a variety of projects, where trees were used as well, I built silly things like XML file editors, fucking XML to describe logic that was then converted by a piece of code I built to generate java code from that XML. The XML was a fucking tree, I built an editor so that an insurance company rep could fill in the data within XML nodes to describe logic (don't ask me why, this was 2001-2002 or something).
Before that I had to work with data sets from AT&T that were loaded from mainframes in order to create normal parseable file sets that were sent to rebiller companies, with the records that were at some point represented as tree nodes in levels. That was 1997 I think. Fuck. Before that I wrote tools for myself to study languages, English and French, long ago, where sentences and words in different languages were structured as tree nodes, with multiple crossing tree structures corresponding to different grammar rules.
Fucking hell.