Ex Parte Fanshawe

Board of Patent Appeals and Interferences

Apr 30, 2009

10323416 (B.P.A.I. Apr. 30, 2009)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________
BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________
Ex parte DAVID G.J. FANSHAWE
____________
Appeal 2007-0934
Application 10/323,416
Technology Center 2600
____________
Decided:1 April 30, 2009
____________
Before KENNETH W. HAIRSTON, LEE E. BARRETT, and HOWARD B.
BLANKENSHIP, Administrative Patent Judges.

BARRETT, Administrative Patent Judge.

DECISION ON APPEAL
This is a decision on appeal under 35 U.S.C. § 134(a) from the final
rejection of claims 1-5, 7, and 14-23..2 Claims 6 and 8-13 have been
canceled. We have jurisdiction pursuant to 35 U.S.C. § 6(b).

1 The two-month time period for filing an appeal or commencing a
civil action, as recited in 37 C.F.R. § 1.304, begins to run from the decided
date shown on this page of the decision. The time period does not run from
the Mail Date (paper delivery) or Notification Date (electronic delivery).
Appeal 2007-0934
Application 10/323,416

2
We reverse.
STATEMENT OF THE CASE
The invention
The invention relates to an access control system for a lock. As
shown in Figure 1, the lock 10 includes a locking device control 12 and a
lock actuator 11 to release the door. A locking command device or tag 20 is
carried by a user and communicates over a short range wireless link to
provide a security access code and actuate the lock actuator. The
Specification states: "The locking controller 12 may provide to the tag 20 the
information required to request an authorisation code. Such information
includes, for example, a telephone number to dial to contact to the access
code repository 30." Spec. 5: 1-4.

The claims
Claim 1 is reproduced below:
1. A method of operating an access control system that includes a
locking device control coupled to a locking arrangement, said control
generating an enabling signal to initiate actuation of said locking
arrangement on reception of a valid access code; and a command
device that is configured to provide an access code to the locking
device control, said method comprising:
determining whether a provided access code received at the
locking device control is valid, and generating said enabling signal in
the case that the received code is valid;

2 The statement of the rejection includes claim 6. However,
according to the amendment after final received November 10, 2005, and the
Claims Appendix to the Appeal Brief, claim 6 is canceled.
Appeal 2007-0934
Application 10/323,416

3
otherwise, in the case the received code is not valid:
providing the command device with repository contact
information that is derived from the locking device control;
causing the command device to request a valid access
code from a code repository determined by the repository contact
information and, in the event the valid access code is made available,
relaying the valid access code from the command device
to the locking device control.

The references

Clark US 4,829,296 May 9, 1989
Larson US 5,815,557 Sep. 29, 1998
Moreno US 6,882,269 B2 Apr. 19, 2005
(filed Jul. 12, 2001)

The rejections
Claims 1-53 stand rejected under 35 U.S.C. § 102(b) as anticipated by
Larson.
Claims 14-16 and 18-22 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Larson and Clark.
Claims 7, 17 and 23 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Larson and Clark, and further in view of Moreno.

3 The statement of the rejection includes claim 6, but claim 6 has been
canceled. See footnote 2.
Appeal 2007-0934
Application 10/323,416

4
DISCUSSION
Anticipation
Issue
Based on Appellant's contentions, the issue is: Does Larson teach
"providing the command device with repository contact information that is
derived from the locking device control" and "causing the command device
to request a valid access code from a code repository determined by the
repository contact information" as recited in claim 1?

Contentions
The Examiner first refers to the embodiment of Figure 2 of Larson.
The Examiner finds that when the key 46 does not have the necessary access
code, the key requests a valid access code from the clearinghouse 18' and
then relays the access code to the lock to gain access (Ans. 4). The user can
enter a request to access a particular lock via a keypad to the
clearinghouse 18' which then authorizes the user's key 46. The Examiner
finds that "[t]his is a step of providing the locking device command means
with repository information; the key ID can be considered repository
information (as broadly claimed) since the repository needs the key ID in
order to provide the access codes to the telephone acting as a key" (id.). The
Examiner also refers to the embodiment of Figure 3 and finds that Larson
teaches providing repository contact information from the locking device
control at "col. 8 lines 15+, the user calls the clearinghouse to acquire the
Appeal 2007-0934
Application 10/323,416

5
code, here a telephone number is needed for such communication"
(Advisory Action 2; similar statement at Ans. 6).
Appellant argues that Larson does not address how the contact
information is obtained and does not teach providing it to the command
device based on information from the locking device control (Br. 6). It is
argued that the user needing to know the telephone number is not the same
as providing the number from the locking device control (id).
The Examiner finds that "[t]he lock ID is 'repository contact
information'" (Advisory Action 2).
Appellant disagrees, "because merely being able to identify the lock
does not serve to identify the repository that contains the enabling signal for
the lock, and does not provide the contact information necessary to establish
contact with such a repository" (Br. 7).
The Examiner states that "repository contact information" is not
"limited to telephone numbers to dial, merely that information required to
request an authorization code is provided to the key. This does not state that
the lock sends this information in a transmission, merely that the information
is provided to the key." Ans. 7. The Examiner interprets that the user
reading the lock ID from the lock meets the claim limitation of "derived
from the locking control device" and that once the user inputs this data into
the key it is provided to the key (command device) (Ans. 7).

