Christopher W. Bell

Patent Trials and Appeals Board

Oct 28, 2019

14040991 - (D) (P.T.A.B. Oct. 28, 2019)

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.
14/040,991 09/30/2013 Christopher W. Bell 83395115 1016
28395 7590 10/28/2019
BROOKS KUSHMAN P.C./FGTL
1000 TOWN CENTER
22ND FLOOR
SOUTHFIELD, MI 48075-1238
EXAMINER
HOLLOWAY, JASON R
ART UNIT PAPER NUMBER
3664
NOTIFICATION DATE DELIVERY MODE
10/28/2019 ELECTRONIC
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.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
docketing@brookskushman.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte CHRISTOPHER W. BELL
Appeal 2019-001147
Application 14/040,991
Technology Center 3600
Before CHARLES N. GREENHUT, MICHAEL L. HOELTER, and
JEREMY M. PLENZLER, Administrative Patent Judges.
GREENHUT, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1–7 and 9–20. See Non-Final Act. 1.
We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.

1 We use the word Appellant to refer to “applicant” as defined in 37 C.F.R.
§ 1.42. Appellant identifies the real party in interest as Ford Global
Technologies, LLC. Appeal Br. 1.
Appeal 2019-001147
Application 14/040,991

2
CLAIMED SUBJECT MATTER
The claims are directed to a vehicle diagnostic and prognostic systems
and methods. Claim 1, reproduced below, is illustrative of the claimed
subject matter:
1. A vehicle computing system comprising:
a processor in communication with a wireless transceiver
and programmed to:
transmit vehicle data not otherwise communicated over a
vehicle network to a remote server via the wireless transceiver in
response to a request for the vehicle data received from the
remote server, the vehicle data transmitted after reading the data
from a vehicle module memory location determined from the
request.
REFERENCE
The prior art relied upon by the Examiner is:
Name Reference Date
Kolls US 6,895,310 B1 May 17, 2005
Francoeur US 2011/0046832 A1 Feb. 24, 2011
REJECTIONS
Claims 17–20 are rejected under 35 U.S.C. § 112(a) as containing
subject matter not described in the specification. Non-Final Act. 5.
Claims 1–7 and 9–20 are rejected under 35 U.S.C. § 112(b) as being
indefinite. Non-Final Act. 6.
Claims 1–3, 6, 7, 9, 12–15, 17, and 20 are rejected under 35 U.S.C.
§ 103 as being unpatentable over Kolls. Non-Final Act. 10.
Claims 4–6, 10, 11, 18, and 19 are rejected under 35 U.S.C. § 103 as
being unpatentable over Kolls and Francoeur. Non-Final Act. 12.
Appeal 2019-001147
Application 14/040,991

3
OPINION
§ 112(a) New matter not adequately described
With regard to the claim 17 phrase, “transmitting the data to the server
only in response to a request for the data from the server” the Examiner
found a lack of supporting disclosure for the term “only” when it was newly
inserted by way of amendment. See Non-Final Act. 5. New or amended
claims which introduce elements or limitations which are not supported by
the as-filed disclosure violate the written description requirement. See, e.g.,
In re Lukach, 442 F.2d 967 (CCPA 1971).
Appellant argues that “[t]he word ‘only’ is essentially superfluous to a
proper interpretation of ‘in response to a request.’” Appeal Br. 4. We
disagree.2 Data may be transmitted in response to a request while also being
broadcast at other times. The term “only” clearly changes the limits on when
data can be transmitted to the server, precluding broadcasting it without
requests. As transmission to the server is the relevant step here, it is not clear
why Appellant cites, reproduces, and emphasizes language in paragraphs
dealing with situations when data is not communicated on or over the
vehicle network. See Appeal Br. 4–5. We understand, based on Appellant’s
Specification, server communication to be possible without necessarily
implicating the vehicle network. See Spec. para. 39. Appellant has not
provided any argument or apprised us of any evidence to the contrary.

2 Claims are construed with an eye toward giving effect to all terms in the
claim. See Bicon Inc. v. Straumann Co., 441 F.3d 945, 950 (Fed. Cir. 2006).
See also Stumbo v. Eastman Outdoors, Inc., 508 F.3d 1358, 1362 (Fed. Cir.
2007) (denouncing claim constructions which render phrases in claims
superfluous).

Appeal 2019-001147
Application 14/040,991

4
The remarks provided by Appellant do little, if anything, to controvert
the Examiner’s seemingly reasonable position. Accordingly, we sustain the
Examiner’s rejection under 35 U.S.C. § 112(a).

§ 112(b) Indefiniteness
The Examiner provides several grounds for indefiniteness, each of
which we address below. It is not entirely clear, but the Examiner’s
comment, “[t]he following is a non-exhaustive list” (Non-Final Act. 6)
might hint at the possibility there are other unstated grounds for holding the
claims indefinite. The Patent Trial and Appeal Board is primarily a tribunal
of review. See Ex parte Frye, 94 USPQ2d 1072, 1075–77 (BPAI 2010)
(precedential). “The examiner cannot sit mum, leaving the applicant to shoot
arrows into the dark hoping to somehow hit a secret objection harbored by
the examiner.” In re Oetiker, 977 F.2d 1443, 1449 (Fed. Cir. 1992) (Plager,
J., concurring). It is neither our place, nor Appellant’s burden, to speculate
as to the basis for rejecting claims. In re Stepan, 660 F.3d 1341, 1345 (Fed.
Cir. 2011) (It is the PTO’s obligation to provide timely notice to the
applicant of all matters of fact and law asserted.) Although the Board is
authorized to reject claims under 37 C.F.R. § 41.50(b), no inference should
be drawn when the Board elects not to do so. See MPEP § 1213.02.

