Ex Parte Menninger

Patent Trial and Appeal Board

Feb 3, 2014

10959306 (P.T.A.B. Feb. 3, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
10/959,306 10/07/2004 Anthony F. Menninger 062834-0230 2057
22428 7590 02/03/2014
FOLEY AND LARDNER LLP
SUITE 500
3000 K STREET NW
WASHINGTON, DC 20007
EXAMINER
REFAI, RAMSEY
ART UNIT PAPER NUMBER
3687
MAIL DATE DELIVERY MODE
02/03/2014 PAPER
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE PATENT TRIAL AND APPEAL BOARD 4
___________ 5
6
Ex parte ANTHONY F. MENNINGER 7
___________ 8
9
Appeal 2011-011769 10
Application 10/959,306 11
Technology Center 3600 12
___________ 13
14
15
Before ANTON W. FETTING, MEREDITH C. PETRAVICK, and 16
PHILIP J. HOFFMANN, Administrative Patent Judges. 17
18
FETTING, Administrative Patent Judge. 19
20
21
DECISION ON APPEAL 22
Appeal 2011-011769
Application 10/959,306

2
STATEMENT OF THE CASE1 1

1 Our decision will make reference to the Appellant’s Appeal Brief (“App.
Br.,” filed February 3, 2011) and Reply Brief (“Reply Br.,” filed May 20,
2011), and the Examiner’s Answer (“Ans.,” mailed April 28, 2011).
Anthony F. Menninger (Appellant) seeks review under 35 U.S.C. § 134 2
of a final rejection of claims 10, 12-17, and 19-27, the only claims pending 3
in the application on appeal. We have jurisdiction over the appeal pursuant 4
to 35 U.S.C. § 6(b). 5
The Appellant invented a way of electronic reporting of point of sale 6
data at point of sale locations to a supply chain management system using 7
hierarchies (Specification para. [0001]). 8
An understanding of the invention can be derived from a reading of 9
exemplary claim 10, which is reproduced below [bracketed matter and some 10
paragraphing added]. 11
10. A computer implemented method 12
for creating a second hierarchy of nodes 13
interconnected within an already existing hierarchy of 14
nodes, 15
the existing hierarchy of nodes different from the second 16
hierarchy, 17
for a supply chain management electronic reporting 18
system 19
utilizing a network having one or more computers, 20
comprising: 21
[1] adding, 22
via the one or more computers, 23
at least one new node 24
to connect to the already existing hierarchy 25
without changing relationships between a plurality 26
of nodes in the existing hierarchy 27
to create the second hierarchy interlocked with the 28
existing hierarchy, 29
Appeal 2011-011769
Application 10/959,306

3
with the new node 1
disposed in the existing hierarchy 2
so that it has at least one of the same 3
children 4
as at least one node in the existing hierarchy, 5
but 6
is of a different type 7
compared to the at least one node in the 8
existing hierarchy, 9
wherein both the existing and second hierarchies include 10
a plurality of point of sale location nodes 11
representing point of sale locations; 12
[2] determining, 13
via the one or more computers, 14
an ID 15
for each of the existing hierarchy and the second 16
hierarchy; 17
and 18
[3] selecting, 19
via the one or more computers, 20
one of the hierarchy IDs; 21
and 22
[4] reporting electronically, 23
via the one or more computers, 24
point of sale data 25
from point of sale locations 26
in one of the existing and second hierarchies. 27
28
The Examiner relies upon the following prior art: 29
Statman US 2004/0088361 A1 May 6, 2004
Dvorak US 7,092,929 B1 Aug. 15, 2006
30
Claims 10, 12-17, and 19-27 stand rejected under 35 U.S.C. § 103(a) as 31
unpatentable over Statman and Dvorak. 32
Appeal 2011-011769
Application 10/959,306

4
ISSUES 1
The issues of obviousness turn primarily on whether Statman describes 2
that nodes of a different type and of different hierarchies may share a same 3
child node. 4
FACTS PERTINENT TO THE ISSUES 5
The following enumerated Findings of Fact (FF) are believed to be 6
supported by a preponderance of the evidence. 7
Facts Related to Claim Construction 8
01. The disclosure contains no lexicographic definition of “type.” 9
02. Neither independent claim 10 nor 24 recite which nodes 10
represent point of sale locations. 11
Facts Related to Appellant’s Disclosure 12
03. Although Specification para.[0028] recites “[i]n this application 13
one hierarchy is considered different from another hierarchy if the 14
nodes at a particular hierarchy level of the one hierarchy are of a 15
different type than the nodes at the particular hierarchy level of the 16
other hierarchy,” this is in the context of an exemplary software 17
application embodiment recited in the previous paragraph. 18
“Figure 2 illustrates an example of a data structure 200 for the 19
electronic reporting of point of sale (POS) data at a point of sale 20
location to a supply chain management system utilizing a network 21
according to an embodiment of the invention.” Spec. para. 22
[0027]. 23
24
Appeal 2011-011769
Application 10/959,306

5
Facts Related to the Prior Art 1
Statman 2
04. Statman is directed to distributing information and particularly 3
to distributing information to an appropriate service to process the 4
information. Statman para. [0001]. 5
05. Statman describes distributing information from a source to a 6
service to process the information is provided. In one 7
embodiment, the distribution system provides a node hierarchy 8
(also referred to as a distribution hierarchy) of distribution nodes 9
and service nodes. The node hierarchy has a root node, which is a 10
distribution node, which receives information that is to be 11
distributed to a service node. The root node passes the received 12
information to its child nodes, which may be either distribution 13
nodes or service nodes. Each child node may determine whether 14
or not to accept the information for further distribution or for 15
servicing. If a distribution node accepts the passed information, 16
then it passes the information to each of its child nodes. The 17
information is thus passed down the node hierarchy through 18
distribution nodes to service nodes that will accept and process the 19
information. Thus, the distribution nodes are non-leaf nodes of 20
the node hierarchy, and the service nodes are leaf nodes of the 21
node hierarchy. The distribution system allows various 22
distribution and service nodes to be implemented on the same or 23
different computer systems. Statman para. [0033]. 24
06. In one embodiment, the nodes of a node hierarchy are 25
instantiated in a bottom-up manner. Initially, all service nodes, 26
Appeal 2011-011769
Application 10/959,306

6
which are the leaf nodes, are instantiated. Each node knows the 1
node type of its parent node. When a node is instantiated, it 2
connects to its parent node. It connects by first retrieving a 3
reference to a node of its parent node type. If a node of the parent 4
node type has not been instantiated, then a node of the parent node 5
type is instantiated. A reference to that parent node is returned to 6
the child node. To complete the connection, the child node then 7
registers itself with its parent node so that the child node can be 8
passed information from the parent node. When the parent node is 9
instantiated, it connects to its parent node. It connects by 10
retrieving a reference to a node of its parent node type. If a node 11
of its parent node type has not been instantiated, then a node of its 12
parent node type is instantiated. A reference to that parent node is 13
then returned to the parent node. The parent node then registers 14
with its parent node to complete the connection. This process 15
continues until a root node is instantiated that has no parent node 16
type. The bottom-up instantiation of the node hierarchy results in 17
the instantiation of only those distribution nodes that are needed to 18
distribute information to the set of service nodes that are being 19
instantiated. Statman para. [0036]. 20
07. FIG. 1 is a block diagram illustrating a node hierarchy in one 21
embodiment. The node hierarchy 100 includes nodes 101-108. 22
Nodes 101, 102, 103, 105, and 108 are distribution nodes, and 23
nodes 104, 106, and 107 are service nodes. Distribution node 101 24
is a root node. In this embodiment, the node hierarchy is a tree 25
structure in that each node has only one parent node, except for 26
Appeal 2011-011769
Application 10/959,306

7
the root node, which has no parent node. One skilled in the art 1
will appreciate that a node hierarchy may not be a tree structure. 2
For example, a node may have multiple parent nodes, and a node 3
hierarchy may have more than one root node. The horizontal 4
ellipses of FIG. 1 indicate sibling nodes that are not illustrated, 5
and the vertical ellipses of FIG. 1 indicate child nodes that are not 6
illustrated. When information is to be distributed down through 7
the node hierarchy, the information is first passed to the root node 8
101. The root node may determine whether the information is 9
acceptable, and if acceptable, it passes the information to each of 10
its child nodes 102-104. Child nodes 102 and 103 determine 11
whether the passed information is acceptable and if acceptable, 12
pass the information along to their child nodes, such as child 13
nodes 105-106. Child node 104 is a service node that may 14
determine whether the information is acceptable and if acceptable, 15
effects performance of the service associated with that service 16
node. The service node may directly perform the service or direct 17
another computing entity (e.g., process, object, module) to 18
perform the service. Thus, the information propagates down the 19
node hierarchy through the distribution nodes that find the 20
information acceptable until it is received and processed by those 21
service nodes that find the information acceptable. Statman para. 22
[0037]. 23
08. The node hierarchy 100 may be created in a bottom-up manner. 24
In particular, each service node 104, 106, and 107 may be 25
instantiated initially. If service node 104 is instantiated first, it 26
Appeal 2011-011769
Application 10/959,306

8
requests that the root node 101 be instantiated and receives a 1
reference to the root node 101. In one embodiment, each node 2
type has an associated singleton with a function that is responsible 3
for instantiating an object for that node type if one is not already 4
instantiated and returning a reference to that object. Alternatively, 5
the function may be implemented as a static function of the node 6
type class, rather than as a singleton. The service node 104, using 7
the received reference, registers to receive information from the 8
root node 101. Each node has access to its parent node type, 9
which in the case of a root node is null. If service node 106 is 10
instantiated second, it requests that distribution node 103 be 11
instantiated, receives a reference to distribution node 103, and, 12
using the reference, registers to receive information from 13
distribution node 103. When distribution node 103 is instantiated, 14
it requests that its parent node, the root node 101, be instantiated. 15
Since the root node 101 is already instantiated, distribution node 16
103 is provided with a reference to the root node 101 so that it can 17
register with the root node 101. If service node 107 is instantiated 18
third, it requests that distribution node 105 be instantiated, 19
receives a reference to distribution node 105, and, using the 20
received reference, registers to receive information from 21
distribution node 105. Distribution node 105 then requests that 22
distribution node 103 be instantiated. Since distribution node 103 23
is already instantiated, distribution node 105 is provided with a 24
reference to distribution node 103 and uses the reference to 25
register with distribution node 103. This process continues until 26
Appeal 2011-011769
Application 10/959,306

9
all the service nodes have been instantiated and registered with 1
their parent distribution nodes. In addition, service nodes can 2
dynamically be instantiated as a service comes on line. In such a 3
case, the parent distribution nodes are also dynamically 4
instantiated as appropriate. When a service goes off line, the 5
corresponding service node notifies its parent node. The parent 6
node determines whether it has any more child nodes. If not, it 7
notifies its parent node (so that its parent node can determine 8
whether it has any more child nodes) and then destructs itself. 9
After the parent node has been notified and has destructed itself, 10
the service node destructs itself. Statman para. [0038]. 11
09. FIG. 4 is a block diagram illustrating nodes of the same node 12
type in different node hierarchies in one embodiment. In this 13
embodiment, each node hierarchy is allowed only one node of 14
each node type. Each node type has a shared component 401 with 15
a get node component 402 and shared mapping 403. The shared 16
mapping maps indexes to references to nodes of that node type, 17
such as nodes 404 and 405. The shared mapping has a mapping 18
for each instance of a node of that type in a node hierarchy. The 19
get node component is invoked by each child node during 20
instantiation of the child node and is passed an index of the node 21
hierarchy of the child node. The get node component checks the 22
mapping to determine whether a node of the node type with that 23
index has already been instantiated. If not, the get node 24
component instantiates a node of that node type for that index and 25
adds to the shared mapping an entry that maps the index to the 26
Appeal 2011-011769
Application 10/959,306

10
instantiated node. The get node component then returns a 1
reference to the parent node to the child node. The child node can 2
then use that reference to register with the parent node. Statman 3
para. [0046]. 4
10. Statman claim 20 recites: 5
A method in a computer system for creating a node 6
hierarchy, each node in the hierarchy having a node type, 7
the method comprising: for each of a plurality of node 8
types, creating a node of that node type when a node of 9
that type is not already instantiated, the created node 10
having a parent node type; under control of the created 11
node, creating a parent node of the parent node type for 12
the created node when a parent node of that parent type is 13
not already instantiated, the parent node optionally 14
having a parent node type wherein each parent node is 15
passed information and selectively passes the information 16
to its child nodes down through the node hierarchy. 17
18
11. Statman claim 24 recites: “The method of claim 20 wherein 19
multiple node hierarchies are created each with a different index.” 20
12. Statman claim 25 recites: “The method of claim 20 wherein 21
multiple node hierarchies are created and including receiving 22
information and passing it to a root node of a hierarchy.” 23
13. Statman claim 28 recites: “The method of claim 20 wherein 24
leaf nodes can be dynamically added to the node hierarchy.” 25
26
Appeal 2011-011769
Application 10/959,306

11
Dvorak 1
14. Dvorak is directed to item level and above planning where the 2
plans are dynamically updated using forecasts of item and location 3
sales and inventory needs throughout the supply chain 4
incorporating all the important decisions on how to present, 5
promote, and markdown each item, automatically adjusting 6
forecasts based on real selling results for the item and 7
incorporating the impacts of any known constraints on the sales or 8
inventory needs such as Purchase Orders (POs) not arriving in 9
time to keep the selling locations fully stocked for sale. Dvorak 10
2:6-20. 11
15. Weekly, weekly adjusted, daily or more frequent forecasts of 12
need and sales for basic and fashion goods can be generated as a 13
basis for rolling up item level forecasts into aggregate reports. 14
The system can automatically generate detailed reports identifying 15
items within departments or some other level of aggregation 16
which are overstocked. Automatic report generation can save the 17
user from sorting through unneeded pages or from going back and 18
requesting additional reports. Inventory budgets can be 19
automatically prorated from levels of a hierarchy at which they 20
are set down to items for overstocked identification. Dvorak 21
10:46-64. 22
16. While the causal event calendar stores information at a granular 23
level, the user interface can be constructed to simplify ease of 24
entry and maintenance. If hierarchies are developed for both the 25
selling locations (typically stores) and for goods, then user entry 26
Appeal 2011-011769
Application 10/959,306

12
can occur at these levels. For example, the user could select "all 1
stores" in the selling location hierarchy along with a single good 2
for the good hierarchy and enter the event information, and the 3
causal event calendar system would apply the event information to 4
all selling locations falling below "all stores" in the selling 5
location hierarchy (in this case, presumably all stores). Similarly, 6
if only one region was running the causal event then the user 7
might select the selling locations in "North West Region" and the 8
causal event calendar system would apply the event information to 9
all selling locations falling below "North West Region" in the 10
selling location hierarchy. Similarly, on the good dimension, if an 11
entire department will be in a promotional event, the user could 12
select "Watch department" in the good hierarchy and specify all of 13
the required selling location and event information; in this case, 14
the event information will be applied to all of the goods that fall 15
under "Watch department" in the product hierarchy. Of course, 16
the user may select nodes on both the good and selling location 17
hierarchy, in which case the event will be applied to all goods and 18
all selling locations falling under the specified nodes in the 19
hierarchy. This could be a single good in a single selling location 20
or groups of goods in groups of stores. Dvorak 51:28-55. 21
17. The causal event calendar table serves as the single repository 22
of causal event information feeding a range of retail systems or a 23
range of different activities within a system. Dvorak 51:56-60. 24
18. Top down planning provides plans at levels higher than 25
individual goods, but some differentiate historical discounting 26
Appeal 2011-011769
Application 10/959,306

13
where the point of sale (POS) data does not fully capture the 1
causal factors, particularly for the exogenous factors (e.g., selling 2
during Pre-Mothers’ day is usually not differentiated other than by 3
date in a POS whereas type of promotion can be). In these 4
instances it is helpful to have the causal calendar data available to 5
the Top-down Planning system or system activities. Dvorak 6
52:50-58. 7
ANALYSIS 8
We are not persuaded by the Appellant’s argument that 9
Statman, however, does not disclose the feature of claim 10 of 10
"with the new node disposed in the existing hierarchy so that it 11
has at least one of the same children as at least one node in the 12
existing hierarchy, but is of a different type compared to the at 13
least one node in the existing hierarchy," where the new node is 14
of the second hierarchy. Even if some of the distribution nodes 15
of Statman were to share children, Statman nowhere discloses 16
that nodes of a different type and of different hierarchies share 17
children. Even if Statman could be considered to disclose that 18
its distribution nodes may have a different type, nowhere does 19
Statman disclose that distribution nodes having a different type 20
and of different hierarchies share a same child node. Statman 21
discusses node type at least in paragraphs [0036], [0038], 22
[0043], [0045] and [0046]. Nowhere, however, does Statman 23
disclose that nodes of a different type and of different 24
hierarchies share a same child node. 25
App. Br. 10. 26
Statman describes a directed graphical model of a network that may be a 27
tree or mesh. FF 05. In such a tree or mesh, each single node is added by 28
creating paths from the new node to one or more existing nodes. 29
Where the tree or mesh is directed, as in Statman, the nodes on the other 30
side of the new paths leading into the new node are parents of the new node, 31
and the nodes on the other side of paths leading from the new node are 32
Appeal 2011-011769
Application 10/959,306

14
children of the new node. This is done in Statman in an exemplary 1
embodiment. FF 06-08. Such insertion does not alter any existing paths and 2
so does so “without changing relationships between a plurality of nodes in 3
the existing hierarchy.” 4
Because Statman allows for a directed mesh as well as tree structure, 5
Statman implicitly allows for a child node to have plural parents. Statman 6
explicitly refers to its tree or mesh as a set of hierarchies. FF 10. Thus, in 7
Statman, nodes of different hierarchies share a same child node. As to the 8
nodes being of different type, the attribute of “type” is undefined. 9
Therefore, it is sufficient that the new node be in some manner different, 10
even if only in the mind of the beholder, from some other node. Statman 11
explicitly shows a plurality of node types. FF 10. Therefore, when a new 12
node of a type different from the previous is instantiated, it is of a type 13
different from at least one other existing node. 14
We are not persuaded by the Appellant’s argument that Dvorak teaches 15
away from Statman. App. Br. 11. Appellant essentially contends Statman 16
could not be bodily incorporated in Dvorak because Statman describes 17
passing information downstream instead of upstream. 18
"The test for obviousness is not whether the features of a secondary 19
reference may be bodily incorporated into the structure of the primary 20
reference. . . Rather, the test is what the combined teachings of those 21
references would have suggested to those of ordinary skill in the art." In re 22
Keller, 642 F.2d 413, 425, (CCPA 1981). See also In re Sneed, 710 F.2d 23
1544, 1550, (Fed. Cir. 1983) ("[I]t is not necessary that the inventions of the 24
references be physically combinable to render obvious the invention under 25
review."); and In re Nievelt, 482 F.2d 965, (CCPA 1973) ("Combining the 26
Appeal 2011-011769
Application 10/959,306

15
teachings of references does not involve an ability to combine their specific 1
structures."). 2
The Examiner found that Dvorak described the portions of the claim 3
referring to point of sale data and locations and passing information both up 4
and downstream, and found that Statman described how a set of tree or mesh 5
hierarchies may provide a useful high level construct for implementing the 6
reporting of Dvorak’s information. The Examiner relies on Statman only for 7
the well-known topological properties of tree and mesh hierarchies as a 8
generic reference of such graph type implementations, and does not rely on 9
the specific use to which Statman puts its network. 10
CONCLUSIONS OF LAW 11
The rejection of claims 10, 12-17, and 19-27 under 35 U.S.C. § 103(a) as 12
unpatentable over Statman and Dvorak is proper. 13
DECISION 14
The rejection of claims 10, 12-17, and 19-27 is affirmed. 15
No time period for taking any subsequent action in connection with this 16
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 17
§ 1.136(a)(1)(iv) (2011). 18
19
AFFIRMED 20
21
22
23
24
Klh 25