DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 25-30 and 36-41 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yang (US 2013/0023255 A1) in view of Adams (US 2009/0188977 A1).
Regarding claim 25, Yang teaches a server device for discovering smart card slots in a client device, the server device comprising: a processor subsystem; and memory including instructions, which when executed by the processor subsystem (Yang discloses a target communication device (an in-vehicle communication device, e.g., a car phone) that connects over Bluetooth to a separate communication device that is coupled to a plurality of SIM cards, and that accesses a selected SIM card of that device (Yang ¶¶ [0002], [0014], [0016]; claim 19). Yang further discloses implementation "as software executed by a processor," where "[t]he software may be stored in a medium accessible by a machine or computer-readable medium, such as read-only memory (ROM), random-access memory (RAM)" (¶ [0030])), cause the processor subsystem to perform operations comprising:
receiving, at the server device from the client device, over an established Bluetooth connection, smart card connector status, the client device having a plurality of smart card slots (Yang's communication device (a mobile phone or card reader) is coupled to a plurality of SIM cards seated in corresponding SIM slots; the accessibility check expressly examines "whether a SIM card and a corresponding SIM slot are in bad contact, a SIM card malfunctions, no SIM card plugged, or a SIM slot malfunctions" (¶ [0016]), confirming a plurality of physical card slots. A Bluetooth connection is established between the target device and that device before any further operation (¶ [0016], step 110; FIGS. 1–5, steps 110/210/310/410/510));
interrogating one or more of the plurality of smart card slots over the Bluetooth connection using a protocol to attempt to access an application at each of the one or more of the plurality of smart card slots (Yang teaches that, after the Bluetooth connection is established, Yang detects the connection status of the SIM cards occupying the slots and generates a checking result (¶¶ [0006], [0016]; claim 1). Yang expressly contemplates checking fewer than all cards: "the BT SAP server may only check for the accessibility of one SIM card in a dual SIM case" (¶ [0029]); and
in response to identifying the application exists in a slot of the plurality of smart card slots, connecting with the application (Yang: upon the checking result identifying the appropriate card, the Bluetooth SAP "of the communication device [is configured] to use a specific SIM card selected from the plurality of SIM cards" (¶ [0006]; claim 1), and "the specific SIM card of the communication device is accessed by the in-vehicle communication device" (claim 19), which thereafter uses "the identification and communication functions of the remote SIM card" (¶ [0002])).
Yang is silent to teaching that configured to perform receiving smart card connector parameters and interrogating using a smart card protocol, wherein the application pre-associated with the server device.
In the same field of endeavor, Adams teaches a device configured to perform receiving smart card connector parameters (Adams discloses that the card-holding device (smart card reader 104) reports connector-related parameter data to the requesting device over their short-range link: each smart card reader driver component "will register itself with a central driver information store... and will be associated with a unique driver ID at the time of registration. When the smart card reader 104 synchronizes settings with the mobile communication device 106, the smart card reader 104 may transmit, to the mobile communication device 106, a list of driver IDs associated with installed smart card reader driver components" (¶ [0046]); the link is a Bluetooth link (¶ [0021]; claims 7, 14, 20).) and interrogating using a smart card protocol (Adams discloses accessing the card seated in the card-holding device's slot over the Bluetooth link using a smart card protocol: command and response Application Protocol Data Units, "where a standard structure for an APDU is defined by ISO 7816" (¶ [0032]), transmitted to the smart card 102 via the storage component interface 322 (¶¶ [0024], [0053]; claim 9). Adams further discloses the attempt-to-access step: "when the smart card driver module has a requirement to send a command to the smart card reader 104, the smart card driver module first determines... whether the appropriate smart card reader driver component is present on the smart card reader 104" (¶ [0047])), wherein the application pre-associated with the server device (Adams teaches "[T]here is likely to be a corresponding smart card reader driver component for every smart card driver module at the mobile communication device 106... programmed by the same person, or at least the same organization" (¶ [0045]); and "a smart card driver module is supplied by the manufacturer of the smart card 102" (¶ [0030]). The requesting device thus recognizes the sought application through the attempt to access it, as the instant specification requires (¶ [0037])).
It would have been obvious to a PHOSITA at the time to implement Yang's Bluetooth-mediated remote card access using Adams' ISO 7816 APDU exchange over Bluetooth and Adams' driver-ID reporting and pre-access determination, for at least the following reasons:
Same field of endeavor and same problem. Both references address one device obtaining access, over a Bluetooth link, to a smart card physically resident in a different device. Yang's device is expressly "a mobile phone and a card reader" (¶ [0014]); Adams describes that very arrangement in structural detail (¶¶ [0014], [0022]–[0024]). A PHOSITA looking to build Yang's system would naturally consult Adams for the card-access layer Yang presupposes.
Regarding claim 26, the combination of Yang and Adams teaches the server device of claim 25, wherein interrogating one or more of the plurality of smart card slots comprises:
identifying smart card types of each of the one or more of the plurality of smart card slots; filtering the one or more of the plurality of smart card slots based on the smart card types to produce filtered results; and interrogating the smart card slots in the filtered results (Yang identifies a characteristic of each of the plurality of cards/slots, filters the plurality on that characteristic to produce a subset, and then interrogates only the members of that subset on the next criterion: accessibility is checked first, and "if the checking result indicates that more than one of the plurality of SIM cards is accessible... the flow will go to step 130, and it is detected if accessible SIM cards include any idle SIM card" (¶ [0017]); the roaming check is then applied only to "each of the idle of SIM cards" (¶ [0019]). See also FIG. 1 (steps 120→130→140) and FIG. 2 (steps 220–275). Yang filters on connection status rather than on the identity or kind of what occupies each slot).
Regarding claim 27, the combination of Yang and Adams teaches the server device of claim 26, wherein the smart card types include embedded Secure Element (eSE) and host card emulation (HCE) (Official Notice is taken, under MPEP 2144.03, that embedded Secure Elements and host card emulation were both well known in the art as smart card implementation types before the effective filing date of the claimed invention, and that a device interacting with smart card applications over a wireless link was commonly configured to distinguish between them. Applicant is reminded that to adequately traverse this finding, Applicant must specifically point out the supposed errors in the Examiner's action, which would include stating why the noticed fact is not considered to be common knowledge or well-known in the art. See 37 CFR 1.111(b); MPEP 2144.03(C). Documentary evidence will be furnished upon proper traversal. Given that notice, it would have been obvious to a PHOSITA to have the smart card types on which the Yang/Adams filtering operates be eSE and HCE cards, because those were the card technologies present in the devices at issue, and the selection of known card technologies for use in a known filtering scheme is nothing more than the exercise of ordinary skill yielding predictable results. Nothing in the claim ties the recited labels to any change in the filtering operation itself).
Regarding claim 28, the combination of Yang and Adams teaches the server device of claim 25, wherein the plurality of smart card slots include a virtual smart card slot, a physical smart card slot, or a combination of a physical smart card slot and a virtual smart card slot (Yang discloses physical SIM slots into which cards are plugged (¶ [0016]: "no SIM card plugged, or a SIM slot malfunctions"; ¶ [0003]: dual-SIM and multi-SIM phones). Adams discloses a physical slot in the form of storage component interface 322, which "receives the smart card 102" (¶¶ [0022], [0024])).
Regarding claim 29, the combination of Yang and Adams teaches the server device of claim 25, wherein the smart card protocol includes ISO/IEC 7816 (Adams discloses that communication with the card is standardized on Application Protocol Data Units, "where a standard structure for an APDU is defined by ISO 7816" (¶ [0032]), and further identifies the ISO 7816 transmission protocols T=0 and T=1 and characterizes ISO 7816 as "an international standard related to electronic identification cards, especially smart cards" (¶ [0033]). Using this standardized protocol in the Yang/Adams combination would have been obvious for the reason Adams itself supplies — standardization and interoperability with cards supplied by third-party manufacturers (¶¶ [0030], [0032])).
Regarding claim 30, the combination of Yang and Adams teaches the server device of claim 25, wherein the application is pre-associated with the server device when the server device is initially provisioned for field service (Adams discloses that the counterpart software on the requesting (server) device is installed before the device enters service: "A smart card (SC) driver module 230C may also be installed on the mobile communication device 106 during manufacture, to implement aspects of the present disclosure" (¶ [0019]), and that module "is supplied by the manufacturer of the smart card 102" (¶ [0030]) — i.e., the association between the requesting device and the card-resident application is fixed at provisioning rather than negotiated at run time. Adams correspondingly discloses that the applications on the card-holding device "may be installed on the smart card reader 104 as a component of the software application modules 328 during the manufacturing process" (¶ [0026])).
Regarding claim 36, Yang teaches a method for discovering smart card slots in a device, the method comprising:
receiving, at the server device from the client device, over an established Bluetooth connection, smart card connector status, the client device having a plurality of smart card slots (Yang's communication device (a mobile phone or card reader) is coupled to a plurality of SIM cards seated in corresponding SIM slots; the accessibility check expressly examines "whether a SIM card and a corresponding SIM slot are in bad contact, a SIM card malfunctions, no SIM card plugged, or a SIM slot malfunctions" (¶ [0016]), confirming a plurality of physical card slots. A Bluetooth connection is established between the target device and that device before any further operation (¶ [0016], step 110; FIGS. 1–5, steps 110/210/310/410/510));
interrogating one or more of the plurality of smart card slots over the Bluetooth connection using a protocol to attempt to access an application at each of the one or more of the plurality of smart card slots (Yang teaches that, after the Bluetooth connection is established, Yang detects the connection status of the SIM cards occupying the slots and generates a checking result (¶¶ [0006], [0016]; claim 1). Yang expressly contemplates checking fewer than all cards: "the BT SAP server may only check for the accessibility of one SIM card in a dual SIM case" (¶ [0029]); and
in response to identifying the application exists in a slot of the plurality of smart card slots, connecting with the application (Yang: upon the checking result identifying the appropriate card, the Bluetooth SAP "of the communication device [is configured] to use a specific SIM card selected from the plurality of SIM cards" (¶ [0006]; claim 1), and "the specific SIM card of the communication device is accessed by the in-vehicle communication device" (claim 19), which thereafter uses "the identification and communication functions of the remote SIM card" (¶ [0002])).
Yang is silent to teaching that comprising receiving smart card connector parameters and interrogating using a smart card protocol, wherein the application pre-associated with the server device.
In the same field of endeavor, Adams teaches a method comprising receiving smart card connector parameters (Adams discloses that the card-holding device (smart card reader 104) reports connector-related parameter data to the requesting device over their short-range link: each smart card reader driver component "will register itself with a central driver information store... and will be associated with a unique driver ID at the time of registration. When the smart card reader 104 synchronizes settings with the mobile communication device 106, the smart card reader 104 may transmit, to the mobile communication device 106, a list of driver IDs associated with installed smart card reader driver components" (¶ [0046]); the link is a Bluetooth link (¶ [0021]; claims 7, 14, 20).) and interrogating using a smart card protocol (Adams discloses accessing the card seated in the card-holding device's slot over the Bluetooth link using a smart card protocol: command and response Application Protocol Data Units, "where a standard structure for an APDU is defined by ISO 7816" (¶ [0032]), transmitted to the smart card 102 via the storage component interface 322 (¶¶ [0024], [0053]; claim 9). Adams further discloses the attempt-to-access step: "when the smart card driver module has a requirement to send a command to the smart card reader 104, the smart card driver module first determines... whether the appropriate smart card reader driver component is present on the smart card reader 104" (¶ [0047])), wherein the application pre-associated with the server device (Adams teaches "[T]here is likely to be a corresponding smart card reader driver component for every smart card driver module at the mobile communication device 106... programmed by the same person, or at least the same organization" (¶ [0045]); and "a smart card driver module is supplied by the manufacturer of the smart card 102" (¶ [0030]). The requesting device thus recognizes the sought application through the attempt to access it, as the instant specification requires (¶ [0037])).
It would have been obvious to a PHOSITA at the time to implement Yang's Bluetooth-mediated remote card access using Adams' ISO 7816 APDU exchange over Bluetooth and Adams' driver-ID reporting and pre-access determination, for at least the following reasons:
Same field of endeavor and same problem. Both references address one device obtaining access, over a Bluetooth link, to a smart card physically resident in a different device. Yang's device is expressly "a mobile phone and a card reader" (¶ [0014]); Adams describes that very arrangement in structural detail (¶¶ [0014], [0022]–[0024]). A PHOSITA looking to build Yang's system would naturally consult Adams for the card-access layer Yang presupposes.
Regarding claims 37-41, the dependent claims are interpreted and rejected for the same reasons as set forth above in claims 26-30, respectively.
Claim(s) 31-35 and 42-46 is/are rejected under 35 U.S.C. 103 as being unpatentable over Yang and Adams as applied to claims 25 and 36 above, and further in view of Wang (US 2016/0379017 A1).
Regarding claim 31, the combination of Yang and Adams teaches the server device of claim 25.
The combination of Yang and Adams is silent to teaching that wherein the application is a fine ranging application.
In the same field of endeavor, Wang teaches a device wherein the application is a fine ranging application (Wang teaches that an application resident in the card's memory is configured or downloaded and executed to provide functionality in conjunction with the coupled device (¶¶ [0057]–[0058]), and that the card's transceiver may implement a UWB system selected from a short, closed list of identified short-range alternatives (¶ [0041]).Wang does not, however, disclose ranging. That limitation is supplied by Applicant's Admitted Prior Art (AAPA). The instant application states, as a characterization of the state of the art rather than of the invention, that both BLE and UWB can be used for ranging applications, that a ranging application is one used to determine a distance between two devices, and that while BLE serves for coarse ranging with RSSI, UWB is better suited for fine ranging (¶¶ [0013]–[0014]). Admissions in the specification are available as prior art in ex parte examination. MPEP 2129.
It would have been obvious to a PHOSITA to select UWB from Wang's finite list of identified predictable short-range options and to have the card-resident application of Wang be a fine ranging application, because the art recognized UWB as the technology best suited to fine ranging (AAPA ¶ [0014]) and identified concrete uses for it in exactly the access-control and point-of-sale contexts in which Yang's Bluetooth-mediated remote card access operates (AAPA ¶ [0014]).
Regarding claim 32, the combination of Yang and Adams teaches the server device of claim 31.
The combination of Yang and Adams is silent to teaching that wherein the application implements ultra-wideband (UWB) technology to provide ranging data to the server device.
In the same field of endeavor, Wang teaches a device wherein the application implements ultra-wideband (UWB) technology to provide ranging data to the server device (Wang's card carries the radio 116 and antenna 118 by which the resident application communicates with other electronic devices (¶¶ [0026], [0036]), and Wang expressly contemplates a card carrying two transceivers with different communication parameters and ranges (¶ [0038]) — for example, one Bluetooth and one UWB, both drawn from the list at ¶ [0041]. Combined with AAPA ¶¶ [0013]–[0014], having the card's ranging application use its UWB radio to furnish distance information to the device it is transacting with is the predictable result of putting Wang's dual-radio card and the art's recognized use of UWB together. The device receiving that data is Yang's target device — the same device that, in the Yang/Adams combination, established the Bluetooth connection and located the application).
It would have been obvious to a PHOSITA to select UWB from Wang's finite list of identified predictable short-range options and to have the card-resident application of Wang be a fine ranging application, because the art recognized UWB as the technology best suited to fine ranging (AAPA ¶ [0014]) and identified concrete uses for it in exactly the access-control and point-of-sale contexts in which Yang's Bluetooth-mediated remote card access operates (AAPA ¶ [0014]).
Regarding claim 33, the combination of Yang and Adams teaches the server device of claim 32.
The combination of Yang and Adams is silent to teaching that wherein the operations comprise negotiating, over the Bluetooth connection, UWB parameters for a UWB ranging session.
In the same field of endeavor, Wang teaches a device wherein the operations comprise negotiating, over the Bluetooth connection, UWB parameters for a UWB ranging session (Wang enumerates the parameters that govern a transceiver's operation, including the RF band, radio-frequency channel parameter, rate selection parameter, frame size parameter, MCS, and PHY layer parameter (¶ [0037]), and teaches that different transceivers on the same card use different parameter sets (¶ [0038])). The need to exchange those parameters in advance is supplied by AAPA: the application states that in present implementations, due to power requirements, UWB is not ideal for in-band discovery, that devices using UWB would rapidly deplete their reserves monitoring for connections, and that UWB therefore requires the connection parameters to be exchanged before the session (¶ [0015], first three sentences).
It would have been obvious to a PHOSITA to select UWB from Wang's finite list of identified predictable short-range options and to have the card-resident application of Wang be a fine ranging application, because the art recognized UWB as the technology best suited to fine ranging (AAPA ¶ [0014]) and identified concrete uses for it in exactly the access-control and point-of-sale contexts in which Yang's Bluetooth-mediated remote card access operates (AAPA ¶ [0014]).
Regarding claim 34, the combination of Yang and Adams teaches the server device of claim 33.
The combination of Yang and Adams is silent to teaching that wherein the operations comprise establishing the UWB ranging session using the UWB parameters.
In the same field of endeavor, Wang teaches a device wherein the operations comprise establishing the UWB ranging session using the UWB parameters (Parameters exchanged "before the session" (AAPA ¶ [0015]) are exchanged in order to be used in that session; an exchange whose product went unused would serve no purpose.
It would have been obvious to a PHOSITA to select UWB from Wang's finite list of identified predictable short-range options and to have the card-resident application of Wang be a fine ranging application, because the art recognized UWB as the technology best suited to fine ranging (AAPA ¶ [0014]) and identified concrete uses for it in exactly the access-control and point-of-sale contexts in which Yang's Bluetooth-mediated remote card access operates (AAPA ¶ [0014]).
Regarding claim 35, the combination of Yang and Adams teaches the server device of claim 25.
The combination of Yang and Adams is silent to teaching that wherein the operations comprise: disconnecting from the application; and establishing an ultra-wideband (UWB) ranging session using data received from the application.
In the same field of endeavor, Wang teaches a device wherein the operations comprise: disconnecting from the application; and establishing an ultra-wideband (UWB) ranging session using data received from the application (The second step is addressed at claims 32–34 above. As to disconnecting, Wang teaches a card operating from a finite onboard power source 112 that also supplies the coupled device (¶ [0033]), and AAPA ¶ [0015] identifies UWB power consumption as the constraint driving the two-radio architecture. Releasing a connection once the data it was opened to obtain has been received is a matter of ordinary design directed to that recognized constraint and would have been obvious to a PHOSITA as an ordinary power-management measure yielding no unexpected result).
It would have been obvious to a PHOSITA to select UWB from Wang's finite list of identified predictable short-range options and to have the card-resident application of Wang be a fine ranging application, because the art recognized UWB as the technology best suited to fine ranging (AAPA ¶ [0014]) and identified concrete uses for it in exactly the access-control and point-of-sale contexts in which Yang's Bluetooth-mediated remote card access operates (AAPA ¶ [0014]).
Regarding claims 42-46, the dependent claims are interpreted and rejected for the same reasons as set forth above in claims 31-35, respectively.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Rejection I — Claims 25–32, 35–43, and 46 over U.S. Patent No. 11,875,209
Claims 25–32, 35–43, and 46 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 of U.S. Patent No. 11,875,209 B2 ("the '209 patent"). Although the claims at issue are not identical, they are not patentably distinct from each other for the reasons set forth below.
Independent claim 25 vs. '209 claim 1
Instant claim 25 differs from claim 1 of the '209 patent only by omission. Claim 25 (i) does not require that the interrogation be performed "using the smart card connector parameters," and (ii) requires interrogation of only "one or more" of the plurality of smart card slots, rather than iterating through the plurality by interrogating "each slot." A server device practicing claim 1 of the '209 patent necessarily practices instant claim 25, since interrogating each slot of a plurality is interrogating one or more slots of that plurality. Instant claim 25 is therefore broader than, and wholly encompasses, the patented claim.
A later claim that is broader in scope than, and fully encompasses, an earlier patented claim is anticipated by that claim and is not patentably distinct from it. In re Goodman, 11 F.3d at 1053 (later genus claim not patentably distinct from earlier species claim); In re Berg, 140 F.3d at 1432; MPEP § 804(II)(B)(1). Moreover, the mere omission of a limitation from a patented claim, without more, is an obvious variation of that claim; it would have been obvious to one of ordinary skill in the art at the time the invention was made to arrive at instant claim 25 by omitting the recited use of the connector parameters and by interrogating fewer than all slots, particularly where the desired application is located before all slots are exhausted.
Instant method claim 36 stands in the same relationship to claim 11 of the '209 patent as claim 25 does to claim 1, differing only in the same two respects identified above. Claim 36 is therefore anticipated by, and not patentably distinct from, claim 11 of the '209 patent for the reasons given above.
Rejection II — Claims 33, 34, 44, and 45 over U.S. Patent No. 11,875,209 in view of U.S. Patent No. 12,190,186
Claims 33, 34, 44, and 45 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 of U.S. Patent No. 11,875,209 B2 in view of claims 1–20 of U.S. Patent No. 12,190,186 B2 ("the '186 patent").
Claims 33, 34, 44, and 45 depend, directly or indirectly, from claims 25, 32, 36, and 43, which are unpatentable over the '209 patent claims for the reasons given in Rejection I. The '209 patent claims do not recite negotiation of UWB parameters over the Bluetooth connection or establishment of the UWB ranging session using those negotiated parameters.
It would have been obvious to one of ordinary skill in the art at the time the invention was made to incorporate the UWB-parameter negotiation and session-establishment steps of '186 claims 8, 9, 18, and 19 into the slot-interrogation server device and method of '209 claims 1 and 11. Both sets of patented claims are directed to a server device that uses an out-of-band Bluetooth connection to a client device's smart card application as the precursor to a UWB ranging session, and '209 claims 9 and 20 already recite establishing a UWB ranging session "using data received from the application." Negotiating the UWB parameters over the already-established Bluetooth connection is simply the express recitation of how that ranging data is obtained, and combining these known claimed features would have yielded no more than the predictable result of a UWB ranging session established with parameters exchanged out-of-band. The combination is further suggested by the fact that both reference patents are members of the same family, claim priority to the same provisional application (62/908,839), name the same inventive entity, and are commonly assigned.
Rejection III (Alternative) — Claims 25–46 over U.S. Patent No. 12,190,186 in view of U.S. Patent No. 11,875,209
Claims 25–46 are alternatively rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1–20 of U.S. Patent No. 12,190,186 B2 in view of claims 1–20 of U.S. Patent No. 11,875,209 B2.
Claims 1 and 11 of the '186 patent recite a server device and method that receive smart card connector parameters from a client device over an established Bluetooth connection and use a smart card protocol over that connection to attempt to access a particular, pre-associated application, connecting with the application in response to identifying that it exists. The '186 claims recite a client device having "a smart card with a plurality of applications stored thereon loaded into a smart card slot," rather than a client device having a plurality of smart card slots of which one or more are interrogated. Claims 1, 5, 11, and 15 of the '209 patent recite a client device having a plurality of smart card slots — including virtual slots, physical slots, or a combination — that are interrogated over the Bluetooth connection using a smart card protocol. It would have been obvious to extend the single-slot access of the '186 claims to the multi-slot interrogation of the '209 claims, as this amounts to no more than the duplication of a claimed structure and the application of a known technique to a known device ready for improvement to yield predictable results. The remaining instant dependent claims correspond to '186 claims 2–10 and 12–20 and '209 claims 3–10 and 13–20 as set forth in the tables above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
10,050,957, 2006/0064592, 2018/0220273, 2007/0251997, 2016/0266943, 2012/0292393, 2011/0197007 teach smart card and Bluetooth.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WEN WU HUANG whose telephone number is (571)272-7852. The examiner can normally be reached Mon-Fri 10-6.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wesley Kim can be reached at (571) 272-7867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WEN W HUANG/Primary Examiner, Art Unit 2648
Prosecution Insights