Christopher W. BellDownload PDFPatent Trials and Appeals BoardOct 28, 201914040991 - (D) (P.T.A.B. Oct. 28, 2019) Copy Citation 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) Copy with citationCopy as parenthetical citation