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 HANS-ARNO JACOBSEN, PH.D.
`IN SUPPORT OF PETITION FOR
`COVERED BUSINESS METHOD REVIEW
`
`
`
`U.S. PATENT NO. 7,603,674
`
`
`
`HP_1031_0001
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`HEWLETT-PACKARD COMPANY,
`Petitioner
`
`v.
`
`
`
`
`
`YYZ, LLC,
`Patent Owner
`
`
`
`
`
`CBM No. Unassigned
`
`DECLARATION OF HANS-ARNO JACOBSEN, PH.D.
`IN SUPPORT OF PETITION FOR
`COVERED BUSINESS METHOD REVIEW
`
`
`
`U.S. PATENT NO. 7,603,674
`
`
`
`HP_1031_0001
`
`
`
`I, Hans-Arno Jacobsen, 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”).
`
`Professional Background
`
`2.
`
`I have more than 20 years of experience in research, academia, and
`
`industry in the areas of middleware systems, event processing, service computing,
`
`enterprise data processing, distributed systems, and information systems.
`
`3.
`
`I hold the title of Full Professor with tenure in the Department of
`
`Electrical & Computer Engineering and the Department of Computer Science
`
`(cross-appointed) at the University of Toronto, Canada. I held the Bell University
`
`Laboratories Chair in Software and lead the Middleware Systems Research Group.
`
`A copy of my curriculum vitae is attached as Appendix A to this declaration.
`
`4.
`
`I received my Ph.D. degree from Humboldt University, Berlin in 1999
`
`and my M.A.Sc. degree from the University of Karlsruhe (TH), Germany in 1994.
`
`Between 1992 and 1998 I engaged in pre-doctoral research activities working at
`
`various research laboratories world-wide, including the Laboratoire d'Informatique
`
`et d'Intelligence Artificielle (LIFIA) in Grenoble, France, the International
`
`Computer Science Institute (ICSI) in Berkeley, United States, and Lawrence
`
`Berkeley National Laboratory (LBNL) in Berkeley, United States. After
`
`completing my doctorate from 1998 to 1999, I engaged in post-doctoral research at
`
`-1-
`
`HP_1031_0002
`
`
`
`Institut National de Recherche en Informatique et en Automatique (French Institute
`
`for Research in Computer Science and Automation - INRIA) in Rocquencourt,
`
`France, before joining the University of Toronto in 2001.
`
`5. My areas of research include the design and development of
`
`middleware systems, event processing, service computing, business process
`
`management, and applications in enterprise data processing distributed systems,
`
`and information systems. My current research focuses on publish/subscribe,
`
`content-based routing, event processing, and aspect-orientation. My applied
`
`research focuses on information and communication technology for energy
`
`management and energy efficiency. I also explore the integration of modern
`
`hardware components, such as SSDs (Solid State Drives) and FPGAs (Field
`
`Programmable Gate Arrays), into middleware, event processing, and data
`
`management architectures.
`
`6.
`
`I have served as program committee member of various international
`
`conferences, including the Institute of Electrical and Electronics Engineers (IEEE)
`
`International Conference on Distributed Computing Systems (ICDCS),
`
`International Conference on Data Engineering (ICDE), Association for Computing
`
`Machinery (ACM) Middleware Conference, ACM SIGMOD Conference
`
`(Special Interest Group on Management of Data), ACM Object-Oriented
`
`Programming, Systems, Languages & Applications Conferences (OOPSLA) and
`
`-2-
`
`HP_1031_0003
`
`
`
`International Conference on Very Large Data Bases (VLDB). I was the Program
`
`Chair of the 5th ACM International Middleware Conference and the General Chair
`
`of the Inaugural International Conference on Distributed Event-Based Systems
`
`(DEBS). I was among the initiators of the ACM International Conference on
`
`Distributed Event-Based Systems conference series. I have given numerous
`
`keynote addresses at major national and international conferences, such as the
`
`International Conference on Business Process Management, the ACM Middleware
`
`Conference, and the Chinese National Computer Congress.
`
`7.
`
`I was awarded the Alexander von Humboldt-Professorship Award
`
`from the Humboldt Foundation to conduct research at the Technische Universität
`
`München.
`
`8.
`
`I hold numerous patents and was involved in important industrial
`
`developments in the area of distributed systems, middleware systems, and business
`
`process management with partners like Bell Canada, Computer Associates, IBM,
`
`Yahoo! and Sun Microsystems.
`
`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
`
`-3-
`
`HP_1031_0004
`
`
`
`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 eSleuth prior art related materials I considered include: eSleuth
`
`1.0 User’s Guide (“User’s Guide”) (Exhibit 1011); eSleuth 1.0 Administrator’s
`
`Guide (“Administrator’s Guide”) (Exhibit 1012); Release Notes eSleuth 1.0.0
`
`Early Adoption Release (“Release Notes”) (Exhibit 1013); a whitepaper entitled
`
`eSleuth - eBusiness Transaction Analysis Software that Simplifies the Development
`
`of Reliable, High-Quality eBusiness Systems (“First Whitepaper”) (Exhibit 1006);
`
`and a whitepaper entitled eBusiness Transaction Analysis Software that Improves
`
`Reliability, Performance, and Quality (“Second Whitepaper”) (Exhibit 1008),1
`
`(collectively, “eSleuth Materials”), along with the Cullens Declaration (Exhibit
`
`1030).
`
`13. The other prior art I considered include: MQSeries Primer, IBM
`
`MQSeries EAI Center, October 1999 (“MQSeries Primer”) (Exhibit 1017); Using
`
`
`
`1
`
`An online version of the text of the Second Whitepaper is also at Exhibit
`
`1009 at 6-12.
`
`-4-
`
`HP_1031_0005
`
`
`
`the IBM MQSeries Integrator Version 1.0, IBM International Technical Support
`
`Organization, SG24-5386-00, May 1999 (“MQSeries Integrator 1.0 Manual”)
`
`(Exhibit 1018); Oracle8i, Application Developer’s Guide - Advanced Queuing,
`
`Release 8.1.5, February 1999 (“Oracle 8i Guide”) (Exhibit 1019); D. Linthicum,
`
`Enterprise Application Integration, Addison-Wesley Longman, Copyright 2000
`
`(“Linthicum”) (Exhibit 1020); and Y. Hoffner, Monitoring in Distributed Systems,
`
`ANSA Architecture Report, October 25, 1994 (“Hoffner”) (Exhibit 1021).
`
`14.
`
`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
`
`15.
`
`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.
`
`16. 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
`
`-5-
`
`HP_1031_0006
`
`
`
`software.
`
`Overview of the ’674 Patent
`
`17. The ’674 patent is directed to a method and system for monitoring
`
`business processes, such as the financial process of turning orders into cash. See,
`
`e.g., ’674 patent Abstract and 3:43-5:3.
`
`18. The ’674 patent describes the fact that the activities of a business or
`
`enterprise can be grouped into processes; that those processes can in turn be further
`
`broken down into sub-processes; and that those sub-processes can be further
`
`broken down into activities. ’674 patent at 1:24-37. The ’674 patent provides a
`
`single example of a business process called Order to Cash, which is described as
`
`being comprised of sub-processes called Receive Order Inquiry, Provide Customer
`
`Quotation, Create Customer Outline Agreement, Create Sales Order, Schedule
`
`Production, Manufacture Product, Ship Product, and Invoice Customer. Id. The
`
`’674 patent does not purport to have invented the concept of breaking business
`
`processes down into processes and sub-processes, and such a breakdown was of
`
`course well-known in the prior art. See ’674 patent, Background of the Invention;
`
`see also Exhibit 1019 (Oracle8i Guide) at 1-2; Exhibit 1018 (MQSeries Integrator
`
`1.0 Manual) at 153-54.
`
`19. The ’674 patent describes the fact that processes, sub-processes, and
`
`activities operate in part by communicating information. Id. at 1:38-39. The ’674
`
`-6-
`
`HP_1031_0007
`
`
`
`patent provides examples of ways to carry out such communication, including
`
`email, electronic data interchange (“EDI”), and other asynchronous or message
`
`based communication. Id. at 1:39-42, 1:46-48. The ’674 patent describes some of
`
`the purported benefits of asynchronous communication, such as the flexibility in
`
`assembling and modifying business processes. Id. at 1:58-66. The Background
`
`section of the ’674 patent admits that asynchronous communication, including
`
`asynchronous messaging, was known in the prior art. Id. at 1:38-2:13.
`
`20. The ’674 patent describes a single example of monitoring a business
`
`process in which the sub-processes in the Order to Cash process communicate in
`
`an asynchronous messaging environment; in the example described, the
`
`asynchronous messaging environment uses a message broker. Id. at 3:43-55. The
`
`’674 patent concedes that message brokers were known in the prior art, and in fact
`
`identifies an IBM MQSeries component as an example of a message broker known
`
`in the prior art. Id. at 3:43-57.
`
`21. The ’674 patent uses the term “original messages” to refer to
`
`messages sent through the asynchronous messaging environment while passing
`
`between the sub-processes in the Order to Cash process; this is simply a naming
`
`convention used by the inventors to refer to messages communicated between sub-
`
`processes and activities within a process . See, e.g., id. at 3:11-15, 3:49-65. In the
`
`example shown in Figure 1, the original messages (labeled A through G) are
`
`-7-
`
`HP_1031_0008
`
`
`
`simply messages sent through a prior art message broker as part of carrying out an
`
`exemplary business process, Order to Cash. Id. at 3:11-15. Use of asynchronous
`
`message environments, including those with message brokers, to carry out business
`
`processes was well-known prior to the filing of the parent to the ’674 patent, as
`
`conceded by the inventors. Id. at 1:46-2:22.
`
`22. The single example embodiment described in the ’674 patent uses a
`
`message broker to communicate messages. Id. at 3:49-53. The ’674 patent further
`
`states that a “messaging component” can be added to the message broker “through
`
`methods known in the art.” Id. at 3:56-57. The ’674 patent states that this
`
`messaging component can create a so-called “monitoring message” for each
`
`original message received by the message broker, wherein the monitoring message
`
`contains data from the original messages passing through the message broker. Id.
`
`at 3:57-61.
`
`23. The ’674 patent explains that in some embodiments the messaging
`
`component, which creates the monitoring messages, may be provided by the
`
`message broker itself. Id. at 3:66-4:1 (“The messaging component may be, in
`
`some embodiments . . . provided by the messaging broker.”). The ’674 patent
`
`gives an example of a known prior art message broker that could provide the so-
`
`called messaging component—the prior art IBM MQSeries messaging broker. Id.
`
`at 4:1-4 (“IBM's MQSeries messaging broker provides a component that can be
`
`-8-
`
`HP_1031_0009
`
`
`
`configured to perform a copying function for the messages it receives, and so
`
`create monitoring messages for the messages it receives.”). The ’674 patent also
`
`explains that, in some cases, the messaging component is not provided by the
`
`messaging broker. Id. at 3:66-4:1 (“The messaging component may be, in some
`
`embodiments, or may not be, in other embodiments, provided by the messaging
`
`broker.”) (emphasis added). Thus, the inventors conceded that the prior art
`
`included multiple known ways to implement the messaging component—namely,
`
`by configuring the IBM MQSeries message broker or by adding it through
`
`unspecified “means known in the art”—and likewise multiple known ways to
`
`create so-called monitoring messages.
`
`24. The ’674 patent states that the monitoring messages are sent to a
`
`central database repository. Id. at 3:61-65 (“The monitoring message with its data
`
`is then sent from the messaging broker to a central database repository or database
`
`. . . .”). The patent uses the terms “database” and “repository” interchangeably. Id.
`
`at 3:63-65 (“the terms ‘repository’ or ‘database’ are used interchangeably
`
`throughout”). Of course, the ’674 patent implicitly acknowledges, as it must, that
`
`databases were used in the prior art for storing information. In fact, as further
`
`described below in paragraphs 40-42, one known use of databases in the prior art
`
`was for storing copies of messages in an asynchronous messaging environment.
`
`25. The ’674 patent further states that, upon being sent to the central
`
`-9-
`
`HP_1031_0010
`
`
`
`database repository, the monitoring messages populate an “information flow or
`
`transaction record.” Id. at 4:59-60 (“The monitoring message data populates one
`
`information flow or transaction record . . . .”). The ’674 patent does not provide a
`
`definition for the general term “transaction record,” but as used in the ’674 patent
`
`one of ordinary skill in the art would have understood the term “transaction record”
`
`to mean stored information related to a transaction.
`
`26. The ’674 patent explains that the central message database could be
`
`reviewed in order to “measure, monitor, and track enterprise communications and
`
`processes,” such as through the providing of information about customers or
`
`orders, bottlenecks in the process, or information across time spans such as days,
`
`weeks, or months. Id. at 5:4-22; 5:45-48. The ’674 patent states that storing
`
`information in the central message repository and making this information
`
`available for analysis “offloads” at least some of this burden from the enterprise
`
`applications, i.e., from the systems underlying the processes, sub-processes, and/or
`
`activities that generate the messages in the business enterprise. Id. at 5:7-16.
`
`27. To the extent that the ’674 patent describes any technology
`
`(asynchronous messaging environments, message brokers, databases) or
`
`applications of technology (original messages, monitoring messages, transaction
`
`records), such applications of existing technology would have been well-known by
`
`one of ordinary skill in the art. None of these technical elements were novel at the
`
`-10-
`
`HP_1031_0011
`
`
`
`time the original parent patent was filed, and such applications of existing
`
`technology were also obvious to one of ordinary skill in the art.
`
`Analysis of Claim Terms in the ’674 Patent
`
`28.
`
`I understand that, in a Covered Business Method review, patent claim
`
`terms are to be given their broadest reasonable interpretation as understood by a
`
`person of ordinary skill in light of the patent specification.
`
`29. Based on this understanding of how claim terms should be construed,
`
`I set forth below certain claim constructions for terms found in claims 51-52 and
`
`55-57 of the ’674 patent. For any other claim terms, I apply their ordinary and
`
`customary meaning.
`
`30.
`
` “Asynchronous messaging environment” should be construed as “a
`
`messaging environment in which data is transmitted without prior coordination
`
`between communication end points.” This is the broadest reasonable interpretation
`
`in light of the patent specification, which states: “Enterprise communications are
`
`now increasingly asynchronous, or connectionless, transmitting data without prior
`
`coordination between communication end points, such as through ‘event based’
`
`communications which use messages to move data instead of large files.” ’674
`
`patent at 1:52-57.
`
`31.
`
`“Process” should be construed as “an enterprise or business
`
`operation.” This is the broadest reasonable interpretation in light of the patent
`
`-11-
`
`HP_1031_0012
`
`
`
`specification, which states: “The activities of a business or enterprise can be
`
`grouped into processes. Processes are business operations that are separated as
`
`desired and usually occur across business units.” Id. at 1:24-26; see also id. at
`
`2:56-57 (“It is a further object of the present invention to provide monitoring
`
`capabilities for enterprise processes.”).
`
`32.
`
`“Sub-process” should be construed as “a part or a step of a process.”
`
`This is the broadest reasonable interpretation in light of the patent specification,
`
`which states: “The processes are comprised of sub-processes.” Id. at 1:28-29.
`
`33.
`
`“Original message” should be construed as “a message sent within or
`
`between processes, sub-processes, and/or activities.” This is the broadest
`
`reasonable interpretation in light of the patent specification, which states: “For
`
`each original message sent within a process, sub-process or activity, the preferred
`
`embodiments . . .” (id. at 3:11-15); “The dashed line arrows connecting the sub-
`
`processes are the communication paths between the sub-processes.” id. at 3:47-49;
`
`and “That customer request will begin the Receive Order Inquiry sub-process
`
`which will end with the generation of a Receive Order Inquiry message traveling to
`
`the Provide Customer Quotation sub-process. . . .” (id. at 4:12-16 and Fig. 2).
`
`34.
`
`“Monitoring message” should be construed as “a message related to
`
`an original message or to something being monitored.” This is the broadest
`
`reasonable interpretation in light of the patent specification, which states: “[i]t is a
`
`-12-
`
`HP_1031_0013
`
`
`
`further object of the present invention to provide monitoring capabilities for
`
`enterprise processes,” and “[t]his monitoring message contains, in this
`
`embodiment, specific data generated from the original messages passing between
`
`the sub-processes.” Id. at 3:59-61. As an example, the specification states that a
`
`monitoring message can simply be a copy of the original message: “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.” Id. at 4:1-4.
`
`35.
`
` “Central message repository” should be construed as “a collection
`
`point for messages and information passing through the enterprise” which can
`
`include a “database.” This is the broadest reasonable interpretation in light of the
`
`patent specification, which states: “This central message repository or database is
`
`comprised of information passing through the enterprise. In effect, the database
`
`provides a collection point or an ‘end point’ for the asynchronous communications
`
`. . . .” (id. at 3:20-23); and “the terms ‘repository’ or ‘database’ are used
`
`interchangeably throughout” (id. at 3:63-65).
`
`36.
`
`“Transaction” should be construed as “an instance of a process or sub-
`
`process.” This is the broadest reasonable interpretation in light of the patent
`
`specification, which states: “Of course, these records may vary depending on the
`
`status of the transaction, that is, whether the transaction is in the middle of the
`
`-13-
`
`HP_1031_0014
`
`
`
`process, at the beginning of the process, etc.” ’674 patent at 6:21-24; “As
`
`monitoring messages progress through any given process and/or sub-process, the
`
`transaction record is updated. Once the monitoring messages complete the
`
`transaction record, all of the information needed to measure that transaction
`
`through the process is contained in one record in the central message database.”
`
`’674 patent at 4:60-66.
`
`37.
`
`“Transaction record” should be construed as “stored information
`
`related to a transaction.” This is the broadest reasonable interpretation in light of
`
`the patent specification, which states: “The monitoring message data populates one
`
`information flow or transaction record (‘transaction record’). As monitoring
`
`messages progress through any given process and/or sub-process, the transaction
`
`record is updated.” Id. at 4:59-62.
`
`Overview of the State of the Art.
`
`38. Computerized asynchronous messaging environments were well-
`
`known by 1999. Asynchronous messaging environments include a type of
`
`software often referred to as “middleware” or “message-oriented middleware,”
`
`designed to tie together many different systems and applications within a business
`
`enterprise. Asynchronous middleware messaging systems were known to provide
`
`certain benefits, such as permitting distributed applications to communicate with
`
`one another when each had available time and resources to do so. As described in
`
`-14-
`
`HP_1031_0015
`
`
`
`the 1999 book Enterprise Application Integration:
`
`Asynchronous middleware is middleware that moves information
`between one or many applications in an asynchronous mode—that is,
`the middleware software is able to decouple itself from the source or
`target applications, and the applications are not dependent on the other
`connected applications for processing. The process that allows this to
`occur has the application(s) placing a message in a queue and then
`going about their business, waiting for the responses at some later
`time from the other application(s). The primary advantage of the
`asynchronous model is that the middleware will not block the
`application for processing. Moreover, because the middleware is
`decoupled from the application, the application can always continue
`processing, regardless of the state of the other applications.
`
`Exhibit 1020 (Linthicum) at 135-136. Various commercial middleware systems
`
`made use of asynchronous messaging by 1999, including software systems from
`
`IBM, Oracle, and others.
`
`39. One popular message-oriented middleware system in 1999 was IBM’s
`
`MQSeries. MQSeries enabled different application programs to send and receive
`
`messages as part of an asynchronous messaging environment. Application
`
`programs in a distributed computing environment could use MQSeries API calls to
`
`send and receive messages via the MQSeries message queue manager, as
`
`illustrated in Fig. 1 from the MQSeries Primer:
`
`-15-
`
`HP_1031_0016
`
`
`
`
`
`Exhibit 1017 (MQSeries Primer) at 3. Via this message queue manager, MQSeries
`
`provided support for asynchronous messaging. Id. at 4 (“With asynchronous
`
`messaging, the sending program proceeds with its own processing without waiting
`
`for a reply to its message.”). MQSeries was one example of message-oriented
`
`middleware known and in commercial use by 1999.
`
`40. Another example of message-oriented middleware was the Oracle8
`
`database management system by Oracle Corporation. In 1999, Oracle
`
`implemented aspects of asynchronous messaging as part of the Oracle8 database
`
`server. Oracle8 provided this functionality by integrating a message queuing
`
`system with the Oracle8 database, thereby creating a message-enabled database.
`
`Oracle Advanced Queueing (Oracle AQ) provides message queuing as
`an integrated part of the Oracle server. Oracle AQ provides this
`functionality by integrating the queuing system with the database,
`thereby creating a message-enabled database.
`
`-16-
`
`HP_1031_0017
`
`
`
`Exhibit 1019 (Oracle8i Guide) at xx (emphasis in original). The Advanced
`
`Queuing (AQ) functionality of Oracle8 could be implemented to operate in an
`
`asynchronous messaging environment, as described in the Oracle8i Guide:
`
`the
`Asynchronous Messaging as an Application Model - In
`asynchronous, disconnected or deferred model programs in the role
`of producers place messages in a queue and then proceed with their
`work. Programs in the role of consumers retrieve requests from the
`queue and act on them. This model is well suited for applications that
`can continue with their work after placing a request in the queue
`because they are not blocked waiting for a reply. It is also suited to
`applications that can continue with their work until there is a message
`to retrieve.
`
`Exhibit 1019 (Oracle8i Guide) at 1-3 (emphasis in original).
`
`41. By 1999, it was known that message-oriented middleware systems
`
`could be used to facilitate the execution of business operations, particularly those
`
`involving a distributed computing environment where messages were
`
`communicated by different applications performing various sub-processes within
`
`the business operation. For example, to demonstrate the functionality and
`
`potential uses of Oracle8i, the Oracle8i Guide described an exemplary online
`
`bookstore business operation in which its message-enabled database could be
`
`deployed across a distributed computing environment of a large enterprise:
`
`The operations of a large bookseller, BooksOnLine, are based on an
`online book ordering system which automates activities across the
`various departments involved in the entire sale process. The front end
`of the system is an order entry application which is used to enter new
`orders. These incoming orders are processed by an order processing
`application which validates and records
`the order. Shipping
`
`-17-
`
`HP_1031_0018
`
`
`
`departments located at regional warehouses are then responsible for
`ensuring that these orders are shipped in a timely fashion. There are
`three regional warehouses: one serving the East Region, one serving
`the West Region, and a third warehouse for shipping International
`orders. Once an order has been shipped, the order information is
`routed to a central billing department which handles payment
`processing. The customer service department, located at its own site,
`is responsible for maintaining order status and handling inquiries
`about orders. . . .
`
`This scenario describes an application in which messages come from
`and are disbursed to multiple clients (nodes) in a distributed
`computing environment. Messages are not only passed back and forth
`between clients and servers but are also intricately interleaved
`between processes on different servers. The integration of the various
`component applications consist of multi-step processes in which each
`step is triggered by one or more messages, and which may then give
`rise to one or more messages.
`
`Exhibit 1019 (Oracle8i Guide) at 1-2. The exemplary BooksOnLine business
`
`operation is referenced throughout the Oracle8i Guide to illustrate how the Oracle8
`
`message-enabled database could be used to carry out a business operation
`
`comprised of multiple processes and sub-processes in a distributed computing
`
`environment.
`
`42. As described above, by 1999 the idea of using message-oriented
`
`middleware in an asynchronous messaging environment, combined with a
`
`database, as part of an enterprise business operation was well-known to those of
`
`ordinary skill in the art.
`
`43. By 1999, a specific type of message-oriented middleware had been
`
`developed called “message brokers.” Message brokers were well-known by those
`
`-18-
`
`HP_1031_0019
`
`
`
`of ordinary skill in the art by 1999. Like other message-oriented middleware,
`
`message brokers support asynchronous messaging. See Exhibit 1020 (Linthicum)
`
`at 293 (“A message broker is a software system based on asynchronous, store-and-
`
`forward messaging.”). A message broker can be described as an intermediary that
`
`directs the flow of messages. Like other message-oriented middleware, message
`
`brokers were well-known to be useful in automating enterprise communications
`
`that traditionally had been performed manually. See Exhibit 1020 (Linthicum) at
`
`292 (“In providing greater efficiency and flexibility, message brokers more closely
`
`resemble the way business ‘actually works’—automating functions currently
`
`performed manually, for example, sending sales reports through interoffice mail or
`
`walking data down the hall on disk.”). Message brokers carry out many of the
`
`same messaging functions of traditional message-oriented middleware, but also
`
`permit some additional functionality to help broker the difference between systems
`
`in an enterprise.
`
`44.
`
`In 1999, one example of a message broker was IBM’s MQSeries
`
`Integrator component, which provided message broker functionality:
`
`MQSeries Integrator is message brokering software that ensures
`business-critical applications and processes can understand each other.
`Based on MQSeries’ messaging and queuing capabilities, the
`MQSeries Integrator is a real-time, intelligent rules-based message
`routing and dynamic message content transformation and formatting
`system that allows you to integrate all types of applications and
`systems into robust, flexible and scalable information networks.
`
`-19-
`
`HP_1031_0020
`
`
`
`Exhibit 1018 (MQSeries Integrator 1.0 Manual) at 3. By 1999, it was well-known
`
`by those of ordinary skill in the art that message brokers could be used to facilitate
`
`the execution of a business process. By way of a very basic example, the
`
`MQSeries Integrator 1.0 Manual describes a simplified, abstract example of a
`
`business operation or process (making fruit salad) wherein communication through
`
`MQSeries Integrator messages occurs among different sub-process applications
`
`running in different warehouses in a distributed environment: one application for
`
`apples is running at the apple warehouse, one application for oranges is running at
`
`the orange warehouse, one application for peaches is running at the peaches
`
`warehouse, and one application for pears is running at the pears warehouse.
`
`
`
`-20-
`
`HP_1031_0021
`
`
`
`Exhibit 1018 (MQSeries Integrator 1.0 Manual) at 153-154. In the example, when
`
`a fruit salad is ordered, the front-end program sends a message to the first sub-
`
`process, Apple Inventory. The Apple Inventory application performs an inventory
`
`check and then generates and sends a message indicating whether the request for
`
`apples can be fulfilled, and this message is routed back through the message
`
`broker. The front-end program likewise sends similar requests to the other sub-
`
`processes—Orange Inventory, Peach Inventory and Pear Inventory—which
`
`generate their own messages carrying inventory data. The end-result of this simple
`
`business process example is that a fruit salad ends up being either produced (if all
`
`the necessary fruit is available) or backordered. See id. at 154.
`
`45. Thus, as described above, the idea of carrying out a business operation
`
`by implementing an asynchronous messaging environment based on a message
`
`broker was well-known to those of ordinary skill in the art.
`
`46. By 1999, one of ordinary skill in the art would have recognized the
`
`value in monitoring a business operation, especially a business operation carried
`
`out across a distributed system. As described in a 1994 paper by Yigal Hoffner,
`
`“[m]onitoring is the process of obtaining, collecting, and presenting the
`
`information required by an observer about the observed system.” Exhibit 1021
`
`(Hoffner) at 4. The concept of monitoring distributed systems—including those
`
`with asynchronous communication—was well-known to those of ordinary skill in
`
`-21-
`
`HP_1031_0022
`
`
`
`the art in 1999. See id. at 10 (“objects will be able to invoke other objects
`
`asynchronously . . . . Thus we may wish to: . . . follow the chain of activity as it
`
`moves from one object to another.”). The concept of carrying out such monitoring
`
`in a distributed system through the use of “monitoring messages” was also well-
`
`known to those of ordinary skill in the art at the time. The Hoffner paper provides
`
`a conceptual description of a monitor using monitoring messages, involving: (1)
`
`creating monitoring messages based on events (e.g., original messages); (2)
`
`forwarding the monitoring messages to one or more destinations; (3) storing or
`
`logging the monitoring messages; (4) collating and processing the monitoring
`
`messages to detect events; and (5) presenting or visualizing the monitoring
`
`message data in such a way that an observer w
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