“data not otherwise communicated over a vehicle network”
We do not see, and the Examiner does not adequately explain, any
lack of clarity with this limitation specifically because it is a negative
limitation presented early in the claim (Non-Final Act. 8; Appeal Br. 11).
However, in the context that it is used in claims 1, 9, and 17, the Examiner
Appeal 2019-001147
Application 14/040,991

5
reasonably identifies an ambiguity, in that it is not clear from the claim
language whether “over a vehicle network” is an attribute of the recited
action, transmitting (claims 1 and 9) or receiving (claim 17), or a further
description of context in which the data is not otherwise communicated. See
Final Act. 6. The first interpretation posed would mean, as the Examiner
phrases it, “the vehicle data is not otherwise communicated in general” and
is transmitted over a vehicle network to a remote server. Non-Final Act. 6.
The second of the interpretations posed is that data “not otherwise
communicated over a vehicle network” is transmitted, with or without the
use of the vehicle network, to a remote server.
As alluded to in our discussion of the rejection under § 112(a), it
would appear from the Specification that what might be contemplated are
mutually exclusive options for transmitting the data, either over the vehicle
network, or to the remote server. Spec. para. 39. However, this is not entirely
clear because it is not clear that data transmission cannot both use the
vehicle network and also be transmitted to a remote server. Appellant does
not present any argument or apprise us of any language in the Specification
to definitively clarify this. If Appellant wishes to limit the claims to
particular embodiments disclosed in the Specification it is up to Appellant to
do so. It is not our responsibility to scour the Specification in an effort to
import limitations that resolve ambiguities in the claim language. In re
Morris, 127 F.3d 1048, 1056 (Fed. Cir. 1997) (“35 U.S.C. § 112[b] . . . puts
the burden of precise claim drafting squarely on the applicant.”)
Our reviewing court has “cautioned against reading limitations into a
claim from the preferred embodiment described in the specification, even if
it is the only embodiment described, absent clear disclaimer in the
Appeal 2019-001147
Application 14/040,991

6
specification.” In re Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1369 (Fed.
Cir. 2004) (citations omitted). This warning is particularly applicable here,
where Appellant has not presented any estoppel-generating arguments3 on
the issue, so as to clearly disavow subject matter encompassed by a chosen
claim interpretation. Id. (quoting Liebel-Flarsheim Co. v. Medrad, Inc., 358
F.3d 898, 906 (Fed. Cir. 2004)). Appellant argues only that “multiple
permutations” do not necessarily demonstrate indefiniteness without
addressing the specific ambiguities identified by the Examiner. Appeal Br.
5–6. Accordingly, the Examiner was justified in requiring Appellant to
resolve these ambiguities during prosecution while Appellant has that
opportunity. See Ex parte Miyazaki, 89 USPQ2d 1207, 1211 (BPAI 2008)
accord In re Packard, 751 F.3d 1307, 1313–14 (Fed. Cir. 2014).

“a vehicle module memory”
According to the Examiner, “it appears there is part of the claim
missing since it is unclear what a ‘vehicle module memory’ entails as this
phrasing appears to be a very condensed version of the actual description in
the specification.” Final Act. 7.
Appellant misinterprets the Examiner’s comment about a part of the
claim being missing as the Examiner asserting that the claim “omi[ts]

