Mshift, Inc. v. Digital Insight Corp.

747 F.Supp.2d 1147 (2010)

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.

No. C 10-00710 WHA.

United States District Court, N.D. California.

October 8, 2010.

Daniel J. Bergeson, Melinda Mae Morton, Bergeson, LLP, San Jose, CA, James Carl Otteson, Xiang Long, Agility IP Law, East Palo Alto, CA, for Plaintiff.

Andrew P. Valentine, Brent Kevin Yamashita, Erik Fuehrer, DLA Piper LLP, East Palo Alto, CA, Heather Nicole Mewes, Hector J. Ribera, Rodger R. Cole, Songmee L. Connolly, Fenwick & West LLP, Mountain View, CA, for Defendants.

Jingming James Cai, Schein & Cai LLP, San Jose, CA, Brian S. Seal, Highbury Chapman LLC, Washington, DC, Hae-Chan Park, Wayne Michael Helge, H.C. Park & Associates, PLC, Pro Hac, Vice, Vienna, VA, for Defendant-Intervenor.

CLAIM CONSTRUCTION ORDER, ORDER GRANTING DEFENDANTS' MOTION FOR SUMMARY JUDGMENT, AND ORDER DENYING PLAINTIFF' MOTION FOR SANCTIONS

WILLIAM ALSUP, District Judge.

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, plaintiffs 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.

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 mobile-banking 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, high-speed 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

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:1-3). As explained throughout the specification and prosecution history, the '881 patent was not directed 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: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.

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:39-42). 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:28-31) (emphasis added). Stated differently, the "conversion engine" claimed by the '881 patent acted as a translator between mobile devices and "network sites."

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:26-52):

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:

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:53-57). 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:37-38). 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:45-46). 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:1-5). 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:3-6). 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:6-9). In sum, these four steps demonstrate how the conversion 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:28-31).

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:

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:35-37, 14:45-47). 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 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:17-44). 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:19-20, 10:40-43, 12:43-49, 13:49-52, 14:45-52). 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:30-34).

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 "text-entry fields, icons, check-fields assigning Boolean values, and selectable items provided in a menu" (cols. 7:50-58, 8:11-13).^[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:55-58). 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.

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:41-55, 8:10-16). 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: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.

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:13-34). 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.

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:41-44). 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:4-13).

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. B-E).

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.

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

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). 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 v. 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 online-banking 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 mobile-banking 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 HTML-compatible 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 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. 242-43; Buckner Decl. ¶¶ 3-17).

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):

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.

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):

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 online-banking customers.

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. 118-20, 164-66):

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"

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 inner-workings of the DI/MMV system must be examined.

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 mobile-banking 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. 10-13; Choi Dep. 75, 103-04; Lee Dep. 54). In carrying out this process, the DI/MMV retrieves one or more web pages from the DI online-banking 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 mobile device being used by the depositor (Buckner Decl. ¶ 19, Exhs. 9, 10, 14; Choi Dep. 33-34, 90-91, 191-94, 197-99). 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 mobile-banking 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:

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 online-banking 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

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 to file an amended complaint naming MMV and eleven additional Digital Insight financial-institution 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 non-infringement grounds. In discussing this prospect with all counsel, the undersigned judge stated (Long Decl. Exh. A at 9-10):

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 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 plaintiffs 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 ¶¶ 10-11).

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 ¶ 12-13). 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) 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.

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, 248-49, 106 S.Ct. 2505, 91 L.Ed.2d 202 (1986). All reasonable inferences, however, must be drawn in the light most favorable to the nonmoving 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).

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, 1047-48 (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, 113 S.Ct. 2578, 125 L.Ed.2d 168 (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

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:28-36, 2:52-58, 2:65-3:21, 3:42-45). 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, 116 S.Ct. 1384, 134 L.Ed.2d 577 (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 1317-18.

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:42-45):

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.

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, 904-05 (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:29-30).

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"

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 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:11-13). 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 plaintiffs 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:48-53) (emphasis added). 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:5-10, 8:30-34). Plaintiffs 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:50-58).

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 plaintiffs 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 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

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 the accused DI/MMV system. The relevant claim language is set forth below (col. 14:28-34) (emphases added):

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

