MShift, Inc. v. Digital Insight Corporation et al
Filing
336
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)
<![CDATA[
MShift, Inc. v. Digital Insight Corporation et al
Doc. 336
1 2 3 4 5 6 7 8 9 10 MSHIFT, INC., a Delaware corporation, 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, Defendants, and SK C&C CO. LTD., Defendant-Intervenor. AND RELATED COUNTERCLAIMS. / / CLAIM CONSTRUCTION ORDER, ORDER GRANTING DEFENDANTS' MOTION FOR SUMMARY JUDGMENT, AND ORDER DENYING PLAINTIFF'S MOTION FOR SANCTIONS No. C 10-00710 WHA IN THE UNITED STATES DISTRICT COURT FOR THE NORTHERN DISTRICT OF CALIFORNIA
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Dockets.Justia.com
1 2 3 4 5 6 7 8 9 10
INTRODUCTION In this patent-infringement dispute involving mobile-banking technology, defendants Digital Insight Corporation, Mobile Money Ventures, LLC ("MMV"), and thirteen of their bank and credit-union customers move for summary judgment on plaintiff MShift, Inc.'s claim that their accused mobile-banking system infringes United States Patent No. 6,950,881. Also addressed herein -- following a claim construction hearing and full briefing on the merits -- are the constructions of two claim terms relevant to the resolution of the instant motion. Finally, plaintiff's recently filed motion for Rule 37 discovery sanctions is addressed by this order. 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 financial institutions across the country. MShift's mobile-banking technology formed the backbone of those services. The relationship, however, failed to last. After their partnership folded, both companies went their separate ways and Digital Insight partnered with a new entity -- MMV -- to provide the underlying technology for its mobile-banking system. MShift was not pleased. With its '881 patent in hand, MShift sued Digital Insight, its partner MMV, and thirteen of their financial-institution customers. Defendants responded by giving prompt notice to both MShift and the Court that they would be filing a summary judgment motion of non-infringement. An intense period of discovery ensued. As explained in detail herein, defendants took reasonable measures to provide MShift with a full and fair opportunity to substantiate the merits of its infringement contentions. Digital Insight and MMV produced hundreds of thousands of pages of technical documents (including source code) pertaining to the accused mobile-banking system, many before any document requests had been made. Defendants also produced nine employees for depositions. Even after full briefing on defendants' summary judgment motion had been completed, the undersigned judge granted a request by MShift for extra time to conduct further discovery on the accused mobile-banking system, including two additional depositions of defense witnesses. Both sides were then invited to file supplemental 20-page briefs (accompanied by voluminous declarations and expert analyses) on why the accused system did or did not infringe the '881 patent. 2
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
1 2 3 4 5 6 7 8 9 10
Despite these opportunities to defeat defendants' motion, MShift failed to rise to the occasion. Following multiple hearings and a massive amount of briefing from both sides, this order finds that there are no genuine issues of material fact as to whether the accused mobilebanking system infringes the '881 patent. No reasonable jury could find that it does. In so holding, this order rejects MShift's repeated attempts to distract the Court's attention from the weaknesses of its arguments (including plaintiff's eleventh-hour Rule 37 motion for sanctions). Accordingly, defendants' motion for summary judgment of non-infringement is GRANTED. Plaintiff's motion for sanctions under Rule 37 is DENIED. STATEMENT This action involves both mobile-banking and online-banking systems. Understanding their differences is critical to the analysis herein. The term "mobile banking" describes products and services that allow depositors to manage their bank accounts -- e.g., check balances, make payments to third parties, and transfer funds -- using the limited screen space, bandwidth, and processing power of smartphones and other mobile devices. By contrast, the term "online banking" describes similar products and services optimized for use with the large displays, highspeed Internet connections, and feature-rich web browsers typically found on desktop and laptop computers. In other words, while online banking and mobile banking both enable depositors to manage their bank accounts over the Internet, they are each specifically designed and streamlined for use with different types of consumer devices. Defendant Digital Insight offers its bank and credit-union customers both of these product options. Specifically, every financial institution who uses Digital Insight's online-banking system has the option to sign up for its mobile-banking offerings. Plaintiff MShift also offers a suite of mobile-banking products to financial institutions. The instant action, however, places the spotlight squarely on MShift's '881 patent. This patent is described in relevant detail below. 1. THE '881 PATENT
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
The '881 patent asserted by MShift, whose application was filed in October 2000, is entitled "system for converting wireless communications for a mobile device" (col. 1:13). As explained throughout the specification and prosecution history, the '881 patent was not directed 3
1 2 3 4 5 6 7 8 9 10
towards the mobile-banking industry (or any particular industry for that matter) but was instead intended to address specific shortcomings in the way mobile devices could send, receive, and display content at the time of the invention.1 One of these problems was a supposed "language barrier" between mobile devices and so-called "network sites" that provided information and content. A. The "Language Barrier" in Mobile Communications
A clear explanation of the "language barrier" at the time the patent was drafted was provided by the "background of the invention" (col. 1:2836): 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. In other words, while "network sites" could provide content to mobile devices in a variety of languages, mobile devices were typically programmed to understand only a single language.2 To address this "language barrier" between mobile devices and certain network sites, the invention claimed by the '881 patent "enable[d] mobile devices programmed in one language to access network sites structured to provide information using a second language" (col 1:3942). The invention facilitated this access by "converting" the communications between mobile devices and network sites. In this connection, the specification further explained that "[e]mbodiments of the invention provide a conversion engine to enable mobile devices to retrieve content from network sites, where the mobile device and the network site use different languages" (col. 2:2831) (emphasis added). Stated differently, the "conversion engine" claimed by the '881 patent acted as a translator between mobile devices and "network sites." 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:4750).
1
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
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:2427). A typical example of a "network site" is a website on the Internet (col. 4:3336).
2
4
1 2 3 4 5 6 7 8 9 10
B.
The "Conversion Engine" of the Asserted Claim
The conversion engine is undoubtedly the centerpiece of both the patented invention and claim 20 -- the sole claim of the '881 patent being asserted. As stated, the "conversion engine" is the component of the claimed invention that allows a mobile device that can only understand a particular programming language to "couple" with (i.e., request and receive information and content from) network sites that communicate using different programming languages. 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:2652): 20. A system for exchanging communications between a mobile device and a network site, the system comprising: 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, 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 shown, there are three main components in the system covered by claim 20: (1) a mobile device, (2) a conversion engine, and (3) a network site. To illustrate the interplay between these components, a block diagram taken directly from the '881 patent is shown below. The three key components in the asserted claim -- a mobile device ("60"), a conversion engine ("50"), and a network site ("30") -- are clearly labeled:
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
5
1 2 3 4 5 6 7 8 9 10
United States District Court
11
For the Northern District of California
The four arrows shown in Figure 1 of the patent represent the flow of information between these three components in an embodiment of the invention (col. 1:5357). Understanding this flow is critical to understanding MShift's infringement allegations as well as the claim construction issues discussed herein. First, as the specification explained, the mobile device makes a request for content from the network site (col. 4:3738). Since the network site and mobile device communicate using different programming languages, however, they cannot interface directly with each other. As such, the mobile device's request for content (represented by the arrow labeled as "1") is first sent to the conversion engine (col. 4:4546). Second, once the conversion engine receives the request from the mobile device, it transforms the request into a different programming language that is compatible with the network site. Once transformed, the conversion engine then forwards the request directly to the network site (represented by the arrow labeled as "2") (col. 5:15). Third, in response to the request from the conversion engine, the network site provides the requested content which the conversion engine then retrieves (represented by the arrow labeled as "3") (col. 5:36). Fourth, the conversion engine converts the content retrieved from the network site "into a newly formatted content" which "is signaled to the mobile device" in a programming language the mobile device can understand (represented by the arrow labeled as "4") (col. 5:69). In sum, these four steps demonstrate how the conversion
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
6
1 2 3 4 5 6 7 8 9 10
engine is used to "enable mobile devices to receive content from network sites" where they would otherwise be unable to communicate with each other (see col. 1:2831). To ensure clarity, a flow diagram of this process -- shown from the perspective of the "conversion engine" -- is reproduced below as (albeit broken down into five steps instead of four). This diagram, labeled Figure 2, comes directly from the '881 patent:
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 The invention claimed by '881 patent, however, requires more than just language conversion between mobile devices and network sites. The patented invention also contains an additional limitation (among others) that is critical to the merits of MShift's infringement contentions and to claim construction. This limitation is the "restructuring" of "input entries" within the content of the network site into "selectable links" by the conversion engine. C. The "Restructuring" of "Input Entries" into "Selectable Links"
Beyond acting as a translator between a mobile device and a network site, the conversion engine set forth in claim 20 also "restructures a plurality of input entries within the content [from the network site] into selectable links that can be rendered on the mobile device" (col. 14:3537, 14:4547). While the exact contours of this limitation depend in part upon the claim construction portion of this order (in particular, the parties dispute the meaning of the claim term "input entries"), the substance of this limitation is presented below. 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 2 3 4 5 6 7 8 9 10
between the parties that a hyperlink on a web page is a "selectable link." This is consistent with how the specification describes such "selectable links" in the context of the claimed invention (col. 8:1744). There is also no genuine dispute between the parties as to what "restructures" mean. As used in the specification and the claims, and as cited by MShift in its briefs, "restructure" is used synonymously with "reformat" (cols. 8:1920, 10:4043, 12:4349, 13:4952, 14:4552). In context with the surrounding claim language, it simply means that during the language translation process, the conversion engine reformats an "input entry" into a hyperlink. Stated differently, where the source code from the network site contains instructions 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 associated with the "input entry" it replaced (col. 8:3034). Finally, while the outer reaches of the term "input entries" are disputed, both sides -- at a minimum -- agree that the term "input entries" as used in the '881 patent encompasses "textentry fields, icons, check-fields assigning Boolean values, and selectable items provided in a menu" (cols. 7:5058, 8:1113).3 In layman's terms, an "input entry" is simply a feature on a web page that allows the user to input information into the page. Examples include text boxes for entering one's first and last name, billing address, and credit-card number when making an online purchase, drop-down boxes for selecting between different payment types, and date-selection boxes for specifying a particular date (see col. 7:5558). A more precise meaning of "input entries" will be addressed briefly in the claim construction portion of this order. The requirement that the conversion engine of the claimed invention "restructure[] a plurality of input entries within the content [from the network site] into selectable links that can be rendered on the mobile device" was added to the '881 patent for two critical reasons. Both are addressed below.
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 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:1744, 9:413). 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:1920, 3639). There is no dispute that the two terms are identical as used in the '881 patent.
8
1 2 3 4 5 6 7 8 9 10
i.
The HDML Problem
The technical shortcomings of mobile-device communications at the time the '881 patent was drafted (which would have been prior to the October 2000 application filing date) provide one explanation for this particular limitation. The specification frequently discussed the fact that mobile devices on the market at the time lacked the ability to display more than one input entry on the same screen at the same time (cols. 7:4155, 8:1016). In particular, the specification made exclusive reference to embodiments where the mobile device was limited to communicating with network sites and displaying content using a language called HDML (handheld device markup language). As the patent further explained (col. 7:4853): 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. As an illustration, mobile devices that communicated in HDML were incapable of rendering a simple "login page" where a user is prompted to enter a username and password. Since two text entry fields (also called "text boxes" herein) would need to be displayed simultaneously to the user (one for the username and one for the password), a mobile device that displayed content in HDML would not be capable of properly rendering such a page. A workaround was needed. The "restructuring" of input entries into "selectable links" for display on a mobile device was the solution proposed by the '881 patent. This solution was feasible because mobile devices at the time the patent was drafted -- including those that communicated in HDML -- were not limited in the number of "selectable links" that could be displayed simultaneously on a single rendered web page (see col. 8:1334). As such, the '881 patent claimed an invention where web pages containing more than a single input entry (i.e., a "plurality of input entries") would be automatically "restructured" by a conversion engine so that each "input entry" was replaced by a selectable link before being rendered on a mobile device.4 Such a "restructured" web page would then render properly on mobile devices using HDML or some other similarly limited language.
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:3034).
4
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
9
1 2 3 4 5 6 7 8 9 10
Of course, using these "restructured" web pages involved a cumbersome process. The mobile-device user would be forced to click on each of the hyperlinks associated with an input entry, one at a time. For each selected link, the conversion engine would then present the user with a second web page -- preferably a "virtual page" that is generated automatically by the conversion engine -- containing a single input entry corresponding to the hyperlink selected by the user (col. 8:4144). While an inelegant solution, this provided a functional workaround to the "one input entry per screen" limitation found in mobile devices at that time (see col. 9:413). 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 their briefs and at oral argument, the "restructuring" limitation was added to each and every claim of the '881 patent during its prosecution to overcome repeated rejections by the patent examiner under 35 U.S.C. 102(e) and 103(a) (Yamashita Decl. Exhs. BE). Specifically, the patent examiner was concerned about two prior art references -- the Schwartz patent (U.S. Patent No. 6,473,609) and the Jamtgaard patent (U.S. Patent No. 6,430,624). In the examiner's opinion, these patents anticipated and rendered obvious the invention MShift was attempting to patent. According to the comments made in the "final rejection" of MShift's patent application by the USPTO, the Schwartz reference disclosed a system for exchanging communications between a mobile device and a network site, where a conversion engine coupled to the mobile device included logic to convert content from the network site in a second language (like cHTML) into a first language (like HDML) for rendering on the mobile device. In the same "final rejection" action, the patent examiner further concluded that the Schwartz reference disclosed a conversion engine that "identifies one or more input entries at the network site, and signals the input entries as selectable links to the mobile device." Combined with the Jamtgaard reference, which disclosed a system where a web pages were automatically reformatted and translated into different languages for display on mobile devices, the patent examiner soundly rejected all of the proposed claims in MShift's patent application.
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
10
1 2 3 4 5 6 7 8 9 10
Undaunted, MShift amended its application and sought reconsideration from the USPTO, emphasizing (among other things) that the "restructuring" of "input entries" into "selectable links" for display on the mobile device and a second "directly linked" limitation rendered its proposed claims allowable over the Jamtgaard and Schwartz prior art references.5 Both of these limitations are found in claim 20. In making this argument to the USPTO, MShift made the following representations to the patent examiner (id. at Exh. E) (emphasis added): 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. For whatever reason, the patent examiner accepted these arguments on reconsideration and allowed the claims despite its earlier statements that the "restructuring" of "input entries" into "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 restricted to mobile devices using a programming language where only "one input entry per screen" is allowed. Rather, it expressly encompasses mobile devices that communicate in a language that allows for multiple input entries per page.6 Nevertheless, this order emphasizes that the "restructuring" of "input entries" into "selectable links" applies with equal force to claim 20, as the addition of this particular limitation was necessary for MShift to overcome the prior art. 2. THE ACCUSED MOBILE-BANKING SYSTEM
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Turning now to the accused mobile-banking system, defendant Digital Insight provides online-banking and mobile-banking solutions to banks and credit unions nationwide. Over 1,500 banks and credit unions currently use Digital Insight's online-banking product (Prior Decl. ¶ 11).
The "directly linked" limitation was not targeted by defendants' summary judgment motion. It is therefore unnecessary to address it in this order. 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.
6 5
11
1 2 3 4 5 6 7 8 9 10
A subset of these online-banking clients also use the accused mobile-banking system, which both sides call the "DI/MMV system." A. Online Banking vs. Mobile Banking
Online-banking and mobile-banking systems both provide depositors with the means to manage their bank accounts over the Internet, but only online-banking services are specially optimized for the large displays, high-speed Internet connections, and feature-rich web browsers typically found in desktop and laptop computers. This order will refer to the particular onlinebanking websites provided by Digital Insight to its customers as "DI online-banking websites." 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 Internet access. In contrast to online-banking services, mobile-banking services are specially designed to be used with smartphones and other mobile devices that have much smaller screen displays, slower Internet connections, and -- in some cases -- more limited web-browsing capabilities. When referenced herein, the particular mobile-banking websites provided by Digital Insight (in partnership with MMV) to its financial-institution customers will be called "MMV mobilebanking websites." Like their larger online-banking counterparts, these MMV mobile-banking websites are accessible to bank depositors by simply entering the proper URL into a HTMLcompatible web browser on a smartphone or other mobile device with Internet access. Two important points must be remembered with respect to DI online-banking websites and MMV mobile-banking websites. First, while MMV mobile-banking websites are optimized for use with a mobile device, there is nothing preventing a depositor from accessing an MMV mobile-banking website using a desktop or laptop computer. Conversely, there is nothing -- except perhaps automatic redirection scripts -- preventing a depositor from browsing to a DI online-banking website using a mobile device.7 At their core, both are simply websites on the
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 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. ¶¶ 1617). This is because the DI online-banking website is
12
1 2 3 4 5 6 7 8 9 10
Internet. Both can therefore be accessed using any HTML-compatible web browser. Second, and implied by the prior point, MMV mobile-banking websites and DI online-banking websites have completely different URLs and are hosted on entirely different web servers (Choi Dep. 24243; Buckner Decl. ¶¶ 317). To illustrate these differences, shown below are the online-banking and mobile-banking websites for USE Credit Union, one of Digital Insight's many customers. The "home page" for USE Credit Union's DI online-banking website (as accessed from a desktop computer) is shown on the left, while the "home page" for USE Credit Union's MMV mobile-banking website (as accessed from a smartphone) is shown on the right (Buckner Decl. ¶¶ 7, 9):
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
programmed to "detect" whether a mobile device is being used to access it. URL: https://www.usecu.org/home/home URL: https://m.diginsite.com/usecu/
As these screenshots demonstrate, the content displayed on a DI online-banking website makes full use of a large amount of screen space and -- with the inclusion of numerous graphics -- fast download speeds. By contrast, the content on an MMV mobile-banking website is streamlined for efficiency on a much smaller screen, and much slower download speeds.
13
1 2 3 4 5 6 7 8 9 10
B.
The "Bill Pay/Make a Payment" Feature
Using either a DI online-banking website or an MMV mobile-banking website, depositors can perform various account-related activities such as viewing their account balances, making payments to third parties, and transferring funds. Both sides have focused their attention on only one of these features throughout this litigation: the "Bill Pay/Make a Payment" feature. It is on this particular feature of the accused system that this order will focus as well. 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):
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 14 While the graphics, colors, and logos may differ between DI online-banking websites for Digital Insight's various financial-institution customers, the screenshot shown above accurately reflects how the "Bill Pay/Make a Payment" web page is formatted for all of Digital Insight's onlinebanking customers.
1 2 3 4 5 6 7 8 9 10
As shown in the screenshot, the DI online-banking website's "Bill Pay/Make a Payment" web page is content-rich. There is a list of numerous payees on the left portion of the page and pending and processed payments on the right portion of the page. The web page also contains multiple text boxes, date-selection boxes, and buttons. On this page, a depositor can specify a payment amount and date for any of the payees listed and make a payment to that payee. By contrast, the "Bill Pay/Make a Payment" web page found on USE Credit Union's MMV mobile-banking website has a much simpler interface. As shown below, a simple list of "payees" is first displayed to the depositor (left). The name of each payee is displayed as a 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 be specified (right) (Dkt. No. 87 at 61, 63; Buckner Dep. 11820, 16466):
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Whether a depositor uses his or her financial institution's DI online-banking website or an MMV mobile-banking website to make a payment, the result is the same: the depositor's bank or credit union will make the payment to the designated payee on the specified date. C. How the Accused DI/MMV System "Works"
* The screenshots shown herein of the accused DI/MMV system do not display actual banking or account information of depositors.
According to MShift, the accused DI/MMV system -- which operates all of the MMV mobile-banking websites offered by Digital Insight to its clients -- infringes claim 20 of the '881 patent. Defendants, of course, contend exactly the opposite. To resolve this dispute, the innerworkings of the DI/MMV system must be examined. 15
1 2 3 4 5 6 7 8 9 10
In a nutshell, the DI/MMV system works as follows: First, a depositor enters the URL of the MMV mobile-banking website for his financial institution into a HTML-compatible web browser, which triggers a HTTP request to be sent to the MMV mobile-banking website. The DI/MMV system responds to this request by displaying the "home page" of the MMV mobilebanking website as shown earlier in this order, not the DI online-banking website. Once the depositor provides his username and password to access his account, he is presented with various account management options, including a "Bill Pay/Make a Payment" option. As stated, since both sides focus exclusively on this particular feature of the accused system, this order will also focus solely on this feature. Second, assuming that the depositor selects the "Bill Pay/Make a Payment" link on the MMV mobile-banking website, another HTTP request is immediately sent from depositor's web browser to the DI/MMV system to display the MMV mobile-banking website's "Bill Pay/Make a Payment" web page. After receiving this request, the DI/MMV system begins the process of retrieving the necessary account data for that particular depositor to display on the "Bill Pay/Make a Payment" web page. Specifically, the DI/MMV system must retrieve a list of payees associated with the depositor's bank account(s), the last amount paid to each payee, and the date that each payee was last paid. To retrieve this information, the DI/MMV system uses a process called "screen scraping" to extract this data from the financial institution's DI online-banking website (Buckner Decl. ¶ 19; Otteson Decl. Exhs. 1013; Choi Dep. 75, 10304; Lee Dep. 54). In carrying out this process, the DI/MMV retrieves one or more web pages from the DI onlinebanking website to extract the data that it needs.8 Third, after the DI/MMV system has "screen scraped" the data it needs from the financial institution's DI online-banking website, it repackages the information into an intermediary format and then integrates the data into pre-programmed web-page templates called "style sheets." Style sheets are used to format the "Bill Pay/Make a Payment" web page for display on the particular
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."
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
16
1 2 3 4 5 6 7 8 9 10
mobile device being used by the depositor (Buckner Decl. ¶ 19, Exhs. 9, 10, 14; Choi Dep. 3334, 9091, 19194, 19799). This particular step bears repeating. Once the DI/MMV system has "screen scraped" the list of payees, last payment amounts, and last payment dates from the financial institution's DI online-banking website, the data is integrated into MMV mobilebanking website templates that have been pre-designed. In other words, the placement of every link, button, and text box on an MMV mobile-banking website has been preordained -- these web-page features are not derivative of features on a DI online-banking website. 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. A flow chart summarizing this process is shown below:
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 17
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. 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.
º
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.
DI Online-Banking Website "Bill Pay/Make a Payment" Page
DI/MMV System
»
»
1 2 3 4 5 6 7 8 9 10
As this process makes clear, when a depositor browses to the "Bill Pay/Make a Payment" web page on an MMV mobile-banking website, all of the account and transaction information displayed to the depositor has been extracted by the DI/MMV system from the financial institution's DI online-banking website. For this reason, the MMV mobile-banking website for any particular bank or credit union will not work properly if the financial institution's DI onlinebanking website is inaccessible or otherwise "offline" (Buckner Dep. 135). D. MShift's Infringement Contentions
According to MShift, the mobile-banking system described above infringes claim 20. 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 request for a content from a network site." Under this theory of infringement, the "network site" is not the MMV mobile-banking website, but the corresponding DI online-banking website of the depositor's bank or credit union. This asserts that the DI/MMV system described above serves as the "conversion engine." Given this backdrop, MShift alleges -- as it must to prove infringement -- that the DI/MMV system serves as a "language translator" between mobile devices and DI online-banking websites. In other words, MShift contends that mobile devices accessing MMV mobile-banking websites are receiving content in an entirely different language than the content provided directly by DI online-banking websites, and the DI/MMV system -- the "conversion engine" herein -- is what enables these mobile devices to communicate with DI online-banking websites. Additionally, MShift argues that the DI/MMV system "restructures" a plurality of "input entries" within the content provided by DI online-banking websites into "selectable links" for display on these mobile devices. As discussed below, the undisputed factual record and a proper construction of the relevant claim language defeat MShift's allegations. . 3. PROCEDURAL HISTORY
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
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 2 3 4 5 6 7 8 9 10
to file an amended complaint naming MMV and eleven additional Digital Insight financialinstitution customers as defendants (Dkt. No. 86). During this process, one of the developers of the accused DI/MMV system -- a Korean company named SK C&C Co. Ltd. -- moved for and was granted leave to intervene as a defendant (Dkt. No. 118). Defense counsel provided ample notice that they intended to file the instant summary judgment motion. This intention was communicated to MShift as early as the Rule 26(f) conference held on April 21, 2010, and was repeated again in the joint case management statement filed on May 6 (Valentine Decl. ¶ 3; Dkt. No. 54). Beginning on May 7, before 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). During the case management conference held before the undersigned judge on May 13, defendants again voiced their intention of filing an early summary judgment motion on noninfringement grounds. In discussing this prospect with all counsel, the undersigned judge stated (Long Decl. Exh. A at 910): 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. At the same case management conference, the undersigned judge also provided fair warning to counsel for MShift that if defense counsel "made it very clear" that they "will produce everyone . . . that could reasonably have anything to do with the grounds on which [defendants] are going to move," then a summary judgment motion would not ordinarily be premature (id. at 11). On May 21, defense counsel provided MShift with a detailed outline of every argument they intended to raise in their summary judgment motion. The same communication also offered to make "DI and MMV technical witnesses . . . and 30(b)(6) witnesses available for deposition immediately" (Valentine Decl. ¶ 5, Exh. A) (emphasis in original). Defense counsel also told MShift that "[f]or any witness [MShift] depose[s] in May or June 2010, [defendants] will agree to 19
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
1 2 3 4 5 6 7 8 9 10
make that witness available for a second deposition at a later date." This offer was intended to allow MShift to "develop an understanding of the DI and MMV technology relatively quickly without feeling any need to save [its] `one shot' with a witness until a later stage of discovery" (ibid.). Defendants then notified MShift that the instant motion would be filed on or before July 8, with a hearing noticed for August 12. On June 4, immediately after receiving MShift's infringement contentions, defendants supplemented their May 21 disclosures with an even more detailed outline of their noninfringement arguments (id. at ¶ 6). That same day, MShift served a set of interrogatories on Digital Insight, requesting full disclosure of the basis of defendants' non-infringement position. Defendants responded to the request two days later (id. at ¶ 7, Exh. B). MShift then served its amended infringement contentions on June 15. In response, on June 18, defendants sent another letter to plaintiff identifying an additional argument of non-infringement as well as their views on the particular claim construction issues relevant to the instant motion (id. at ¶ 8, Exh. C). Also on June 18, MShift served a second set of document production requests on Digital Insight, seeking essentially all technical documents and communications concerning the design, development, use, and testing of the DI/MMV system. After meeting and conferring with plaintiff's counsel, defense counsel agreed to produce responsive documents and communications from eleven different custodians. Additionally, defendant MMV, to whom no document requests were directed, voluntarily agreed to produce responsive documents and communications from three different custodians (id. at ¶ 9). In addition to these document productions, both Digital Insight and MMV produced the source code for two of the financial institution defendants as requested by MShift (id. at ¶¶ 1011). With respect to defendant-intervenor SK C&C, even before it moved to intervene in this action, seven of its design and development documents as well as over 700 email communications between MMV and SK C&C spanning the entire development period for the accused mobilebanking system were produced by MMV (id. at ¶¶ 1213). In total, defendants produced approximately 186,000 pages of responsive technical documents to MShift between May 7 and July 23. Additionally, between June 28 and July 10, defendants produced (and MShift deposed) 20
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
1 2 3 4 5 6 7 8 9 10
seven technical witnesses with knowledge relating to the design and functionality of the accused DI/MMV system (id. at ¶ 14). In mid-July, after defendants' opening brief had already been filed, MShift asked defendants for a three-week extension to file its opposition brief to the instant motion for summary judgment. In its request, plaintiff cited the need for additional discovery of technical documents from defendant-intervenor SK C&C. In response, defendants agreed to provide plaintiff with a fifteen-day extension -- giving MShift a total of five weeks to prepare its opposition brief -- and also agreed to produce the requested SK C&C documents immediately. 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 following caveat (ibid.): 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. Despite this agreement between the parties, on August 6, the same day that MShift filed its opposition brief to the instant motion, MShift also filed a Rule 56(f) motion citing the need for additional discovery from defendant-intervenor SK C&C on the technical details of the accused DI/MMV system. A hearing on the instant motion was held on September 2. At the hearing, the undersigned judge probed MShift's counsel on their infringement theories -- in particular, whether the DI/MMV system "restructured" any "input entries" into "selectable links." Nevertheless, in an abundance of caution, defendant-intervenor SK C&C was ordered to search through its documents again to ensure that all responsive documents to any reasonable discovery request had been produced. MShift was also granted two additional depositions of SK C&C employees with knowledge of the accused mobile-banking system and SK C&C's production of relevant technical documents. Following this extended discovery period, both sides were allowed to submit lengthy supplemental briefs to bolster their respective positions. All parties took full advantage of this opportunity. 21
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
1 2 3 4 5 6 7 8 9 10
Three days after these supplemental briefs were filed, MShift moved for monetary and discovery sanctions against defendants pursuant to FRCP 37. According to MShift, defendants had taken every opportunity to "hide the ball" with respect to producing information necessary for plaintiff to defend against the instant motion. Specifically, the motion contends that defendants failed to identify in their initial disclosures the names of certain SK C&C engineers with knowledge of the accused system, and were "deliberately evasive" about the role that a Nepalese company named FocusOne played in the development of the accused system. Despite these accusations of discovery misconduct, however, MShift readily admitted throughout its Rule 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. at 8). In other words, despite allegedly improper tactics by defendants, MShift believed that it had received all the discovery necessary to defeat the instant motion on the merits. Finally, while all these events unfolded, the parties completed their briefing on claim construction issues. A technology tutorial was held on September 22, followed by a claim construction hearing on September 30. This order follows and is based upon all of the filings and hearings mentioned herein. ANALYSIS Summary judgment is proper when the "pleadings, depositions, answers to interrogatories, and admissions on file, together with the affidavits, show that there is no genuine issue as to any material fact and that the moving party is entitled to judgment as a matter of law." FRCP 56(c). An issue is "genuine" only if there is sufficient evidence for a reasonable fact-finder to find for the non-moving party, and "material" only if the fact may affect the outcome of the case. Anderson v. Liberty Lobby, Inc., 477 U.S. 242, 24849 (1986). All reasonable inferences, however, must be drawn in the light most favorable to the non-moving party. Olsen v. Idaho State Bd. of Med., 363 F.3d 916, 922 (9th Cir. 2004). That said, unsupported conjecture or conclusory statements are insufficient to defeat summary judgment. Surrell v. Cal. Water Serv. Co., 518 F.3d 1097, 1103 (9th Cir. 2008).
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
22
1 2 3 4 5 6 7 8 9 10
These standards apply equally to summary judgment motions involving patent infringement claims. See Union Carbide Corp. v. American Can Co., 724 F.2d 1567, 1571 (Fed. Cir. 1984). To survive a motion for summary judgment of non-infringement, a patentee must set forth competent evidence that "features of the accused product would support a finding of infringement under the claim construction adopted by the court, with all reasonable inferences drawn in favor of the non-movant." Intellectual Science and Technology, Inc. v. Sony Electronics, Inc., 589 F.3d 1179, 1183 (Fed. Cir. 2009) (citing Arthur A. Collins, Inc. v. N. Telecom Ltd., 216 F.3d 1042, 104748 (Fed. Cir. 2000)). If expert testimony is provided by the 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 Ltd. v. Brown & Williamson Tobacco Corp., 509 U.S. 209, 242 (1993). Unsupported conclusions on the ultimate issue of infringement will not alone create a genuine issue of material fact for trial. Arthur A. Collins, 216 F.3d at 1046. Defendants' motion for summary judgment of non-infringement focuses on two limitations set forth in claim 20: (1) the requirement of a "first language" and "second language," and (2) the "conversion engine" that "restructures a plurality of input entries within the content" of the network site "into selectable links" on the mobile device. Before these limitations can be addressed, however, this order must first resolve relevant issues regarding claim construction. 1. CLAIM CONSTRUCTION
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
The parties' claim construction briefs focus on four disputed terms and phrases in claim 20 of the '881 patent: (1) "language," (2) "input entries," (3) "directly linked," and (4) "signaling the content to be rendered as one or more pages." Only the first two terms are relevant to the resolution of defendants' summary judgment motion. This order does not need to reach the remaining terms and phrases. A. "Language"
The dispute over this claim term is admittedly narrow. Both sides agree that the term "language" as used in claim 20 of the '881 patent refers to a programming language. Indeed, the intrinsic evidence is clear on this point (see, e.g., cols 1:2836, 2:5258, 2:653:21, 3:4245). 23
1 2 3 4 5 6 7 8 9 10
Where the parties disagree is whether any further limitations apply. Specifically, plaintiff proposes that "language" be construed as "programming that is operable on a network site or a mobile device; examples of languages include HTML, CHTML, wireless markup language (WML), and HDML." Defendants, by contrast, argue that the "plain and ordinary meaning" of "language" as used throughout the '881 patent should apply. According to defendants, this means that a language must "couple network sites and mobile devices," "allow either a single or multiple input entries per page," and be limited to "markup languages." Additionally, defendants assert that a language must "determine which network sites can be accessed" by mobile devices. 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. Lear Corp., 516 F.3d 1331, 1335 (Fed. Cir. 2008). While claim terms "are generally given their ordinary and customary meaning," the "claims themselves provide substantial guidance as to the meaning of particular claim terms." Phillips v. AWH Corp., 415 F.3d 1303, 1312, 1314 (Fed. Cir. 2005) (en banc) (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). The specification of a patent is also highly relevant to claim construction. Indeed, claims "must be read in view of the specification, of which they are a part." Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed.Cir.1995) (en banc), aff'd, 517 U.S. 370 (1996). Finally, courts should give due consideration to a patent's prosecution history, which "can inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be." Phillips, 415 F.3d at 1318 (citations omitted). These components of the intrinsic record are the primary resources in properly construing claim terms. Id. at 131718. As stated, the term "language" as used in claim 20 is undoubtedly a programming language. Indeed, the specification provided an express, if not lexicographic, definition of this term as used in the '881 patent (col. 3:4245): 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
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
1 2 3 4 5 6 7 8 9 10
This straightforward construction -- that a language is "programming used to couple network sites and mobile devices" -- is all that is necessary to properly construe this term. The additional limitations and clarifications proposed by the parties are unnecessary in light of the use of "language" in claim 20. First, it is implied from the adopted construction that a "first language" (as used in claim 20) is operable on a mobile device and a "second language" (as used in claim 20) is operable on a network site. Second, the surrounding text in claim 20 makes clear that both the "first language" and "second language" must allow "multiple input entries per page." Since these limitations are set forth expressly in the claim language, it is unnecessary to 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 specification, it would be improper to read such a limitation into the claims.9 See Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 90405 (Fed. Cir. 2004). Fourth, it is implied from the adopted construction and the intrinsic evidence that the "language" used by a particular mobile device determines which network sites it can access (see col. 1:2930). In sum, this order construes "language" as "programming used to couple network sites and mobile devices" -- exactly as the specification defined it and consistent with its usage throughout the claim language and intrinsic evidence. Any other limitations mentioned above are either implied by this construction, implied by the context of its use in claim 20, or expressly set forth within the asserted claim as separate limitations. B. "Input Entries"
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
The term "input entries" as found in claim 20 presents a more contentious dispute. Defendants propose that "input entries" be construed as "[f]eatures that allow a user to enter information into a page, such as text entry fields, icons, menu items, and check-fields." MShift, by contrast, proposes that "input entries" be more broadly construed as "[f]eatures that allow a user to provide input." As its briefing makes clear, plaintiff intends its proposed construction to
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."
9
25
1 2 3 4 5 6 7 8 9 10
encompass descriptive labels that accompany text entry fields as well as hidden data not even displayed to depositors on a web page. As a preliminary matter, both sides agree that the features encompassed by defendants' proposed construction -- namely, features that "allow a user to enter information into a page, such as text entry fields, icons, menu items, and check-fields" -- are "input entries" within the meaning of the '881 patent. Indeed, the specification expressly lists "text-entry fields, icons, check-fields assigning Boolean values, and selectable items provided in a menu" as specific examples of "input features" (col. 8:1113). In this connection, both sides also agree that the 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 specification and even within in certain patent claims (e.g., claim 13). Where the parties diverge, however, is on whether "input entries" can extend beyond "features that allow a user to enter information into a page" to labels and hidden form elements that are never displayed on a web page. As explained below, the intrinsic evidence does not support such a broad construction. First, the ordinary and customary meaning of the term "input entries" to a person having ordinary skill in the relevant art supports defendants' narrower construction. Indeed, MShift's own expert, Dr. Sandeep Chatterjee, who is proffered by plaintiff as being someone with ordinary skill in the relevant art, conceded in his declaration that "defendants' proposed construction [of `input entries'] provides more detail and clarity [than plaintiff's proposed construction], which is consistent with and supported by the patent" (Chatterjee Claim Const. Decl. ¶ 27). Dr. Chatterjee no doubt recognized that plaintiff's proposed construction lacked sufficient detail and clarity and could be used to improperly cover web page features that did not allow a user to enter information into a page. Second, plaintiff's proposed construction would improperly cover features that the specification clearly indicated were not "input entries." As stated, the specification made frequent reference to mobile devices that used HDML to request and receive content from network sites. In this connection, the specification expressly recognized that HDML was "limited to displaying a single input feature per rendered network page" (col. 7:4853) (emphasis added). 26
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
1 2 3 4 5 6 7 8 9 10
Displaying multiple selectable links on the same page, however, was clearly not a problem for HDML-based mobile devices. This can be concluded because the restructuring of a plurality of input entries into multiple selectable links was exactly the workaround proposed by the '881 patent to bypass the "single input feature" problem. As such, "selectable links" are clearly not "input features" or "input entries" within the meaning of the '881 patent. The specification also made clear that the physical buttons on a mobile device and "wording or graphics" on a web page were not "input entries" (see cols. 4:510, 8:3034). Plaintiff's proposed construction, however, could easily be used to cover "selectable links," "wording or graphics," and the physical buttons 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 to cover in light of the intrinsic evidence: features displayed on a web page, like text entry fields, menu items, and check fields, that allow a user to enter information into the page (see col. 7:5058). Third, the prosecution history -- and in particular, MShift's representations to the USPTO to distinguish the claims of the '881 patent from the prior art -- provides the final nail in the coffin for plaintiff's proposed construction. To allow MShift to expand the meaning of "input entries" beyond its HDML (or equivalent) context would enable plaintiff to recapture territory that it surrendered during the course of prosecuting the asserted patent. As stated, the Schwartz and Jamtgaard references disclosed the use of a conversion engine between mobile devices and network sites to reformat web pages, translate between different programming languages, and "break up" content into multiple pages using selectable links (see Yamashita Claim Const. Decl. Exhs. 1, 3).10 After the USPTO repeatedly rejected its patent application due to these prior art references, MShift finally obtained the '881 patent by arguing to the patent examiner that the Schwartz and Jamtgaard references did not teach the particular "restructuring" of "input entries" -- necessitated by the inherent limitations of HDML -- as set forth in the claims. To allow
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 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:5567), 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:2339).
27
1 2 3 4 5 6 7 8 9 10
MShift to now expand the meaning of "input entries" to encompass mere labels and other webpage features that do not allow a user to input information into the page would be improper in light of this history. See Phillips, 415 F.3d at 1318 (citations omitted). For these reasons, this order construes "input entries" as "features displayed on a web page that allow a user to enter information into the page, like text entry fields, menu items, and check fields." 2. NON-INFRINGEMENT OF THE '881 PATENT
Turning now to the merits of defendants' motion for summary judgment, two independent arguments are presented by defendants as to why the accused DI/MMV system does not infringe. Both are compelling. A. The "First Language" and "Second Language" Limitation
United States District Court
11
For the Northern District of California
12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
Defendants' first non-infringement argument targets the "first language" and "second language" limitation found in claim 20. According to defendants, this limitation is not met by
]]>
Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.
Why Is My Information Online?
