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,062,749
`
`
`
`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,062,749
`
`
`
`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,062,749 (the “’749 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 Institut National de Recherche
`
`-1-
`
`HP_1031_0002
`
`
`
`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 International Conference on
`
`Very Large Data Bases (VLDB). I was the Program Chair of the 5th ACM
`
`-2-
`
`HP_1031_0003
`
`
`
`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
`
`’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
`
`-3-
`
`HP_1031_0004
`
`
`
`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 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
`
`the IBM MQSeries Integrator Version 1.0, IBM International Technical Support
`
`
`
`1
`
`An online version of the text of the Second Whitepaper is also at Exhibit 1009
`
`at 6-12.
`
`-4-
`
`HP_1031_0005
`
`
`
`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 ’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.
`
`-5-
`
`HP_1031_0006
`
`
`
`Overview of the ’749 Patent
`
`17. The ’749 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., ’749 patent Abstract and 3:39-4:68.
`
`18. The ’749 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. ’749 patent at 1:15-29. The ’749 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
`
`’749 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 ’749 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 ’749 patent describes the fact that processes, sub-processes, and
`
`activities operate in part by communicating information. Id. at 1:29-30. The ’749
`
`patent provides examples of ways to carry out such communication, including email,
`
`-6-
`
`HP_1031_0007
`
`
`
`electronic data interchange (“EDI”), and other asynchronous or message based
`
`communication. Id. at 1:31-34, 1:37-39. The ’749 patent describes some of the
`
`purported benefits of asynchronous communication, such as the flexibility in
`
`assembling and modifying business processes. Id. at 1:49-58. The Background
`
`section of the ’749 patent admits that asynchronous communication, including
`
`asynchronous messaging, was known in the prior art. Id. at 1:29-2:4.
`
`20. The ’749 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:39-52. The ’749 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:39-53.
`
`21. The ’749 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:6-10, 3:45-61. In the example shown
`
`in Figure 1, the original messages (labeled A through G) are simply messages sent
`
`through a prior art message broker as part of carrying out an exemplary business
`
`-7-
`
`HP_1031_0008
`
`
`
`process, Order to Cash. Id. at 3:6-10. Use of asynchronous message environments,
`
`including those with message brokers, to carry out business processes was well-
`
`known prior to the filing of the ’749 patent, as conceded by the inventors. Id. at
`
`1:37-2:13.
`
`22. The single example embodiment described in the ’749 patent uses a
`
`message broker to communicate messages. Id. at 3:44-48. The ’749 patent further
`
`states that a “messaging component” can be added to the message broker “through
`
`methods known in the art.” Id. at 3:52-53. The ’749 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:53-58.
`
`23. The ’749 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:62-64 (“The messaging component may be, in some
`
`embodiments . . . provided by the messaging broker.”). The ’749 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 3:64-
`
`67 (“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”). The ’749 patent also explains
`
`-8-
`
`HP_1031_0009
`
`
`
`that, in some cases, the messaging component is not provided by the messaging
`
`broker. Id. at 3:62-64 (“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 ’749 patent states that the monitoring messages are sent to a central
`
`database repository. Id. at 3:58-60 (“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:59-
`
`60 (“the terms ‘repository’ or ‘database’ are used interchangeably throughout”). Of
`
`course, the ’749 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 ’749 patent further states that, upon being sent to the central
`
`database repository, the monitoring messages populate an “information flow or
`
`transaction record.” Id. at 4:56-57 (“The monitoring message data populates one
`
`-9-
`
`HP_1031_0010
`
`
`
`information flow or transaction record . . . .”). The ’749 patent does not provide a
`
`definition for the general term “transaction record,” but as used in the ’749 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 ’749 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:1-19, 5:42-45. The ’749 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:4-13.
`
`27. To the extent that the ’749 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 time the original
`
`patent was filed, and such applications of existing technology were also obvious to
`
`one of ordinary skill in the art.
`
`-10-
`
`HP_1031_0011
`
`
`
`Analysis of Claim Terms in the ’749 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 22-23 and 27-
`
`29 of the ’749 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.” ’749
`
`patent at 1:43-48.
`
`31.
`
`“Process” should be construed as “an enterprise or business operation.”
`
`This is the broadest reasonable interpretation in light of the patent 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
`
`-11-
`
`HP_1031_0012
`
`
`
`usually occur across business units.” Id. at 1:15-17; see also id. at 2:51-52 (“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:19-20.
`
`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:6-10); “The dashed line arrows connecting the sub-processes are the
`
`communication paths between the sub-processes.” id. at 3:44-45; 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:7-12 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 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
`
`-12-
`
`HP_1031_0013
`
`
`
`from the original messages passing between the sub-processes.” Id. at 2:51-52, 3:55-
`
`57. 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 3:64-67.
`
`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:15-18); and “the terms ‘repository’ or ‘database’ are used
`
`interchangeably throughout” (id. at 3:59-61).
`
`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
`
`process, at the beginning of the process, etc.” ’749 patent at 6:20-23; “As monitoring
`
`messages progress through any given process and/or sub-process, the transaction
`
`-13-
`
`HP_1031_0014
`
`
`
`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.” ’749 patent at 4:59-63.
`
`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:56-59.
`
`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 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
`
`-14-
`
`HP_1031_0015
`
`
`
`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
`- In
`Asynchronous Messaging as an Application Model
`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 departments
`
`-17-
`
`HP_1031_0018
`
`
`
`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 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
`
`-18-
`
`HP_1031_0019
`
`
`
`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.
`
`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
`
`-19-
`
`HP_1031_0020
`
`
`
`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.
`
`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
`
`
`
`-20-
`
`HP_1031_0021
`
`
`
`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
`
`Inventor y, 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 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
`
`-21-
`
`HP_1031_0022
`
`
`
`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
`
`would be able to review it.
`
`-2
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