As stated, a "language" is "programming used to couple network sites and mobile devices." As used in claim 20, both sides agree that a "first language" refers to the programming language used by a mobile device to request and receive content from network sites, and a "second language" refers to the programming language used by a network site to send and receive content. Both sides also agree that the "first language" and "second language" must be different programming languages (Br. 12-14; Opp. 9-16). This, of course, is supported by a plain reading of claim 20 in light of the specification—there would be no need for a "conversion engine" to "convert the content from the second language to the first language" if both the mobile device and the network site communicated in the same language (col. 14:40-42).

Given this backdrop, defendants contend that both the mobile devices and DI online-banking websites (i.e., the "network sites") in the accused DI/MMV system communicate using the same language: HTML (Br. 12-14). Moreover, even if MShift's argument that the DI onlinebanking websites provide content in XHTML 1.0 (rather than HTML) is credited, defendants contend that XHTML 1.0 and HTML do not satisfy the "first language" and "second language" limitation of claim 20 because they are both entirely compatible with HTML browsers. Both of these points are addressed below.

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 communicates with mobile devices in HTML, and only HTML. To support this contention, defendants point to a number of items of evidence, including the very same technical schematic of the DI/MMV system relied upon by MShift in its opposition brief. This schematic of the accused system shows that HTML is programming language outputted to mobile browsers by the accused system (Opp. 7; Otteson Decl. Exh. 13). Additionally, defendants point to the underlying source code and deposition testimony from multiple technical witnesses showing that the DI/MMV system—while perhaps capable of outputting content in other formats— only outputs HTML to mobile devices (see, e.g., Buckner Decl. ¶ 31, Exh. 4; Buckner Dep. 110; Potel Decl. ¶¶ 48-51; J. Choi Dep. 87-88, 91, 195, 239; Lee Dep. 58-61, 86, 137; Kang Dep. 60, 155). This evidence all supports the conclusion that the accused system only outputs HTML to mobile devices.

MShift's "evidence" rebutting this point fails to create a genuine issue of fact on this topic. Specifically, MShift points to a cherry-picked selection of style sheets (among a large number of style sheets) that were stored in a digital folder produced by defendants during discovery that—if actually used by the accused system—would supposedly output content to mobile phones in non-HTML languages such as WML, HDML, XHTML, XML, and WAP (see Chatterjee Suppl. Decl. ¶¶ 28-57; Chatterjee Decl. ¶¶ 43-44, 65-70, 73). The problem is, there is no evidence that these particular style sheets were ever used by the accused system. Indeed, when specifically asked at their depositions whether the DI/MMV system made use of these particular style sheets or outputted content to mobile devices in non-HTML languages, all technical witnesses said "no" (see Lee Dep. 61, 86, 137; J. Choi Dep. 239; Kang Dep. 60, 155; see also Buckner Decl. ¶¶ 31-32; Potel Decl. ¶¶ 48, 50).^[11] The reason for this is simple: the DI/MMV system was not designed to be used by older phones that lacked HTML-browsing capabilities.

The only evidence MShift cites to support its contention that these non-HTML style sheets were ever used by the DI/MMV system is its assertion that defendants' counsel, Wayne Helge, "confirmed" that these style sheets were being used by the accused system (see, e.g., Chatterjee Suppl. Decl. ¶¶ 40, 44, 48, 52). Contrary to MShift's assertion, however, Attorney Helge never "confirmed" anything of the sort. In fact, the deposition transcript cited by MShift to support this argument says nothing about these particular style sheets being used by the accused system (see S. Choi Dep. 30-31). Rather, Attorney Helge merely stated that the folder in which these style sheets were located was produced as part of the DI/MMV system. This statement does not come close to "confirming" that every single style sheet produced to plaintiff was actually being used by the accused system, especially in light of the overwhelming evidence to the contrary.

None of plaintiff's remaining arguments is persuasive. For example, there is no evidence that content was ever sent to mobile devices from the accused system in WCML format (Kang Dep. 75-76). Rather, the record shows that WCML was an intermediate format used internally by the DI/MMV system (J. Choi Dep. 198-201). Another failed argument by MShift is that a "change request" in the record, which appears to show defendants requesting a WAP-based style sheet, is evidence from which a reasonable jury could find that the accused system sent content to mobile devices in WAP format. Deposition testimony, however, confirms that the style sheets created in response to this exact change request were HTML style sheets (Kang. Dep. 69-70). Finally, MShift's last gasp attempt to stave off summary judgment is an argument that defendants can be liable for patent infringement for "offering to sell" the capability of having the DI/MMV system output content in WAP or WML format (Suppl. Br. 7). Not only is this argument untimely (as it is based upon a marketing brochure that MShift had in its possession prior to filing its original opposition brief to the instant summary judgment motion), it lacks merit as well. The only evidence cited by MShift in support of its "offering to sell" allegation does not sufficiently show that defendants made a commercial offer to sell an infringing product.

