UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG, S.A.
`Patent Owner
`
`
`
`
`
`
`
`
`
`
`
`
`Patent 7,587,207
`
`
`
`
`
`
`
`
`
`
`
`
`
`DECLARATION OF DR. CHARLES D. KNUTSON
`IN SUPPORT OF THE PETITION
`
`
`
`
`
`1
`
`APPLE 1003
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.
`Petitioner
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG, S.A.
`Patent Owner
`
`
`
`
`
`
`
`
`
`
`
`
`Patent 7,587,207
`
`
`
`
`
`
`
`
`
`
`
`
`
`DECLARATION OF DR. CHARLES D. KNUTSON
`IN SUPPORT OF THE PETITION
`
`
`
`
`
`1
`
`APPLE 1003
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`
`
`I.
`
`INTRODUCTION ........................................................................................... 1
`
`II.
`
`SUMMARY OF CONCLUSIONS ................................................................. 1
`
`III. QUALIFICATIONS AND EXPERIENCE ..................................................... 2
`
`IV. DOCUMENTS REVIEWED .......................................................................... 7
`
`V.
`
`LEGAL UNDERSTANDINGS ....................................................................... 7
`
`VI. RELEVANT FIELD AND LEVEL OF ONE OF ORDINARY SKILL
`IN THE ART ................................................................................................. 11
`
`VII. THE ’207 PATENT .....................................................................................101
`
`VIII. OVERVIEW OF MCCALL ....................................................................... 144
`
`IX. OVERVIEW OF BT CORE ......................................................................... 17
`
`A.
`
`COMBINATION OF MCCALL AND BT CORE ............................. 18
`
`X. OVERVIEW OF LARSSON ......................................................................... 23
`
`A.
`
`COMBINATION OF MCCALL, BT CORE, AND
`LARSSON ........................................................................................... 25
`
`XI. OVERVIEW OF HANCOCK ....................................................................... 29
`
`A.
`
`COMBINATION OF MCCALL, BT CORE, LARSSON,
`AND HANCOCK................................................................................ 31
`
`XII. CLAIMS 1-3, 5, 6, AND 9-11 OF THE 207 PATENT ARE
`RENDERED OBVIOUS BY MCCALL, BT CORE, LARSSON,
`AND HANCOCK .......................................................................................... 33
`
`XIII. CONCLUSION .............................................................................................. 50
`
`
`
`
`
`
`
`i
`
`2
`
`
`
`
`
`
`DECLARATION EXHIBITS
`
`APPLE-1001
`
`U.S. Patent No. 7,587,207 to Davies (“’207 Patent”)
`
`APPLE-1002
`
`Prosecution History of the ’207 Patent (“the Prosecution
`History”)
`
`APPLE-1004
`
`Curriculum Vitae of Dr. Charles Knutson
`
`APPLE-1005 U.S. Patent No. 6,738,628 (“McCall”)
`
`APPLE-1006 U.S. Patent No. 5,806,017 (“Hancock”)
`
`APPLE-1007 Specification of the Bluetooth System: Wireless connections
`made easy, Core, Vol. 1, Bluetooth, Dec. 1, 1999 (“BT Core”)
`
`APPLE-1008 U.S. Patent No. 6,255,800 (“Bork”)
`
`APPLE-1009
`
`[Reserved]
`
`APPLE-1010 Internet Archive Capture of
`http://www.bluetooth.com:80/developer/specification/specificat
`ion.asp from March 1, 2000
`
`APPLE-1011 Internet Archive Capture of
`http://www.bluetooth.com:80/developer/specification/core.asp
`from March 1, 2000
`
`APPLE-1012 Internet Archive Capture of
`http://www.bluetooth.com:80/developer/specification/order.asp
`from March 1, 2000
`
`APPLE-1013 Internet Archive Capture of
`http://www.bluetooth.com:80/news/archive/archive.asp from
`March 4, 2000
`
`APPLE-1014 U.S. Patent No. 6,704,293 (“Larsson”)
`
`
`
`ii
`
`3
`
`
`
`APPLE-1015 PCT Patent Application Publication No. WO 01/41371
`(“Rune”)
`
`
`
`
`
`
`
`
`iii
`
`4
`
`
`
`
`
`
`I, Charles D. Knutson, hereby declare the following:
`
`I.
`
`INTRODUCTION
`
`1.
`
`I have been retained by Fish & Richardson P.C., counsel for Apple Inc.
`
`(“Apple” or “Petitioner”), to analyze certain issues relating to the validity of certain
`
`claims of U.S. Patent No. 7,587,207 (“’207 Patent”).
`
`2.
`
`In forming the opinions I have expressed in this declaration, I have
`
`reviewed the ’207 patent, its file history, the Petition for Inter Partes Review from
`
`Apple, and any documents cited or listed in this declaration. Furthermore, my
`
`opinions are also based on my experience and knowledge (as detailed further below).
`
`3.
`
`I have been retained on behalf of Apple Inc., and am being compensated
`
`for my work on this matter. My compensation is not contingent upon the outcome
`
`of this matter.
`
`II.
`
`SUMMARY OF CONCLUSIONS
`
`4.
`
`As explained below, my opinion is that a POSITA would have viewed
`
`claims 1-3, 5, 6, and 9-11 of the ’207 patent as being obvious in view of U.S. Patent
`
`No. 6,738,628 (“McCall”), U.S. Patent No. 5,806,017 (“Hancock”), U.S. Patent No.
`
`6,704,293 (“Larsson”), and Specification of the Bluetooth System: Wireless
`
`connections made easy, Core, Vol. 1, Bluetooth, Dec. 1, 1999 (“BT Core”).
`
`
`
`1
`
`5
`
`
`
`
`
`
`III. QUALIFICATIONS AND EXPERIENCE
`
`5.
`
`I received my Doctor of Philosophy (Ph.D.) degree in the field of
`
`Computer Science from Oregon State University in 1998. I received my Master of
`
`Science (M.S.) and Bachelor of Science (B.S.) degrees in Computer Science from
`
`Brigham Young University.
`
`6.
`
`Since 1986, I have been engaged in engineering, management,
`
`research, and instructional positions. During my undergraduate education at
`
`Brigham Young University between 1985 and 1988, I focused on operating systems,
`
`leading to my employment as a development engineer at Hewlett-Packard between
`
`May, 1988, and February, 1989. During that time, I developed low-level system
`
`software for the HP Vectra personal computer.
`
`7.
`
`I was employed as a development engineer, test engineer, and manager
`
`at Novell, Inc. between March, 1989, and September, 1994. During that time, I
`
`became very familiar with the theory and operation of data communication systems
`
`and system software. As a system test manager at Novell, I pioneered the creation
`
`of cutting edge system test tools for automated validation of network protocols.
`
`8.
`
`I was founder of ComSoft Consulting in Corvallis, Oregon. In this
`
`capacity, between September, 1994, and October, 1996, I did consulting work for
`
`clients including Intel and Novell. My consulting work for Novell included creating
`
`functional and test specifications for the installation of certain Novell software
`
`
`
`2
`
`6
`
`
`
`
`
`
`products in the context of a Novell NetWare local area network. My consulting
`
`work for Intel included design and implementation of multi-protocol network
`
`communication mechanisms.
`
`9.
`
`I was Vice President of Research and Development for Counterpoint
`
`Systems Foundry, Inc. (acquired in 1997 by Extended Systems, Inc., later spun off,
`
`and currently operating as OpenSynergy, Inc.) from September, 1996, to September,
`
`1999. My development group created the infrared beaming capability that 3Com
`
`Corporation employed in their PalmOS handheld devices. My development group
`
`also created infrared and Bluetooth development platforms (including commercial
`
`Bluetooth protocol stacks for embedded platforms and products) that have become
`
`de facto standards in the embedded/handheld device market worldwide.
`
`10.
`
`I was Chair of the Test and Interoperability Committee of the Infrared
`
`Data Association (IrDA) from February, 1998, to October, 1999, and served as a
`
`member of the IrDA Architecture Council from February 1998 to April 2008. I was
`
`also a member of the Infrared Object Exchange (IrOBEX) Working Group from
`
`January 2002 to December 2005, helping to define standards for data object
`
`exchange in IrDA and Bluetooth. In addition, I was a member of the IrDA Financial
`
`Messaging Working Group (February, 2001 to December, 2005), Convenor of the
`
`IrDA Digital Imaging SIG (October, 1997 to October, 1999), Co-Convenor of the
`
`IrOBEX Interoperability Working Group (February, 1998 to October, 1998),
`
`
`
`3
`
`7
`
`
`
`
`
`
`Convenor of the IrDA Test Frames Working Group (February, 1998), and member
`
`of the IrDA Interoperability Test Council (July, 1997 to February, 1998).
`
`11.
`
`I created and presented short courses on embedded systems, data
`
`communications, software quality, and software engineering at the Embedded
`
`Systems Conference, Portable by Design Conference, Wind River Developers
`
`Conference, and other industry venues over a nine-year period from 1997 to 2005.
`
`12. Since July, 1987, I have taught college-level courses on computer
`
`organization and assembly language programming, operating systems, programming
`
`languages, databases, networking, wireless data communications (including
`
`communication protocols and location services), systems performance analysis,
`
`software quality, and software engineering.
`
`13.
`
`I have authored or co-authored two books on networking and data
`
`communications, 57 academic papers (21 of which involved data communications),
`
`six standards documents for the Infrared Data Association, and 43 trade journal and
`
`magazine publications (including articles on network administration, network
`
`product installation, and data communications).
`
`14.
`
`I have served in leadership positions, including Organizing Committee,
`
`Technical Program Committee, Panel Moderator, Session Chair, Tutorial Instructor,
`
`and Reviewer, at academic conferences focused on data communications and
`
`software quality. These conferences include the ACM SIGMOBILE International
`
`
`
`4
`
`8
`
`
`
`
`
`
`Conference on Mobile Computing and Networking, the ACM Symposium on
`
`Mobile Ad Hoc Networking & Computing, the IEEE GLOBECOM General
`
`Symposium, the IEEE International Conference on Computer Communications and
`
`Networks, the IEEE Symposium on Ad Hoc Wireless Networks, the IEEE Vehicular
`
`Technology Conference Symposium on Integrated Heterogeneous Wireless
`
`Networks, the IEEE Wireless Communications and Networking Conference, the
`
`International Conference on Evaluation and Assessment in Software Engineering,
`
`the International Symposium on Empirical Software Engineering and Measurement,
`
`and the International Conference on Open Source Systems.
`
`15.
`
`I have served as a reviewer for academic journals focused on data
`
`communications and mobile computing including the IEEE Transactions on
`
`Wireless Communications. I have also served as a reviewer for academic journals
`
`focused on software engineering, including IEEE Transactions on Software
`
`Engineering and Methodology, IEEE Transactions on Software Engineering,
`
`Empirical Software Engineering, and Information and Software Technology.
`
`16.
`
`I was a faculty member in the Computer Science Department at
`
`Brigham Young University from July, 2000, to December, 2014, as an Assistant
`
`Professor and then as a tenured Associate Professor.
`
`17.
`
`I was the founder and Director of the Mobile Computing Laboratory in
`
`the Computer Science Department of Brigham Young University in Provo, Utah
`
`
`
`5
`
`9
`
`
`
`
`
`
`from 2000
`
`to 2008, conducting
`
`research
`
`in short-range wireless data
`
`communications, with emphasis on infrared and Bluetooth data communications.
`
`During my tenure as Director of the Brigham Young University Mobile Computing
`
`Laboratory, I advised twelve graduate students (11 Master of Science candidates and
`
`one Doctoral candidate) whose research focused on wireless data communications.
`
`18.
`
`In 2006, I founded the SEQuOIA (“Software Engineering Quality:
`
`Observation, Insight, Analysis”) at Brigham Young University and established a
`
`graduate research program in empirical software engineering. During my tenure as
`
`Director of the SEQuOIA Lab, I advised nine graduate students (eight master of
`
`science candidates and one doctoral candidate) whose research focused on empirical
`
`software engineering.
`
`19.
`
`In 2013, I received the Brigham Young University Technology
`
`Transfer Award. I am currently an Emeritus Professor of Computer Science at
`
`Brigham Young University.
`
`20.
`
`In August, 2018, I joined the faculty at Utah Valley University as an
`
`Associate Professor of Computer Science,
`
`teaching courses
`
`in computer
`
`organization and assembly language programming, analysis of programming
`
`languages, and software design.
`
`
`
`6
`
`10
`
`
`
`
`
`
`21. Additional details concerning my professional qualifications,
`
`experience, and publications are set forth in my curriculum vitae (“CV”) provided
`
`as Exhibit 1004.
`
`IV. DOCUMENTS REVIEWED
`
`22.
`
`I have reviewed the exhibits listed in the Declarations Exhibit List
`
`included above, as well as any other documents referenced herein but not included
`
`on the exhibit list.
`
`V. LEGAL UNDERSTANDINGS
`
`23.
`
`I am informed by counsel for the Petitioner and understand that
`
`statutory and judicially created standards must be considered to determine the
`
`validity of a patent claim. I have reproduced standards relevant to this declaration
`
`in this section, as provided to me by counsel for Petitioner and as I understand them.
`
`24.
`
`I am informed by counsel for the Petitioner and understand that a claim
`
`is unpatentable for obviousness under 35 U.S.C. § 103 “if the differences between
`
`the subject matter sought to be patented and the prior art are such that the subject
`
`matter as a whole would have been obvious at the time the invention was made to a
`
`person having ordinary skill in the art to which said subject matter pertains.” 35
`
`U.S.C. § 103. I am informed by counsel for the Petitioner and understand that
`
`obviousness may be based upon a single reference or a combination of references. I
`
`am informed by counsel for the Petitioner and understand that the combination of
`
`
`
`7
`
`11
`
`
`
`
`
`
`familiar elements according to known methods is likely to be obvious when it does
`
`no more than yield predictable results. However, I am informed by counsel for the
`
`Petitioner and understand that a patent claim composed of several elements is not
`
`proved obvious merely by demonstrating that each of its elements was,
`
`independently, known in the prior art.
`
`25.
`
`I am informed by counsel for the Petitioner and understand that when a
`
`patented invention is a combination of known elements, a court must determine
`
`whether there was an apparent reason to combine the known elements in the fashion
`
`claimed by the patent at issue by considering the teachings of prior art references,
`
`the effects of demands known to people working in the field or present in the
`
`marketplace, and the background knowledge possessed by a person having ordinary
`
`skill in the art.
`
`26.
`
`I am informed by counsel for the Petitioner and understand that a patent
`
`claim composed of several limitations is not proved obvious merely by
`
`demonstrating that each of its limitations was independently known in the prior art. I
`
`am informed by counsel for the Petitioner and understand that identifying a reason
`
`those elements would be combined can be important because inventions in many
`
`instances rely upon building blocks long since uncovered, and claimed discoveries
`
`almost of necessity tend to be combinations of what, in some sense, is already
`
`known. I am informed by counsel for the Petitioner and understand that it is
`
`
`
`8
`
`12
`
`
`
`
`
`
`improper to use hindsight in an obviousness analysis, and that a patent's claims
`
`should not be used as a “roadmap” to combine prior art references.
`
`27.
`
`I am informed by counsel for the Petitioner and understand that an
`
`obviousness inquiry requires consideration of the following factors: (1) the scope
`
`and content of the prior art; (2) the differences between the claims and the prior art;
`
`(3) the level of ordinary skill in the pertinent art; and (4) any objective indicia of
`
`non-obviousness, such as commercial success, long-felt but unresolved need, failure
`
`of others, industry recognition, copying, and unexpected results. I understand that
`
`the foregoing factors are sometimes referred to as the “Graham factors.”1
`
`28.
`
`I am informed by counsel for Petitioner that objective indicia of non-
`
`obviousness can be evidence of nonobviousness in the record, and enables the Patent
`
`Trial and Appeal Board (“Board”) and the courts to avoid the trap of hindsight. I
`
`am further informed that such evidence must always be present when considered in
`
`connection with an obviousness determination. Further, to be afforded substantial
`
`weight, the objective indicia of nonobviousness must be tied to the novel elements
`
`of the claims at issue, but the objective indicia need only be reasonably
`
`commensurate with the scope of the claims. I am not aware of evidence of objective
`
`indicia of non-obviousness relevant to the ’207 patent.
`
`
`1 See KSR Int’l v. Teleflex Inc., 550 U.S. 398, 406-07 (2007) (quoting Graham v.
`John Deere Co., 383 U.S. 1, 17-18 (1966)).
`
`
`
`9
`
`13
`
`
`
`
`
`
`29.
`
`I am informed by counsel for the Petitioner and understand that all prior
`
`art references are to be looked at from the viewpoint of a person of ordinary skill in
`
`the art. Furthermore, obviousness is analyzed from the perspective of one of
`
`ordinary skill in the art at the time of the invention.
`
`VI. RELEVANT FIELD AND LEVEL OF ONE OF ORDINARY SKILL
`IN THE ART
`
`30.
`
`In my remarks below, I may use the acronym “POSITA” to refer to a
`
`person of ordinary skill in the art at or preceding the date of June 26, 2000. In my
`
`opinion, a POSITA would have had Master of Science Degree (or a similar technical
`
`Master’s Degree, or higher degree) in an academic area emphasizing electrical
`
`engineering or computer engineering with a concentration
`
`in wireless
`
`communication systems or, alternatively, a Bachelor of Science Degree (or higher
`
`degree) in an academic area emphasizing electrical or computer engineering and
`
`having two or more years of experience in wireless communication systems.
`
`31. Additional education in a relevant field, or industry experience may
`
`compensate for a deficit in one of the other aspects of the requirements stated above.
`
`I am at least a POSITA, and my opinions herein are from the standpoint of a POSITA
`
`during the relevant time frame.
`
`
`
`10
`
`14
`
`
`
`
`
`
`VII. THE ’207 PATENT
`
`32. The ’207 patent, entitled “Data Delivery Through Beacons,” was filed
`
`on June 7, 2001, and issued on September 8, 2009.
`
`33. The ’207 Patent describes a wireless communication system that
`
`includes beacons and “Context-Aware” (CA) devices. Ex. 1001, Abstract, 2:14-27.
`
`CA devices (e.g., mobile phones and personal digital assistants) are portable user
`
`devices that use “low power, short range base stations” referred to as “beacons,” “to
`
`provide location-specific information” to a user. Ex. 1001, 1:3-20.
`
`34. The ’207 Patent aimed to address problems related to connecting user
`
`devices to a Bluetooth piconet network. In particular, the ’207 Patent explains that
`
`when a user device wanted to join the piconet, the connection process required for a
`
`beacon device to connect to a user device might take over 10 seconds. Ex. 1001,
`
`7:18-31. This was problematic because user devices typically did “not spend enough
`
`time near a given beacon to establish a Bluetooth link.” Ex. 1001, 7:18-31. As a
`
`result, a user device would “not know its current location” and “the operation of any
`
`location aware applications on the terminal” would be impaired. Ex. 1001, 10:1-
`
`11.
`
`35.
`
`In an attempt to address the problems noted above, the ’207 Patent
`
`discloses a system in which “the amount of dedicated circuitry and operating
`
`procedure are kept to low levels.” Ex. 1001, 1:65-2:13. In the ’207 Patent’s system,
`
`
`
`11
`
`15
`
`
`
`
`
`
`CA devices “quickly and efficiently gather data from beacons such that the user is
`
`not required to undertake actions such as staying close to a beacon whilst contact is
`
`established between portable device and beacon.” Ex. 1001, 1:65-2:5.
`
`36. The ’207 Patent’s system includes a plurality of beacons 102, 104, 106,
`
`108 distributed throughout a locale, such as a department store, shopping, mall,
`
`theme park, or other infrastructure. Ex. 1001, FIG. 2, 5:52-65. “A portable device
`
`that wants to be discovered by a beacon [utilizing the Bluetooth protocol] enters the
`
`inquiry scan substate. Here, it listens for a[n inquiry] message” that contains an
`
`additional data field and a General Inquiry Access Code (GIAC) or (Dedicated
`
`Inquiry Access Code) DIAC of interest. Ex. 1001, 6:65-67, 7:32-35, 6:49-55, 6:62-
`
`65. For instance, as shown in the ’207 Patent’s FIG. 5 (below), “inquiry messages
`
`have an extra field appended to them, capable of carrying a user-defined payload
`
`(CA DATA).” Ex. 1001, 7:45-55.
`
`
`’207 Patent, FIG. 5 (additional data field carrying location information in red)
`
`37. The appended field includes location information. Ex. 1001, 10:12-16.
`
`“The location information may take a number of forms in both the format location
`
`information is represented and in the format it is broadcast. For example, the
`
`
`
`12
`
`16
`
`
`
`
`
`
`information may be represented in terms of mapping coordinates, Global Positioning
`
`System data, or any other suitable way. Location information may be absolute or
`
`relative. In the latter case location information may be expressed, for example, with
`
`reference to building room designations, vehicle identity (say, when a person is on
`
`a bus) or in other ways as will be apparent to the person skilled in the art.” Ex. 1001,
`
`11:27-36. Effectively, by combining the location information with the inquiry
`
`message, a beacon can transmit pertinent location information to devices in its
`
`vicinity in a shorter time span and with fewer (exchanged) messages.
`
`38.
`
`“On hearing an inquiry containing an appropriate IAC, the portable
`
`device enters a so-called inquiry response substate and issues a number of inquiry
`
`response messages to the beacon. The beacon will then page the portable device,
`
`inviting it to join the piconet.” Ex. 1001, 8:40-45.
`
`39.
`
`In order to mitigate possible confusion for someone immersed in
`
`modern data communications standards, such as WiFi, I am adding remarks related
`
`to the recitation of “beacon” in the ’207 Patent. The ’207 Patent uses the term
`
`“beacon” specifically to refer to the devices that send signals, not to the signals that
`
`are sent. For example, “[t]hese beacons are small infrared transceivers …” Ex. 1001,
`
`1:57-58. As another example, “… such that the user is not required to undertake
`
`actions such as staying close to a beacon whilst contact is established between
`
`portable device and beacon …” Ex. 101, 1:67-2:2.
`
`
`
`13
`
`17
`
`
`
`
`
`
`40.
`
`It seems clear from my reading of the ’207 patent specification and
`
`claims that a “beacon” refers to the hardware system (including system and
`
`application software) that transmits or broadcasts data, and not to the data
`
`transmissions themselves. I also note, consistent with this understanding, that the
`
`terms “beacon” and “beacon device” are used interchangeably in the ’207 Patent. I
`
`also note that the term “beacon signal” is used consistently in the ’207 to refer to the
`
`broadcast message sent by a beacon.
`
`VIII. OVERVIEW OF MCCALL
`
`41.
`
`I have reviewed McCall extensively. In McCall, communications
`
`between devices may be implemented using the Bluetooth protocol. Ex. 1005,
`
`Abstract, 2:47-52, 5:5-15. McCall’s FIG. 1 (reproduced below) shows a wireless
`
`communication network with beacons 102-112 located “throughout a floor of a
`
`building 100 in which assets 120, 122 are to be tracked.” Ex. 1005, 3:30-35, 1:1-5,
`
`Abstract. Note that McCall uses the terms “beacon” and “beacon signal” in a manner
`
`consistent with the ’207 patent, namely, to refer to devices that broadcast
`
`information (and not to the information itself).
`
`
`
`14
`
`18
`
`
`
`
`
`
`Beacons
`shown in
`red boxes
`
`Assets
`
`Ex. 1005, FIG. 1 (with annotations in color)
`
`
`
`42.
`
` McCall discloses various embodiments, one of which involves a
`
`beacon that does not have a receiver. Ex. 1005, 4:10-16. In this embodiment, “the
`
`beacon 102-112 transmits its identifying signal continuously, or at intervals” and the
`
`“asset 120, 122 passively listens for beacons 102-112 that are transmitting either
`
`continuously or intermittently.” Ex. 1005, 4:10-16, 4:26-32. For example, McCall’s
`
`FIG. 4 (reproduced below) shows a beacon 110 transmitting the identifying signal
`
`(shown by a uni-directional arrow) using a Bluetooth Inquiry protocol to asset 122
`
`(see also step 304 in McCall’s FIG. 3 reproduced below). Ex. 1005, 5:5-27. The
`
`identifying signal includes a unique global ID that identifies the beacon. Ex. 1005,
`
`3:58-65, 4:25-35.
`
`
`
`15
`
`19
`
`
`
`
`
`
`
`
`
`
` Ex. 1005, FIG. 4 Ex. 1005, FIG. 3
`
`43. As shown above in steps 306 and 308 of FIG. 3, an asset 120, 122
`
`receives the identifying signal and decodes the signal to determine the beacon ID.
`
`The location of the asset 120, 122 may then be determined using the unique beacon
`
`ID received from the beacon. Ex. 1005, 3:63-4:7, 4:32-67. For example, the asset
`
`120, 122 may send the beacon ID to server 402 which computes a location
`
`corresponding to the beacon ID and transmits the location back to the asset 120, 122.
`
`Ex. 1005, 4:35-64, FIG. 3. The asset 120, 122 then determines its location based on
`
`the location information provided by server 402. Ex. 1005, 4:35-64. In some cases,
`
`the asset 120, 122 may have the resources to compute its own location based on the
`
`received beacon ID. Ex. 1005, 4:64-67.
`
`IX. OVERVIEW OF BT CORE
`
`44.
`
`I have reviewed BT (Bluetooth) Core extensively. BT Core is a
`
`Bluetooth standard document that describes standard features of the Bluetooth
`
`
`
`16
`
`20
`
`
`
`
`
`
`communications protocol. Ex. 1007, pp 5-13. A standard Bluetooth packet format
`
`(shown below) is described in BT Core as including access code, header, and
`
`payload fields. Ex. 1007, p 47.
`
`Standard Bluetooth packet format (Ex. 1007, p. 47)
`
`
`
`45. Several variations of Bluetooth packets are possible. One type of
`
`packet is the inquiry packet or inquiry message, which is transmitted during the
`
`Bluetooth Inquiry protocol. Ex. 1007, p 108. The Bluetooth Inquiry protocol is used
`
`when a source device needs to learn the addresses of potential destination devices.
`
`Ex. 1007, pp 108-10. During the inquiry process, the source device broadcasts
`
`inquiry messages while following the inquiry hopping sequence, which causes the
`
`inquiry messages to be delivered to potential destination devices at different
`
`frequencies in a specified frequency hopping pattern. Ex. 1007, p 108. When a
`
`destination device receives an inquiry message, it may return an inquiry response
`
`message that includes its address, so the source device can use the address to
`
`establish a connection with the receiving device. Ex. 1007, pp 108-11.
`
`46.
`
`It is a well-established and known fact that a Bluetooth inquiry message
`
`generally only includes the access code field, which includes two required data fields
`
`
`
`17
`
`21
`
`
`
`(the preamble field and the sync word field) and an optional trailer field, as shown
`
`below. Ex. 1007, p 48.
`
`
`
`
`Standard Access code field format (Ex. 1007, p. 48)
`
`
`
`47.
`
`Inquiry access codes may include a general inquiry access code (GIAC)
`
`or a dedicated inquiry access code (DIAC). Ex. 1007, p 48. A GIAC “can be used
`
`to discover which other Bluetooth units are in range.” Ex. 1007, p 48. A DIAC can
`
`be used to discover specified types of Bluetooth units or devices in range. Ex. 1007,
`
`p 48.
`
`A. Combination of McCall and BT Core
`
`48.
`
`In my opinion, McCall and BT Core are complementary. For instance,
`
`as I noted above, McCall teaches that its communication network can be
`
`implemented using the Bluetooth protocol, and that the Bluetooth Inquiry protocol
`
`can be used for communications between devices to provide or obtain the unique ID
`
`of a beacon. Ex. 1005, 5:5-27, 2:47-52, Abstract. BT Core provides details of the
`
`Bluetooth Inquiry protocol, which are not explicitly noted in McCall (e.g., McCall
`
`discloses transmitting data packets in an Inquiry protocol, but does not explicitly
`
`disclose the type or structure of the data packets transmitted in an Inquiry protocol
`
`messaging session). Ex. 1005, 5:19-27.
`
`
`
`18
`
`22
`
`
`
`
`
`
`49. A POSITA like myself would naturally look at BT Core to obtain a
`
`better understanding of Bluetooth features, such as the data packets used in McCall
`
`to obtain a beacon ID, since BT Core is a Bluetooth standard document that provides
`
`details for implementing Bluetooth protocols. Furthermore, a POSITA would
`
`combine the teachings of McCall and BT Core to fully realize the implementation
`
`of Bluetooth in McCall’s device tracking method. Such a combination amounts to
`
`filling the gaps in McCall in a predicatable way and involves nothing more than the
`
`use of a known technique to improve similar devices in the same way or the
`
`combination of prior art elements according to known methods.
`
`50. For instance, the combination of McCall and BT Core reveals that data
`
`packets transmitted during an Inquiry protocol would include inquiry messages and
`
`inquiry response messages. The inquiry message includes an access code field, and
`
`the inquiry response message includes an address of the device responding to the
`
`inquiry message.
`
`51. When the combination of McCall and BT Core is applied to McCall’s
`
`embodiment in which a beacon only includes a transmitter (indicating that the
`
`beacon cannot receive any message), it would have been obvious to a POSITA that
`
`an inquiry message is transmitted by a beacon 102-112 to an asset 120, 122 to
`
`communicate with the asset 120, 122 and convey the beacon’s ID to the asset 120,
`
`122. This would have been obvious at least because inquiry messages are used in
`
`
`
`19
`
`23
`
`
`
`
`
`
`the Bluetooth protocol to establish a connection between two devices (as noted
`
`above in the discussion of BT Core.) Ex. 1007, pp 108-10. Specifically, when a
`
`device wishes to become a slave in a Bluetooth piconet, it enters the inquiry scan
`
`substate, listening for inquiry messages from any broadcasting device. Upon receipt
`
`of an inquiry message, the device transmits an inquiry response message to the
`
`master of the Bluetooth piconet, which is the device’s first communication to the
`
`master.
`
`52.
`
`In fact, in an environment in which the beacon cannot receive Bluetooth
`
`messages and an inquiry response, such as in McCall’s transmitter-only
`
`embodiment, McCall’s beacon would not be able to establish a Bluetooth connection
`
`with another device. The only way the beacon can provide information to another
`
`device using Bluetooth is through a pre-connection inquiry message. It appears
`
`obvious to me that McCall’s transmitter-only embodiment would therefore involve
`
`transmitting location tracking information (e.g., beacon
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