3 See, e.g., Conoco, Inc. v. Energy & Environmental Int’l, L.C., 460 F.3d
1349, 1363 (Fed. Cir. 2006) (“prosecution history estoppel can occur during
prosecution . . . by surrendering claim scope through argument.” (Citation
omitted.); see also Omega Engineering, Inc. v. Raytek Corp., 334 F.3d 1314,
1324 (Fed. Cir. 2003) (“where the patentee has unequivocally disavowed a
certain meaning to obtain his patent, the doctrine of prosecution disclaimer
attaches and narrows the ordinary meaning of the claim congruent with the
scope of the surrender.”).
Appeal 2019-001147
Application 14/040,991

7
essential elements” in the manner discussed in MPEP § 2172.01. Appeal Br.
7. The Examiner clarifies that was not the Examiner’s intent. Ans. 8.
Regarding this issue, Appellant also reproduces several paragraphs from the
Specification, asserting, “Applicant’s disclosure is abundantly clear with
respect to what ‘vehicle module memory’ entails giving examples of
particular modules (BCCM), hexadecimal memory addresses/locations
(0x84E), and variable names (available charger input power).” Appeal Br.
10 (quoting from, without citation to, Figure 7B).
It seems Appellant is asserting that the Battery Charging Control
Module, the “BCCM,” is itself an example of a “vehicle memory module.”
Figure 7B depicts a graphical user interface for retrieving data which
appears to be about the BCCM, but it is not clear that the data represented in
Figure 7B resides on the BCCM. Figure 7B depicts “variable address (e.g.,
in a hex format).” The variable addresses in hexadecimal format would,
most likely, be understood by the skilled artisan to refer to memory
addresses residing somewhere. However, Appellant’s arguments on this
issue do not provide any indication regarding where, or on what,
specifically, those addresses refer.
From the quoted portion of the Specification (Appeal Br. 8–10) it
seems that there is a possibility that control modules 203 may have their own
readable memory. Spec. para. 39. However, it has not been clarified that the
BCCM is among the modules 203. Figure 7B depicts “BCM” within box
203, but the Specification does not discuss a BCM or expressly indicate that
the BCCM is among the modules 203. Another portion of the Specification
quoted by Appellant refers to various devices typically dedicated for the
purpose of data storage. Spec. para. 21. Both the Examiner and the
Appeal 2019-001147
Application 14/040,991

8
Appellant recognize that although the exact phrase may not be used in the
Specification, the Specification makes the general comment, “[t]he
processor may retrieve a memory read from one or more modules.” Ans. 10;
Appeal Br. 8.
In light of the foregoing discussion, we think “vehicle module
memory” refers to memory on any component associated with a vehicle and
having memory, whether or not that component is dedicated to the purpose
of storing data, or does so incidental to some other function or functions.
Thus, we conclude the phrase is broad but not indefinite and do not rely on
these grounds to sustain the Examiner’s § 112(b) rejection.

“the vehicle data associated with the data identifier not otherwise
communicated over a vehicle network”
It is not clear where this limitation, regarded by the Examiner as
unclear (Non-Final Act. 7), appears in the claims presently before us for
review. Accordingly, we do not rely on this grounds to sustain the
Examiner’s § 112(b) rejection.

“a variable address” (claims 7 and 16)
Examples of variable addresses are, as discussed above, depicted in
Figure 7. We agree with Appellant that the term is used in the Specification
and claims to refer to the storage location in memory of a variable and that
this usage is consistent with that customary in the art. Appeal Br. 12.4

4 See, e.g., https://en.wikipedia.org/wiki/Memory_address;
https://en.wikipedia.org/wiki/Variable_(computer_science) (last accessed
Oct. 10, 2019).
Appeal 2019-001147
Application 14/040,991

9
Accordingly, we do not rely on this grounds to sustain the Examiner’s
§ 112(b) rejection.
Obviousness
The claims rejected based on Kolls alone are argued as a group (see
Appeal Br. 13–15) for which we select claim 1 as representative. 37 C.F.R.
§ 41.37(c)(1)(iv). Appellant does not present any additional substantive
arguments regarding the claims rejected based on Kolls and Francoeur.
Appeal Br. 15.
Even though contested aspects (see Appeal Br. 13–15) of the
Examiner’s rejection of claim 1 involve the limitation discussed above with
regard to the § 112(b) rejection, the uncertainty concerning this claim
language does not preclude us from addressing the prior art rejections based
entirely, or in part, on Kolls. This is because the relevant portion of Kolls
suggests a sufficient matrix of communication possibilities that includes
ones that suggest the subject matter covered by either of the possible claim
interpretations discussed above. Although not made explicit by the
Examiner, based on the Examiner’s paraphrasing of the limitation in
question, it appears the Examiner addressed the claim language in question
for purposes of the prior-art rejections by using the latter of the proposed
interpretations discussed above. Non-Final Act. 11 (“data not otherwise
transmitted in a vehicle network is transmitted to the remote server [with or
without using the vehicle network].”) (emphasis added). As mentioned
above, this interpretation appears to be more reflective of the embodiments
disclosed in Appellant’s Specification.
The Examiner has relied primarily on the methods of Kolls that are
depicted in Figures 6 and 7. Non-Final Act. 11; Ans. 13–15. The process
Appeal 2019-001147
Application 14/040,991

10
depicted in Figure 6 of Kolls involves the communication of GPS
information. The information can be communicated or “transmit[ed]”
between the in-vehicle device 200, a COM device proximate the vehicle, and
an Internet-based or “remote” server (steps 506, 508). That communication
may be in response to a request from the police or another entity (step 504).
In the method depicted in Figure 7 of Kolls an audio (mic) and/or video feed
can be communicated in similar fashion (step 612) upon receipt of a request
(606). Both Figure 6 and Figure 7 depict a step (512 and 614, respectively)
in which data communication can be suspended or terminated. The
Examiner acknowledged that Kolls does not explicitly disclose the absence
of data transmission in the vehicle network. Non-Final Act. 10. However,
the Examiner reasonably found that such a modification would have been
obvious “to prevent the sending of unwanted data.” Non-Final Act. 11.
Appellant argues the Examiner’s stated reasoning is conclusory and
does not solve a problem recognized by Kolls. Appeal Br. 13. Initially, it is
noted that the reasoning to modify a prior-art reference need not be based on
solving a problem recognized by the prior-art inventor, or expressly
discussed in the prior-art reference. A reason to modify a prior art reference
may be found explicitly or implicitly in market forces; design incentives; or
“any need or problem known in the field of endeavor at the time of
invention.” Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1328–
29 (Fed. Cir. 2009) (quoting KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398,
418–21 (2007)). In any case, in Kolls discussion of Figures 6 and 7 and
repeatedly in the discussion of the other methods cited by the Examiner,
Kolls expressly states, “[d]ata communication suspension or termination can
be desirable where the cost of communications, the availability of
Appeal 2019-001147
Application 14/040,991