In sum, based upon the arguments and evidence presented by both sides, there is no genuine issue of material fact that the accused system communicates with (i.e., sends content and information to) mobile devices exclusively in HTML.

ii. XHTML 1.0 is Not a Different Language from HTML in the Context of the '881 Patent and Claim 20.

The argument over whether the DI online-banking websites output content in XHTML or HTML format has been thoroughly briefed by both sides. Both Dr. Chatterjee and Dr. Potel have opined in detail over this question in multiple declarations. According to MShift's software expert, Dr. Chatterjee, the "DOCTYPE" declaration prominently displayed in the source code of web pages rendered on a DI online-banking website is ample proof for a reasonable jury to find that the accused "network site" displays its content in "XHTML 1.0" format rather than in HTML format (Chatterjee Decl. ¶ 72, Exh. R; Chatterjee Suppl. Decl. ¶¶ 62-65).^[12] This order agrees.

The inquiry, however, does not end with this small victory. Even assuming that the DI online-banking websites (i.e., the "network sites") provide content and information in "XHTML 1.0" format, this does not mean that the "first language" and "second language" limitation in the asserted claim has been met. As stated, the reason why the "first language" and "second language" in claim 20 must be different from each other in the context of the asserted claim is because there would be no need for a conversion engine to enable the mobile device to retrieve content from a network site if the languages were the same. In this connection, the specification of the '881 patent repeatedly emphasized that an advantage of the claimed invention—and in particular, the conversion engine of the invention—was that it enabled and allowed communication between mobile devices and network sites that used different languages (see, e.g., cols. 1:39-41, 1:48-51, 2:28-31, 3:38-41). This logically implies that the "first language" and "second language" in claim 20 must be sufficiently "different" such that without the "conversion engine" as an intermediary, the mobile device would not be able to access, couple with, or communicate with the network site.

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 accessed by HTML browsers. This is true regardless of whether the web pages displayed on the DI online-banking websites are written in "XHTML 1.0" format, as MShift asserts, or HTML, as defendants assert (see, e.g., Potel Decl. ¶¶ 15 n. 2, 48; Potel Suppl. Decl. ¶ 8). As even plaintiffs expert Dr. Chatterjee admits, the differences between these two languages are purely grammatical (e.g., "XHTML 1.0" requires that tags be properly closed, while HTML is more forgiving). In other words, whether the DI online-banking websites are programmed in "XHTML 1.0" or HTML is a distinction without a difference. This conclusion is further bolstered by the fact that "XHTML 1.0" was intended merely to be a "reformation" of modern HTML. Both languages share the same root element— ""—and use the exact same "tags" to denote various web page features (Potel Claim Const. Decl. ¶¶ 22-25, 61, Exh. C). In short, whether written in "XHTML 1.0" or HTML, the "network sites" of the accused DI/MMV system can communicate with, and are accessible by, all mobile devices equipped with HTML browsers.

With this point established, it is undisputed that there is no "language barrier" preventing the same HTML-compatible mobile devices that can access and communicate with MMV mobile-banking websites from directly accessing and communicating with DI online-banking websites (Buckner Decl. ¶ 32; Potel Decl. ¶ 48). Stated differently, there is no need for any "conversion engine" to translate between "XHTML 1.0" and HTML so that these mobile devices can view web pages on the alleged "network sites." No translation is necessary.

In sum, even crediting MShift's argument that the DI online-banking websites communicate in "XHTML 1.0," the differences between "XHTML 1.0" and HTML are insufficient as a matter of law to satisfy the "first language" and "second language" limitation set forth in claim 20 of the '881 patent. For this reason, there can be no infringement of claim 20 by the accused DI/MMV mobile-banking system.

B. The "Restructuring" Limitation

