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,062,749
`
`
`
`
`
`
`
`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,062,749
`
`
`
`
`
`
`
`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,062,749 (“the ’749 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
`
`’749 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 ’749 patent, and I have no other
`
`financial stake in this matter.
`
`11. The patent-related materials I considered include: the ’749 patent
`
`(Exhibit 1001); the original prosecution history for the ’749 patent (Exhibit 1002);
`
`and the reexamination file history for the ’749 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 ’749 patent at the time at which the 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 22, 23, 27, 28, and 29 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 22 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 ’749 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 (’749 patent) at 3:44-47 (“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 22 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 ’749 patent concedes that MQSeries
`
`discloses a messaging environment comprised of at least one original message,
`
`because the ’749 patent points to MQSeries as the exemplary messaging
`
`environment in the single embodiment described in the patent. See, e.g. id. at3:44-
`
`47 (“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 22 recites: “monitoring
`
`a process, which is comprised of at least a first and second sub process, by
`
`-21-
`
`HP_1032_0022
`
`
`
`
`
`generating original message data from each of said first and second sub process . . .
`
`.” A “process” is a business operation; a sub-process is just a step in a business
`
`operation. Monitoring a multi-step business operation (i.e., a process comprised of
`
`more than one sub-process) would have been obvious to one of ordinary skill in the
`
`art based on the disclosures in the MQSeries Integrator Materials and Linthicum. In
`
`addition, “generating original message data from each of said first and second sub-
`
`process” is simply a recitation of using MQSeries Integrator to transmit messages in
`
`the execution of such a multi-step process. Therefore, this limitation would have
`
`been obvious to one of ordinary skill in the art based on the MQSeries Integrator
`
`Materials and Linthicum.
`
`33. Monitoring business operations being carried out with MQSeries
`
`Integrator was obvious to one of ordinary skill in the art at the time the patent was
`
`filed based on the MQSeries Integrator Materials in view of Linthicum. One of
`
`ordinary skill in the art would recognize that, in a business enterprise, auditing and
`
`analyzing messages in a message warehouse is one way to carry out monitoring of
`
`the business operations (i.e., processes and sub-processes) in the enterprise. As
`
`described in paragraph 26 above, MQSeries Integrator provided the functionality to
`
`implement a message warehouse using the Warehouse node or Database node. See
`
`Exhibit 1022 (MQSeries Control Center) at 132 (“You can use a message
`
`warehouse: . . . For offline or batch processing of messages (a process sometimes
`
`-22-
`
`HP_1032_0023
`
`
`
`
`
`referred to as data mining). . . . Once stored in the message warehouse, messages
`
`can be retrieved using standard database query and data mining techniques.”);
`
`Exhibit 1024 (MQSeries Introduction) at 198 (“The Warehouse node within a
`
`message flow supports the recording of information in a database for subsequent
`
`retrieval and processing by other applications.”). It would have been obvious to one
`
`of ordinary skill in the art that one of the benefits of an MQSeries Integrator
`
`message warehouse is the ability to use “other applications” to audit and analyze the
`
`messages in the message warehouse and thereby monitor business operations. One
`
`of ordinary skill in the art at the time would recognize that because MQSeries
`
`Integrator was frequently implemented in the middle of the communication web in a
`
`hub-and-spoke architecture, with all message traffic going through it, it is an ideal
`
`place for monitoring. Moreover, Linthicum describes the use of a message
`
`warehouse for data mining, i.e., analyzing the data for business process information:
`
`Message Warehousing[:] Another feature of message brokers is
`message warehousing. A message warehouse is a database that, as an
`option, is able to store messages that flow through the message broker
`(see Figure 18.7). In general, message brokers provide this message
`persistence facility to meet several requirements: message mining,
`message integrity, message archiving, and auditing.
`
`Message mining implies that the message warehouse is a quasi-data
`warehouse, allowing for the extraction of business data to support
`decisions. For example, it is possible to use the message warehouse to
`determine the characteristics, and amount, of new customer information
`that is being processed through the message broker. All new sales
`orders for a given period of time can be displayed. Off-the-shelf data
`mining and reporting tools work wonderfully for such applications.
`
`-23-
`
`HP_1032_0024
`
`
`
`
`
`Exhibit 1020 (Linthicum) at 304 (underline added, bold in original). Determining
`
`the characteristics and amount of new customer information that is being processed
`
`through the message broker is an example of monitoring a business operation, i.e.,
`
`monitoring a process. One of ordinary skill in the art would recognize that there
`
`were myriad ways a message warehouse could be analyzed to monitor a business
`
`operation. One way to carry out such analysis was to apply basic SQL queries to the
`
`message warehouse in order to access data about particular business transactions and
`
`processes. Also, as stated in Linthicum, off-the-shelf data mining and reporting
`
`tools were available at this time for performing various types of monitoring and
`
`analysis of the message data in a message warehouse. See id. at 304.
`
`34. Regarding “generating original message data from each of said first and
`
`second sub-process”—this is disclosed in the MQSeries Integrator Materials and
`
`would have been well known (and also obvious) to one of ordinary skill in the art at
`
`least as early as 1999. The use of asynchronous messaging to generate original
`
`message data from different applications carrying out sub-processes in a business
`
`process was well known in the prior art, and the idea of using MQSeries Integrator
`
`as a tool to carry out a business process and facilitate the generation of original
`
`messages from sub-processes in a business operation was not novel. For example,
`
`an IBM reference guide for the very first version of MQSeries Integrator 1.0
`
`describes using MQSeries Integrator to execute a business operation wherein
`
`-24-
`
`HP_1032_0025
`
`
`
`
`
`original messages with original message data are generated from sub-processes. See
`
`Exhibit 1018 (MQSeries Integrator 1.0 Reference) at 153-154. In this simple
`
`example the business process is making a fruit salad, and different sub-processes
`
`applications—one for apples, one for oranges, one for peaches, and one for pears—
`
`communicate with an order processing system by generating and sending original
`
`message data concerning inventory of these items.
`
`
`
`Id. When an order is received, the first sub-process (e.g., the Apple Inventory
`
`application) receives a request, performs an inventory check and then generates and
`
`sends a message through the MQSeries Integrator message broker indicating
`
`whether the request for apples can be fulfilled. Likewise, a second sub-process (e.g.,
`
`-25-
`
`HP_1032_0026
`
`
`
`
`
`the Orange Inventory application) generates its own message indicating whether the
`
`request for oranges can be fulfilled. These are examples of original messages with
`
`original message data being generated from a first and second sub-process in a
`
`business operation. MQSeries Integrator 2.0 continued and in fact expanded this
`
`support for business processes. See, e.g., Exhibit 1023 (MQSeries Planning) at 9
`
`(“MQSeries Integrator Version 2.0 supports business processes that meet your
`
`application and business integration needs.”). The MQSeries Integrator Materials
`
`provide another example of MQSeries Integrator being used to carry out a multi-step
`
`business process for a fictional supermarket called SRU Corporation.
`
`
`
`Exhibit 1023 (MQSeries Planning) at 29-35 and Fig. 14 (describing a business
`
`operation with different processes for distributing sales transaction information to
`
`different sub-processes responsible for providing financial updates, maintaining
`
`inventory stock, and communicating with business partners). All of these simple
`
`-26-
`
`HP_1032_0027
`
`
`
`
`
`examples illustrate the point, echoed in the ’749 patent (in which the single
`
`exemplary embodiment used MQSeries as the message broker implementing a
`
`multi-step business process Order-to-Cash), that MQSeries Integrator provided
`
`functionality to facilitate the communication of original message data from sub-
`
`processes whilst executing a business process.
`
`35. Thus, “monitoring a process, which is comprised of at least a first and
`
`second sub process,
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
