Ex Parte Blechman

Patent Trial and Appeal Board

Jan 9, 2014

10431845 (P.T.A.B. Jan. 9, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
10/431,845 05/08/2003 Elain Blechman PROAPP03 6838
7590 01/10/2014
Eugene Lieberstein
2151 Long Ridge Road
Stamford, CT 06903
EXAMINER
HEWITT II, CALVIN L
ART UNIT PAPER NUMBER
3685
MAIL DATE DELIVERY MODE
01/10/2014 PAPER
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE 1
___________ 2
3
BEFORE THE PATENT TRIAL AND APPEAL BOARD 4
___________ 5
6
Ex parte ELAIN BLECHMAN 7
___________ 8
9
Appeal 2011-010518 10
Application 10/431,845 11
Technology Center 3600 12
___________ 13
14
15
Before ANTON W. FETTING, JOSEPH A. FISCHETTI, and 16
MICHAEL W. KIM, Administrative Patent Judges. 17
FETTING, Administrative Patent Judge. 18
DECISION ON APPEAL 19
20
Appeal 2011-010518
Application 10/431,845
2

STATEMENT OF THE CASE1 1
Elain Blechman (Appellant) seeks review under 35 U.S.C. § 134 of a 2
final rejection of claims 3-15, the only claims pending in the application on 3
appeal. We have jurisdiction over the appeal pursuant to 35 U.S.C. § 6(b). 4
The Appellant invented a “unique client-centric, multi-level, multi-5
discipline, e-health system” (Specification 1, Field of the Invention). 6
An understanding of the invention can be derived from a reading of 7
exemplary claim 3, which is reproduced below [bracketed matter and some 8
paragraphing added]. 9
3. A method 10
for accessing client-centric relational database(s), 11
using software inclusive of programming logic stored and 12
implemented on internet servers containing 13
comprehensive records of multiple clients, 14
with each of said client’s records incorporating many 15
different data categories 16
offering to authorized users of each client many 17
different functions 18
for accessing and sharing information, exchanging 19
data, coordinating actions, storing data, routing 20
and transmission to client-authorized destinations 21
consistent with client specified user privileges 22
provided each of the client authorized user(s), 23
comprising the steps of: 24
[1] storing and classifying data in client records 25

1 Our decision will make reference to the Appellant’s Appeal Brief (“App.
Br.,” filed January 3, 2011) and Reply Brief (“Reply Br.,” filed May 31,
2011), and the Examiner’s Answer (“Ans.,” mailed March 29, 2011).
Appeal 2011-010518
Application 10/431,845
3

inclusive of data defining client specified user privileges 1
including the privileges of selective viewing of data, 2
updating, entry, consolidation, archiving, import and 3
export from web enabled devices; 4
[2] employing said programming logic to code the client 5
specified user privileges 6
for enforcing clients’ or their designated client-record 7
administrator(s) access 8
from web enabled devices to the clients’ records 9
and 10
to the records of other clients 11
when granted authorization to be an authorized user 12
by one or more other clients to their records; 13
[3] assigning unique identifiers 14
to each client-authorized user 15
for authenticating the user 16
via a user interface 17
to gain access to client records; 18
[4] using said programming logic for enforcing the 19
authorization and access 20
to the client records, data categories and data functions 21
within the client records 22
consistent with client specified user privileges 23
and 24
to deny access to users without authentication; 25
and 26
[5] providing each client or its designated client-record 27
administrator(s) via a user interface 28
with complete control over its records 29
to access such records at all times for designating the 30
client specified user privileges to each authorized user 31
Appeal 2011-010518
Application 10/431,845
4

and 1
to reevaluate previously authorized user privileges 2
such that each client may at any time 3
change, delete or designate newly authorized user 4
privileges and/or designate new users 5
to its own client records. 6
The Examiner relies upon the following prior art: 7
Voegeli US 2003/01010782 A1 May 29, 2003
Hotchkiss US 2003/0140043 A1 Jul. 24, 2003
Hacker US 6,988,075 B1 Jan. 17, 2006
Felsher US 2008/0306872 A1 Dec. 11, 2008
Claims 3-6 and 10-15 stand rejected under 35 U.S.C. § 103(a) as 8
unpatentable over Hacker and Felsher.3 9
Claims 7 and 8 stand rejected under 35 U.S.C. § 103(a) as unpatentable 10
over Hacker, Felsher, and Voegeli. 11
Claim 9 stands rejected under 35 U.S.C. § 103(a) as unpatentable over 12
Hacker, Felsher, and Hotchkiss. 13

2 The “Evidence Relied Upon” section at page 3 of the Answer lists Voegeli,
but then lists U.S. Application Publication 20030101079, which is to
McLaughin. Voegeli is U.S. Application Publication 20030101078. We
have reviewed both references, and the disclosures for which the references
are cited are more consistent with Voegeli. Based on this, and both the
Appeal Brief’s and the Answer’s citation and referral to Voegeli (App. Br. 9;
Ans. 6), we treat the listing of U.S. Application Publication 20030101079
instead of U.S. Application Publication 20030101078 as an inadvertent
typographical error.
3 Claims 13-15 are included within this rejection at page 6 of the Examiner’s
Answer.
Appeal 2011-010518
Application 10/431,845
5

ISSUES 1
The issues of obviousness turn primarily on whether Hacker and Felcher 2
describe a patient providing different levels of access to different parties, 3
and whether these references use programming logic to do so. 4
FACTS PERTINENT TO THE ISSUES 5
The following enumerated Findings of Fact (FF) are believed to be 6
supported by a preponderance of the evidence. 7
Facts Related to the Prior Art 8
Hacker 9
01. Hacker is directed to centrally storing patients medical records 10
electronically on a database for patient-controlled remote access 11
by both patients and medical providers. Hacker 1:4-8. 12
02. Hacker automatically generates medical insurance claims. Hacker 13
6:36-37. 14
03. Hacker provides patient control over access to their records by 15
using a patient supplied identifier, such as an ID/passphrase 16
combination, bar code, smart card, or biometric sample, in order 17
to access the electronic medical record. Hacker 6:24-29. 18
04. Hacker electronically stores patient medical records on a database 19
and allows for remote access to the records by medical providers 20
and patients. Patients control access to their record by providing a 21
unique access identification means to a system server connected to 22
the database. Hacker 7:22-26. 23
Appeal 2011-010518
Application 10/431,845
6

05. Particularly sensitive patient information can be passphrase 1
protected so that the medical provider must get permission from 2
the patient to gain access to it. The patient can also specify an 3
emergency override of passphrase protection, and notification to 4
the patient can be provided as to what information was released to 5
emergency medical personnel, including time, location, pages 6
accessed. Hacker 7:63 – 8:3. 7
06. When patients have allowed access, medical providers can view 8
appropriate portions of the patient’s medical record, and add 9
information to the patient’s medical record where appropriate. By 10
limiting access to needed information, the patient’s privacy can be 11
increased. When a medical provider feels they need access to 12
blocked portions, the medical provider can ask the patient for a 13
patient-selected passphrase, and the patient can decide whether or 14
not to grant access. Hacker 8:4-17. 15
07. Insurance claim forms can be automatically generated by server 16
520 and sent to the patient’s health insurance. Hacker 10:20-22. 17
08. Diagnostic labs post test results in a patient’s electronic medical 18
record. Hacker 12:10-12. 19
Felsher 20
09. Felsher is directed to the creation, use, processing, maintenance, 21
transmission, querying and protection of information records, 22
repositories, systems and methods. Felsher para 0002. 23
10. Felsher involves the implementation and use of a virtual trust, 24
wherein a content owner entrusts information content, generally in 25
Appeal 2011-010518
Application 10/431,845
7

digital form, to a virtual trustee, which implements a set of access 1
rules and controls on behalf of the content owner, for distribution 2
of the content. The virtual trustee, in turn, may shield the true 3
identity of the customer or consumer. Felsher para 0203. 4
11. In the case of information content which is private, such as 5
business or personal records, the system architecture differs, in 6
that disclosure of the content must be protected. In a normal 7
consumer media system, the content is not confidential, and thus 8
the distribution system is intended to impose a barrier to 9
circumvention, rather than generally protect with high security the 10
content. A secure system must, however, be designed to meet 11
emergency requests. Felsher para 0230. 12
12. In the case of confidential records, the recipient’s “role” may 13
checked for consistency with a set of role-based access rules, 14
defined by the content owner, but may change in different 15
contexts. The reported role may be accepted, or verified with a 16
database. Based on the role of the recipient and the identification 17
of the content, an index for the database is searched for records. 18
Preferably, the index includes, for each content record associated 19
entry, an identification of the location of the content record and a 20
set of access rules, which are, for example, role based. Felsher 21
para 0233. 22
13. The role-based access rules are generally defined automatically 23
based on contextual and circumstantial data. Manual rules and 24
edits may also be supported. Typically, a hierarchy is defined of 25
Appeal 2011-010518
Application 10/431,845
8

data sensitivity, with the most sensitive data provided with the 1
highest level of restrictions. Felsher para 0234. 2
14. When a recipient seeks a record, he must identify himself, his role 3
in the patient care, and the identity of the patient and/or record. 4
The identification of the recipient is then authenticated. The 5
recipient's role is checked for consistency with the recipient's 6
identity, but may change in different contexts. For example, a 7
physician may be an attending/primary care physician or a 8
consultant on a case. The reported role may be accepted, or 9
verified with a recipient medical institution database. Based on 10
the role of the recipient and the identification of the patient, an 11
index for the database is searched for records. Preferably, the 12
index includes, for each patient associated entry, an identification 13
of the location of the medical record and a set of access rules, 14
which are, for example, role based. The access rules are defined 15
by a set of defaults, and “overrides”, implementing a patient's 16
wishes. The defaults, in turn, are defined as a standard overall 17
system security level, additionally, the custodian medical 18
institution that is the source of the records may impose their own 19
access rules. Felsher paras 0253-0257. 20
15. Each transaction within the database may be a small record, for 21
example a result of a simple blood test, or a large record, such as 22
radiological data. A transaction may also include aggregations of 23
data, such as records from an entire hospital admission. Each 24
transaction is preferably associated with a descriptive header, 25
providing metadata regarding the record content, as well as rules 26
Appeal 2011-010518
Application 10/431,845
9

for access. The access rules may be stored outside the record 1
itself, and thus provide only a very general level of information 2
outside the record itself, while ensuring that only those aspects of 3
the record are retrieved which are necessary for the context of use. 4
Felsher para 0266. 5
ANALYSIS 6
We are not persuaded by the Appellant’s argument that: 7
Hacker is totally silent as to concept or suggestion of assigning 8
user privileges unrelated to entry identification to the selected 9
patient records in the database and is totally silent as to the use 10
of programming logic to enforce the exercise of user privileges 11
consistent with the user privileges as designated or assigned by 12
the client (patient). 13
App. Br. 12. The Appellant’s contention does not persuade us, because the 14
Appellant responds to the rejection by attacking the references separately, 15
even though the rejection is based on the combined teachings of the 16
references. Nonobviousness cannot be established by attacking the 17
references individually when the rejection is predicated upon a combination 18
of prior art disclosures. See In re Merck & Co., 800 F.2d 1091, 1097 (Fed. 19
Cir. 1986). 20
Felsher is directed to the creation, use, processing, maintenance, 21
transmission, querying and protection of information records, repositories, 22
systems and methods. Felsher involves the implementation and use of a 23
virtual trust, wherein a content owner entrusts information content, generally 24
in digital form, to a virtual trustee, which implements a set of access rules 25
and controls on behalf of the content owner, for distribution of the content. 26
FF 09-10. Thus, Felsher describes that it was known to extend the scope of 27
Appeal 2011-010518
Application 10/431,845
10

Hacker’s user access rules to all forms of data access. Further, Hacker also 1
describes the user providing other users editing access to records. FF 06. 2
Also, as the Examiner found, any software implementation as in Hacker 3
and Felsher necessarily employs “programming logic to code the client 4
specified user privileges for enforcing clients’ or their designated client-5
record administrator(s) access” (claim 3, limitation [2]). Although Appellant 6
contents that “[t]his concept [of programming logic] is fundamental to the 7
subject invention and is not taught or suggested by Hacker and cannot be 8
attributed to Hacker by implication” (App. Br. 17), this contention is no 9
more than a blank assertion with no evidence to support it. Again, the 10
simple fact that software is per se programming logic is sufficient to rebut 11
this contention. 12
We are not persuaded by the Appellant’s argument that: 13
Hacker does not in its Abstract or elsewhere teach a database 14
which “includes fields and a set of operations” and does not 15
teach or suggest “using the fields and set of operations of the 16
database” to implement his objectives but instead merely states 17
that the database stores the records of the patients. A database 18
which does no more than passively store records does not 19
require a set of operations. 20
App. Br. 16-17. Any database is comprised of fields and records and its 21
implementing database management system necessarily provides a set of 22
operations for maintaining and querying the database. Both Hacker and 23
Felsher show their medical databases residing on database servers, which are 24
known to those in the art as requiring a database management system for 25
implementation. 26
Appeal 2011-010518
Application 10/431,845
11

With respect to claims 4 and 5, reciting “programming logic controls the 1
sharing of information of database client records between client authorized 2
users consistent with specified user privileges” and “programming logic to 3
control document retrieval,” respectively, we are not persuaded by the 4
Appellant’s argument that “[c]ontrol over access has nothing to do with the 5
sharing of information in database client records between different client-6
authorized users.” App. Br. 18. Sharing is no more than access by plural 7
parties, not necessarily at the same time. Thus sharing is a subset of the 8
scope of forms of access over which Felsher describes control. 9
With respect to claim 6, reciting “triggering an alert to be communicated 10
to one or more authorized users as calls for emergency action,” we are not 11
persuaded by the Appellant’s argument that “[n]o mention is made of 12
triggering an alert to be communicated to one or more authorized users as 13
calls for emergency action in col.7 lines 66-67 or in col. 8 lines 1-8 of 14
Hacker.” App. Br. 19. This portion of Hacker describes notifying a patient 15
as to what information is released in an emergency override, and is thus a 16
release for emergency action. 17
With respect to claim 10, reciting “using said programming logic for 18
enabling client-authorized users to generate coordinated assessment reports 19
of a client from different authorized users,” we are not persuaded by the 20
Appellant’s argument that “Hacker does not teach using programming logic 21
and does not teach generating coordinated reports of a client from different 22
authorized users.” App. Br. 20. The contention regarding programming 23
logic is cumulative, and Hacker’s description of diagnostic labs posting test 24
results in patient records are instances of client-authorized users generating 25
coordinated assessment reports. 26
Appeal 2011-010518
Application 10/431,845
12

With respect to claim 11, reciting “authorizing a plurality of authorized 1
users to coordinate treatment of an individual in a named client account and 2
for generating a coordinated treatment plan,” we are not persuaded by the 3
Appellant’s argument that “Hacker does not teach having a plurality of 4
authorized users generate a coordinated treatment plan for a patient.” App. 5
Br. 20. Hacker’s description of medical providers viewing appropriate 6
portions of the patients medical record, and adding information to the 7
patient’s medical record where appropriate, are instances of coordinate 8
treatment of an individual in a named client account and generating a 9
coordinated treatment plan. 10
With respect to claim 12, reciting: 11
storing insurance records of an individual in a named client 12
account and assigning a given health insurance carrier 13
authorization to access the named client account with the 14
authorization record including the stipulation that the privilege 15
of access is strictly limited to viewing of the insurance records 16
of the named client. 17
(Claim 12), we are not persuaded by the Appellant’s argument that “[n]o 18
such teaching of storing insurance records of a patient exists in Hacker and 19
Hacker does not teach limiting the privilege of access strictly to viewing of 20
the insurance records of the named client.” App. Br. 21. Hacker’s 21
description of submitting insurance claims makes providing insurance 22
carriers with at least view access predictable. Also, an insurance carrier is 23
simply a role in the health care system, and Felsher describes assigning 24
access rights based on roles. 25
Appeal 2011-010518
Application 10/431,845
13

CONCLUSIONS OF LAW 1
The rejection of claims 3-6 and 10-15 under 35 U.S.C. § 103(a) as 2
unpatentable over Hacker and Felsher is proper. 3
The rejection of claims 7 and 8 under 35 U.S.C. § 103(a) as unpatentable 4
over Hacker, Felsher, and Voegeli is proper. 5
The rejection of claim 9 under 35 U.S.C. § 103(a) as unpatentable over 6
Hacker, Felsher, and Hotchkiss is proper. 7
DECISION 8
The rejection of claims 3-15 is affirmed. 9
No time period for taking any subsequent action in connection with this 10
appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 11
§ 1.136(a)(1)(iv) (2011). 12
AFFIRMED 13
llw 14
15