As a separate and independent ground for granting its summary judgment motion, defendants contend that the accused DI/MMV system does not contain anything close to a "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 patent (col. 14:45-47).

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 information into the page, like text entry fields, menu items, and check fields." These "input entries within the content" are distinguished from "other content"—like labels and graphics—merely presented to the user as static information or obscured from the user as hidden fields. Given the prosecution history of the '881 patent, the accused system must contain this particular limitation for infringement to be found. It would be improper to allow MShift to extend the infringing reach of "input entries"—whether through claim construction or under the doctrine of equivalents—to encompass labels, graphics, and hidden form elements. See Honeywell Int'l, Inc. v. Hamilton Sundstrand Corp., 523 F.3d 1304, 1312 (Fed.Cir.2008) (prosecution history estoppel "prevents a patent owner from recapturing with the doctrine of equivalents subject matter surrendered to acquire a patent").

In support of their motion for summary judgment of non-infringement, defendants unleash a two-pronged attack on MShift's contention that the DI/MMV system "restructures" a plurality of "input entries" within the content of the DI online-banking website into "s electable links" that 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 depositor-specific data from within the content. Once this data has been extracted, the remaining content retrieved from the DI online-banking website—including any "input entries" therein—is ignored. Second, the extracted data—and only the extracted data—is then inserted into predesigned web-page templates for the MMV mobile-banking website. As such, there is no "restructuring" or "reformatting" of any "input entries" within the content of the DI onlinebanking website into "selectable links" displayed on the MMV mobile-banking website. Rather, all of the links shown on the MMV mobile-banking website have been pre-programmed to be there regardless of whether any "input entries" are found within the content of the DI online-banking website.

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.

According to defendants, the "screen scraping" component of the accused mobile-banking system—which is the component of the DI/MMV system that interacts directly with the alleged "network sites"— is not concerned about restructuring "input entries" (like text entry boxes, check boxes, and menu items) within the content of DI online-banking websites. Rather, the accused DI/MMV system uses DI-online banking websites solely as "virtual databases" that contain depositor-specific account data. This data is then used to populate style sheets used to display web pages on MMV mobile-banking websites (see, e.g., Otteson Decl. Exh. 13). In other words, the "screen scraping" of DI online-banking websites is all about retrieving data. It has nothing to do with "input entries."

MShift's own demonstration of how defendants' mobile-banking system allegedly infringes claim 20 of the '881 patent confirms that this claim limitation has not been met. As detailed in MShift's supplemental brief, the "screen scraping" of depositor-specific data from the DI online-banking website for use in the MMV mobile-banking website's "Bill Pay/Make a Payment" web pages is performed by a particular server-side computer file—programmed in Java—within the accused system (Suppl. Br. 9-12; Chatterjee Suppl. Decl. ¶¶ 68-74, Exhs. M, 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 "Bill Pay/Make a Payment" web page (and potentially other content) from the DI online-banking website (Chatterjee Suppl. Decl. ¶ 68, Exh. M at 2084-85). After this content has been retrieved, other functions in the Java file are used by the accused system to extract payment accounts, payee names, last payment amounts, and last payment dates from the content (id. at ¶ 69, Exh. M at 2086-88). This extracted depositor-specific data is then fed into the style sheets for the "Bill Pay/Make a Payment" web pages of the MMV mobile-banking website.

In his supplemental declaration, MShift's expert, Dr. Chatterjee, focuses exclusively on the extraction of payee information from the DI online-banking website by this particular Java file. Going line-by-line through the source code, Dr. Chatterjee contends that the Java file searches through the HTML (or XHTML 1.0) of the "Bill Pay/Make a Payment" web page from the DI online-banking website until it locates particular "" tags within the source code (id. at ¶ 69, Exh. M at 2086-88, Exh. N).^[14] The purpose of HTML "" tags is clearly explained by defendants' expert, Dr. Potel, in his claim construction declaration (Potel Claim Const. Decl. ¶ 61). Once the "" tag is found, the Java application retrieves and stores the data located in the "id" attribute of the "" tag. The Java application then searches for different HTML tags called "" tags (id. at ¶¶ 69-70, Exh. M at 2086-88, Exh. N). Once these "" tags have been found, the Java application retrieves and stores the data located in the "value" attribute of these particular "" tags. The purpose of HTML "" tags is also clearly explained by defendants' expert, Dr. Potel, in his claim construction declaration (Potel Claim Const. Decl. ¶ 61). This extracted data is then integrated into particular hyperlinks that appear on the MMV mobile-banking website (Chatterjee Suppl. Decl. ¶ 68-73).