11
communications, or the option not to maintain data communications is
desirable.” Kolls col. 51, ll. 39–44; col. 52, ll. 30–34. Of course, if the GPS
data of the Figure 6 method or the audio/video data of the Figure 7 method
will not be used for any purpose within the vehicle, it makes little sense to
consume resources by transmitting that data over the in-vehicle network.
The fact that Kolls teaches this concept specifically with respect to external
communications (Ans. 13) may defeat an anticipation rejection under § 102,
but the fact that it is generally applicable strongly supports the Examiner’s
rejection under § 103. The hypothetical artisan of § 103 must be presumed to
know something about the art apart from what the references expressly
disclose. In re Jacoby, 309 F.2d 513, 516 (CCPA 1962).
Appellant makes a brief argument regarding the alleged absence of a
“data identifier” in Kolls. Appellant does not provide any explanation as to
why the request queries relied upon by the Examiner do not serve to identify
the desired data. Non-Final Act. 12; Ans. 14. Moreover, this limitation does
not appear in independent claim 1 which has been chosen as representative
of the claims Appellant has chosen to argue as a group under 37 C.F.R.
§ 41.37(c)(1)(iv). Limitations not appearing in the claims cannot be relied
upon for patentability. In re Self, 671 F.2d 1344, 1348 (CCPA 1982).
Appellant’s final argument is that “there is no disclosure or suggestion
of transmitting vehicle data in response to a request for the data from the
remote server. Rather, Kolls transmits data in response to an engine anomaly
(block 1404) or a user requesting service (block 1406).” Appeal Br. 14.
Appellant correctly reproduces the column and line numbers of Kolls cited
by the Examiner regarding the rejection of claim 1. However, Appellant then
goes on to address a procedure, and particular aspects of that procedure, that
Appeal 2019-001147
Application 14/040,991

12
are not relied on by the Examiner for rejecting, or that appear to have any
relevance to the rejection of, claim 1. Appellant’s argument does not address
the requests at steps 504, 506, and 606 in Figures 6 and 7 and discussed in
columns 51–52 of Kolls. Arguments must address the Examiner’s action. 37
C.F.R. § 41.37(c)(1)(iv) (“The arguments shall explain why the examiner
erred as to each ground of rejection contested by appellant”).
For the foregoing reasons, we sustain the Examiner’s rejections under
35 U.S.C. § 103.
CONCLUSION
The Examiner’s rejection under 35 U.S.C. § 112(a) is affirmed.
The Examiner’s rejection under 35 U.S.C. § 112(b) is affirmed, but
only on the grounds so indicated above.5
The Examiner’s rejections under 35 U.S.C. § 103(a) are affirmed.

5 “The affirmance of the rejection of a claim on any of the grounds specified
constitutes a general affirmance of the decision of the examiner on that
claim, except as to any ground specifically reversed.” 37 C.F.R.
§ 41.50(a)(1).
Appeal 2019-001147
Application 14/040,991

13
DECISION SUMMARY
Claims
Rejected
35 U.S.C. § Basis  Affirmed Reversed
17–20 112(a) Written description 17–20
1–7 and
9–20
112(b) Indefiniteness 1–7 and 9–
20

1–3, 6, 7,
9, 12–15,
17, and
20
103 Kolls 1–3, 6, 7, 9,
12–15, 17,
and 20

4–6, 10,
11, 18,
and 19
103 Kolls, Francoeur  4–6, 10, 11,
18, and 19

Overall Outcome: 1–7 and 9–
20

TIME PERIOD FOR RESPONSE
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 1.136(a)(1)(iv).
AFFIRMED

Notice of References Cited

Application/Control No.

14/040,991
Applicant(s)/Patent Under
Reexamination

Examiner

Art Unit

Page 1 of 1

U.S. PATENT DOCUMENTS

* Document Number Country Code-Number-Kind Code Date MM-YYYY

Name

Classification
1 A US- 1 1
B US-
C US-
D US-
E US-
F US-
G US-
H US-
I US-
J US-
K US-
L US-
M US-
FOREIGN PATENT DOCUMENTS

* Document Number Country Code-Number-Kind Code Date MM-YYYY

Country

Name

Classification
N
O
P
Q
R
S
T
NON-PATENT DOCUMENTS
* Include as applicable: Author, Title Date, Publisher, Edition or Volume, Pertinent Pages)

U

https://en.wikipedia.org/wiki/Memory_address;

V

https://en.wikipedia.org/wiki/Variable_(computer_science)

W

X

*A copy of this reference is not being furnished with this Office action. (See MPEP § 707.05(a).)
Dates in MM-YYYY format are publication dates. Classifications may be US or foreign.