Appeal 2007-0934
Application 10/323,416

6
Analysis
Initially, we give "repository contact information" its ordinary and
customary meaning of "information required to contact a repository." That
is, if you ask someone for their "contact information," you are asking for
information on how they can be contacted or reached. While it is true, as
stated by the Examiner, that "repository contact information" is not limited
to a telephone number, e.g., it could be a repository Web address, it must
still provide information to contact the repository, not information used once
the repository is contacted.
The Examiner errs in interpreting any "information required to request
an authorisation code," such as a lock ID, to be "repository contact
information." "Repository contact information" is a specific type of
information. The Examiner's statement that "the key ID can be considered
repository information" (Ans. 4) suggests that the Examiner has improperly
read the limitation "contact" out of the claims and is looking at repository
information rather than the claimed repository contact information. The
Specification states: "The locking controller 12 may provide to the tag 20 the
information required to request an authorisation code. Such information
includes, for example, a telephone number to dial to contact to the access
code repository 30." Spec. 5: 1-4. If we had to guess, we suspect that the
Examiner is interpreting the "information required to request an
authorisation code" in the first sentence to be the "repository contact
information" in the second sentence, when, in fact, the "repository contact
Appeal 2007-0934
Application 10/323,416

7
information" is a specific type of "information required to request an
authorisation code."
We agree with Appellant that Larson does not discuss how the
repository (clearinghouse) contact information is obtained. The implication
is that it is either programmed into the key of Figure 2 or that the user is
given a number to dial in the embodiment of Figure 3. There is no teaching
or suggestion that the contact information comes from the lock in Larson.
Reading the lock ID from the lock does not meet the limitation of
"repository contact information that is derived from the locking device
control" because a lock ID is not "repository contact information."

Conclusion
Larson does not teach "providing the command device with repository
contact information that is derived from the locking device control" and
"causing the command device to request a valid access code from a code
repository determined by the repository contact information" as recited in
claim 1. The rejection of claims 1-5 is reversed.

Obviousness
Larson and Clark
Independent claims 14 and 19 contain similar "repository contact
information" limitations to that considered in claim 1 except that they further
require that the "repository contact information" is received by a key.
Claim 14 recites a "key configured to: . . . receive repository contact
information from the lock control, and request a valid access code from a
Appeal 2007-0934
Application 10/323,416

8
code repository determined by the repository contact information if the key
does not already possess a valid access code for that lock control." Claim 19
recites "transmitting lock identifying information and repository contact
information from the lock control to the key" and "transmitting lock
identifying information from the key to a particular code repository
dependent on the repository contact information, if the key does not contain
the access code."
The Examiner relies on Clark for a teaching of transmission of ID
codes from a receiver to an access device so the key can lookup the access
code in a database and finds that the lock ID corresponds to the "repository
contact information" (Ans. 5). The Examiner also finds that transmitting the
lock's location in the fourth embodiment of Larson is "repository contact
information" (id.).
Appellants argue that the rejection fails to identify where Larson or
Clark teaches the "repository contact information" limitations (Br. 8). It is
argued that in the fourth embodiment of Larson, a delivery company calls
the clearinghouse (col. 8, ll. 66 to col. 9, l. 27) and "neither the lock control
nor the key contain contact information to the clearinghouse" (Br. 8).
As discussed with respect to claim 1, "repository contact information"
is defined as "information required to contact a repository" and this
limitation is not taught or suggested in Larson. The Examiner errs in finding
that a lock ID in Clark or a lock's location in Larson is "repository contact
information" because neither specifies how to contact a repository, but only
uses the information to retrieve information once the repository is contacted.
Appeal 2007-0934
Application 10/323,416

9
Accordingly, the rejection of independent claims 14 and 19, and dependent
claims 15, 16, 18, and 20-22, is reversed.

Larson, Clark, and Moreno
Moreno is applied to teach encrypting communications between the
key and the lock control. Moreno does not cure the deficiencies of Larson as
to claim 1 or as to Larson and Clark as to claims 14 and 19. Accordingly,
the rejection of claims 7, 17, and 23 is reversed.

CONCLUSION
The rejections of claims 1-5, 7, and 14-23 are reversed.

REVERSED
erc

PHILIPS INTELLECTUAL PROPERTY & STANDARDS
P.O. BOX 3001
BRIARCLIFF MANOR, NY 10510