Dr. Chatterjee's analysis, however, contains a fatal flaw. It presumes that the "" tags and "" tags from which the Java application extracts data are associated with "input entries" within the content of the DI online-banking website. They are not. A "" tag—by itself—does not display any "input entries" on a web page. Only so-called "form elements," denoted by "" tags, are capable of displaying such "input entries" (Potel Claim Const. Decl. ¶ 61). Critically, however, not all form elements actually display "input entries" on a web page to a user. For example, form elements denoted by "" are completely invisible to users. As such, they are not features on a web page that allow a user to input data into the page. Rather, such form elements are used to store vital information "behind the scenes" that would be meaningless to a depositor if displayed on the page (such information would include numerical database "ids" corresponding to a depositor's bank accounts, payees, and payment methods). As such, "hidden" form elements are most definitely not "input entries" as construed by this order.^[15]

Here's why this is important: the particular Java function discussed in detail by Dr. Chatterjee and within MShift's supplemental brief extracts data exclusively from "hidden" form elements in the DI online-banking website (Chatterjee Suppl. Decl. ¶ 70; Suppl. Br. 10). In other words, the function does not extract data from any text entry boxes, check boxes, menu items, or any other web-page features that are displayed to the user and allow a user to enter information into the page. As such, MShift's best evidence of infringement fails to live up to its billing. Not only does the accused DI/MMV system extract only data from within the content of the DI online-banking website, this data is not even extracted from any "input entries" as defined herein.

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 by one of the functions in the Java application discussed above, there is no evidence that "selectable links" displayed on the MMV mobile-banking website are created by "restructuring" 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 scrape" the DI online-banking website retrieves content from the so-called "network site," it scours the content for data. It does not perform a search for "input entries within the content" to "restructure" into "selectable links" (Buckner Decl. ¶¶ 11-29, Exhs. 1-3; Buckner Dep. 48, 112, 121-22, 126-27; J. Choi Dep. 75, 122-25, 140-42, 245-46; Lee Dep. 42-43). Second, even assuming that data is extracted from a HTML "" tag that happens to correspond to a text box, menu option, or check box, there is no evidence that the "input entry" itself is "restructured" into "selectable links" by the accused system.

Indeed, as explained earlier in this order, the hyperlinks displayed on the "Bill Pay/Make a Payment" web pages of an MMV mobile-banking website have already been programmed to be there through the use of style sheets. They are not generated on-the-fly by the DI/MMV system in response to the "restructuring" of any "input entries" on the DI online-banking website. Stated differently, the existence of links on the MMV mobile-banking website is not contingent upon the presence of a corresponding input entry within the content of the alleged "network site." True, the number of hyperlinks displayed to a user, the text displayed in each hyperlink, and the exact destination address of each hyperlink may change depending upon data that has been retrieved from HTML tags corresponding to "input entries" on the DI online-banking website. Even crediting this proposition, however, the fact remains that the existence of these hyperlinks on the MMV mobile-banking website does not depend upon the "restructuring" of these "input entries" (J. Choi Dep. 122-25, 140-42; Buckner Decl. ¶¶ 11-18, 26, 28, Exhs. 1-3). Rather, their existence and placement on the MMV mobile-banking website depends solely upon the style sheets used to display the web pages (see Choi Dep. 122-25, 140-42).

Neither MShift nor its expert, Dr. Chatterjee, can point to any other source code, technical document, or witness testimony showing that the accused system "restructures" input entries into "selectable links" in the manner required by claim 20. Beyond his failed analysis of the Java application revealed above, Dr. Chatterjee can only opine on the "look and feel" of the "Bill Pay/Make a Payment" web pages on the DI online-banking website and the MMV mobile-banking website to summarily conclude that "[c]learly, the input entries from the bill pay site are restructured into selectable links" (Chatterjee Decl. ¶¶ 76-79).

