MShift, Inc. v. Digital Insight Corporation et al, No. 3:2010cv00710 - Document 336 (N.D. Cal. 2010)

Court Description: CLAIM CONSTRUCTION ORDER, ORDER GRANTING DEFENDANTS' MOTION FOR SUMMARY JUDGMENT, AND ORDER DENYING PLAINTIFF'S MOTION FOR SANCTIONS by Judge Alsup granting 156 Motion for Summary Judgment (whalc1, COURT STAFF) (Filed on 10/8/2010)

Download PDF

MShift, Inc. v. Digital Insight Corporation et al Doc. 336 1 2 3 4 5 6 IN THE UNITED STATES DISTRICT COURT 7 FOR THE NORTHERN DISTRICT OF CALIFORNIA 8 9 MSHIFT, INC., a Delaware corporation, 11 For the Northern District of California United States District Court 10 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Plaintiff, v. DIGITAL INSIGHT CORPORATION, d/b/a INTUIT FINANCIAL SERVICES, a Delaware corporation, COMMUNITY TRUST BANK, a Louisiana corporation, MOBILE MONEY VENTURES, LLC, a Delaware Limited Liability corporation, MERITRUST CREDIT UNION, a Kansas corporation, PROFESSIONAL FEDERAL CREDIT UNION, an Indiana corporation, SANFORD INSTITUTION FOR SAVINGS, a Maine corporation, FORT WORTH COMMUNITY CREDIT UNION, a Texas corporation, USE CREDIT UNION, a California corporation, GATE CITY BANK, A Minnesota corporation, BUSEY BANK, an Illinois corporation, DENSION STATE BANK, a Kansas corporation, FIDELITY BANK, a Massachusetts corporation, FIRST INTERNET BANK OF INDIANA, an Indiana corporation, and VISION BANK, a Florida corporation, CLAIM CONSTRUCTION ORDER, ORDER GRANTING DEFENDANTS’ MOTION FOR SUMMARY JUDGMENT, AND ORDER DENYING PLAINTIFF’S MOTION FOR SANCTIONS Defendants, and SK C&C CO. LTD., Defendant-Intervenor. / 26 27 No. C 10-00710 WHA AND RELATED COUNTERCLAIMS. / 28 Dockets.Justia.com 1 2 INTRODUCTION In this patent-infringement dispute involving mobile-banking technology, defendants 3 Digital Insight Corporation, Mobile Money Ventures, LLC (“MMV”), and thirteen of their bank 4 and credit-union customers move for summary judgment on plaintiff MShift, Inc.’s claim that 5 their accused mobile-banking system infringes United States Patent No. 6,950,881. Also 6 addressed herein — following a claim construction hearing and full briefing on the merits — are 7 the constructions of two claim terms relevant to the resolution of the instant motion. Finally, 8 plaintiff’s recently filed motion for Rule 37 discovery sanctions is addressed by this order. 9 This action arose out of a business relationship gone sour. Not long ago, MShift and Digital Insight were business partners providing mobile-banking products and services to 11 For the Northern District of California United States District Court 10 financial institutions across the country. MShift’s mobile-banking technology formed the 12 backbone of those services. The relationship, however, failed to last. After their partnership 13 folded, both companies went their separate ways and Digital Insight partnered with a new entity 14 — MMV — to provide the underlying technology for its mobile-banking system. MShift was not 15 pleased. With its ’881 patent in hand, MShift sued Digital Insight, its partner MMV, and thirteen 16 of their financial-institution customers. Defendants responded by giving prompt notice to both 17 MShift and the Court that they would be filing a summary judgment motion of non-infringement. 18 An intense period of discovery ensued. As explained in detail herein, defendants took 19 reasonable measures to provide MShift with a full and fair opportunity to substantiate the merits 20 of its infringement contentions. Digital Insight and MMV produced hundreds of thousands of 21 pages of technical documents (including source code) pertaining to the accused mobile-banking 22 system, many before any document requests had been made. Defendants also produced nine 23 employees for depositions. Even after full briefing on defendants’ summary judgment motion 24 had been completed, the undersigned judge granted a request by MShift for extra time to conduct 25 further discovery on the accused mobile-banking system, including two additional depositions of 26 defense witnesses. Both sides were then invited to file supplemental 20-page briefs (accompanied 27 by voluminous declarations and expert analyses) on why the accused system did or did not 28 infringe the ’881 patent. 2 1 Despite these opportunities to defeat defendants’ motion, MShift failed to rise to the 2 occasion. Following multiple hearings and a massive amount of briefing from both sides, this 3 order finds that there are no genuine issues of material fact as to whether the accused mobile- 4 banking system infringes the ’881 patent. No reasonable jury could find that it does. In so 5 holding, this order rejects MShift’s repeated attempts to distract the Court’s attention from the 6 weaknesses of its arguments (including plaintiff’s eleventh-hour Rule 37 motion for sanctions). 7 Accordingly, defendants’ motion for summary judgment of non-infringement is GRANTED. 8 Plaintiff’s motion for sanctions under Rule 37 is DENIED. 9 STATEMENT This action involves both mobile-banking and online-banking systems. Understanding 11 For the Northern District of California United States District Court 10 their differences is critical to the analysis herein. The term “mobile banking” describes products 12 and services that allow depositors to manage their bank accounts — e.g., check balances, make 13 payments to third parties, and transfer funds — using the limited screen space, bandwidth, and 14 processing power of smartphones and other mobile devices. By contrast, the term “online 15 banking” describes similar products and services optimized for use with the large displays, high- 16 speed Internet connections, and feature-rich web browsers typically found on desktop and laptop 17 computers. In other words, while online banking and mobile banking both enable depositors to 18 manage their bank accounts over the Internet, they are each specifically designed and streamlined 19 for use with different types of consumer devices. 20 Defendant Digital Insight offers its bank and credit-union customers both of these product 21 options. Specifically, every financial institution who uses Digital Insight’s online-banking system 22 has the option to sign up for its mobile-banking offerings. Plaintiff MShift also offers a suite of 23 mobile-banking products to financial institutions. The instant action, however, places the 24 spotlight squarely on MShift’s ’881 patent. This patent is described in relevant detail below. 25 1. THE ’881 PATENT 26 The ’881 patent asserted by MShift, whose application was filed in October 2000, is 27 entitled “system for converting wireless communications for a mobile device” (col. 1:1–3). As 28 explained throughout the specification and prosecution history, the ’881 patent was not directed 3 1 towards the mobile-banking industry (or any particular industry for that matter) but was instead 2 intended to address specific shortcomings in the way mobile devices could send, receive, and 3 display content at the time of the invention.1 One of these problems was a supposed “language 4 barrier” between mobile devices and so-called “network sites” that provided information and 5 content. 6 A. 7 A clear explanation of the “language barrier” at the time the patent was drafted was 8 provided by the “background of the invention” (col. 1:28–36): Typically, mobile devices are programmed to use a single language. The language use [sic] by the mobile device determines which network sites can be accessed. In some countries and geographic regions, mobile devices favor one type of language. Information providers typically structure network sites to provide content to the mobile devices using the language that is more prevalent in that geographic region. This makes it difficult for devices using other languages to have the same breadth of network access. 9 10 11 For the Northern District of California United States District Court The “Language Barrier” in Mobile Communications 12 13 14 In other words, while “network sites” could provide content to mobile devices in a variety of 15 languages, mobile devices were typically programmed to understand only a single language.2 16 To address this “language barrier” between mobile devices and certain network sites, the 17 invention claimed by the ’881 patent “enable[d] mobile devices programmed in one language to 18 access network sites structured to provide information using a second language” (col 1:39–42). 19 The invention facilitated this access by “converting” the communications between mobile devices 20 and network sites. In this connection, the specification further explained that “[e]mbodiments of 21 the invention provide a conversion engine to enable mobile devices to retrieve content from 22 network sites, where the mobile device and the network site use different languages” (col. 23 2:28–31) (emphasis added). Stated differently, the “conversion engine” claimed by the ’881 24 patent acted as a translator between mobile devices and “network sites.” 25 As explained by the specification, the “mobile devices” contemplated by the ’881 patent included “cell phones, smart phones, handheld computers and personal digital assistants (PDAs) that use wireless communications” (col. 2:47–50). 1 26 27 As used in the ’881 patent, the term “network site” meant any site on a network to which “mobile devices can couple . . . to receive information and content” (col. 1:24–27). A typical example of a “network site” is a website on the Internet (col. 4:33–36). 2 28 4 1 B. The “Conversion Engine” of the Asserted Claim 2 The conversion engine is undoubtedly the centerpiece of both the patented invention and 3 claim 20 — the sole claim of the ’881 patent being asserted. As stated, the “conversion engine” is 4 the component of the claimed invention that allows a mobile device that can only understand a 5 particular programming language to “couple” with (i.e., request and receive information and 6 content from) network sites that communicate using different programming languages. 7 8 9 The text of claim 20, the only claim asserted, is reproduced below. The terms and phrases disputed by the parties in their claim construction briefs are shown in italics (col. 14:26–52): 20. A system for exchanging communications between a mobile device and a network site, the system comprising: 11 For the Northern District of California United States District Court 10 12 a mobile device for making a request for a content from a network site, wherein the request is composed from a first language that allows multiple input entries per page, and the content from the network site is composed from a second language that allows multiple input entries per page; 13 14 15 16 17 a conversion engine that is directly linked to the mobile device to accept the request for the content from the network site, wherein the conversion engine is in communication with the network site to retrieve the content from the network site in response to receiving the request from the mobile device, the conversion engine including logic to convert the content from the second language to the first language and signaling the content to be rendered as one or more pages on the mobile device, 18 19 20 21 and wherein the conversion engine further restructures a plurality of input entries within the content into selectable links that can be rendered on the mobile device, and wherein each of the selectable links on the mobile device can be selected to generate a second request for another content from a second network site without requiring conversion of the second request by the conversion engine. 22 As shown, there are three main components in the system covered by claim 20: (1) a mobile 23 device, (2) a conversion engine, and (3) a network site. To illustrate the interplay between these 24 components, a block diagram taken directly from the ’881 patent is shown below. The three key 25 components in the asserted claim — a mobile device (“60”), a conversion engine (“50”), and a 26 network site (“30”) — are clearly labeled: 27 28 5 1 2 3 4 5 6 7 8 9 11 For the Northern District of California United States District Court 10 The four arrows shown in Figure 1 of the patent represent the flow of information between 12 these three components in an embodiment of the invention (col. 1:53–57). Understanding this 13 flow is critical to understanding MShift’s infringement allegations as well as the claim 14 construction issues discussed herein. First, as the specification explained, the mobile device 15 makes a request for content from the network site (col. 4:37–38). Since the network site and 16 mobile device communicate using different programming languages, however, they cannot 17 interface directly with each other. As such, the mobile device’s request for content (represented 18 by the arrow labeled as “1”) is first sent to the conversion engine (col. 4:45–46). Second, once 19 the conversion engine receives the request from the mobile device, it transforms the request into a 20 different programming language that is compatible with the network site. Once transformed, the 21 conversion engine then forwards the request directly to the network site (represented by the arrow 22 labeled as “2”) (col. 5:1–5). Third, in response to the request from the conversion engine, the 23 network site provides the requested content which the conversion engine then retrieves 24 (represented by the arrow labeled as “3”) (col. 5:3–6). Fourth, the conversion engine converts the 25 content retrieved from the network site “into a newly formatted content” which “is signaled to the 26 mobile device” in a programming language the mobile device can understand (represented by the 27 arrow labeled as “4”) (col. 5:6–9). In sum, these four steps demonstrate how the conversion 28 6 1 engine is used to “enable mobile devices to receive content from network sites” where they would 2 otherwise be unable to communicate with each other (see col. 1:28–31). 3 To ensure clarity, a flow diagram of this process — shown from the perspective of the 4 “conversion engine” — is reproduced below as (albeit broken down into five steps instead of 5 four). This diagram, labeled Figure 2, comes directly from the ’881 patent: 6 7 8 9 11 For the Northern District of California United States District Court 10 12 13 14 15 The invention claimed by ’881 patent, however, requires more than just language 16 conversion between mobile devices and network sites. The patented invention also contains an 17 additional limitation (among others) that is critical to the merits of MShift’s infringement 18 contentions and to claim construction. This limitation is the “restructuring” of “input entries” 19 within the content of the network site into “selectable links” by the conversion engine. 20 C. 21 Beyond acting as a translator between a mobile device and a network site, the conversion 22 engine set forth in claim 20 also “restructures a plurality of input entries within the content [from 23 the network site] into selectable links that can be rendered on the mobile device” (col. 14:35–37, 24 14:45–47). While the exact contours of this limitation depend in part upon the claim construction 25 portion of this order (in particular, the parties dispute the meaning of the claim term “input 26 entries”), the substance of this limitation is presented below. 27 28 The “Restructuring” of “Input Entries” into “Selectable Links” The three claim terms that stand out in this limitation are “restructures,” “input entries,” and “selectable links.” Starting with the agreed-upon terms first, there is no genuine dispute 7 1 between the parties that a hyperlink on a web page is a “selectable link.” This is consistent with 2 how the specification describes such “selectable links” in the context of the claimed invention 3 (col. 8:17–44). There is also no genuine dispute between the parties as to what “restructures” 4 mean. As used in the specification and the claims, and as cited by MShift in its briefs, 5 “restructure” is used synonymously with “reformat” (cols. 8:19–20, 10:40–43, 12:43–49, 6 13:49–52, 14:45–52). In context with the surrounding claim language, it simply means that 7 during the language translation process, the conversion engine reformats an “input entry” into a 8 hyperlink. Stated differently, where the source code from the network site contains instructions 9 to display an “input entry” on a page, the conversion engine replaces that source code with instructions to display a “selectable link” instead. The “selectable link” is coded to be directly 11 For the Northern District of California United States District Court 10 associated with the “input entry” it replaced (col. 8:30–34). 12 Finally, while the outer reaches of the term “input entries” are disputed, both sides — at a 13 minimum — agree that the term “input entries” as used in the ’881 patent encompasses “text- 14 entry fields, icons, check-fields assigning Boolean values, and selectable items provided in a 15 menu” (cols. 7:50–58, 8:11–13).3 In layman’s terms, an “input entry” is simply a feature on a 16 web page that allows the user to input information into the page. Examples include text boxes for 17 entering one’s first and last name, billing address, and credit-card number when making an online 18 purchase, drop-down boxes for selecting between different payment types, and date-selection 19 boxes for specifying a particular date (see col. 7:55–58). A more precise meaning of “input 20 entries” will be addressed briefly in the claim construction portion of this order. 21 The requirement that the conversion engine of the claimed invention “restructure[] a 22 plurality of input entries within the content [from the network site] into selectable links that can 23 be rendered on the mobile device” was added to the ’881 patent for two critical reasons. Both are 24 addressed below. 25 26 27 28 3 The term “input entries” is used synonymously and interchangeably with the term “input features” throughout the specification and claim language (cols. 8:17–44, 9:4–13). For example, the specification discusses the reformatting of “input features” into “HDML type links,” and then — a few sentences later — states that these HDML links correspond to “input entries” on the network site (cols. 8:19–20, 36–39). There is no dispute that the two terms are identical as used in the ’881 patent. 8 1 i. 2 The HDML Problem The technical shortcomings of mobile-device communications at the time the ’881 patent 3 was drafted (which would have been prior to the October 2000 application filing date) provide 4 one explanation for this particular limitation. The specification frequently discussed the fact that 5 mobile devices on the market at the time lacked the ability to display more than one input entry 6 on the same screen at the same time (cols. 7:41–55, 8:10–16). In particular, the specification 7 made exclusive reference to embodiments where the mobile device was limited to communicating 8 with network sites and displaying content using a language called HDML (handheld device 9 markup language). As the patent further explained (col. 7:48–53): Current versions of HDML are limited to displaying a single input feature per rendered network page. That is, when the HDML device retrieves a network page from a network site programmed in HDML, that network page can only have one text entry field, menu item, check field etc. 11 For the Northern District of California United States District Court 10 12 13 As an illustration, mobile devices that communicated in HDML were incapable of rendering a 14 simple “login page” where a user is prompted to enter a username and password. Since two text 15 entry fields (also called “text boxes” herein) would need to be displayed simultaneously to the 16 user (one for the username and one for the password), a mobile device that displayed content in 17 HDML would not be capable of properly rendering such a page. A workaround was needed. 18 The “restructuring” of input entries into “selectable links” for display on a mobile device 19 was the solution proposed by the ’881 patent. This solution was feasible because mobile devices 20 at the time the patent was drafted — including those that communicated in HDML — were not 21 limited in the number of “selectable links” that could be displayed simultaneously on a single 22 rendered web page (see col. 8:13–34). As such, the ’881 patent claimed an invention where web 23 pages containing more than a single input entry (i.e., a “plurality of input entries”) would be 24 automatically “restructured” by a conversion engine so that each “input entry” was replaced by a 25 selectable link before being rendered on a mobile device.4 Such a “restructured” web page would 26 then render properly on mobile devices using HDML or some other similarly limited language. 27 4 28 As the specification explained, “[p]referably, each HDML link is displayed with features such as wording or graphics so as to clearly indicate a wish by the user to make an entry for the input feature associated with that HDML link” (col. 8:30–34). 9 1 Of course, using these “restructured” web pages involved a cumbersome process. The 2 mobile-device user would be forced to click on each of the hyperlinks associated with an input 3 entry, one at a time. For each selected link, the conversion engine would then present the user 4 with a second web page — preferably a “virtual page” that is generated automatically by the 5 conversion engine — containing a single input entry corresponding to the hyperlink selected by 6 the user (col. 8:41–44). While an inelegant solution, this provided a functional workaround to the 7 “one input entry per screen” limitation found in mobile devices at that time (see col. 9:4–13). 8 9 ii. Overcoming the Prior Art The second reason behind the addition of the “restructuring” limitation to claim 20 is revealed in the prosecution history of the ’881 patent. As defendants emphasized repeatedly in 11 For the Northern District of California United States District Court 10 their briefs and at oral argument, the “restructuring” limitation was added to each and every claim 12 of the ’881 patent during its prosecution to overcome repeated rejections by the patent examiner 13 under 35 U.S.C. 102(e) and 103(a) (Yamashita Decl. Exhs. B–E). 14 Specifically, the patent examiner was concerned about two prior art references — the 15 Schwartz patent (U.S. Patent No. 6,473,609) and the Jamtgaard patent (U.S. Patent No. 16 6,430,624). In the examiner’s opinion, these patents anticipated and rendered obvious the 17 invention MShift was attempting to patent. According to the comments made in the “final 18 rejection” of MShift’s patent application by the USPTO, the Schwartz reference disclosed a 19 system for exchanging communications between a mobile device and a network site, where a 20 conversion engine coupled to the mobile device included logic to convert content from the 21 network site in a second language (like cHTML) into a first language (like HDML) for rendering 22 on the mobile device. In the same “final rejection” action, the patent examiner further concluded 23 that the Schwartz reference disclosed a conversion engine that “identifies one or more input 24 entries at the network site, and signals the input entries as selectable links to the mobile device.” 25 Combined with the Jamtgaard reference, which disclosed a system where a web pages were 26 automatically reformatted and translated into different languages for display on mobile devices, 27 the patent examiner soundly rejected all of the proposed claims in MShift’s patent application. 28 10 1 Undaunted, MShift amended its application and sought reconsideration from the USPTO, 2 emphasizing (among other things) that the “restructuring” of “input entries” into “selectable 3 links” for display on the mobile device and a second “directly linked” limitation rendered its 4 proposed claims allowable over the Jamtgaard and Schwartz prior art references.5 Both of these 5 limitations are found in claim 20. In making this argument to the USPTO, MShift made the 6 following representations to the patent examiner (id. at Exh. E) (emphasis added): 7 The cited Schwartz and Jamtgaard references neither disclose nor suggest the invention as presently claimed. For example, . . . Schwartz fails to describe or suggest a conversion engine that is in direct communication to a mobile device, or a conversion engine that restructures a plurality of input entries within the content into selectable links that can be rendered on the mobile device. 8 9 11 For the Northern District of California United States District Court 10 For whatever reason, the patent examiner accepted these arguments on reconsideration and 12 allowed the claims despite its earlier statements that the “restructuring” of “input entries” into 13 “selectable links” was anticipated and rendered obvious by the prior art (id. at Exh. F). One final observation about claim 20 is important. Claim 20, by its own terms, is not 14 15 restricted to mobile devices using a programming language where only “one input entry per 16 screen” is allowed. Rather, it expressly encompasses mobile devices that communicate in a 17 language that allows for multiple input entries per page.6 Nevertheless, this order emphasizes that 18 the “restructuring” of “input entries” into “selectable links” applies with equal force to claim 20, 19 as the addition of this particular limitation was necessary for MShift to overcome the prior art. THE ACCUSED MOBILE-BANKING SYSTEM 20 2. 21 Turning now to the accused mobile-banking system, defendant Digital Insight provides 22 online-banking and mobile-banking solutions to banks and credit unions nationwide. Over 1,500 23 banks and credit unions currently use Digital Insight’s online-banking product (Prior Decl. ¶ 11). 24 5 25 26 27 28 The “directly linked” limitation was not targeted by defendants’ summary judgment motion. It is therefore unnecessary to address it in this order. 6 An examination of the prosecution history reveals that claim 20 was added to the ’881 patent after the patent examiner issued a “final rejection” of MShift’s patent application. Up until that point, all of MShift’s proposed claims included the limitation that the mobile device use a language that allowed only a single input entry per page. In seeking reconsideration of the USPTO’s “final rejection” action, MShift added what eventually became claim 20. Curiously, when providing reasons for finally allowing the claims, the patent examiner lumped the new claim with MShift’s other proposed claims and never addressed this key difference. 11 1 A subset of these online-banking clients also use the accused mobile-banking system, which both 2 sides call the “DI/MMV system.” 3 A. Online Banking vs. Mobile Banking 4 Online-banking and mobile-banking systems both provide depositors with the means to 5 manage their bank accounts over the Internet, but only online-banking services are specially 6 optimized for the large displays, high-speed Internet connections, and feature-rich web browsers 7 typically found in desktop and laptop computers. This order will refer to the particular online- 8 banking websites provided by Digital Insight to its customers as “DI online-banking websites.” 9 DI online-banking websites are accessible to bank depositors — just like any other website — by simply entering the proper URL (i.e., website address) into a web browser on a computer with 11 For the Northern District of California United States District Court 10 Internet access. 12 In contrast to online-banking services, mobile-banking services are specially designed to 13 be used with smartphones and other mobile devices that have much smaller screen displays, 14 slower Internet connections, and — in some cases — more limited web-browsing capabilities. 15 When referenced herein, the particular mobile-banking websites provided by Digital Insight (in 16 partnership with MMV) to its financial-institution customers will be called “MMV mobile- 17 banking websites.” Like their larger online-banking counterparts, these MMV mobile-banking 18 websites are accessible to bank depositors by simply entering the proper URL into a HTML- 19 compatible web browser on a smartphone or other mobile device with Internet access. 20 Two important points must be remembered with respect to DI online-banking websites 21 and MMV mobile-banking websites. First, while MMV mobile-banking websites are optimized 22 for use with a mobile device, there is nothing preventing a depositor from accessing an MMV 23 mobile-banking website using a desktop or laptop computer. Conversely, there is nothing — 24 except perhaps automatic redirection scripts — preventing a depositor from browsing to a DI 25 online-banking website using a mobile device.7 At their core, both are simply websites on the 26 27 28 7 A automatic redirection script works as follows: if a depositor only knows the URL for his financial institution’s DI online-banking website and attempts to navigate there using a mobile device, the DI onlinebanking website will — in most instances — automatically “redirect” the depositor to the financial institution’s MMV mobile-banking website (Moeller Decl. ¶¶ 16–17). This is because the DI online-banking website is 12 1 Internet. Both can therefore be accessed using any HTML-compatible web browser. Second, and 2 implied by the prior point, MMV mobile-banking websites and DI online-banking websites have 3 completely different URLs and are hosted on entirely different web servers (Choi Dep. 242–43; 4 Buckner Decl. ¶¶ 3–17). 5 To illustrate these differences, shown below are the online-banking and mobile-banking 6 websites for USE Credit Union, one of Digital Insight’s many customers. The “home page” for 7 USE Credit Union’s DI online-banking website (as accessed from a desktop computer) is shown 8 on the left, while the “home page” for USE Credit Union’s MMV mobile-banking website (as 9 accessed from a smartphone) is shown on the right (Buckner Decl. ¶¶ 7, 9): 11 For the Northern District of California United States District Court 10 12 13 14 15 16 17 18 19 20 21 URL: https://www.usecu.org/home/home URL: https://m.diginsite.com/usecu/ 22 As these screenshots demonstrate, the content displayed on a DI online-banking website makes 23 full use of a large amount of screen space and — with the inclusion of numerous graphics — fast 24 download speeds. By contrast, the content on an MMV mobile-banking website is streamlined 25 for efficiency on a much smaller screen, and much slower download speeds. 26 27 28 programmed to “detect” whether a mobile device is being used to access it. 13 1 B. The “Bill Pay/Make a Payment” Feature 2 Using either a DI online-banking website or an MMV mobile-banking website, depositors 3 can perform various account-related activities such as viewing their account balances, making 4 payments to third parties, and transferring funds. Both sides have focused their attention on only 5 one of these features throughout this litigation: the “Bill Pay/Make a Payment” feature. It is on 6 this particular feature of the accused system that this order will focus as well. 7 8 Shown below is a screenshot from the “Bill Pay/Make a Payment” web page as accessed through USE Credit Union’s DI online-banking website (Moeller Decl. ¶ 14, Exh. 10): 9 11 For the Northern District of California United States District Court 10 12 13 14 15 16 17 18 19 20 21 22 23 24 While the graphics, colors, and logos may differ between DI online-banking websites for Digital 25 Insight’s various financial-institution customers, the screenshot shown above accurately reflects 26 how the “Bill Pay/Make a Payment” web page is formatted for all of Digital Insight’s online- 27 banking customers. 28 14 1 As shown in the screenshot, the DI online-banking website’s “Bill Pay/Make a Payment” 2 web page is content-rich. There is a list of numerous payees on the left portion of the page and 3 pending and processed payments on the right portion of the page. The web page also contains 4 multiple text boxes, date-selection boxes, and buttons. On this page, a depositor can specify a 5 payment amount and date for any of the payees listed and make a payment to that payee. 6 By contrast, the “Bill Pay/Make a Payment” web page found on USE Credit Union’s 7 MMV mobile-banking website has a much simpler interface. As shown below, a simple list of 8 “payees” is first displayed to the depositor (left). The name of each payee is displayed as a 9 selectable link. When a depositor selects one of the payees in the list (e.g., “Andrew Valentine” as seen below), the depositor is taken to a second web page where a payment amount and date can 11 For the Northern District of California United States District Court 10 be specified (right) (Dkt. No. 87 at 61, 63; Buckner Dep. 118–20, 164–66): 12 13 * The screenshots shown herein of the accused DI/MMV system do not display actual banking or account information of depositors. 14 15 16 17 18 19 20 21 Whether a depositor uses his or her financial institution’s DI online-banking website or an MMV 22 mobile-banking website to make a payment, the result is the same: the depositor’s bank or credit 23 union will make the payment to the designated payee on the specified date. 24 C. How the Accused DI/MMV System “Works” 25 According to MShift, the accused DI/MMV system — which operates all of the MMV 26 mobile-banking websites offered by Digital Insight to its clients — infringes claim 20 of the ’881 27 patent. Defendants, of course, contend exactly the opposite. To resolve this dispute, the inner- 28 workings of the DI/MMV system must be examined. 15 1 In a nutshell, the DI/MMV system works as follows: First, a depositor enters the URL of 2 the MMV mobile-banking website for his financial institution into a HTML-compatible web 3 browser, which triggers a HTTP request to be sent to the MMV mobile-banking website. The 4 DI/MMV system responds to this request by displaying the “home page” of the MMV mobile- 5 banking website as shown earlier in this order, not the DI online-banking website. Once the 6 depositor provides his username and password to access his account, he is presented with various 7 account management options, including a “Bill Pay/Make a Payment” option. As stated, since 8 both sides focus exclusively on this particular feature of the accused system, this order will also 9 focus solely on this feature. Second, assuming that the depositor selects the “Bill Pay/Make a Payment” link on the 11 For the Northern District of California United States District Court 10 MMV mobile-banking website, another HTTP request is immediately sent from depositor’s web 12 browser to the DI/MMV system to display the MMV mobile-banking website’s “Bill Pay/Make a 13 Payment” web page. After receiving this request, the DI/MMV system begins the process of 14 retrieving the necessary account data for that particular depositor to display on the “Bill 15 Pay/Make a Payment” web page. Specifically, the DI/MMV system must retrieve a list of payees 16 associated with the depositor’s bank account(s), the last amount paid to each payee, and the date 17 that each payee was last paid. To retrieve this information, the DI/MMV system uses a process 18 called “screen scraping” to extract this data from the financial institution’s DI online-banking 19 website (Buckner Decl. ¶ 19; Otteson Decl. Exhs. 10–13; Choi Dep. 75, 103–04; Lee Dep. 54). 20 In carrying out this process, the DI/MMV retrieves one or more web pages from the DI online- 21 banking website to extract the data that it needs.8 22 Third, after the DI/MMV system has “screen scraped” the data it needs from the financial 23 institution’s DI online-banking website, it repackages the information into an intermediary format 24 and then integrates the data into pre-programmed web-page templates called “style sheets.” Style 25 sheets are used to format the “Bill Pay/Make a Payment” web page for display on the particular 26 27 28 8 The reliance of the accused DI/MMV system on “screen scraping” to obtain this account-specific data is central to MShift’s infringement contentions. MMV mobile-banking websites essentially piggyback off of their corresponding DI online-banking websites. In other words, there is no centralized database from which both DI online-banking websites and MMV mobile-banking websites independently retrieve data. Rather, MMV mobile-banking websites use their corresponding DI online-banking websites as “virtual databases.” 16 1 mobile device being used by the depositor (Buckner Decl. ¶ 19, Exhs. 9, 10, 14; Choi Dep. 33–34, 2 90–91, 191–94, 197–99). This particular step bears repeating. Once the DI/MMV system has 3 “screen scraped” the list of payees, last payment amounts, and last payment dates from the 4 financial institution’s DI online-banking website, the data is integrated into MMV mobile- 5 banking website templates that have been pre-designed. In other words, the placement of every 6 link, button, and text box on an MMV mobile-banking website has been preordained — these 7 web-page features are not derivative of features on a DI online-banking website. 8 9 Fourth, once the depositor’s account-specific data has been integrated into the “Bill Pay/Make a Payment” style sheet for the MMV mobile-banking website, the DI/MMV system sends the web page to the depositor’s mobile device in HTML format. 11 For the Northern District of California United States District Court 10 A flow chart summarizing this process is shown below: 12 13 14 15 16 17 18 MMV MobileBanking Website “Bill Pay/Make a Payment” Page º STEP 1. A depositor browses to the “Bill Pay/Make a Payment” web page on an MMV mobile-banking website using a mobile device. The DI/MMV system receives the request from the mobile device. º DI/MMV System STEP 2. The DI/MMV system begins “screen scraping” the DI onlinebanking website for the depositor’s financial institution to extract the payee names and last payment information for the depositor. 19 20 21 22 23 24 25 26 STEP 4. Once all the data has been integrated into the “Bill Pay/Make a Payment” style sheet, the web page is sent to the depositor’s mobile device in HTML format and loads as depicted in the smartphone on the left. STEP 3. Once the “screen scraping” process is complete, the DI/MMV system integrates the payee data into a predesigned template for the MMV mobile-banking website’s “Bill Pay/Make a Payment” web page. » » 27 28 17 DI Online-Banking Website “Bill Pay/Make a Payment” Page 1 As this process makes clear, when a depositor browses to the “Bill Pay/Make a Payment” 2 web page on an MMV mobile-banking website, all of the account and transaction information 3 displayed to the depositor has been extracted by the DI/MMV system from the financial 4 institution’s DI online-banking website. For this reason, the MMV mobile-banking website for 5 any particular bank or credit union will not work properly if the financial institution’s DI online- 6 banking website is inaccessible or otherwise “offline” (Buckner Dep. 135). 7 D. 8 According to MShift, the mobile-banking system described above infringes claim 20. 9 MShift’s Infringement Contentions Specifically, MShift alleges that when a depositor uses his mobile device to browse the MMV mobile-banking website of his bank or credit union, the mobile device is actually “making a 11 For the Northern District of California United States District Court 10 request for a content from a network site.” Under this theory of infringement, the “network site” 12 is not the MMV mobile-banking website, but the corresponding DI online-banking website of the 13 depositor’s bank or credit union. This asserts that the DI/MMV system described above serves as 14 the “conversion engine.” 15 Given this backdrop, MShift alleges — as it must to prove infringement — that the 16 DI/MMV system serves as a “language translator” between mobile devices and DI online-banking 17 websites. In other words, MShift contends that mobile devices accessing MMV mobile-banking 18 websites are receiving content in an entirely different language than the content provided directly 19 by DI online-banking websites, and the DI/MMV system — the “conversion engine” herein — is 20 what enables these mobile devices to communicate with DI online-banking websites. 21 Additionally, MShift argues that the DI/MMV system “restructures” a plurality of “input entries” 22 within the content provided by DI online-banking websites into “selectable links” for display on 23 these mobile devices. 24 As discussed below, the undisputed factual record and a proper construction of the 25 relevant claim language defeat MShift’s allegations. 26 . 27 28 3. PROCEDURAL HISTORY MShift filed this action in February 2010, originally naming Digital Insight and two of its financial-institution customers as defendants (Dkt. No. 1). Shortly thereafter, MShift was allowed 18 1 to file an amended complaint naming MMV and eleven additional Digital Insight financial- 2 institution customers as defendants (Dkt. No. 86). During this process, one of the developers of 3 the accused DI/MMV system — a Korean company named SK C&C Co. Ltd. — moved for and 4 was granted leave to intervene as a defendant (Dkt. No. 118). 5 Defense counsel provided ample notice that they intended to file the instant summary 6 judgment motion. This intention was communicated to MShift as early as the Rule 26(f) 7 conference held on April 21, 2010, and was repeated again in the joint case management 8 statement filed on May 6 (Valentine Decl. ¶ 3; Dkt. No. 54). Beginning on May 7, before 9 receiving any document requests from MShift, defense counsel began producing technical documents and source code pertaining to the accused DI/MMV system (Valentine Decl. ¶ 4). 11 For the Northern District of California United States District Court 10 During the case management conference held before the undersigned judge on May 13, 12 defendants again voiced their intention of filing an early summary judgment motion on non- 13 infringement grounds. In discussing this prospect with all counsel, the undersigned judge stated 14 (Long Decl. Exh. A at 9–10): 15 16 17 18 19 Well, I will tell you what I did when I was in practice and I was in your position . . . I wrote a clear-cut fair letter to the other side. I said, we want to move for summary judgment, we are going to move on the following very clear-cut grounds. We will make our witnesses available for you to depose starting tomorrow. I’m an open book. And I say, we’ll give you a reasonable time to do this. If you don’t do it, we’re going to make our motion. But don’t claim 56(f) when we make the motion. 20 At the same case management conference, the undersigned judge also provided fair warning to 21 counsel for MShift that if defense counsel “made it very clear” that they “will produce everyone . 22 . . that could reasonably have anything to do with the grounds on which [defendants] are going to 23 move,” then a summary judgment motion would not ordinarily be premature (id. at 11). 24 On May 21, defense counsel provided MShift with a detailed outline of every argument 25 they intended to raise in their summary judgment motion. The same communication also offered 26 to make “DI and MMV technical witnesses . . . and 30(b)(6) witnesses available for deposition 27 immediately” (Valentine Decl. ¶ 5, Exh. A) (emphasis in original). Defense counsel also told 28 MShift that “[f]or any witness [MShift] depose[s] in May or June 2010, [defendants] will agree to 19 1 make that witness available for a second deposition at a later date.” This offer was intended to 2 allow MShift to “develop an understanding of the DI and MMV technology relatively quickly 3 without feeling any need to save [its] ‘one shot’ with a witness until a later stage of discovery” 4 (ibid.). Defendants then notified MShift that the instant motion would be filed on or before July 5 8, with a hearing noticed for August 12. 6 On June 4, immediately after receiving MShift’s infringement contentions, defendants infringement arguments (id. at ¶ 6). That same day, MShift served a set of interrogatories on 9 Digital Insight, requesting full disclosure of the basis of defendants’ non-infringement position. 10 Defendants responded to the request two days later (id. at ¶ 7, Exh. B). MShift then served its 11 For the Northern District of California supplemented their May 21 disclosures with an even more detailed outline of their non- 8 United States District Court 7 amended infringement contentions on June 15. In response, on June 18, defendants sent another 12 letter to plaintiff identifying an additional argument of non-infringement as well as their views on 13 the particular claim construction issues relevant to the instant motion (id. at ¶ 8, Exh. C). Also on 14 June 18, MShift served a second set of document production requests on Digital Insight, seeking 15 essentially all technical documents and communications concerning the design, development, use, 16 and testing of the DI/MMV system. After meeting and conferring with plaintiff’s counsel, 17 defense counsel agreed to produce responsive documents and communications from eleven 18 different custodians. Additionally, defendant MMV, to whom no document requests were 19 directed, voluntarily agreed to produce responsive documents and communications from three 20 different custodians (id. at ¶ 9). In addition to these document productions, both Digital Insight 21 and MMV produced the source code for two of the financial institution defendants as requested 22 by MShift (id. at ¶¶ 10–11). 23 With respect to defendant-intervenor SK C&C, even before it moved to intervene in this 24 action, seven of its design and development documents as well as over 700 email communications 25 between MMV and SK C&C spanning the entire development period for the accused mobile- 26 banking system were produced by MMV (id. at ¶¶ 12–13). In total, defendants produced 27 approximately 186,000 pages of responsive technical documents to MShift between May 7 and 28 July 23. Additionally, between June 28 and July 10, defendants produced (and MShift deposed) 20 1 seven technical witnesses with knowledge relating to the design and functionality of the accused 2 DI/MMV system (id. at ¶ 14). 3 In mid-July, after defendants’ opening brief had already been filed, MShift asked 4 defendants for a three-week extension to file its opposition brief to the instant motion for 5 summary judgment. In its request, plaintiff cited the need for additional discovery of technical 6 documents from defendant-intervenor SK C&C. In response, defendants agreed to provide 7 plaintiff with a fifteen-day extension — giving MShift a total of five weeks to prepare its 8 opposition brief — and also agreed to produce the requested SK C&C documents immediately. 9 Defendants further agreed to make available two deponents from SK C&C the very next day for depositions in California (id. at ¶ 18, Exh. D). In arranging this deal, both sides agreed to the 11 For the Northern District of California United States District Court 10 following caveat (ibid.): 12 In exchange for these significant concessions, and assuming SK C&C provides the information we have identified above, MShift will agree to respond to the Defendants’ motion for summary judgment on the merits and will not assert a Rule 56(f) objection. 13 14 15 Despite this agreement between the parties, on August 6, the same day that MShift filed its 16 opposition brief to the instant motion, MShift also filed a Rule 56(f) motion citing the need for 17 additional discovery from defendant-intervenor SK C&C on the technical details of the accused 18 DI/MMV system. 19 A hearing on the instant motion was held on September 2. At the hearing, the undersigned 20 judge probed MShift’s counsel on their infringement theories — in particular, whether the 21 DI/MMV system “restructured” any “input entries” into “selectable links.” Nevertheless, in an 22 abundance of caution, defendant-intervenor SK C&C was ordered to search through its 23 documents again to ensure that all responsive documents to any reasonable discovery request had 24 been produced. MShift was also granted two additional depositions of SK C&C employees with 25 knowledge of the accused mobile-banking system and SK C&C’s production of relevant technical 26 documents. Following this extended discovery period, both sides were allowed to submit lengthy 27 supplemental briefs to bolster their respective positions. All parties took full advantage of this 28 opportunity. 21 1 Three days after these supplemental briefs were filed, MShift moved for monetary and 2 discovery sanctions against defendants pursuant to FRCP 37. According to MShift, defendants 3 had taken every opportunity to “hide the ball” with respect to producing information necessary 4 for plaintiff to defend against the instant motion. Specifically, the motion contends that 5 defendants failed to identify in their initial disclosures the names of certain SK C&C engineers 6 with knowledge of the accused system, and were “deliberately evasive” about the role that a 7 Nepalese company named FocusOne played in the development of the accused system. Despite 8 these accusations of discovery misconduct, however, MShift readily admitted throughout its Rule 9 37 motion that it “was finally able to piece together enough evidence to prove that defendants have an infringing ‘conversion engine’” (Sanctions Mot. at 3, 12, and 17; Reply to Sanctions Mot. 11 For the Northern District of California United States District Court 10 at 8). In other words, despite allegedly improper tactics by defendants, MShift believed that it 12 had received all the discovery necessary to defeat the instant motion on the merits. 13 Finally, while all these events unfolded, the parties completed their briefing on claim 14 construction issues. A technology tutorial was held on September 22, followed by a claim 15 construction hearing on September 30. This order follows and is based upon all of the filings and 16 hearings mentioned herein. 17 18 ANALYSIS Summary judgment is proper when the “pleadings, depositions, answers to interrogatories, 19 and admissions on file, together with the affidavits, show that there is no genuine issue as to any 20 material fact and that the moving party is entitled to judgment as a matter of law.” FRCP 56(c). 21 An issue is “genuine” only if there is sufficient evidence for a reasonable fact-finder to find for 22 the non-moving party, and “material” only if the fact may affect the outcome of the case. 23 Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 248–49 (1986). All reasonable inferences, 24 however, must be drawn in the light most favorable to the non-moving party. Olsen v. Idaho 25 State Bd. of Med., 363 F.3d 916, 922 (9th Cir. 2004). That said, unsupported conjecture or 26 conclusory statements are insufficient to defeat summary judgment. Surrell v. Cal. Water Serv. 27 Co., 518 F.3d 1097, 1103 (9th Cir. 2008). 28 22 1 These standards apply equally to summary judgment motions involving patent 2 infringement claims. See Union Carbide Corp. v. American Can Co., 724 F.2d 1567, 1571 (Fed. 3 Cir. 1984). To survive a motion for summary judgment of non-infringement, a patentee must set 4 forth competent evidence that “features of the accused product would support a finding of 5 infringement under the claim construction adopted by the court, with all reasonable inferences 6 drawn in favor of the non-movant.” Intellectual Science and Technology, Inc. v. Sony 7 Electronics, Inc., 589 F.3d 1179, 1183 (Fed. Cir. 2009) (citing Arthur A. Collins, Inc. v. N. 8 Telecom Ltd., 216 F.3d 1042, 1047–48 (Fed. Cir. 2000)). If expert testimony is provided by the 9 patentee in an attempt to defeat summary judgment, the testimony proffered must be supported by sufficient facts and be reasonable in light of the undisputed factual record. See Brooke Group 11 For the Northern District of California United States District Court 10 Ltd. v. Brown & Williamson Tobacco Corp., 509 U.S. 209, 242 (1993). Unsupported conclusions 12 on the ultimate issue of infringement will not alone create a genuine issue of material fact for 13 trial. Arthur A. Collins, 216 F.3d at 1046. 14 Defendants’ motion for summary judgment of non-infringement focuses on two 15 limitations set forth in claim 20: (1) the requirement of a “first language” and “second language,” 16 and (2) the “conversion engine” that “restructures a plurality of input entries within the content” 17 of the network site “into selectable links” on the mobile device. Before these limitations can be 18 addressed, however, this order must first resolve relevant issues regarding claim construction. 19 1. 20 The parties’ claim construction briefs focus on four disputed terms and phrases in claim CLAIM CONSTRUCTION 21 20 of the ’881 patent: (1) “language,” (2) “input entries,” (3) “directly linked,” and (4) “signaling 22 the content to be rendered as one or more pages.” Only the first two terms are relevant to the 23 resolution of defendants’ summary judgment motion. This order does not need to reach the 24 remaining terms and phrases. 25 A. “Language” 26 The dispute over this claim term is admittedly narrow. Both sides agree that the term 27 “language” as used in claim 20 of the ’881 patent refers to a programming language. Indeed, the 28 intrinsic evidence is clear on this point (see, e.g., cols 1:28–36, 2:52–58, 2:65–3:21, 3:42–45). 23 1 Where the parties disagree is whether any further limitations apply. Specifically, plaintiff 2 proposes that “language” be construed as “programming that is operable on a network site or a 3 mobile device; examples of languages include HTML, CHTML, wireless markup language 4 (WML), and HDML.” Defendants, by contrast, argue that the “plain and ordinary meaning” of 5 “language” as used throughout the ’881 patent should apply. According to defendants, this means 6 that a language must “couple network sites and mobile devices,” “allow either a single or multiple 7 input entries per page,” and be limited to “markup languages.” Additionally, defendants assert 8 that a language must “determine which network sites can be accessed” by mobile devices. 9 Courts must determine the meaning of disputed claim terms from the perspective of one of ordinary skill in the pertinent art at the time the patent was filed. Chamberlain Group, Inc. v. 11 For the Northern District of California United States District Court 10 Lear Corp., 516 F.3d 1331, 1335 (Fed. Cir. 2008). While claim terms “are generally given their 12 ordinary and customary meaning,” the “claims themselves provide substantial guidance as to the 13 meaning of particular claim terms.” Phillips v. AWH Corp., 415 F.3d 1303, 1312, 1314 (Fed. Cir. 14 2005) (en banc) (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 15 1996)). The specification of a patent is also highly relevant to claim construction. Indeed, claims 16 “must be read in view of the specification, of which they are a part.” Markman v. Westview 17 Instruments, Inc., 52 F.3d 967, 979 (Fed.Cir.1995) (en banc), aff'd, 517 U.S. 370 (1996). Finally, 18 courts should give due consideration to a patent’s prosecution history, which “can inform the 19 meaning of the claim language by demonstrating how the inventor understood the invention and 20 whether the inventor limited the invention in the course of prosecution, making the claim scope 21 narrower than it would otherwise be.” Phillips, 415 F.3d at 1318 (citations omitted). These 22 components of the intrinsic record are the primary resources in properly construing claim terms. 23 Id. at 1317–18. 24 As stated, the term “language” as used in claim 20 is undoubtedly a programming 25 language. Indeed, the specification provided an express, if not lexicographic, definition of this 26 term as used in the ’881 patent (col. 3:42–45): 27 28 As used herein, languages refers to programming used to coupling [sic] network sites and mobile devices. Examples of languages include HTML, CHTML, wireless markup language (WML), and HDML. 24 1 This straightforward construction — that a language is “programming used to couple network 2 sites and mobile devices” — is all that is necessary to properly construe this term. 3 The additional limitations and clarifications proposed by the parties are unnecessary in 4 light of the use of “language” in claim 20. First, it is implied from the adopted construction that a 5 “first language” (as used in claim 20) is operable on a mobile device and a “second language” (as 6 used in claim 20) is operable on a network site. Second, the surrounding text in claim 20 makes 7 clear that both the “first language” and “second language” must allow “multiple input entries per 8 page.” Since these limitations are set forth expressly in the claim language, it is unnecessary to 9 incorporate them into the construction of “language.” Third, while it is true — as defendants point out — that only markup languages were provided as examples of “languages” by the 11 For the Northern District of California United States District Court 10 specification, it would be improper to read such a limitation into the claims.9 See 12 Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 904–05 (Fed. Cir. 2004). Fourth, it is 13 implied from the adopted construction and the intrinsic evidence that the “language” used by a 14 particular mobile device determines which network sites it can access (see col. 1:29–30). 15 In sum, this order construes “language” as “programming used to couple network sites and 16 mobile devices” — exactly as the specification defined it and consistent with its usage throughout 17 the claim language and intrinsic evidence. Any other limitations mentioned above are either 18 implied by this construction, implied by the context of its use in claim 20, or expressly set forth 19 within the asserted claim as separate limitations. 20 B. “Input Entries” 21 The term “input entries” as found in claim 20 presents a more contentious dispute. 22 Defendants propose that “input entries” be construed as “[f]eatures that allow a user to enter 23 information into a page, such as text entry fields, icons, menu items, and check-fields.” MShift, 24 by contrast, proposes that “input entries” be more broadly construed as “[f]eatures that allow a 25 user to provide input.” As its briefing makes clear, plaintiff intends its proposed construction to 26 27 9 28 Of course, the fact that claim 20 requires “language[s] that allow[] multiple input entries per page” may restrict the programming languages that can satisfy this limitation to so-called markup languages. This, however, does not mean that such a limitation should be read into the construction of “language.” 25 1 encompass descriptive labels that accompany text entry fields as well as hidden data not even 2 displayed to depositors on a web page. 3 As a preliminary matter, both sides agree that the features encompassed by defendants’ 4 proposed construction — namely, features that “allow a user to enter information into a page, 5 such as text entry fields, icons, menu items, and check-fields” — are “input entries” within the 6 meaning of the ’881 patent. Indeed, the specification expressly lists “text-entry fields, icons, 7 check-fields assigning Boolean values, and selectable items provided in a menu” as specific 8 examples of “input features” (col. 8:11–13). In this connection, both sides also agree that the 9 terms “input features” and “input entries” as used throughout the ’881 patent are synonymous with each other. This is because the two terms are used interchangeably throughout the 11 For the Northern District of California United States District Court 10 specification and even within in certain patent claims (e.g., claim 13). 12 Where the parties diverge, however, is on whether “input entries” can extend beyond 13 “features that allow a user to enter information into a page” to labels and hidden form elements 14 that are never displayed on a web page. As explained below, the intrinsic evidence does not 15 support such a broad construction. First, the ordinary and customary meaning of the term “input 16 entries” to a person having ordinary skill in the relevant art supports defendants’ narrower 17 construction. Indeed, MShift’s own expert, Dr. Sandeep Chatterjee, who is proffered by plaintiff 18 as being someone with ordinary skill in the relevant art, conceded in his declaration that 19 “defendants’ proposed construction [of ‘input entries’] provides more detail and clarity [than 20 plaintiff’s proposed construction], which is consistent with and supported by the patent” 21 (Chatterjee Claim Const. Decl. ¶ 27). Dr. Chatterjee no doubt recognized that plaintiff’s 22 proposed construction lacked sufficient detail and clarity and could be used to improperly cover 23 web page features that did not allow a user to enter information into a page. 24 Second, plaintiff’s proposed construction would improperly cover features that the 25 specification clearly indicated were not “input entries.” As stated, the specification made 26 frequent reference to mobile devices that used HDML to request and receive content from 27 network sites. In this connection, the specification expressly recognized that HDML was “limited 28 to displaying a single input feature per rendered network page” (col. 7:48–53) (emphasis added). 26 1 Displaying multiple selectable links on the same page, however, was clearly not a problem for 2 HDML-based mobile devices. This can be concluded because the restructuring of a plurality of 3 input entries into multiple selectable links was exactly the workaround proposed by the ’881 4 patent to bypass the “single input feature” problem. As such, “selectable links” are clearly not 5 “input features” or “input entries” within the meaning of the ’881 patent. The specification also 6 made clear that the physical buttons on a mobile device and “wording or graphics” on a web page 7 were not “input entries” (see cols. 4:5–10, 8:30–34). Plaintiff’s proposed construction, however, 8 could easily be used to cover “selectable links,” “wording or graphics,” and the physical buttons 9 on a mobile device due to its overly broad wording. This would be improper. By contrast, defendants’ proposed construction more closely tracks what the term “input entries” was intended 11 For the Northern District of California United States District Court 10 to cover in light of the intrinsic evidence: features displayed on a web page, like text entry fields, 12 menu items, and check fields, that allow a user to enter information into the page (see col. 13 7:50–58). 14 Third, the prosecution history — and in particular, MShift’s representations to the USPTO 15 to distinguish the claims of the ’881 patent from the prior art — provides the final nail in the 16 coffin for plaintiff’s proposed construction. To allow MShift to expand the meaning of “input 17 entries” beyond its HDML (or equivalent) context would enable plaintiff to recapture territory 18 that it surrendered during the course of prosecuting the asserted patent. As stated, the Schwartz 19 and Jamtgaard references disclosed the use of a conversion engine between mobile devices and 20 network sites to reformat web pages, translate between different programming languages, and 21 “break up” content into multiple pages using selectable links (see Yamashita Claim Const. Decl. 22 Exhs. 1, 3).10 After the USPTO repeatedly rejected its patent application due to these prior art 23 references, MShift finally obtained the ’881 patent by arguing to the patent examiner that the 24 Schwartz and Jamtgaard references did not teach the particular “restructuring” of “input entries” 25 — necessitated by the inherent limitations of HDML — as set forth in the claims. To allow 26 27 28 10 Specifically, the USPTO recognized that Schwartz disclosed a conversion engine capable of translating between different programming languages (see Yamashita Claim Const. Decl. Exh. 6, col. 8:55–67), while Jamtgaard disclosed a system that could reformat Internet content for mobile devices by breaking the content into pieces and using selectable links to navigate between them (id. at Exh. 5, col. 18:23–39). 27 1 MShift to now expand the meaning of “input entries” to encompass mere labels and other web- 2 page features that do not allow a user to input information into the page would be improper in 3 light of this history. See Phillips, 415 F.3d at 1318 (citations omitted). 4 For these reasons, this order construes “input entries” as “features displayed on a web 5 page that allow a user to enter information into the page, like text entry fields, menu items, and 6 check fields.” 7 2. 8 Turning now to the merits of defendants’ motion for summary judgment, two independent 9 arguments are presented by defendants as to why the accused DI/MMV system does not infringe. Both are compelling. 11 For the Northern District of California United States District Court 10 NON-INFRINGEMENT OF THE ’881 PATENT A. 12 Defendants’ first non-infringement argument targets the “first language” and “second The “First Language” and “Second Language” Limitation 13 language” limitation found in claim 20. According to defendants, this limitation is not met by the 14 accused DI/MMV system. The relevant claim language is set forth below (col. 14:28–34) 15 (emphases added): 16 17 18 19 20 21 22 23 a mobile device for making a request for a content from a network site, wherein the request is composed from a first language that allows multiple input entries per page, and the content from the network site is composed from a second language that allows multiple input entries per page a conversion engine that is directly linked to the mobile device to accept the request for the content from the network site, wherein the conversion engine is in communication with the network site to retrieve the content from the network site in response to receiving the request from the mobile device, the conversion engine including logic to convert the content from the second language to the first language and signaling the content to be rendered as one or more pages on the mobile device 24 As stated, a “language” is “programming used to couple network sites and mobile devices.” As 25 used in claim 20, both sides agree that a “first language” refers to the programming language used 26 by a mobile device to request and receive content from network sites, and a “second language” 27 refers to the programming language used by a network site to send and receive content. Both 28 sides also agree that the “first language” and “second language” must be different programming 28 1 languages (Br. 12–14; Opp. 9–16). This, of course, is supported by a plain reading of claim 20 in 2 light of the specification — there would be no need for a “conversion engine” to “convert the 3 content from the second language to the first language” if both the mobile device and the network 4 site communicated in the same language (col. 14:40–42). 5 Given this backdrop, defendants contend that both the mobile devices and DI online- the same language: HTML (Br. 12–14). Moreover, even if MShift’s argument that the DI online- 8 banking websites provide content in XHTML 1.0 (rather than HTML) is credited, defendants 9 contend that XHTML 1.0 and HTML do not satisfy the “first language” and “second language” 10 limitation of claim 20 because they are both entirely compatible with HTML browsers. Both of 11 For the Northern District of California banking websites (i.e., the “network sites”) in the accused DI/MMV system communicate using 7 United States District Court 6 these points are addressed below. 12 13 i. The DI/MMV System Communicates with Mobile Devices in HTML. According to defendants, there is no genuine dispute over whether the DI/MMV system 14 communicates with mobile devices in HTML, and only HTML. To support this contention, 15 defendants point to a number of items of evidence, including the very same technical schematic of 16 the DI/MMV system relied upon by MShift in its opposition brief. This schematic of the accused 17 system shows that HTML is programming language outputted to mobile browsers by the accused 18 system (Opp. 7; Otteson Decl. Exh. 13). Additionally, defendants point to the underlying source 19 code and deposition testimony from multiple technical witnesses showing that the DI/MMV 20 system — while perhaps capable of outputting content in other formats — only outputs HTML to 21 mobile devices (see, e.g., Buckner Decl. ¶ 31, Exh. 4; Buckner Dep. 110; Potel Decl. ¶¶ 48–51; J. 22 Choi Dep. 87–88, 91, 195, 239; Lee Dep. 58–61, 86, 137; Kang Dep. 60, 155). This evidence all 23 supports the conclusion that the accused system only outputs HTML to mobile devices. 24 MShift’s “evidence” rebutting this point fails to create a genuine issue of fact on this 25 topic. Specifically, MShift points to a cherry-picked selection of style sheets (among a large 26 number of style sheets) that were stored in a digital folder produced by defendants during 27 discovery that — if actually used by the accused system — would supposedly output content to 28 mobile phones in non-HTML languages such as WML, HDML, XHTML, XML, and WAP (see 29 1 Chatterjee Suppl. Decl. ¶¶ 28–57; Chatterjee Decl. ¶¶ 43–44, 65–70, 73). The problem is, there is 2 no evidence that these particular style sheets were ever used by the accused system. Indeed, when 3 specifically asked at their depositions whether the DI/MMV system made use of these particular 4 style sheets or outputted content to mobile devices in non-HTML languages, all technical 5 witnesses said “no” (see Lee Dep. 61, 86, 137; J. Choi Dep. 239; Kang Dep. 60, 155; see also 6 Buckner Decl. ¶¶ 31–32; Potel Decl. ¶¶ 48, 50).11 The reason for this is simple: the DI/MMV 7 system was not designed to be used by older phones that lacked HTML-browsing capabilities. 8 The only evidence MShift cites to support its contention that these non-HTML style sheets “confirmed” that these style sheets were being used by the accused system (see, e.g., Chatterjee 11 For the Northern District of California were ever used by the DI/MMV system is its assertion that defendants’ counsel, Wayne Helge, 10 United States District Court 9 Suppl. Decl. ¶¶ 40, 44, 48, 52). Contrary to MShift’s assertion, however, Attorney Helge never 12 “confirmed” anything of the sort. In fact, the deposition transcript cited by MShift to support this 13 argument says nothing about these particular style sheets being used by the accused system (see 14 S. Choi Dep. 30–31). Rather, Attorney Helge merely stated that the folder in which these style 15 sheets were located was produced as part of the DI/MMV system. This statement does not come 16 close to “confirming” that every single style sheet produced to plaintiff was actually being used 17 by the accused system, especially in light of the overwhelming evidence to the contrary. 18 None of plaintiff’s remaining arguments is persuasive. For example, there is no evidence 19 that content was ever sent to mobile devices from the accused system in WCML format (Kang 20 Dep. 75–76). Rather, the record shows that WCML was an intermediate format used internally 21 by the DI/MMV system (J. Choi Dep. 198–201). Another failed argument by MShift is that a 22 “change request” in the record, which appears to show defendants requesting a WAP-based style 23 sheet, is evidence from which a reasonable jury could find that the accused system sent content to 24 mobile devices in WAP format. Deposition testimony, however, confirms that the style sheets 25 11 26 27 28 Dr. Chatterjee’s assertion that certain style sheets output content in XML to mobile devices fails for other reasons as well (Chatterjee Decl. ¶¶ 65–70). As defined by Dr. Chatterjee, XML is a language that “does not define any specific tags or attributes” but “simply defines the rules by which tags and attributes can be used in a new XML-based language” (id. at ¶ 55). In other words, XML is not an independent markup language for displaying web pages. Rather, it is used to create other XML-based languages (see Potel Reply Decl. ¶¶ 12–14). In sum, Dr. Chatterjee’s opinion that style sheets with an “output method” of “xml” will output XML (rather than HTML) to mobile devices is wholly unsupported by his own definition of XML. 30 1 created in response to this exact change request were HTML style sheets (Kang. Dep. 69–70). 2 Finally, MShift’s last gasp attempt to stave off summary judgment is an argument that defendants 3 can be liable for patent infringement for “offering to sell” the capability of having the DI/MMV 4 system output content in WAP or WML format (Suppl. Br. 7). Not only is this argument 5 untimely (as it is based upon a marketing brochure that MShift had in its possession prior to filing 6 its original opposition brief to the instant summary judgment motion), it lacks merit as well. The 7 only evidence cited by MShift in support of its “offering to sell” allegation does not sufficiently 8 show that defendants made a commercial offer to sell an infringing product. genuine issue of material fact that the accused system communicates with (i.e., sends content and 11 For the Northern District of California In sum, based upon the arguments and evidence presented by both sides, there is no 10 United States District Court 9 information to) mobile devices exclusively in HTML. 12 ii. XHTML 1.0 is Not a Different Language from HTML in the Context of the ’881 Patent and Claim 20. 13 The argument over whether the DI online-banking websites output content in XHTML or 14 HTML format has been thoroughly briefed by both sides. Both Dr. Chatterjee and Dr. Potel have 15 opined in detail over this question in multiple declarations. According to MShift’s software 16 expert, Dr. Chatterjee, the “DOCTYPE” declaration prominently displayed in the source code of 17 web pages rendered on a DI online-banking website is ample proof for a reasonable jury to find 18 that the accused “network site” displays its content in “XHTML 1.0” format rather than in HTML 19 format (Chatterjee Decl. ¶ 72, Exh. R; Chatterjee Suppl. Decl. ¶¶ 62–65).12 This order agrees. 20 The inquiry, however, does not end with this small victory. Even assuming that the DI 21 online-banking websites (i.e., the “network sites”) provide content and information in “XHTML 22 1.0” format, this does not mean that the “first language” and “second language” limitation in the 23 asserted claim has been met. As stated, the reason why the “first language” and “second 24 language” in claim 20 must be different from each other in the context of the asserted claim is 25 because there would be no need for a conversion engine to enable the mobile device to retrieve 26 27 12 28 To be exact, the “DOCTYPE” declaration indicates that the DI online-banking websites output content in “XHTML 1.0 Transitional” format. For brevity, however, this order will simply refer to this format as “XHTML 1.0.” 31 1 content from a network site if the languages were the same. In this connection, the specification 2 of the ’881 patent repeatedly emphasized that an advantage of the claimed invention — and in 3 particular, the conversion engine of the invention — was that it enabled and allowed 4 communication between mobile devices and network sites that used different languages (see, e.g., 5 cols. 1:39–41, 1:48–51, 2:28–31, 3:38–41). This logically implies that the “first language” and 6 “second language” in claim 20 must be sufficiently “different” such that without the “conversion 7 engine” as an intermediary, the mobile device would not be able to access, couple with, or 8 communicate with the network site. 9 This is not the situation here. As defendants emphasize, DI online-banking websites are accessible by and display correctly in all major HTML browsers. Indeed, they are intended to be 11 For the Northern District of California United States District Court 10 accessed by HTML browsers. This is true regardless of whether the web pages displayed on the 12 DI online-banking websites are written in “XHTML 1.0” format, as MShift asserts, or HTML, as 13 defendants assert (see, e.g., Potel Decl. ¶¶ 15 n.2, 48; Potel Suppl. Decl. ¶ 8). As even plaintiff’s 14 expert Dr. Chatterjee admits, the differences between these two languages are purely grammatical 15 (e.g., “XHTML 1.0” requires that tags be properly closed, while HTML is more forgiving). In 16 other words, whether the DI online-banking websites are programmed in “XHTML 1.0” or 17 HTML is a distinction without a difference. This conclusion is further bolstered by the fact that 18 “XHTML 1.0” was intended merely to be a “reformation” of modern HTML. Both languages 19 share the same root element — “<html>” — and use the exact same “tags” to denote various web 20 page features (Potel Claim Const. Decl. ¶¶ 22–25, 61, Exh. C). In short, whether written in 21 “XHTML 1.0” or HTML, the “network sites” of the accused DI/MMV system can communicate 22 with, and are accessible by, all mobile devices equipped with HTML browsers. 23 With this point established, it is undisputed that there is no “language barrier” preventing 24 the same HTML-compatible mobile devices that can access and communicate with MMV mobile- 25 banking websites from directly accessing and communicating with DI online-banking websites 26 (Buckner Decl. ¶ 32; Potel Decl. ¶ 48). Stated differently, there is no need for any “conversion 27 engine” to translate between “XHTML 1.0” and HTML so that these mobile devices can view 28 web pages on the alleged “network sites.” No translation is necessary. 32 1 In sum, even crediting MShift’s argument that the DI online-banking websites 2 communicate in “XHTML 1.0,” the differences between “XHTML 1.0” and HTML are 3 insufficient as a matter of law to satisfy the “first language” and “second language” limitation set 4 forth in claim 20 of the ’881 patent. For this reason, there can be no infringement of claim 20 by 5 the accused DI/MMV mobile-banking system. 6 B. 7 As a separate and independent ground for granting its summary judgment motion, The “Restructuring” Limitation 8 defendants contend that the accused DI/MMV system does not contain anything close to a 9 “conversion engine” that “restructures a plurality of input entries within the content into selectable links that can be rendered on the mobile device[,]” as required by claim 20 of the ’881 11 For the Northern District of California United States District Court 10 patent (col. 14:45–47). 12 13 14 15 16 17 18 19 20 21 22 23 The context of this limitation is shown in the excerpt from claim 20 reproduced below (col. 14:45–52) (emphasis added): a conversion engine that is directly linked to the mobile device to accept the request for the content from the network site, wherein the conversion engine is in communication with the network site to retrieve the content from the network site in response to receiving the request from the mobile device, the conversion engine including logic to convert the content from the second language to the first language and signaling the content to be rendered as one or more pages on the mobile device and wherein the conversion engine further restructures a plurality of input entries within the content into selectable links that can be rendered on the mobile device, and wherein each of the selectable links on the mobile device can be selected to generate a second request for another content from a second network site without requiring conversion of the second request by the conversion engine. As stated, “input entries” are “features displayed on a web page that allow a user to enter 24 information into the page, like text entry fields, menu items, and check fields.” These “input 25 entries within the content” are distinguished from “other content” — like labels and graphics — 26 merely presented to the user as static information or obscured from the user as hidden fields. 27 Given the prosecution history of the ’881 patent, the accused system must contain this particular 28 limitation for infringement to be found. It would be improper to allow MShift to extend the 33 1 infringing reach of “input entries” — whether through claim construction or under the doctrine of 2 equivalents — to encompass labels, graphics, and hidden form elements. See Honeywell Int’l, 3 Inc. v. Hamilton Sundstrand Corp., 523 F.3d 1304, 1312 (Fed. Cir. 2008) (prosecution history 4 estoppel “prevents a patent owner from recapturing with the doctrine of equivalents subject 5 matter surrendered to acquire a patent”). 6 In support of their motion for summary judgment of non-infringement, defendants unleash 7 a two-pronged attack on MShift’s contention that the DI/MMV system “restructures” a plurality 8 of “input entries” within the content of the DI online-banking website into “selectable links” that 9 can be rendered on a mobile device. First, defendants argue that while the accused system does retrieve content from the DI online-banking website, it only does this so that it can extract 11 For the Northern District of California United States District Court 10 depositor-specific data from within the content. Once this data has been extracted, the remaining 12 content retrieved from the DI online-banking website — including any “input entries” therein — 13 is ignored. Second, the extracted data — and only the extracted data — is then inserted into pre- 14 designed web-page templates for the MMV mobile-banking website. As such, there is no 15 “restructuring” or “reformatting” of any “input entries” within the content of the DI online- 16 banking website into “selectable links” displayed on the MMV mobile-banking website. Rather, 17 all of the links shown on the MMV mobile-banking website have been pre-programmed to be 18 there regardless of whether any “input entries” are found within the content of the DI online- 19 banking website. 20 21 These two points are addressed in detail below. i. “Screen Scraping” of the DI Online-Banking Websites Extracts Data From the Content, Not Input Entries. 22 According to defendants, the “screen scraping” component of the accused mobile-banking 23 system — which is the component of the DI/MMV system that interacts directly with the alleged 24 “network sites” — is not concerned about restructuring “input entries” (like text entry boxes, 25 check boxes, and menu items) within the content of DI online-banking websites. Rather, the 26 accused DI/MMV system uses DI-online banking websites solely as “virtual databases” that 27 contain depositor-specific account data. This data is then used to populate style sheets used to 28 display web pages on MMV mobile-banking websites (see, e.g., Otteson Decl. Exh. 13). In other 34 1 words, the “screen scraping” of DI online-banking websites is all about retrieving data. It has 2 nothing to do with “input entries.” 3 MShift’s own demonstration of how defendants’ mobile-banking system allegedly 4 infringes claim 20 of the ’881 patent confirms that this claim limitation has not been met. As 5 detailed in MShift’s supplemental brief, the “screen scraping” of depositor-specific data from the 6 DI online-banking website for use in the MMV mobile-banking website’s “Bill Pay/Make a 7 Payment” web pages is performed by a particular server-side computer file — programmed in 8 Java — within the accused system (Suppl. Br. 9–12; Chatterjee Suppl. Decl. ¶¶ 68–74, Exhs. M, 9 N).13 The Java file contains numerous functions capable of performing different data-retrieval and data-processing tasks. One of these functions is used by the DI/MMV system to retrieve the 11 For the Northern District of California United States District Court 10 “Bill Pay/Make a Payment” web page (and potentially other content) from the DI online-banking 12 website (Chatterjee Suppl. Decl. ¶ 68, Exh. M at 2084–85). After this content has been retrieved, 13 other functions in the Java file are used by the accused system to extract payment accounts, payee 14 names, last payment amounts, and last payment dates from the content (id. at ¶ 69, Exh. M at 15 2086–88). This extracted depositor-specific data is then fed into the style sheets for the “Bill 16 Pay/Make a Payment” web pages of the MMV mobile-banking website. 17 In his supplemental declaration, MShift’s expert, Dr. Chatterjee, focuses exclusively on 18 the extraction of payee information from the DI online-banking website by this particular Java 19 file. Going line-by-line through the source code, Dr. Chatterjee contends that the Java file 20 searches through the HTML (or XHTML 1.0) of the “Bill Pay/Make a Payment” web page from 21 the DI online-banking website until it locates particular “<FORM>” tags within the source code 22 (id. at ¶ 69, Exh. M at 2086–88, Exh. N).14 The purpose of HTML “<FORM>” tags is clearly 23 explained by defendants’ expert, Dr. Potel, in his claim construction declaration (Potel Claim 24 13 25 26 27 28 This order notes that the particular Java file discussed in MShift’s supplemental brief was actually in its possession since July 7, 2010, well before MShift filed its original opposition brief (see Suppl. Reply 19). Thus, in addition to failing on the merits, its also fails as untimely as these arguments do not pertain to discovery obtained after the September 2 hearing. 14 Due to the confidential nature of the source code in question, the particular function names, attribute values, and other details will not be mentioned unless absolutely necessary. With respect to tag attributes, both experts fully explain in their declarations that tags used in HTML and XHTML programming often support or require particular attributes (see, e.g., Potel Claim Const. Decl. ¶ 63; Chatterjee Suppl. Decl. ¶ 72). 35 1 Const. Decl. ¶ 61). Once the “<FORM>” tag is found, the Java application retrieves and stores 2 the data located in the “id” attribute of the “<FORM>” tag. The Java application then searches 3 for different HTML tags called “<INPUT>” tags (id. at ¶¶ 69–70, Exh. M at 2086–88, Exh. N). 4 Once these “<INPUT>” tags have been found, the Java application retrieves and stores the data 5 located in the “value” attribute of these particular “<INPUT>” tags. The purpose of HTML 6 “<INPUT>” tags is also clearly explained by defendants’ expert, Dr. Potel, in his claim 7 construction declaration (Potel Claim Const. Decl. ¶ 61). This extracted data is then integrated 8 into particular hyperlinks that appear on the MMV mobile-banking website (Chatterjee Suppl. 9 Decl. ¶ 68–73). Dr. Chatterjee’s analysis, however, contains a fatal flaw. It presumes that the “<FORM>” 11 For the Northern District of California United States District Court 10 tags and “<INPUT>” tags from which the Java application extracts data are associated with 12 “input entries” within the content of the DI online-banking website. They are not. A “<FORM>” 13 tag — by itself — does not display any “input entries” on a web page. Only so-called “form 14 elements,” denoted by “<INPUT>” tags, are capable of displaying such “input entries” (Potel 15 Claim Const. Decl. ¶ 61). Critically, however, not all form elements actually display “input 16 entries” on a web page to a user. For example, form elements denoted by “<input 17 type=‘hidden’>” are completely invisible to users. As such, they are not features on a web page 18 that allow a user to input data into the page. Rather, such form elements are used to store vital 19 information “behind the scenes” that would be meaningless to a depositor if displayed on the page 20 (such information would include numerical database “ids” corresponding to a depositor’s bank 21 accounts, payees, and payment methods). As such, “hidden” form elements are most definitely 22 not “input entries” as construed by this order.15 23 Here’s why this is important: the particular Java function discussed in detail by Dr. 24 Chatterjee and within MShift’s supplemental brief extracts data exclusively from “hidden” form 25 elements in the DI online-banking website (Chatterjee Suppl. Decl. ¶ 70; Suppl. Br. 10). In other 26 27 28 15 Contrary to MShift’s assertions at the claim construction hearing, defendants’ expert did not represent that hidden form elements were “input entries” within the meaning of the ’881 patent. Rather, Dr. Potel merely stated that a hidden form element was simply one of many form elements that could be used between “<FORM>” and “</FORM>” tags (Potel Suppl. Decl. ¶ 12). 36 1 words, the function does not extract data from any text entry boxes, check boxes, menu items, or 2 any other web-page features that are displayed to the user and allow a user to enter information 3 into the page. As such, MShift’s best evidence of infringement fails to live up to its billing. Not 4 only does the accused DI/MMV system extract only data from within the content of the DI 5 online-banking website, this data is not even extracted from any “input entries” as defined herein. 6 7 ii. The “Selectable Links” Already Exist on the DI/MMV System. Even if information was extracted from an “input entry” on the DI online-banking website 8 by one of the functions in the Java application discussed above, there is no evidence that 9 “selectable links” displayed on the MMV mobile-banking website are created by “restructuring” 11 For the Northern District of California United States District Court 10 any “input entries” within the content of the DI online-banking website. First, as explained above, after the Java application used by the accused system to “screen 12 scrape” the DI online-banking website retrieves content from the so-called “network site,” it 13 scours the content for data. It does not perform a search for “input entries within the content” to 14 “restructure” into “selectable links” (Buckner Decl. ¶¶ 11–29, Exhs. 1–3; Buckner Dep. 48, 112, 15 121–22, 126–27; J. Choi Dep. 75, 122–25, 140–42, 245–46; Lee Dep. 42–43). Second, even 16 assuming that data is extracted from a HTML “<INPUT>” tag that happens to correspond to a 17 text box, menu option, or check box, there is no evidence that the “input entry” itself is 18 “restructured” into “selectable links” by the accused system. 19 Indeed, as explained earlier in this order, the hyperlinks displayed on the “Bill Pay/Make a 20 Payment” web pages of an MMV mobile-banking website have already been programmed to be 21 there through the use of style sheets. They are not generated on-the-fly by the DI/MMV system 22 in response to the “restructuring” of any “input entries” on the DI online-banking website. Stated 23 differently, the existence of links on the MMV mobile-banking website is not contingent upon the 24 presence of a corresponding input entry within the content of the alleged “network site.” True, 25 the number of hyperlinks displayed to a user, the text displayed in each hyperlink, and the exact 26 destination address of each hyperlink may change depending upon data that has been retrieved 27 from HTML tags corresponding to “input entries” on the DI online-banking website. Even 28 crediting this proposition, however, the fact remains that the existence of these hyperlinks on the 37 1 MMV mobile-banking website does not depend upon the “restructuring” of these “input entries” 2 (J. Choi Dep. 122–25, 140–42; Buckner Decl. ¶¶ 11– 18, 26, 28, Exhs. 1–3). Rather, their 3 existence and placement on the MMV mobile-banking website depends solely upon the style 4 sheets used to display the web pages (see Choi Dep. 122–25, 140–42). 5 Neither MShift nor its expert, Dr. Chatterjee, can point to any other source code, technical 6 document, or witness testimony showing that the accused system “restructures” input entries into 7 “selectable links” in the manner required by claim 20. Beyond his failed analysis of the Java 8 application revealed above, Dr. Chatterjee can only opine on the “look and feel” of the “Bill 9 Pay/Make a Payment” web pages on the DI online-banking website and the MMV mobilebanking website to summarily conclude that “[c]learly, the input entries from the bill pay site are 11 For the Northern District of California United States District Court 10 restructured into selectable links” (Chatterjee Decl. ¶¶ 76–79). 12 Given that MShift readily admitted that it “managed to establish all that it needs to defeat 13 defendants’ summary judgment motion” and that defendants “ultimately produced the technical 14 documents MShift needed to solidify its summary judgment opposition,” this wholly unsupported 15 conjecture by Dr. Chatterjee is telling. In any event, it cannot defeat summary judgment. See 16 Surrell, 518 F.3d at 1103; see also Brooke Group Ltd. v. Brown & Williamson Tobacco Corp., 17 509 U.S. 209, 242 (1993) (an expert opinion unsupported by sufficient facts and unreasonable in 18 light of the undisputed factual record cannot support a favorable jury’s verdict). 19 Finally, as its “kitchen sink” argument on the issue of “restructuring,” MShift points to a 20 specific mobile device — the Nokia 2720 — as providing “overwhelming evidence” that the 21 accused system “restructures input entries into selectable links” (Opp. 23). The proof, according 22 to plaintiff, is that “a drop down menu on USE Credit Union’s mobile banking [website] is 23 restructured into several selectable links on the Nokia 2720 phone” (Moeller Decl. ¶¶ 54–58, 24 Exhs. 49–54). As with Dr. Chatterjee’s superficial “screenshot-based” analysis exposed above, 25 this contention by MShift — which even Dr. Chatterjee did not endorse — is supported solely by 26 screenshots of the Nokia 2720 phone accessing USE Credit Union’s MMV mobile-banking 27 website. Similar to Dr. Chatterjee’s “screenshot-based” analysis, this assertion is completely 28 divorced from the actual source code produced by defendants showing how the accused system 38 1 actually works (Buckner Reply Decl. ¶ 3; Potel Reply Decl. ¶¶ 20–21). Indeed, as defendants 2 point out in their reply brief, even a cursory inquiry into how Nokia phones work would have 3 revealed that it is Nokia’s own proprietary software that performs this reformatting of drop-down 4 menus (Reply 15). This perhaps explains why this argument never resurfaces in MShift’s 5 supplemental brief, and plaintiff’s expert, Dr. Chatterjee, never signs on to it. Being wholly 6 unsupported by the undisputed record, this order rejects this final, unreasonable argument. 7 Williamson Tobacco, 509 U.S. at 242. 8 9 * * * In sum, based upon the claim constructions herein and the evidence and arguments presented by both sides, this order finds that MShift has failed to meet its burden of showing the 11 For the Northern District of California United States District Court 10 existence of genuine issues of material fact regarding whether the accused DI/MMV system 12 infringes claim 20 of the ’881 patent. MShift cannot show that all limitations in claim 20 of the 13 ’881 patent are present either literally or by a substantial equivalent in the accused system. See 14 TechSearch, L.L.C. v. Intel Corp., 286 F.3d 1360, 1371 (Fed. Cir. 2002). As such, defendants’ 15 motion for summary judgment of non-infringement is GRANTED. 16 3. 17 MShift’s motion under FRCP 37 seeks both monetary and preclusion sanctions due to 18 allegedly “willful” violations by defendants of their discovery obligations under FRCP 26 and 19 three court orders pertaining to discovery. Also inexplicably thrown into plaintiff’s Rule 37 20 motion is a one-sentence request, under FRCP 56(f), to deny defendants’ motion for summary 21 judgment due to these supposed discovery shenanigans. As explained below, the record does not 22 support granting any sanctions against defendants under FRCP 37. PLAINTIFF’S RULE 37 MOTION FOR SANCTIONS 23 A. Sanctions Under FRCP 37(c) 24 Plaintiff’s request for monetary and preclusion sanctions under FRCP 37(c) is premised 25 solely upon defendants’ supposed failure to properly disclose technical witness Byoung Ho Kang 26 in its initial or amended disclosures. According to plaintiff, because Mr. Kang was not disclosed 27 by defendants pursuant to FRCP 26(a)(1)(A) or FRCP 26(e)(1), defendants should not be allowed 28 to cite to his deposition testimony in their response to MShift’s supplemental brief. 39 1 This argument is a non-starter. Defendants did not anticipate relying on Mr. Kang’s 2 testimony in support of their claims or defenses, and did not in fact rely on his testimony in their 3 opening and reply briefs for their motion for summary judgment. It was only after MShift elected 4 to depose Mr. Kang after the September 2 hearing and after MShift cited his testimony in its 5 supplemental brief that his testimony became part of the summary judgment record. Given this 6 backdrop, MShift was not required to disclose the identity of Mr. Kang in its initial disclosures 7 under FRCP 26(a)(1)(A). 8 Since no violation of FRCP 26(a)(1)(A) has occurred, sanctions under FRCP 37(c) are 9 unwarranted. Additionally, it must be emphasized that plaintiff chose to rely upon Mr. Kang’s deposition testimony to defend against the instant motion. Thus, defendants are certainly entitled 11 For the Northern District of California United States District Court 10 to supplement the record with other portions of Mr. Kang’s testimony to rebut and give context to 12 the excerpts cited in MShift’s supplemental brief. The rule of completeness allows this. The 13 request for preclusion and monetary sanctions under FRCP 37(c) is DENIED. 14 B. 15 Plaintiff’s request for monetary sanctions under FRCP 37(b) is based solely upon 16 accusations of “delay” and alleged “violations” of court orders regarding defendants’ discovery 17 obligations. As explained below, these allegations do not justify any award of sanctions against 18 defendants. 19 Sanctions Under FRCP 37(b) The full extent of discovery obtained by MShift was set forth earlier in this order. Only 20 the essential points will be repeated here. Despite the grievances advanced by plaintiff, this order 21 finds that defendants reasonably followed an “open book” strategy in producing technical 22 documents and witnesses to plaintiff. Defendants also extended the briefing schedule by two 23 weeks to provide plaintiff extra time to conduct additional discovery on the technology developed 24 by intervenor SK C&C (including two depositions). In return, MShift expressly agreed to “not 25 assert a Rule 56(f) objection” if the requested technical documents and witnesses with knowledge 26 about the DI/MMV system from SK C&C were produced (Valentine Decl. Exh. D). These 27 documents were produced and two additional witnesses from SK C&C were deposed by MShift 28 on July 22 (id. at ¶¶ 8–12). Defendants then asked MShift to identify any materials that it 40 1 believed had not been produced by DI, MMV, or SK C&C. Plaintiff did not inform defendants of 2 any deficiencies. Rule 56(f) motion alongside its original opposition to defendants’ summary judgment motion. 5 The basis of the Rule 56(f) motion was that defendants had prevented discovery of an important 6 component of the accused system — specifically, the component responsible for “screen 7 scraping” the DI online-banking websites called “xMAS.” Out of an abundance of caution, at the 8 September 2 hearing, the Court granted Rule 56(f) relief and ordered that MShift be given the 9 opportunity to conduct additional discovery on SK C&C and take two more depositions of SK 10 C&C witnesses: one who supposedly handled the production of technical documents and the 11 For the Northern District of California Without any effort to meet and confer, and despite the above agreement, MShift filed a 4 United States District Court 3 other of any technical witness of MShift’s choice. MShift elected to depose Mr. Kang on the 12 details of the elusive “xMAS” component. 13 Both depositions went forward as scheduled. Specifically, Mr. Soo Young Choi was 14 deposed by plaintiff and testified as to the document production efforts that had been undertaken 15 by SK C&C both prior to and after the September 2 hearing (S. Choi Dep. 100–03). These 16 document production efforts are covered in convincing detail in defendants’ opposition to 17 plaintiff’s Rule 37 motion (Sanctions Opp. 11–13). 18 With respect to Mr. Kang, it was during his deposition that MShift asserts it was 19 ambushed with the news that a Nepalese business entity called FocusOne had been involved in 20 the development of the xMAS component. According to MShift, both Mr. Kang and FocusOne 21 had been improperly “hidden” by defendants during the discovery process (Sanctions Br. 10).16 22 In any event, Mr. Kang was asked directly during his deposition if he had knowledge of the 23 critical xMAS component of the accused system (Kang Dep. 149–150): Q: Are you familiar, Mr. Kang, with how the xMAS solution works? A: 24 I am very familiar with that. 25 26 27 28 16 Contrary to MShift’s contentions, documents identifying FocusOne as a developer of xMAS were actually produced by defendants as early as July 7, 2010 (Yamashita Suppl. Decl. ¶¶ 14–15). 41 1 Q: And does that include the components that were originally developed by SK C&C’s partner, FOCUSONE? A. Yes, I’m familiar with how to use and how it operates. 2 3 Despite Mr. Kang’s familiarity with the very xMAS component for which MShift was granted 4 supplemental discovery, counsel for plaintiff were not interested in the merits of whether the 5 xMAS component actually “restructured” any “input entries” into “selectable links.” Instead, 6 MShift focused its attention on the role that FocusOne played in the development of the xMAS 7 component. 8 This misdirection has been characteristic of MShift’s strategy in defending against the 9 instant summary judgment motion. Despite ample discovery — specifically, access to hundreds 10 opportunity to review source code of the accused product — MShift has not been able to uncover For the Northern District of California United States District Court of thousands of pages of technical documents, eleven depositions of technical witnesses, and the 11 12 any competent evidence that the accused DI/MMV system works differently than how every 13 witness and declarant has described under oath. FocusOne represents MShift’s continued efforts 14 to distract the Court from the mountains of evidence demonstrating that the accused DI/MMV 15 system does not infringe its patent. 16 In light of the full record, this order finds that defendants reasonably complied with all 17 discovery-related orders and directives set forth by the Court. As such, monetary sanctions under 18 FRCP 37(b)(2)(C) are unwarranted and DENIED. 19 C. Relief Under FRCP 56(f) 20 Plaintiff’s request for relief under FRCP 56(f) is DENIED. Not only was the request 21 inadequately briefed, it cannot be emphasized enough that MShift repeatedly stated in its filings 22 that it “managed to establish all that it needs to defeat defendants’ summary judgment motion on 23 the merits” and that “defendants ultimately produced the technical documents MShift needed to 24 solidify its summary judgment opposition” (Sanctions Br. 3, 12, 17). 25 Indeed, not every patent case needs to churn on for years. Businesses have a legitimate 26 need to know where they stand when accused of infringement, so that ongoing operations do not 27 incur ever-mounting potential liability. MShift has now taken eleven depositions and has 28 received over 186,000 pages of technical documentation in the months since the initial case 42 1 management conference. Defendants have cooperated in isolating the key non-infringement 2 issues and facilitating discovery thereon, all with an above-board effort to get to the bottom of the 3 case with efficiency. The record compels summary judgment. It would be a waste of resources to 4 allow MShift to go on additional fishing expeditions in vague hopes that something might turn- 5 up. Enough is enough. 6 5. PLAINTIFF’S EVIDENTIARY OBJECTIONS 7 On August 25, MShift filed evidentiary objections targeting declarations submitted in 8 support of defendants’ summary judgment motion.17 None of these objections changes the 9 outcome of this order. First, MShift objects to the evidence provided by defendants in response to plaintiff’s arguments — raised in its opposition brief — targeting the Nokia 2720 phone. With 11 For the Northern District of California United States District Court 10 respect to Peter Buckner’s declaration in reply (which is limited solely to responding to this 12 argument), MShift’s objections are OVERRULED. Paragraph three of Mr. Buckner’s reply 13 declaration, which discusses the “style sheet” used by the DI/MMV system to render web pages 14 on the Nokia 2720 phone, is neither “conclusory” nor lacking in “evidentiary support.” When 15 read in conjunction with the comprehensive declaration Mr. Buckner submitted in support of 16 defendants’ summary judgment motion, the statements made in Mr. Buckner’s declaration in 17 reply are admissible. The earlier declaration established Mr. Buckner’s qualifications and first- 18 hand knowledge to make such statements, and set forth a sufficient factual basis to support the 19 information presented in his reply declaration. MShift’s second objection to this particular 20 paragraph, brought under the Best Evidence Rule, also fails. Not only did Mr. Buckner attach the 21 particular “style sheet” being discussed to his earlier declaration, he was not providing evidence 22 of the source code therein — rather, he was providing his opinion that it was written in HTML 23 rather than XML. 24 Second, MShift objects to various paragraphs in the reply declaration of defendants’ 25 expert, Dr. Potel. A number of these targeted paragraphs — specifically, paragraphs 12 through 26 16 — pertain solely to the XML versus HTML “language” debate. According to MShift, Dr. 27 28 17 Additional objections were made with respect to defendants’ opposition to MShift’s Rule 56(f) motion. Since that motion was granted on September 2, those objections need not be addressed here. 43 1 Potel should have raised these points in his opening declaration. This order disagrees. The 2 particular paragraphs targeted by MShift are admissible to rebut specific representations made in 3 MShift’s opposition brief and by its expert, Dr. Chatterjee. Plaintiff also objects to paragraphs 19 4 and 20 in Dr. Potel’s reply declaration, which responds to MShift’s Nokia 2720 argument. 5 Specifically, MShift asserts that Dr. Potel failed to authenticate the source code referenced in 6 these particular paragraphs, stating that “it is unclear how this code was generated” and “whether 7 it came from where Dr. Potel claims it came from.” This argument also fails. As he explained in 8 paragraphs 19 and 20 of his reply declaration, Dr. Potel obtained the source code from the 9 “‘Transfer Funds’ online banking page” and the “‘Transfer’ mobile banking page as generated for a Nokia 2720 phone” and “an Apple iPhone” (Potel Reply Decl. ¶¶ 19–20). Regardless, even 11 For the Northern District of California United States District Court 10 without this evidence, plaintiff’s “look and feel” arguments based solely upon superficial 12 interactions with the Nokia 2720 phone are insufficient to defeat summary judgment. In sum, 13 plaintiff’s objections targeting Dr. Potel’s reply declaration are OVERRULED. 14 Finally, on September 29, MShift filed a separate evidentiary objection to any reliance by 15 defendants on the deposition testimony of Mr. Kang in their response to MShift’s supplemental 16 brief. As explained above, defendants were not required to disclose Mr. Kang as part of their 17 initial disclosures under FRCP 26(a)(1)(A), because they were not intending to rely upon his 18 testimony in any claims or defenses. Rather, it was MShift who chose to depose Mr. Kang. 19 Accordingly, his deposition testimony may certainly be used by defendants to rebut points made 20 in MShift’s supplemental brief based upon Mr. Kang’s testimony. The rule of completeness 21 would also allow this evidence to come in. For these reasons, this last objection is OVERRULED. 22 All of MShift’s remaining evidentiary objections target material this order neither cites 23 nor relies upon (e.g., paragraph six of the Prior declaration). As such, they need not be addressed 24 by this order. 25 26 CONCLUSION For the reasons set forth herein, and based upon the claim constructions set forth above, 27 defendants’ motion for summary judgment of non-infringement is GRANTED. Plaintiff’s Rule 37 28 motion for monetary and preclusion sanctions is DENIED. Pursuant to the stipulation filed by 44 1 defendants on October 8, defendants’ counterclaims for declaratory judgment of patent invalidity, 2 patent unenforceability, and absolute and equitable intervening rights are DISMISSED (Dkt. No. 3 332). Both sides are ORDERED TO SHOW CAUSE why all remaining state claims should not be 4 dismissed and remitted to state court BY NOON ON FRIDAY, OCTOBER 15, 2010. 5 6 IT IS SO ORDERED. 7 8 Dated: October 8, 2010. WILLIAM ALSUP UNITED STATES DISTRICT JUDGE 9 11 For the Northern District of California United States District Court 10 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 45

Some case metadata and case summaries were written with the help of AI, which can produce inaccuracies. You should read the full case before relying on it for legal research purposes.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.