UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`HEWLETT-PACKARD COMPANY,
`Petitioner
`
`v.
`
`
`
`YYZ, LLC,
`Patent Owner
`
`
`
`
`
`CBM No. Unassigned
`
`DECLARATION OF STEPHEN CRAGGS
`IN SUPPORT OF PETITION FOR
`COVERED BUSINESS METHOD REVIEW
`
`
`
`U.S. PATENT NO. 7,603,674
`
`
`
`
`
`
`
`HP_1032_0001
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`HEWLETT-PACKARD COMPANY,
`Petitioner
`
`v.
`
`
`
`YYZ, LLC,
`Patent Owner
`
`
`
`
`
`CBM No. Unassigned
`
`DECLARATION OF STEPHEN CRAGGS
`IN SUPPORT OF PETITION FOR
`COVERED BUSINESS METHOD REVIEW
`
`
`
`U.S. PATENT NO. 7,603,674
`
`
`
`
`
`
`
`HP_1032_0001
`
`
`
`
`
`I, Stephen Craggs, do hereby declare that:
`
`1.
`
`I have been retained by counsel for Petitioner to provide assistance
`
`regarding U.S. Patent No. 7,603,674 (“the ’674 patent” or “the patent”).
`
`Professional Background
`
`2.
`
`I have over thirty-five years of experience in software product design,
`
`development, management and thought leadership in business computing systems
`
`including transaction processing, integration middleware, monitoring, process
`
`automation, event processing, service oriented architecture and enterprise
`
`application integration.
`
`3.
`
`I am currently Research Director at Lustratus, a market analysis and
`
`advisory firm specializing in all forms of computing middleware and infrastructure
`
`software. I regularly publish papers and articles on all aspects of integration,
`
`middleware and infrastructure software and appliances.
`
`4.
`
`I graduated from Oxford University in Mathematics with Honours in
`
`1977 before joining the IBM development laboratory in Hursley, England that same
`
`year. I worked at IBM until late 1996. During my time at IBM, I held a variety of
`
`roles in CICS development and Transaction Systems before taking up the
`
`opportunity to lead a new business line for IBM called MQSeries (now called
`
`WebSphereMQ). From approximately 1993 to 1996 I held the title of MQSeries
`
`Manager. In this role I had worldwide responsibility for MQSeries strategy, design,
`
`-1-
`
`HP_1032_0002
`
`
`
`
`
`development, branding, marketing and sales enablement. Having successfully
`
`established MQSeries in the marketplace as the leading example of the new software
`
`market category of ‘Messaging Middleware,’ resulting in my being referred to as
`
`‘the Father of Messaging’ by the global press, I left IBM at the end of 1996 to join
`
`Candle Corporation, a global monitoring and management software vendor based in
`
`California.
`
`5.
`
`From 1997 to 2000, I was Vice-President, Application Solutions at
`
`Candle, responsible for building and delivering a suite of monitoring and
`
`middleware products and creating a messaging-based business for Candle spanning
`
`products and consultancy services. These included Candle Command Centre for
`
`MQSeries and MQSeries Integrator, a monitoring product for monitoring and
`
`managing asynchronous IBM MQ messaging and the IBM broker, and the
`
`CandleNet eBusiness Platform powered by Roma which was a messaging-based
`
`process and application integration solution including system and application
`
`monitoring. Roma was acknowledged by Gartner Group as the first Enterprise
`
`Service Bus in the world, offering integration broking in a new bus architecture
`
`form.
`
`6. While working for Lustratus (originally known as Saint) I have
`
`received global acknowledgement as a thought leader in integration middleware. I
`
`co-founded the ESB (Enterprise Service Bus) messaging market segment, publishing
`
`-2-
`
`HP_1032_0003
`
`
`
`
`
`the inaugural paper on ESBs in 2002, and was regarded as a leading worldwide
`
`authority on the Service-Oriented-Architecture (SOA) and integration middleware
`
`markets. My many papers on areas such as Messaging Middleware, Business
`
`Process Management, Decision Management and mBrokers have received much
`
`acclaim and are still regularly downloaded from the Lustratus site.
`
`7.
`
`In the late 1990s I served as IBM’s representative to the Message-
`
`Oriented Middleware Association, and in 2000 I was appointed Vice-Chairman of
`
`the Integration Consortium, a not-for-profit industry consortium of vendors and
`
`users of business integration solutions. Since 2002 I have been a member of the
`
`GLG Council, providing advice on the global integration and middleware industry to
`
`investment firms worldwide. I regularly serve as an independent judge on industry
`
`awards panels such as the CityCompass Financial Industry Benchmarking panel,
`
`Financial-i’s supply chain awards and most recently the IBM Beacon Awards.
`
`8.
`
`I have received numerous IBM awards for my work on CICS and
`
`MQSeries, and since founding Lustratus I have been involved in key business
`
`integration projects and products with companies such as IBM, Staffware, SAP,
`
`SoftwareAG, webMethods, TIBCO, Axway, Progress Software and many others. I
`
`have written many papers on the integration industry, and in 2013 I co-authored
`
`“Operational Decision Management for Dummies” published by Wiley.
`
`-3-
`
`HP_1032_0004
`
`
`
`
`
`Assignment & Materials Considered
`
`9.
`
`Counsel for Petitioner requested that I provide analysis pertinent to the
`
`’674 patent.
`
`10.
`
` For time spent in connection with this case, I am being compensated at
`
`my customary rate. My compensation is not dependent upon the outcome of this
`
`petition or any issues involved in or related to the ’674 patent, and I have no other
`
`financial stake in this matter.
`
`11. The patent-related materials I considered include: the ’674 patent
`
`(Exhibit 1001); the original prosecution history for the ’674 patent (Exhibit 1002);
`
`and the reexamination file history for the ’674 patent (Exhibit 1003).
`
`12. The MQSeries Integrator prior art related materials that I considered
`
`include: MQSeries Primer, IBM MQSeries EAI Center, October 1999 (“MQSeries
`
`Primer”) (Exhibit 1017); Using the IBM MQSeries Integrator Version 1.0, IBM
`
`International Technical Support Organization, SG24-5386-00, May 1999
`
`(“MQSeries Integrator 1.0 Reference”) (Exhibit 1018); MQSeries Integrator - Using
`
`the Control Center – Version 2 Release 0, First Edition, March 2000, GC34-5602
`
`(“MQSeries Control Center”) (Exhibit 1022); MQSeries Integrator – Introduction
`
`and Planning – Version 2 Release 0, First Edition, April 2000, GC34-5599-00
`
`(“MQSeries Planning”) (Exhibit 1023); MQSeries Integrator – Programming Guide
`
`– Version 2 Release 0, First Edition, April 2000, SC34-5603-00 (“MQSeries
`
`-4-
`
`HP_1032_0005
`
`
`
`
`
`Programming”) (Exhibit 1024); MQSeries Integrator – Messages – Version 2, First
`
`Edition, April 2000, SC34-5601-00 (“MQSeries Messages”) (Exhibit 1025);
`
`MQSeries for Windows NT – Quick Beginnings – Version 5.1, March 1999, GC34-
`
`5389-00 (“MQSeries Quick Beginnings”) (Exhibit 1026) and Business Integration
`
`Solutions with MQSeries Integrator, IBM Redbooks, SG24-6154-00, August 2000
`
`(“IBM Redbook”) (Exhibit 1027) (collectively, “MQSeries Integrator Materials”).
`
`13. Based on my nearly twenty years of experience working at IBM,
`
`including four years as MQSeries Manager, I am knowledgeable about IBM’s
`
`practices for preparing and publishing MQSeries product documentation. Generally,
`
`IBM prepared and made publicly available various manuals and other
`
`documentation covering MQSeries. Each document typically included within the
`
`initial pages a date on which the document was approved for release to the public,
`
`along with an indication of the edition. IBM typically made documents available to
`
`interested members of the public on or about this date. In my experience, IBM
`
`never released a software product without also making its documentation available
`
`to the public. Based on my knowledge of IBM’s practices related to MQSeries
`
`documentation, the MQSeries Integrator 2.0 manuals—Exhibit 1022 (bearing a date
`
`of March 2000), Exhibit 1023 (bearing a date of April 2000), Exhibit 1024 (bearing
`
`a date of April 2000), and Exhibit 1025 (bearing a date of April 2000)—would have
`
`been either publicly distributed in printed or digital format (i.e., on disc) with the
`
`-5-
`
`HP_1032_0006
`
`
`
`
`
`MQSeries Integrator 2.0 product and/or made publically available for download
`
`online in digital format on or about the indicated date, but in any event prior to
`
`December 2000. Based on my knowledge of IBM’s practices related to MQSeries
`
`documentation, the MQSeries 5.1 manual—Exhibit 1026 (bearing a date of March
`
`1999) —would have been either publicly distributed in printed or digital format (i.e.,
`
`on disc) with the MQSeries Integrator 2.0 product (MQSeries 5.1 was a prerequisite
`
`and came with MQSeries Integrator 2.0) and/or made publicly available for
`
`download online in digital format on or about the indicated date, but in any event
`
`prior to December 2000. Based on my knowledge of IBM’s practices related to
`
`MQSeries documentation—Exhibit 1018 (bearing a date of March 1999), Exhibit
`
`1017 (bearing a date of October 1999), and Exhibit 1027 (bearing a date of August
`
`2000)—would have been publicly distributed in printed and/or digital format on or
`
`about the indicated date, but in any event prior to December 2000.
`
`14. The other prior art materials I considered include: D. Linthicum,
`
`Enterprise Application Integration, Addison-Wesley Longman, Copyright 2000
`
`(“Linthicum”) (Exhibit 1020); Y. Hoffner, Monitoring in Distributed Systems,
`
`ANSA Architecture Report, October 25, 1994 (“Hoffner”) (Exhibit 1021); M43 –
`
`Introduction to Business Integration & Message Brokers, IBM MQSeries Technical
`
`Conference, June 2000 (“IBM Presentation M43”) (Exhibit 1028); and M56 –
`
`MQSeries Workflow Technical Overview, IBM MQSeries Technical Conference,
`
`-6-
`
`HP_1032_0007
`
`
`
`
`
`June 2000 (“IBM Presentation M56”) (Exhibit 1029).
`
`15.
`
`In addition, in the context of my work on this matter, I have drawn on
`
`my experience and knowledge, as discussed above and described more fully in my
`
`CV, in the areas of middleware technology and event processing.
`
`Person of Ordinary Skill
`
`16.
`
`I understand that the factors considered in determining the ordinary
`
`level of skill in the art include the level of education and experience of persons
`
`working in the field, the types of problems encountered in the field, and the
`
`sophistication of the technology.
`
`17. Based on these factors, in my opinion, a person of ordinary skill in the
`
`art relating to the technology of the ’674 patent at the time at which the parent patent
`
`was originally filed would have been a person with a bachelor’s degree or equivalent
`
`in Computer Engineering or Computer Science and approximately two years of
`
`experience in designing, developing, and/or implementing enterprise software.
`
`MQSeries Integrator
`
`18.
`
`I reviewed a number of documents that describe the features and
`
`functionality of the MQSeries Integrator software product. Specifically, I reviewed
`
`the MQSeries Integrator Materials. Based on my review of these documents, and
`
`my own knowledge, I have the following understanding of the MQSeries Integrator
`
`software product (hereinafter “MQSeries Integrator”).
`
`-7-
`
`HP_1032_0008
`
`
`
`
`
`19. MQSeries Integrator is a software product which IBM had introduced
`
`into its MQSeries product suite by 1999. MQSeries Integrator was designed for use
`
`in the MQSeries messaging environment, serving as a messaging system and
`
`message broker to permit exchange of messages among applications. In early 2000,
`
`IBM released MQSeries Integrator 2.0. See, e.g., Exhibit 1023 (MQSeries Planning)
`
`(identifying a first edition date of April 2000). MQSeries Integrator was built on the
`
`MQSeries framework, and in fact MQSeries came with and was required to operate
`
`MQSeries Integrator 2.0. See, e.g., Exhibit 1023 (MQSeries Planning) at 94
`
`(identifying MQSeries as a prerequisite for running MQSeries Integrator and stating
`
`that “[t]he MQSeries product is supplied in the MQSeries Integrator package.”).
`
`20. MQSeries Integrator included functionality for routing and processing
`
`messages based on business rules configured within MQSeries Integrator. One
`
`common topology for message brokers, such as MQSeries Integrator, was the hub-
`
`and-spoke topology wherein the message broker sat in the ‘hub’ of the network and
`
`all messaging applications were on ‘spokes’ to that hub.
`
`-8-
`
`HP_1032_0009
`
`
`
`
`
`
`
`Exhibit 1020 (Linthicum) at 314 (“[M]essage brokers use a hub-and-spoke topology.
`
`The message broker, as hub, rests between the source and target applications being
`
`integrated in a configuration that resembles a star (see Figure 18.11).”) Because
`
`MQSeries Integrator is generally located at the hub between communication points,
`
`it makes sense to involve the message broker in applying business processing rules
`
`and monitoring and auditing the message traffic. IBM touted to the public the fact
`
`that message brokers were an ideal tool for auditing and monitoring at the IBM
`
`MQSeries Conference in June 2000.
`
`-9-
`
`HP_1032_0010
`
`
`
`
`
`
`
`Exhibit 1028 (IBM Presentation M43) at 12 (highlighting added). This conference
`
`was open to interested members of the public. Declaration of Chane Cullens at ¶ 27.
`
`21. At the same public IBM MQSeries Conference in June 2000, IBM also
`
`presented examples of MQSeries Integrator being used to carry out a process
`
`comprised of multiple sub-processes.
`
`-10-
`
`HP_1032_0011
`
`
`
`
`
`
`
`Exhibit 1029 (IBM Presentation M56) at 10 (depicting MQSeries Integrator as the
`
`hub in a hub-and-spoke architecture used to carry out a business process consisting
`
`of sub-processes such as Send Requirement, Send Request for Bids, Receive Bids,
`
`Place Order, Receive Delivery, and Send Payment).
`
`22. As explained in the MQSeries Materials, messages flowing through
`
`MQSeries Integrator would be processed by “message flows” comprised of any
`
`number of processing nodes:
`
`You define the processing for your messages as a set of actions, or
`rules, executed between receipt of the message by the broker, and
`
`-11-
`
`HP_1032_0012
`
`
`
`
`
`delivery of the message to the target applications. Each action, or subset
`of actions, is performed by a message processing node. These nodes are
`grouped together in a sequence to form a message flow. A particular
`message flow provides a particular service, that is implemented by the
`rules that the message flow employs.
`
`Exhibit 1023 (MQSeries Planning) at 13. A message flow is “a sequence of
`
`operations on a message, performed by a series of message processing nodes.” Id. at
`
`39. A message processing node is “a stand-alone procedure defined within a
`
`message flow that receives a message, performs a specific action against it, and
`
`outputs zero or more messages as a result of the action it has taken.” Id. at 43.
`
`MQSeries Integrator enabled a user to construct a message flow by combining and
`
`connecting any number of message processing nodes, thereby providing the
`
`flexibility to implement complex business processing rules.
`
`Message flows can range from very simple, performing just one action
`on a message, to complex, providing a number of actions on the
`message to transform its format and content.
`
`Within a message flow, you can define the action to be taken according
`to the message template, the message topic, or the data within the
`message itself. Alternatively, the identity of the message originator, or
`the destination to which the message is sent, might be important. Any
`combination of one or more of these attributes, or others, can define the
`rules by which the messages are processed, and determine the sequence
`of nodes you put together to form the message flow.
`
`A message flow can process one message in several ways to deliver a
`number of output messages, perhaps with different format and content,
`to a number of target applications. You can embed one message flow
`within another, enabling you to reuse a particular sequence of nodes,
`that provide a commonly required function, many times.
`
`Figure 4 illustrates the components of a message flow.
`
`-12-
`
`HP_1032_0013
`
`
`
`
`
`
`Exhibit 1023 (MQSeries Planning) at 14. As described above, MQSeries Integrator
`
`also enabled a user to join message flows together to create a more complex message
`
`flow. See, also, id. at 39.
`
`23. MQSeries Integrator was provided with a series of predefined message
`
`processing nodes referred to as “primitives.” The primitive nodes provided the
`
`functions commonly used in MQSeries Integrator. See Exhibit 1023 (MQSeries
`
`Planning) at 14. Each of these primitive nodes could be configured to execute
`
`specific, pre-defined message processing steps, and multiple primitive nodes could
`
`be connected to create a message flow. In this way, the primitive message
`
`processing nodes were the basic building blocks for creating message flows that
`
`processed messages in MQSeries Integrator. The primitive message nodes are listed
`
`in Table 2 of the MQSeries Control Center manual; several have been highlighted
`
`and will be further discussed below.
`
`-13-
`
`HP_1032_0014
`
`
`
`
`
`Exhibit 1022 (MQSeries Control Center) at 83 (highlighting added).
`
`24. The MQInput and MQOutput nodes are two of the primitive nodes
`
`
`
`-14-
`
`HP_1032_0015
`
`
`
`
`
`supplied with MQSeries Integrator. An MQInput node is the first node in a message
`
`flow; it reads messages from an MQSeries message queue and hands off the
`
`message to the next step(s) (i.e., the next message processing node or nodes) in the
`
`message flow. See Exhibit 1023 (MQSeries Planning) at 15. The MQOutput node
`
`is typically the last node in a message flow, and could be configured to send one or
`
`more copies of a message to one or more message queues. See id.; Exhibit 1022
`
`(MQSeries Control Center) at 112.
`
`25. The Compute node is another primitive node supplied with MQSeries
`
`Integrator. The Compute node can make a copy of a message. Exhibit 2023
`
`(MQSeries Planning) at 48. The Compute node derives one or more new output
`
`messages from an input message, optionally adding data obtained from other data
`
`sources. Id. These new output messages would then be passed on to other
`
`subsequent nodes in the message flow, such as a Warehouse node for storage in a
`
`message warehouse and/or an MQOutput node for sending to another MQSeries
`
`queue. Exhibit 1022 (MQSeries Control Center) at 83, 132.
`
`26. The Warehouse node supplied with MQSeries Integrator is a primitive
`
`node that provides the functionality to create a “message warehouse” populated with
`
`copies of messages sent through the MQSeries Integrator message broker. See, e.g.,
`
`Exhibit 1022 (MQSeries Control Center) at 132; Exhibit 1024 (MQSeries
`
`Programming) at 198 (“The Warehouse node within a message flow supports the
`
`-15-
`
`HP_1032_0016
`
`
`
`
`
`recording of information in a database for subsequent retrieval and processing by
`
`other applications.”). “A message warehouse is a database that, as an option, is able
`
`to store messages that flow through the message broker.” Exhibit 1020 (Linthicum)
`
`at 304 (citing to Fig. 18.7).
`
`
`
`Id. at 304. The MQSeries Integrator Materials explain that a message warehouse is
`
`“[a] persistent, historical datastore for events (or messages).” Exhibit 1024
`
`(MQSeries Programming) at 198. The IBM Redbook depicts a message warehouse
`
`as part of an exemplary MQSeries Integrator architecture, and describes storing a
`
`message in the message warehouse:
`
`-16-
`
`HP_1032_0017
`
`
`
`
`
`
`
`Exhibit 1027 (IBM Redbook) at 5 (highlighting added). In the foregoing
`
`architecture diagram, the message warehouse is depicted as the database labeled
`
`“WAREHOUSE” positioned under the message broker. Id. The MQSeries
`
`Integrator Materials describe how the Warehouse node would be configured to
`
`create a copy of some or all of the data from an original message being sent through
`
`-17-
`
`HP_1032_0018
`
`
`
`
`
`the MQSeries Integrator message broker and send this copy to a message warehouse
`
`for offline processing and data mining:
`
`
`
`Exhibit 1022 (MQSeries Control Center) at 132 (highlighting added) (“A warehouse
`
`node stores messages in a message repository or warehouse. . . . You can choose to
`
`store in the message warehouse: The entire message [or] Selected parts of the
`
`message”).
`
`27. The MQSeries Integrator Materials and Linthicum each teach that a
`
`-18-
`
`HP_1032_0019
`
`
`
`
`
`message warehouse can be used to audit messages and perform data-mining and
`
`analysis on the message data. See Exhibit 1022 (MQSeries Control Center) at 132
`
`(“You can use a message warehouse: To maintain an audit trail of messages[;] For
`
`offline or batch processing of messages (a process sometimes referred to as data
`
`mining).”); Exhibit 1020 (Linthicum) at 304 (“In general, message brokers provide
`
`[message warehouse functionality] to meet several requirements: message mining,
`
`message integrity, message archiving, and auditing.”). One of ordinary skill in the
`
`art would understand that in a business operation, message auditing and data mining
`
`refer to analyzing a data source to obtain useful information about the business
`
`operation. The MQSeries Integrator Materials and Linthicum also acknowledge that
`
`there were well-known ways to analyze and audit the messages saved in a message
`
`warehouse. See Exhibit 1022 (MQSeries Control Center) at 132 (“Once stored in
`
`the message warehouse, messages can be retrieved using standard database query
`
`and data mining techniques.”); Exhibit 1020 (Linthicum) at 304 (“Message mining
`
`implies that the message warehouse is a quasi-data warehouse, allowing for the
`
`extraction of business data to support decisions. . . . Off-the-shelf data mining and
`
`reporting tools work wonderfully for such applications”).
`
`28. The MQSeries Integrator Materials also teach that the Database node,
`
`like the Warehouse node, would be configured to write message data to a database;
`
`one of ordinary skill would have understood that a Database node could be
`
`-19-
`
`HP_1032_0020
`
`
`
`
`
`configured to write message data to a message warehouse. See, Exhibit 1022
`
`(MQSeries Control Center) at 90-92. One of the ways in which the Database node
`
`differs from the Warehouse node is that the Database node would be used when the
`
`messages are in XML format. See, e.g., id. at 222 (“If you are using an XML
`
`message, you would replace this [Warehouse] node with a Database node . . . .”).
`
`Comparison of MQSeries Integrator Materials and Linthicum to the Claims
`
`29.
`
`In my opinion, each of claims 51, 52, 55, 56, and 57 would have been
`
`obvious to one of ordinary skill in the art in light of the disclosures contained in the
`
`MQSeries Integrator Materials alone and/or in combination with Linthicum.
`
`30. The first part of the preamble of claim 51 recites: “A computerized
`
`method for use in an asynchronous messaging environment, . . . .” The MQSeries
`
`Integrator Materials disclose an asynchronous messaging environment. MQSeries
`
`was supplied with the MQSeries Integrator component. See, e.g., Exhibit 1023
`
`(MQSeries Planning) at 94 (“The MQSeries product is supplied in the MQSeries
`
`Integrator package.”). In fact, MQSeries was a required prerequisite for the
`
`MQSeries Integrator component. Id. MQseries, including the MQSeries Integrator
`
`component, is based on asynchronous messaging. See, e.g., Exhibit 1026 (MQSeries
`
`Quick Beginnings) at 1 (“MQSeries is a communications system that provides
`
`assured, asynchronous, once-only delivery of data across a broad range of hardware
`
`and software platforms.”). Moreover, in the ’674 patent, MQSeries and the
`
`-20-
`
`HP_1032_0021
`
`
`
`
`
`MQSeries message broker component comprise the asynchronous messaging
`
`environment in the single exemplary embodiment of the purported invention. See,
`
`e.g., Exhibit 1001 (’674 patent) at 3:49-52 (“In the example shown in the figure, the
`
`sub-processes actually communicate through a messaging broker, such as an IBM
`
`MQSeries component . . . .”).
`
`31. The second part of the preamble to claim 51 recites “wherein said
`
`messaging environment comprises at least one original message comprised of
`
`original message data, comprising: . . . .” The MQSeries Integrator Materials
`
`disclose this feature. The “at least one original message” is just a message sent
`
`through the asynchronous messaging environment. In the case of the MQSeries
`
`Integrator software product being used in an enterprise business operation, the
`
`“original” messages are the messages sent between business processes or sub-
`
`processes via MQSeries Integrator. In fact, the ’674 patent concedes that MQSeries
`
`discloses a messaging environment comprised of at least one original message,
`
`because the ’674 patent points to MQSeries as the exemplary messaging
`
`environment in the single embodiment described in the patent. See, e.g. id. at 3:49-
`
`52 (“In the example shown in the figure, the sub-processes actually communicate
`
`through a messaging broker, such as an IBM MQSeries component”).
`
`32. After the preamble, the first limitation of claim 51 recites: “providing,
`
`through a monitoring message, at least part of said original message data to a central
`
`-21-
`
`HP_1032_0022
`
`
`
`
`
`message repository”. The MQSeries Integrator Materials disclose this limitation.
`
`The ’674 patent concedes that MQSeries had the functionality to create the claimed
`
`monitoring messages. Exhibit 1001 (’674 patent) at 4:1-4:19 (“For example, IBM’s
`
`MQSeries messaging broker provides a component that can be configured to
`
`perform a copying function for the messages it receives, and so create monitoring
`
`messages for the messages it receives. . . . When the messaging broker receives the
`
`message . . . it will create a monitoring message, and send the monitoring message to
`
`the central database repository . . . ”). Indeed, as discussed below there are several
`
`ways in which MQSeries Integrator would be configured to perform a copying
`
`function and create monitoring messages. Likewise, the MQSeries Integrator
`
`Materials disclose providing original message data, via the monitoring message, to a
`
`central message repository, and provide several ways to implement this step.
`
`33. One way in which MQSeries Integrator could be configured to carry out
`
`the step of “providing, through a monitoring message, at least part of said original
`
`message data to a central message repository” is the through the configuration of a
`
`message flow using a Compute node and a Warehouse node, as exemplified in the
`
`following diagram I created:
`
`-22-
`
`HP_1032_0023
`
`
`
`
`
`
`
`A message flow in MQSeries Integrator begins with an MQInput node (also often
`
`referred to simply as an “input node”). See Exhibit 1023 (MQSeries Planning) at 40.
`
`After the MQInput node reads a message (i.e., an original message) from a queue, it
`
`sends the message to the next node(s) in the message flow. In the above example,
`
`the MQInput node sends the message to a Compute node. The Compute node can be
`
`configured to make a copy of the message, i.e., a monitoring message. Exhibit 1023
`
`at 48 (“The Compute node can be used to make a copy of a message (that is,
`
`duplicate the message) . . . .”). A Warehouse node is connected to one of the outputs
`
`of the Compute node to receive the newly created monitoring message, while the
`
`original message flows on to the MQOutput node. The Warehouse node provides all
`
`or part of the data from that original message to a message warehouse (optionally
`
`adding other information, such as a timestamp), thereby building an audit trail of
`
`-23-
`
`HP_1032_0024
`
`
`
`
`
`messages. See Exhibit 1023 (MQSeries Planning) at 49. This exemplary
`
`configuration is suggested by the MQSeries Integrator Materials which explain that
`
`the Warehouse node is designed to create a message warehouse, and that one of the
`
`purposes of a message warehouse is to maintain an audit trail of message:
`
`Exhibit 1022 (MQSeries Control Center) at 132 (highlighting added). The message
`
`warehouse is a central message repository: it stores a copy of the original message
`
`data sent to it via the monitoring messages. As previously mentioned, a Database
`
`
`
`-24-
`
`HP_1032_0025
`
`
`
`
`
`node would normally be substituted for the Warehouse node if the message was in
`
`XML format:
`
`Id. at 90. The foregoing excerpts from the MQSeries Materials point out that both
`
`the Warehouse node and the Database node can use a SQL statement (or SQL
`
`expression) to store message data in the message warehouse. SQL is one of the
`
`
`
`-25-
`
`HP_1032_0026
`
`
`
`
`
`standard ways to communicate with a database and to send data to a database for
`
`storage.
`
`34. The foregoing configuration example would have been obvious to one
`
`of ordinary skill in the art at the time the parent patent was filed in light of the
`
`MQSeries Integrator Materials. The MQSeries Integrator Materials provide a
`
`similar example of a message flow that copies and routes a message through at least
`
`two separate message flow paths (annotated in bold lines) in the message flow:
`
`
`
`Exhibit 1023 (MQSeries Planning) at 14 (annotation added). In fact, if the node
`
`circled (by me) in the lower right of Figure 4 was a Warehouse node, this diagram
`
`from the MQSeries Planning manual would be very similar to the exemplary
`
`message flow in the preceding paragraph. Indeed adding a message warehouse to a
`
`message flow was well-known by those of ordinary skill in the art, and was
`
`explicitly disclosed by the MQSeries Materials. See, e.g., Exhibit 1023 (MQSeries
`
`Planning) at 135 (“For example, you can cause all messages to be stored in a
`
`-26-
`
`HP_1032_0027
`
`
`
`
`
`warehouse by adding a Warehouse node into the message flow . . . .”) (emphasis in
`
`original).
`
`35. A second way in which the MQSeries Integrator Materials teach that
`
`MQSeries Integrator could be configured to carry out the step of “providing, through
`
`a monitoring message, at least part of said original message data to a central
`
`message repository” in a distributed environment is depicted in the following
`
`diagram I created:
`
`
`
`In this configuration, the monitoring message (which is a copy of the original
`
`message) is written into an MQSeries queue before it is sent to the Warehouse1 node
`
`
`
`1
`
`A Database node may be substituted for the Warehouse node if an XML
`
`message format is used.
`
`-27-
`
`HP_1032_0028
`
`
`
`
`
`and the message warehouse. The original message continues along its own message
`
`flow path until it is ultimately written to an output message queue by an MQOutput
`
`node and routed on to its intended destination. The monitoring message is read from
`
`its queue by a second MQInput node which sends the monitoring message to a
`
`Warehouse node, which in turn saves it in the message warehouse; thus “providing,
`
`through a monitoring message, at least part of said original message data to a central
`
`message repository.” It is worth noting that the second MQInput node does not need
`
`to be located on the same broker server as the first. See, e.g., Exhibit 1023
`
`(MQSeries Planning) at 11 (“You can install, create, and start any number of brokers
`
`within a broker domain.”). One of ordinary skill in the art would have recognized
`
`that this configuration is particularly useful because, in a distributed environment,
`
`writing the monitoring message to a message queue allows the monitoring message
`
`to be forwarded to a remote queue so that the message warehouse (i.e., the central
`
`message repository) can be managed at a location most suitable. The notion of using
`
`multiple brokers in a distributed environment, and separating database functionality
`
`on different machines in that environment, was well-understood by one of ordinary
`
`skill in the art at the time, and is in fact described at length in the MQSeries
`
`Integrator Materials. See, e.g., Exhibit 1027 (IBM Redbook) at 73 (“In this chapter
`
`we present a more sophisticated setup with multiple brokers, using MQSeries
`
`clustering features and separating database functionality on different machines.”).
`
`-28-
`
`HP_1032_0029
`
`
`
`
`
`36. The MQSeries Integrator Materials not only disclose the predefined
`
`functionality for each of the foregoing primitive nodes—making it obvious to one of
`
`ordinary skill in the art that a simple message flow could be configured in several
`
`different ways to carry out the step of “providing, through a monitoring message, at
`
`least part of said original message data to a central message repository”—they also
`
`explicitly provide an example scenario using the primitive nodes connected together
`
`to create a message flow that creates copies of original messages and stores original
`
`message data in a message warehouse:
`
`Exhibit 1022 (MQSeries Control Center) at 211; see also id. at 221-223. The
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