Given that MShift readily admitted that it "managed to establish all that it needs to defeat defendants' summary judgment motion" and that defendants "ultimately produced the technical documents MShift needed to solidify its summary judgment opposition," this wholly unsupported conjecture by Dr. Chatterjee is telling. In any event, it cannot defeat summary judgment. See Surrell, 518 F.3d at 1103; see also Brooke Group Ltd. v. Brown & Williamson Tobacco Corp., 509 U.S. 209, 242, 113 S.Ct. 2578, 125 L.Ed.2d 168 (1993) (an expert opinion unsupported by sufficient facts and unreasonable in light of the undisputed factual record cannot support a favorable jury's verdict).

Finally, as its "kitchen sink" argument on the issue of "restructuring," MShift points to a specific mobile device—the Nokia 2720—as providing "overwhelming evidence" that the accused system "restructures input entries into selectable links" (Opp. 23). The proof, according to plaintiff, is that "a drop down menu on USE Credit Union's mobile banking [website] is restructured into several selectable links on the Nokia 2720 phone" (Moeller Decl. ¶¶ 54-58, Exhs. 49-54). As with Dr. Chatterjee's superficial "screenshot-based" analysis exposed above, this contention by MShift—which even Dr. Chatterjee did not endorse—is supported solely by screenshots of the Nokia 2720 phone accessing USE Credit Union's MMV mobile-banking website. Similar to Dr. Chatterjee's "screenshot-based" analysis, this assertion is completely divorced from the actual source code produced by defendants showing how the accused system actually works (Buckner Reply Decl. ¶ 3; Potel Reply Decl. ¶¶ 20-21). Indeed, as defendants point out in their reply brief, even a cursory inquiry into how Nokia phones work would have revealed that it is Nokia's own proprietary software that performs this reformatting of drop-down menus (Reply 15). This perhaps explains why this argument never resurfaces in MShift's supplemental brief, and plaintiff's expert, Dr. Chatterjee, never signs on to it. Being wholly unsupported by the undisputed record, this order rejects this final, unreasonable argument. Williamson Tobacco, 509 U.S. at 242, 113 S.Ct. 2578.

* * *

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 existence of genuine issues of material fact regarding whether the accused DI/MMV system infringes claim 20 of the '881 patent. MShift cannot show that all limitations in claim 20 of the '881 patent are present either literally or by a substantial equivalent in the accused system. See TechSearch, L.L.C. v. Intel Corp., 286 F.3d 1360, 1371 (Fed.Cir.2002). As such, defendants' motion for summary judgment of non-infringement is GRANTED.

3. PLAINTIFF'S RULE 37 MOTION FOR SANCTIONS

MShift's motion under FRCP 37 seeks both monetary and preclusion sanctions due to allegedly "willful" violations by defendants of their discovery obligations under FRCP 26 and three court orders pertaining to discovery. Also inexplicably thrown into plaintiffs Rule 37 motion is a one-sentence request, under FRCP 56(f), to deny defendants' motion for summary judgment due to these supposed discovery shenanigans. As explained below, the record does not support granting any sanctions against defendants under FRCP 37.

A. Sanctions Under FRCP 37(c)

Plaintiffs request for monetary and preclusion sanctions under FRCP 37(c) is premised solely upon defendants' supposed failure to properly disclose technical witness Byoung Ho Kang in its initial or amended disclosures. According to plaintiff, because Mr. Kang was not disclosed by defendants pursuant to FRCP 26(a)(1)(A) or FRCP 26(e)(1), defendants should not be allowed to cite to his deposition testimony in their response to MShift's supplemental brief.

This argument is a non-starter. Defendants did not anticipate relying on Mr. Kang's testimony in support of their claims or defenses, and did not in fact rely on his testimony in their opening and reply briefs for their motion for summary judgment. It was only after MShift elected to depose Mr. Kang after the September 2 hearing and after MShift cited his testimony in its supplemental brief that his testimony became part of the summary judgment record. Given this backdrop, MShift was not required to disclose the identity of Mr. Kang in its initial disclosures under FRCP 26(a)(1)(A).

Since no violation of FRCP 26(a)(1)(A) has occurred, sanctions under FRCP 37(c) are 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 to supplement the record with other portions of Mr. Kang's testimony to rebut and give context to the excerpts cited in MShift's supplemental brief. The rule of completeness allows this. The request for preclusion and monetary sanctions under FRCP 37(c) is DENIED.

B. Sanctions Under FRCP 37(b)

Plaintiff's request for monetary sanctions under FRCP 37(b) is based solely upon accusations of "delay" and alleged "violations" of court orders regarding defendants' discovery obligations. As explained below, these allegations do not justify any award of sanctions against defendants.

The full extent of discovery obtained by MShift was set forth earlier in this order. Only the essential points will be repeated here. Despite the grievances advanced by plaintiff, this order finds that defendants reasonably followed an "open book" strategy in producing technical documents and witnesses to plaintiff. Defendants also extended the briefing schedule by two weeks to provide plaintiff extra time to conduct additional discovery on the technology developed by intervenor SK C & C (including two depositions). In return, MShift expressly agreed to "not assert a Rule 56(f) objection" if the requested technical documents and witnesses with knowledge about the DI/MMV system from SK C & C were produced (Valentine Decl. Exh. D). These documents were produced and two additional witnesses from SK C & C were deposed by MShift on July 22 (id. at ¶¶ 8-12). Defendants then asked MShift to identify any materials that it believed had not been produced by DI, MMV, or SK C & C. Plaintiff did not inform defendants of any deficiencies.

Without any effort to meet and confer, and despite the above agreement, MShift filed a Rule 56(f) motion alongside its original opposition to defendants' summary judgment motion. The basis of the Rule 56(f) motion was that defendants had prevented discovery of an important component of the accused system—specifically, the component responsible for "screen scraping" the DI online-banking websites called "xMAS." Out of an abundance of caution, at the September 2 hearing, the Court granted Rule 56(f) relief and ordered that MShift be given the opportunity to conduct additional discovery on SK C & C and take two more depositions of SK C & C witnesses: one who supposedly handled the production of technical documents and the other of any technical witness of MShift's choice. MShift elected to depose Mr. Kang on the details of the elusive "xMAS" component.

Both depositions went forward as scheduled. Specifically, Mr. Soo Young Choi was deposed by plaintiff and testified as to the document production efforts that had been undertaken by SK C & C both prior to and after the September 2 hearing (S. Choi Dep. 100-03). These document production efforts are covered in convincing detail in defendants' opposition to plaintiff's Rule 37 motion (Sanctions Opp. 11-13).

With respect to Mr. Kang, it was during his deposition that MShift asserts it was ambushed with the news that a Nepalese business entity called FocusOne had been involved in the development of the xMAS component. According to MShift, both Mr. Kang and FocusOne had been improperly "hidden" by defendants during the discovery process (Sanctions Br. 10).^[16] In any event, Mr. Kang was asked directly during his deposition if he had knowledge of the critical xMAS component of the accused system (Kang Dep. 149-150):

Q: Are you familiar, Mr. Kang, with how the xMAS solution works?

A: I am very familiar with that.

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.

Despite Mr. Kang's familiarity with the very xMAS component for which MShift was granted supplemental discovery, counsel for plaintiff were not interested in the merits of whether the xMAS component actually "restructured" any "input entries" into "selectable links." Instead, MShift focused its attention on the role that FocusOne played in the development of the xMAS component.

This misdirection has been characteristic of MShift's strategy in defending against the instant summary judgment motion. Despite ample discovery—specifically, access to hundreds of thousands of pages of technical documents, eleven depositions of technical witnesses, and the opportunity to review source code of the accused product—MShift has not been able to uncover any competent evidence that the accused DI/MMV system works differently than how every witness and declarant has described under oath. FocusOne represents MShift's continued efforts to distract the Court from the mountains of evidence demonstrating that the accused DI/MMV system does not infringe its patent.

In light of the full record, this order finds that defendants reasonably complied with all discovery-related orders and directives set forth by the Court. As such, monetary sanctions under FRCP 37(b)(2)(C) are unwarranted and DENIED.

C. Relief Under FRCP 56(f)

Plaintiff's request for relief under FRCP 56(f) is DENIED. Not only was the request inadequately briefed, it cannot be emphasized enough that MShift repeatedly stated in its filings that it "managed to establish all that it needs to defeat defendants' summary judgment motion on the merits" and that "defendants ultimately produced the technical documents MShift needed to solidify its summary judgment opposition" (Sanctions Br. 3, 12, 17).

Indeed, not every patent case needs to churn on for years. Businesses have a legitimate need to know where they stand when accused of infringement, so that ongoing operations do not incur ever-mounting potential liability. MShift has now taken eleven depositions and has received over 186,000 pages of technical documentation in the months since the initial case management conference. Defendants have cooperated in isolating the key noninfringement issues and facilitating discovery thereon, all with an above-board effort to get to the bottom of the case with efficiency. The record compels summary judgment. It would be a waste of resources to allow MShift to go on additional fishing expeditions in vague hopes that something might turn-up. Enough is enough.

4. PLAINTIFF'S EVIDENTIARY OBJECTIONS

On August 25, MShift filed evidentiary objections targeting declarations submitted in support of defendants' summary judgment motion.^[17] None of these objections changes the 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 respect to Peter Buckner's declaration in reply (which is limited solely to responding to this argument), MShift's objections are OVERRULED. Paragraph three of Mr. Buckner's reply declaration, which discusses the "style sheet" used by the DI/MMV system to render web pages on the Nokia 2720 phone, is neither "conclusory" nor lacking in "evidentiary support." When read in conjunction with the comprehensive declaration Mr. Buckner submitted in support of defendants' summary judgment motion, the statements made in Mr. Buckner's declaration in reply are admissible. The earlier declaration established Mr. Buckner's qualifications and firsthand knowledge to make such statements, and set forth a sufficient factual basis to support the information presented in his reply declaration. MShift's second objection to this particular paragraph, brought under the Best Evidence Rule, also fails. Not only did Mr. Buckner attach the particular "style sheet" being discussed to his earlier declaration, he was not providing evidence of the source code therein—rather, he was providing his opinion that it was written in HTML rather than XML.

Second, MShift objects to various paragraphs in the reply declaration of defendants' expert, Dr. Potel. A number of these targeted paragraphs—specifically, paragraphs 12 through 16—pertain solely to the XML versus HTML "language" debate. According to MShift, Dr. Potel should have raised these points in his opening declaration. This order disagrees. The particular paragraphs targeted by MShift are admissible to rebut specific representations made in MShift's opposition brief and by its expert, Dr. Chatterjee. Plaintiff also objects to paragraphs 19 and 20 in Dr. Potel's reply declaration, which responds to MShift's Nokia 2720 argument. Specifically, MShift asserts that Dr. Potel failed to authenticate the source code referenced in these particular paragraphs, stating that "it is unclear how this code was generated" and "whether it came from where Dr. Potel claims it came from." This argument also fails. As he explained in paragraphs 19 and 20 of his reply declaration, Dr. Potel obtained the source code from the "`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 without this evidence, plaintiff's "look and feel" arguments based solely upon superficial interactions with the Nokia 2720 phone are insufficient to defeat summary judgment. In sum, plaintiff's objections targeting Dr. Potel's reply declaration are OVERRULED.

Finally, on September 29, MShift filed a separate evidentiary objection to any reliance by defendants on the deposition testimony of Mr. Kang in their response to MShift's supplemental brief. As explained above, defendants were not required to disclose Mr. Kang as part of their initial disclosures under FRCP 26(a)(1)(A), because they were not intending to rely upon his testimony in any claims or defenses. Rather, it was MShift who chose to depose Mr. Kang. Accordingly, his deposition testimony may certainly be used by defendants to rebut points made in MShift's supplemental brief based upon Mr. Kang's testimony. The rule of completeness would also allow this evidence to come in. For these reasons, this last objection is OVERRULED.

All of MShift's remaining evidentiary objections target material this order neither cites nor relies upon (e.g., paragraph six of the Prior declaration). As such, they need not be addressed by this order.

CONCLUSION

For the reasons set forth herein, and based upon the claim constructions set forth above, defendants' motion for summary judgment of non-infringement is GRANTED. Plaintiffs Rule 37 motion for monetary and preclusion sanctions is DENIED. Pursuant to the stipulation filed by defendants on October 8, defendants' counterclaims for declaratory judgment of patent invalidity, patent unenforceability, and absolute and equitable intervening rights are DISMISSED (Dkt. No. 332). Both sides are ORDERED TO SHOW CAUSE why all remaining state claims should not be dismissed and remitted to state court BY NOON ON FRIDAY, OCTOBER 15, 2010.

IT IS SO ORDERED.

NOTES

[1] 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).

[2] 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).

[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.

[4] 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).

[5] 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.

[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 online-banking 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 programmed to "detect" whether a mobile device is being used to access it.

[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."

[9] 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."

[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).

[11] 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.

[12] 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."

[13] 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).

[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 "" and "" tags (Potel Suppl. Decl. ¶ 12).

[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).

[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.