U.S. Patent and Trademark Office
PTO-892 (Rev. 01-2001) Notice of References Cited Part of Paper No.
Delete Last PagelAdd A Page
10/21/2019 Memory address - Wikipedia
https://en.wikipedia.org/wiki/Memory_address 1/4
Memory address
In computing, a memory address is a reference to a specific
memory location used at various levels by software and
hardware. Memory addresses are fixed-length sequences of digits
conventionally displayed and manipulated as unsigned
integers.[1] Such numerical semantic bases itself upon features of
CPU (such as the instruction pointer and incremental address
registers), as well upon use of the memory like an array endorsed
by various programming languages.
Types of memory addresses
Physical addresses
Logical addresses
Unit of address resolution
Word size versus address size
Contents of each memory location
Address space in application programming
Addressing schemes
Memory models
Memory models in x86 architecture
See also
References
A digital computer's main memory consists of many memory locations. Each memory location has a physical
address which is a code. The CPU (or other device) can use the code to access the corresponding memory location.
Generally only system software, i.e. the BIOS, operating systems, and some specialized utility programs (e.g., memory
testers), address physical memory using machine code operands or processor registers, instructing the CPU to direct a
hardware device, called the memory controller, to use the memory bus or system bus, or separate control, address and
data busses, to execute the program's commands. The memory controllers' bus consists of a number of parallel lines, each
represented by a binary digit (bit). The width of the bus, and thus the number of addressable storage units, and the
number of bits in each unit, varies among computers.
In a computer using virtual memory, accessing
the location corresponding to a memory address
may involve many levels.
Contents
Types of memory addresses
Physical addresses
Logical addresses
10/21/2019 Memory address - Wikipedia
https://en.wikipedia.org/wiki/Memory_address 2/4
A computer program uses memory addresses to execute machine code, and to store and retrieve data. In early computers
logical and physical addresses corresponded, but since the introduction of virtual memory most application programs do
not have a knowledge of physical addresses. Rather, they address logical addresses, or virtual addresses, using the
computer's memory management unit and operating system memory mapping; see below.
Most modern computers are byte-addressable. Each address identifies a single byte (eight bits) of storage. Data larger
than a single byte may be stored in a sequence of consecutive addresses. There exist word-addressable computers, where
the minimal addressable storage unit is exactly the processor's word. For example, the Data General Nova minicomputer,
and the Texas Instruments TMS9900 and National Semiconductor IMP-16 microcomputers used 16 bit words, and there
were many 36-bit mainframe computers (e.g., PDP-10) which used 18-bit word addressing, not byte addressing, giving an
address space of 218 36-bit words, approximately 1 megabyte of storage. The efficiency of addressing of memory depends
on the bit size of the bus used for addresses – the more bits used, the more addresses are available to the computer. For
example, an 8-bit-byte-addressable machine with a 20-bit address bus (e.g. Intel 8086) can address 220 (1,048,576)
memory locations, or one MiB of memory, while a 32-bit bus (e.g. Intel 80386) addresses 232 (4,294,967,296) locations,
or a 4 GiB address space. In contrast, a 36-bit word-addressable machine with an 18-bit address bus addresses only 218
(262,144) 36-bit locations (9,437,184 bits), equivalent to 1,179,648 8-bit bytes, or 1152 KB, or 1.125 MiB—slightly more
than the 8086.
Some older computers (decimal computers), were decimal digit-addressable. For example, each address in the IBM
1620's magnetic-core memory identified a single six bit binary-coded decimal digit, consisting of a parity bit, flag bit and
four numerical bits. The 1620 used 5-digit decimal addresses, so in theory the highest possible address was 99,999. In
practice, the CPU supported 20,000 memory locations, and up to two optional external memory units could be added,
each supporting 20,000 addresses, for a total of 60,000 (00000–59999).
A word size is characteristic to a given computer architecture. It denotes the number of bits that a CPU can process at one
time. Modern processors, including embedded systems, usually have a word size of 8, 16, 24, 32 or 64 bits; most current
general purpose computers use 32 or 64 bits. Many different sizes have been used historically, including 8, 9, 10, 12, 18,
24, 36, 39, 40, 48 and 60 bits.
Very often, when referring to the word size of a modern computer, one is also describing the size of address space on that
computer. For instance, a computer said to be "32-bit" also usually allows 32-bit memory addresses; a byte-addressable
32-bit computer can address 232 = 4,294,967,296 bytes of memory, or 4 gibibytes (GiB). This allows one memory address
to be efficiently stored in one word.
However, this does not always hold true. Computers can have memory addresses larger or smaller than their word size.
For instance, many 8-bit processors, such as the MOS Technology 6502, supported 16-bit addresses— if not, they would
have been limited to a mere 256 bytes of memory addressing. The 16-bit Intel 8088 and Intel 8086 supported 20-bit
addressing via segmentation, allowing them to access 1 MiB rather than 64 KiB of memory. All Intel Pentium processors
since the Pentium Pro include Physical Address Extensions (PAE) which support mapping 36-bit physical addresses to 32-
bit virtual addresses.
In theory, modern byte-addressable 64-bit computers can address 264 bytes (16 exbibytes), but in practice the amount of
memory is limited by the CPU, the memory controller, or the printed circuit board design (e.g. number of physical
memory connectors or amount of soldered-on memory).
Unit of address resolution
Word size versus address size
10/21/2019 Memory address - Wikipedia
https://en.wikipedia.org/wiki/Memory_address 3/4
Each memory location in a stored-program computer holds a binary number or decimal number of some sort. Its
interpretation, as data of some data type or as an instruction, and use are determined by the instructions which retrieve
and manipulate it.
Some early programmers combined instructions and data in words as a way to save memory, when it was expensive: The
Manchester Mark 1 had space in its 40-bit words to store little bits of data – its processor ignored a small section in the
middle of a word – and that was often exploited as extra data storage. Self-replicating programs such as viruses treat
themselves sometimes as data and sometimes as instructions. Self-modifying code is generally deprecated nowadays, as it
makes testing and maintenance disproportionally difficult to the saving of a few bytes, and can also give incorrect results
because of the compiler or processor's assumptions about the machine's state, but is still sometimes used deliberately,
with great care.
In modern multitasking environment, an application process usually has in its address space (or spaces) chunks of
memory of following types:
Machine code, including:
program's own code (historically known as code segment or text segment);
shared libraries.
Data, including:
initialized data (data segment);
uninitialized (but allocated) variables;
run-time stack;
heap;
shared memory and memory mapped files.
Some parts of address space may be not mapped at all.
A computer program can access an address given explicitly – in low-level programming this is usually called an
absolute address, or sometimes a specific address, and is known as pointer data type in higher-level languages. But a
program can also use relative address which specifies a location in relation to somewhere else (the base address). There
are many more indirect addressing modes.
Mapping logical addresses to physical and virtual memory also adds several levels of indirection; see below.
Many programmers prefer to address memory such that there is no distinction between code space and data space (cf.
above), as well as from physical and virtual memory (see below) — in other words, numerically identical pointers refer to
exactly the same byte of RAM.
However, many early computers did not support such a flat memory model — in particular, Harvard architecture
machines force program storage to be completely separate from data storage. Many modern DSPs (such as the Motorola
56000) have three separate storage areas — program storage, coefficient storage, and data storage. Some commonly used
Contents of each memory location
Address space in application programming
Addressing schemes
Memory models
10/21/2019 Memory address - Wikipedia
https://en.wikipedia.org/wiki/Memory_address 4/4
instructions fetch from all three areas simultaneously — fewer storage areas (even if there were the same total bytes of
storage) would make those instructions run slower.
Early x86 computers use the segmented memory model addresses based on a combination of two numbers: a memory
segment, and an offset within that segment.
Some segments are implicitly treated as code segments, dedicated for instructions, stack segments, or normal data
segments. Although the usages are different, the segments do not have different memory protections reflecting this. In the
flat memory model all segments (segment registers) are generally set to zero, and only offsets are variable.
Memory model (programming)
Memory allocation
Memory address register
Base address
Offset (computer science), also known as a displacement
Endianness
Memory management unit (MMU)
Page table
Memory protection
Memory segmentation
Low-level programming language
1. "Archived copy" (https://web.archive.org/web/20121021050559/http://www.personal.psu.edu/dlw27/IST225/Hex_Dec_
Memory.pdf) (PDF). Archived from the original (http://www.personal.psu.edu/dlw27/IST225/Hex_Dec_Memory.pdf)
(PDF) on 2012-10-21. Retrieved 2013-12-15.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Memory_address&oldid=916918101"
This page was last edited on 21 September 2019, at 09:51 (UTC).
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this
site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
Foundation, Inc., a non-profit organization.
Memory models in x86 architecture
See also
References
10/21/2019 Variable (computer science) - Wikipedia
https://en.wikipedia.org/wiki/Variable_(computer_science) 1/6
Variable (computer science)
In computer programming, a variable or scalar is a storage location (identified by a memory address) paired with an
associated symbolic name, which contains some known or unknown quantity of information referred to as a value. The
variable name is the usual way to reference the stored value, in addition to referring to the variable itself, depending on the
context. This separation of name and content allows the name to be used independently of the exact information it
represents. The identifier in computer source code can be bound to a value during run time, and the value of the variable
may thus change during the course of program execution.[1] [2]
Variables in programming may not directly correspond to the concept of variables in mathematics. The latter is abstract,
having no reference to a physical object such as storage location. The value of a computing variable is not necessarily part
of an equation or formula as in mathematics. Variables in computer programming are frequently given long names to
make them relatively descriptive of their use, whereas variables in mathematics often have terse, one- or two-character
names for brevity in transcription and manipulation.
A variable's storage location may be referred by several different identifiers, a situation known as aliasing. Assigning a
value to the variable using one of the identifiers will change the value that can be accessed through the other identifiers.
Compilers have to replace variables' symbolic names with the actual locations of the data. While a variable's name, type,
and location often remain fixed, the data stored in the location may be changed during program execution.
Actions on a variable
Identifiers referencing a variable
Scope and extent
Typing
Parameters
Memory allocation
Naming conventions
Variable types (based on lifetime)
See also
Notes
References
In imperative programming languages, values can generally be accessed or changed at any time. In pure functional and
logic languages, variables are bound to expressions and keep a single value during their entire lifetime due to the
requirements of referential transparency. In imperative languages, the same behavior is exhibited by (named) constants
(symbolic constants), which are typically contrasted with (normal) variables.
Contents
Actions on a variable
10/21/2019 Variable (computer science) - Wikipedia
https://en.wikipedia.org/wiki/Variable_(computer_science) 2/6
Depending on the type system of a programming language, variables may only be able to store a specified datatype (e.g.
integer or string). Alternatively, a datatype may be associated only with the current value, allowing a single variable to
store anything supported by the programming language.
Variables and scope:- (A) Automatic variables: - Each local variable in a function comes into existence only when the
function is called, and disappears when the function is exited. Such variables are known as automatic variables. (B)
External variables: - These are variables that are external to a function on and can be accessed by name by any function.
These variables remain in existence permanently; rather that appearing and disappearing as functions are called and
exited, retain their values even after the functions that set them have returned.
An identifier referencing a variable can be used to access the variable in order to read out the value, or alter the value, or
edit other attributes of the variable, such as access permission, locks, semaphores, etc.
For instance, a variable might be referenced by the identifier "total_count" and the variable can contain the number
1956. If the same variable is referenced by the identifier "r" as well, and if using this identifier "r", the value of the variable
is altered to 2009, then reading the value using the identifier "total_count" will yield a result of 2009 and not 1956.
If a variable is only referenced by a single identifier that can simply be called the name of the variable. Otherwise, we can
speak of one of the names of the variable. For instance, in the previous example, the "total_count" is a name of the
variable in question, and "r" is another name of the same variable.
The scope of a variable describes where in a program's text the variable may be used, while the extent (or lifetime)
describes when in a program's execution a variable has a (meaningful) value. The scope of a variable is actually a property
of the name of the variable, and the extent is a property of the variable itself. These should not be confused with context
(also called environment), which is a property of the program, and varies by point in the source code or execution – see
scope: overview. Further, object lifetime may coincide with variable lifetime, but in many cases is not tied to variable
lifetime.
A variable name's scope affects its extent.
Scope is an important part of the name resolution of a variable. Most languages define a specific scope for each variable (as
well as any other named entity), which may differ within a given program. The scope of a variable is the portion of the
program code for which the variable's name has meaning and for which the variable is said to be "visible". Entrance into
that scope typically begins a variable's lifetime (as it comes into context) and exit from that scope typically ends its lifetime
(as it goes out of context). For instance, a variable with "lexical scope" is meaningful only within a certain
function/subroutine, or more finely within a block of expressions/statements (accordingly with function scope or block
scope); this is static resolution, performable at parse-time or compile-time. Alternatively, a variable with dynamic scope is
resolved at run-time, based on a global binding stack that depends on the specific control flow. Variables only accessible
within a certain functions are termed "local variables". A "global variable", or one with indefinite scope, may be referred to
anywhere in the program.
Extent, on the other hand, is a runtime (dynamic) aspect of a variable. Each binding of a variable to a value can have its
own extent at runtime. The extent of the binding is the portion of the program's execution time during which the variable
continues to refer to the same value or memory location. A running program may enter and leave a given extent many
times, as in the case of a closure.
Identifiers referencing a variable
Scope and extent
10/21/2019 Variable (computer science) - Wikipedia
https://en.wikipedia.org/wiki/Variable_(computer_science) 3/6
Unless the programming language features garbage collection, a variable whose extent permanently outlasts its scope can
result in a memory leak, whereby the memory allocated for the variable can never be freed since the variable which would
be used to reference it for deallocation purposes is no longer accessible. However, it can be permissible for a variable
binding to extend beyond its scope, as occurs in Lisp closures and C static local variables; when execution passes back into
the variable's scope, the variable may once again be used. A variable whose scope begins before its extent does is said to be
uninitialized and often has an undefined, arbitrary value if accessed (see wild pointer), since it has yet to be explicitly
given a particular value. A variable whose extent ends before its scope may become a dangling pointer and deemed
uninitialized once more since its value has been destroyed. Variables described by the previous two cases may be said to be
out of extent or unbound. In many languages, it is an error to try to use the value of a variable when it is out of extent. In
other languages, doing so may yield unpredictable results. Such a variable may, however, be assigned a new value, which
gives it a new extent.
For space efficiency, a memory space needed for a variable may be allocated only when the variable is first used and freed
when it is no longer needed. A variable is only needed when it is in scope, thus beginning each variable's lifetime when it
enters scope may give space to unused variables. To avoid wasting such space, compilers often warn programmers if a
variable is declared but not used.
It is considered good programming practice to make the scope of variables as narrow as feasible so that different parts of a
program do not accidentally interact with each other by modifying each other's variables. Doing so also prevents action at
a distance. Common techniques for doing so are to have different sections of a program use different name spaces, or to
make individual variables "private" through either dynamic variable scoping or lexical variable scoping.
Many programming languages employ a reserved value (often named null or nil) to indicate an invalid or uninitialized
variable.
In statically typed languages such as Java or ML, a variable also has a type, meaning that only certain kinds of values can
be stored in it. For example, a variable of type "integer" is prohibited from storing text values.
In dynamically typed languages such as Python, it is values, not variables, which carry type. In Common Lisp, both
situations exist simultaneously: A variable is given a type (if undeclared, it is assumed to be T, the universal supertype)
which exists at compile time. Values also have types, which can be checked and queried at runtime.
Typing of variables also allows polymorphisms to be resolved at compile time. However, this is different from the
polymorphism used in object-oriented function calls (referred to as virtual functions in C++) which resolves the call based
on the value type as opposed to the supertypes the variable is allowed to have.
Variables often store simple data, like integers and literal strings, but some programming languages allow a variable to
store values of other datatypes as well. Such languages may also enable functions to be parametric polymorphic. These
functions operate like variables to represent data of multiple types. For example, a function named length may determine
the length of a list. Such a length function may be parametric polymorphic by including a type variable in its type
signature, since the number of elements in the list is independent of the elements' types.
The formal parameters (or formal arguments) of functions are also referred to as variables. For instance, in this Python
code segment,
Typing
Parameters
10/21/2019 Variable (computer science) - Wikipedia
https://en.wikipedia.org/wiki/Variable_(computer_science) 4/6
>>> def addtwo(x):
... return x + 2
...
>>> addtwo(5)
7
the variable named x is a parameter because it is given a value when the function is called. The integer 5 is the argument
which gives x its value. In most languages, function parameters have local scope. This specific variable named x can only
be referred to within the addtwo function (though of course other functions can also have variables called x).
The specifics of variable allocation and the representation of their values vary widely, both among programming languages
and among implementations of a given language. Many language implementations allocate space for local variables,
whose extent lasts for a single function call on the call stack, and whose memory is automatically reclaimed when the
function returns. More generally, in name binding, the name of a variable is bound to the address of some particular block
(contiguous sequence) of bytes in memory, and operations on the variable manipulate that block. Referencing is more
common for variables whose values have large or unknown sizes when the code is compiled. Such variables reference the
location of the value instead of storing the value itself, which is allocated from a pool of memory called the heap.
Bound variables have values. A value, however, is an abstraction, an idea; in implementation, a value is represented by
some data object, which is stored somewhere in computer memory. The program, or the runtime environment, must set
aside memory for each data object and, since memory is finite, ensure that this memory is yielded for reuse when the
object is no longer needed to represent some variable's value.
Objects allocated from the heap must be reclaimed—especially when the objects are no longer needed. In a garbage-
collected language (such as C#, Java, Python, Golang and Lisp), the runtime environment automatically reclaims objects
when extant variables can no longer refer to them. In non-garbage-collected languages, such as C, the program (and the
programmer) must explicitly allocate memory, and then later free it, to reclaim its memory. Failure to do so leads to
memory leaks, in which the heap is depleted as the program runs, risks eventual failure from exhausting available
memory.
When a variable refers to a data structure created dynamically, some of its components may be only indirectly accessed
through the variable. In such circumstances, garbage collectors (or analogous program features in languages that lack
garbage collectors) must deal with a case where only a portion of the memory reachable from the variable needs to be
reclaimed.
Unlike their mathematical counterparts, programming variables and constants commonly take multiple-character names,
e.g. COST or total. Single-character names are most commonly used only for auxiliary variables; for instance, i, j, k for
array index variables.
Some naming conventions are enforced at the language level as part of the language syntax which involves the format of
valid identifiers. In almost all languages, variable names cannot start with a digit (0–9) and cannot contain whitespace
characters. Whether or not punctuation marks are permitted in variable names varies from language to language; many
languages only permit the underscore ("_") in variable names and forbid all other punctuation. In some programming
languages, sigils (symbols or punctuation) are affixed to variable identifiers to indicate the variable's datatype or scope.
Memory allocation
Naming conventions
10/21/2019 Variable (computer science) - Wikipedia
https://en.wikipedia.org/wiki/Variable_(computer_science) 5/6
Case-sensitivity of variable names also varies between languages and some languages require the use of a certain case in
naming certain entities;[note 1] Most modern languages are case-sensitive; some older languages are not. Some languages
reserve certain forms of variable names for their own internal use; in many languages, names beginning with two
underscores ("__") often fall under this category.
However, beyond the basic restrictions imposed by a language, the naming of variables is largely a matter of style. At the
machine code level, variable names are not used, so the exact names chosen do not matter to the computer. Thus names of
variables identify them, for the rest they are just a tool for programmers to make programs easier to write and understand.
Using poorly chosen variable names can make code more difficult to review than non-descriptive names, so names which
are clear are often encouraged.[3][4]
Programmers often create and adhere to code style guidelines which offer guidance on naming variables or impose a
precise naming scheme. Shorter names are faster to type but are less descriptive; longer names often make programs
easier to read and the purpose of variables easier to understand. However, extreme verbosity in variable names can also
lead to less comprehensible code.
In terms of the classifications of variables, we can classify variables based on the lifetime of them. The different types of
variables are static, stack-dynamic, explicit heap-dynamic, and implicit heap-dynamic. A static variable is also known as
global variable, it is bound to a memory cell before execution begins and remains to the same memory cell until
termination. A typical example is the static variables in C and C++. A Stack-dynamic variable is known as local variable,
which is bound when the declaration statement is executed, and it is deallocated when the procedure returns. The main
examples are local variables in C subprograms and Java methods. Explicit Heap-Dynamic variables are nameless
(abstract) memory cells that are allocated and deallocated by explicit run-time instructions specified by the programmer.
The main examples are dynamic objects in C++ (via new and delete) and all objects in Java. Implicit Heap-Dynamic
variables are bound to heap storage only when they are assigned values. Allocation and release occur when values are
reassigned to variables. As a result, Implicit heap-dynamic variables have the highest degree of flexibility. The main
examples are some variables in JavaScript, PHP and all variables in APL.
Control variable (programming)
Non-local variable
Temporary variable
Variable interpolation
1. For example, Haskell requires that names of types start with a capital letter.
1. Compilers: Principles, Techniques, and Tools, pp. 26–28
2. Knuth, Donald (1997). The Art of Computer Programming. 1 (3rd ed.). Reading, Massachusetts: Addison-Wesley.
p. 3-4. ISBN 0-201-89683-4.
3. How Not To Pick Variables (http://www.dotcadot.ca/articles/how-not-pick-variables), Retrieved July 11, 2012 [DEAD
LINK]
Variable types (based on lifetime)
See also
Notes
References
10/21/2019 Variable (computer science) - Wikipedia
https://en.wikipedia.org/wiki/Variable_(computer_science) 6/6
Retrieved from "https://en.wikipedia.org/w/index.php?title=Variable_(computer_science)&oldid=922147112"
This page was last edited on 20 October 2019, at 07:44 (UTC).
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this
site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
Foundation, Inc., a non-profit organization.
4. Edsger Dijkstra, To hell with “meaningful identifiers”! (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E
WD1044.html)