DETAILED ACTION
This action is in response to the amendments filed on Feb. 17th, 2026 A summary of this action:
Claims 11 and 15 have been presented for examination.
Claims 11 and 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of a mental process without significantly more
Claim(s) 11, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shafiq, M., and S. Lockley. "Signature-based matching of IFC models." 35th International Symposium on Automation and Robotics in Construction (ISARC). 2018 in view of Weinstein et al., US 2015/0234848.
This action is Final
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments/Amendments
Regarding the claim objections
Withdrawn in view of amendment.
Regarding the § 101 Rejection
Maintained, updated as necessitated by amendment.
Remarks at 4-5 are merely conveying automating a manual activity, which is not an improvement to technology. MPEP § 2106.05(a)(I): “Examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality:…iii. Mere automation of manual processes, such as using a generic computer to process an application for financing a purchase, Credit Acceptance Corp. v. Westlake Services, 859 F.3d 1044, 1055, 123 USPQ2d 1100, 1108-09 (Fed. Cir. 2017) or speeding up a loan-application process by enabling borrowers to avoid physically going to or calling each lender and filling out a loan application, LendingTree, LLC v. Zillow, Inc., 656 Fed. App'x 991, 996-97 (Fed. Cir. 2016) (non-precedential);” – then see MPEP § 2106.05(f): “Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept”
Remarks then focus on the “encoding”, but see MPEP § 2106.05(I): “RecogniCorp, LLC v. Nintendo Co., 855 F.3d 1322, 1327, 122 USPQ2d 1377 (Fed. Cir. 2017) ("Adding one abstract idea (math) to another abstract idea (encoding and decoding) does not render the claim non-abstract")” – also, see the July 2024 Fed. Register notice for its citation to PersonalWeb Techs.
See the rationale of the rejection, i.e. this is an abstract idea. See PersonalWeb, as was cited to for its opinion to clarify in the rejection at pages 6-7.
Data extraction, i.e. collecting information for files is similarly abstract for the reasons stated in the rejection given the generality claimed, with the only linkage in the claim to the filetype of “BIM” being akin to that of Intellectual Ventures in MPEP §2106.05(f and h) for “XML” – see the rejection to clarify on this point.
Code calculation is not claimed, rather is merely “computing a code…”. If this is intended to be calculating a code then it would be a math concept in textual form of a math calculation. Furthermore, see the rejection. Even if this was limited to a hash code, see PersonalWeb on this point, as this was noted in the rejection for its “content-based identifier” was hash or message digest function”. But the claim does not even limit itself to that. See the rejection to clarify.
Combining pieces of information together is no less abstract for the reasons stated in the rejection, i.e. the claim recites no particularity on these steps, outside of merely saying they are integrated. E.g. simply appending three codes together by writing them out on pen and paper. See rejection to clarify.
Furthermore, these remarks allege many unrecited features are in the claims (e.g. that the computing of the code is a math calculation in textual form), but as the adage goes the name of the game is the claim. Remarks for unrecited features with no express basis in the claims are moot, because the feature is not expressly required by the claim.
Similarly, these remarks allege many more pieces of evidence for the improvement to technology then found in the specification as was discussed in the rejection. The improvements consideration is an evidence based consideration (MPEP § 2106.05(a)), so see MPEP § 2145(I): “Arguments presented by applicant cannot take the place of evidence in the record. See In re De Blauwe, 736 F.2d 699, 705, 222 USPQ 191, 196 (Fed. Cir. 1984); In re Schulze, 346 F.2d 600, 602, 145 USPQ 716, 718 (CCPA 1965); In re Geisler, 116 F.3d 1465, 43 USPQ2d 1362 (Fed. Cir. 1997) ("An assertion of what seems to follow from common experience is just attorney argument and not the kind of factual evidence that is required to rebut a prima facie case of obviousness.")
Regarding the § 102/103 Rejection
Maintained, updated as necessitated by amendment.
Remarks do not address the rejection of record, in particular they do not point out how the language of the claims themselves distinguish from the relied upon citations, as evidenced by alleging the integration of codes step being novel compared to Shafiq, which is solely a piecemeal analysis again Shafiq for a feature that Shafiq did not teach (see the rejection) but rather Weinstein was relied upon in combination with Shafiq for this feature.
With respect to Weinstein remarks, these again don’t address the particular citations of Weinstein relied upon or the particular language of the claim and how the claim is distinguished from Weinstein, and it takes Weinstein in a vacuum as a piecemeal attack against Weinstein alone without addressing that the rejection relied upon a particular combination of two references with a particular rationale stated to support this rejection.
Furthermore, the Examiner notes these remarks heavily allege a large number of features that have no express basis in the claims themselves. In other words, it’s not addressing the detailed rejection and rationale of record, by pointing out how the language of the claims themselves distinguish from the prior art. See MPEP § 2145, including (I, II, IV) and then see subsection VI: “Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993) (Claims to a superconducting magnet which generates a "uniform magnetic field" were not limited to the degree of magnetic field uniformity required for Nuclear Magnetic Resonance (NMR) imaging. Although the specification disclosed that the claimed magnet may be used in an NMR apparatus, the claims were not so limited.); Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571-72, 7 USPQ2d 1057, 1064-1065 (Fed. Cir.), cert. denied, 488 U.S. 892 (1988) (Various limitations on which appellant relied were not stated in the claims; the specification did not provide evidence indicating these limitations must be read into the claims to give meaning to the disputed terms.); Ex parte McCullough, 7 USPQ2d 1889, 1891 (Bd. Pat. App. & Inter. 1987) (Claimed electrode was rejected as obvious despite assertions that electrode functions differently than would be expected when used in nonaqueous battery since "although the demonstrated results may be germane to the patentability of a battery containing appellant’s electrode, they are not germane to the patentability of the invention claimed on appeal.").”
To clarify, MPEP § 2103: “In re Hiniker Co., 150 F.3d 1362, 1369, 47 USPQ2d 1523, 1529 (Fed. Cir. 1998) ("[T]he name of the game is the claim.")” and MPEP § 2111: “In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969) (Claim 9 was directed to a process of analyzing data generated by mass spectrographic analysis of a gas. The process comprised selecting the data to be analyzed by subjecting the data to a mathematical manipulation. The examiner made rejections under 35 U.S.C. 101 and 35 U.S.C. 102. In the 35 U.S.C. 102 rejection, the examiner explained that the claim was anticipated by a mental process augmented by pencil and paper markings. The court agreed that the claim was not limited to using a machine to carry out the process since the claim did not explicitly set forth the machine. The court explained that "reading a claim in light of the specification, to thereby interpret limitations explicitly recited in the claim, is a quite different thing from ‘reading limitations of the specification into a claim,’ to thereby narrow the scope of the claim by implicitly adding disclosed limitations which have no express basis in the claim." The court found that applicant was advocating the latter, i.e., the impermissible importation of subject matter from the specification into the claim.). See also In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997)”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11 and 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of a mental process without significantly more.
The abstract idea recited in these claims, described at a high level of abstraction, is nothing more than the abstract idea of comparing information items to see whether or not the information has changed between new sets of information and old sets of information, but for the mere instructions to do this on a computer and generally linking to the field of use of “BIM” by its recitation in the preamble (see MPEP § 2106.05(f): “Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017)…Although the claims purported to modify the underlying XML document in response to modifications made in the dynamic document, nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents…”). See below for additional details on this rejection.
Similar such claims have previously been found to be an abstract idea without significantly more and without an integration to a practical application. See the July 2024 Fed. Register Notice for its discussion of “Claims to “the use of an algorithm-generated content-based identifier to perform the claimed data-management functions,” which include limitations to “controlling access to data items,” “retrieving and delivering copies of data items,” and “marking copies of data items for deletion,” where the claims cover “a medley of mental processes that, taken together, amount only to a multistep mental process,” such that the steps can be practically performed in the human mind, PersonalWeb Techs. LLC v. Google LLC, 8 F.4th 1310, 1316-18 (Fed. Cir. 2021).“ – wherein, as noted above, this being in the field of use of “BIM” is only recited in the preamble, i.e. its not required that the files/objects are even BIM files and objects in the body of the claim.
To clarify, the Examiner notes that the instant disclosure, page 10, description of S1: “all objects in both the old and new files are encoded, wherein code resulted
may be hash code, object signature, object fingerprint, etc., and then an object is taken out of the old or new file… Code being identical but resulted from different raw data is called encoding conflict (such as hash collision)…” and see fig. 69b) for the drop-down, including the “Comparison-first (HashCode)” and “Comparison-first (Quick HashCode)”, then see the opinion of PersonalWeb: “…The district court, on the other hand, concluded that the patents are directed to a three-step process: "(1) using a content-based identifier generated from a 'hash or message digest function,' (2) comparing that content-based identifier against something else, [that is,] another content-based identifier or a request for data; and (3) providing access to, denying access to, or deleting data." PersonalWeb, 2020 U.S. Dist. LEXIS 20015 , [2020 BL 41760], 2020 WL 520618 , at *10. We adopt the district court's view, which closely tracks the claim language. PersonalWeb Techs. LLC v. Google LLC, 8 F.4th 1310, 1315 (Fed. Cir. 2021)… First is the use of a content-based identifier. We said that was abstract in Erie… We similarly described content-based identifiers as abstract in Secured Mail Solutions LLC v. Universal Wilde, Inc., 873 F.3d 905 , 910-11 (Fed. Cir. 2017) (abstract idea of using a "unique identifier . . . to communicate information about the mail object, i.e., the sender, recipient, and contents of the mail object"), and Intellectual Ventures I LLC v. Symantec Corp., 838 F.3d 1307 , 1313 (Fed. Cir. 2016) ( abstract idea of "receiving e-mail (and other data file) [**6] [***6] identifiers, characterizing e-mail based on the identifiers, and communicating the characterization"). The claims' use of content-based identifiers, therefore, is abstract. Generating such identifiers via a known algorithm is no less abstract. "[W]e have treated analyzing information by steps people go through in their minds, or by mathematical algorithms, without more, as essentially mental processes within the abstract-idea category." Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350 , 1354 (Fed. Cir. 2016) (collecting cases)). For [*1317] instance, the identifiers claimed in Symantec were created "using a mathematical algorithm." 838 F.3d at 1313 . And in RecogniCorp, LLC v. Nintendo Co., we explained that "[a] process that started with data, added an algorithm, and ended with a new form of data was directed to an abstract idea." 855 F.3d 1322 , 1327 (Fed. Cir. 2017). That, too, holds true here. Second is the step of comparing the content-based identifier against other values. That is also abstract… Third is the data-management function, which varies across the three patents. Each such function is abstract…”
Step 1
Claim 11 is directed towards the statutory category of a process.
Step 2A – Prong 1
The claims recite an abstract idea of a mental process. See MPEP § 2106.04(a)(2).
As an initial matter, the present claims do not even recite the use of a computer. See MPEP § 2111: “In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969) (Claim 9 was directed to a process of analyzing data generated by mass spectrographic analysis of a gas. The process comprised selecting the data to be analyzed by subjecting the data to a mathematical manipulation. The examiner made rejections under 35 U.S.C. 101 and 35 U.S.C. 102. In the 35 U.S.C. 102 rejection, the examiner explained that the claim was anticipated by a mental process augmented by pencil and paper markings. The court agreed that the claim was not limited to using a machine to carry out the process since the claim did not explicitly set forth the machine. The court explained that "reading a claim in light of the specification, to thereby interpret limitations explicitly recited in the claim, is a quite different thing from ‘reading limitations of the specification into a claim,’ to thereby narrow the scope of the claim by implicitly adding disclosed limitations which have no express basis in the claim." The court found that applicant was advocating the latter, i.e., the impermissible importation of subject matter from the specification into the claim.).”
The mental process recited in claim 11 is:
A method for automatically identifying design changes in a building information model (BIM) regarding a construction project , comprising steps of: - a mental process with an intended use, wherein there is not even an express recitation of the use of a computer.
S1, encoding all objects in an old file and a new file to obtain individual codes of the all objects, comprising:
- a mental process. The encoding of information, i.e. taking a piece of information, e.g. text, and encoding it to another form is a mental process that was performed well before the advent of a computer, such as in the American Revolution or in the 1800’s for encoding into Morse code for the use of the telegraph, and the taking is mere mental data collecting, e.g. observing a folder with a series of papers in it (example of a file with objects), and mentally judging to take out one of those papers (e.g. by physically removing it from the folder).
To clarify, this limitation does not recite any particularity in how this step is performed, nor require the use of a computer (as discussed above). Rather, it is directed at the mental process itself, i.e. the abstract idea of mentally encoding objects in files, e.g. by converting the text of papers in files to Morse code for the use of the telegraph for transmission (wherein the telegraph existed long before computers, see MPEP § 2106.04(b) for “O’Reilly v. Morse, 56 U.S. 62, 113 (1853)”). Nor does this limitation even recite what information is in the files, or what the objects are, i.e. this readily encompasses paper files (e.g. in file folders, or binders, or other collections of documents), wherein each paper in the file is an object, and the encoding is performed on each paper.
Other types of encoding may also be readily performed mentally, e.g. the use simpler cryptographic cyphers that have existed long before the invention of the computer, e.g. the cyphers used in the American Revolution (evidence provided below for clarity of record of the existence of such cyphers and their use to encode paper documents, e.g. George Washington encountered encoded paper files).
The Examiner further notes that neither the claims nor the instant disclosure (page 10) discuss any particular technological method, e.g. a conventional algorithm, to even perform this step, even if such use was recited, as per PersonalWeb as was discussed above: “…The claims' use of content-based identifiers, therefore, is abstract. Generating such identifiers via a known algorithm is no less abstract.”
To further clarify on the history of encoding textual documents, see Wilcox, “Revolutionary Secrets: Cryptology in the American Revolution”, 2012, United States National Security Agency, Center for Cryptologic History, accessed via URL: media(dot)defense(dot)gov/2021/Jul/13/2002761510/-1/-1/0/REVOLUTIONARY_SECRETS_2012(dot)PDF – see pages 7-10 which discuss an example wherein George Washington encountered an encoded piece of information (page 8) and by working with others found a means to decipher the message (pages 9-10). Also see the section “West Point for Sale” starting on page 26 for a second example.
Furthermore, the Examiner notes that the use of the encoded information by these present claims is for nothing more than checking whether or not information was changed between two versions of files – as such, the encoding may also be a simple encoding system, e.g. the use of the Dewey Decimal System by a librarian, and assigning different codes to a new revision of a book, determined by a simple mental observation, e.g. 101.101, and to an older version of a book, e.g. 101.100.
In the context of structure design, the Examiner notes that the present claims still reflect what is a mental process, e.g. an architect, civil engineer, or structural engineer, mentally observing a series of drawings/blueprints for a building, wherein each drawing is from a different period in time (e.g. drawings of the US White House or Congress, which have both received multiple renovations and changes), mentally judging each time there are design changes in the drawings (e.g. addition of a room, changing locations of walls, etc.), mentally judging that each time there is a design change to encode the drawing with a version number, e.g. Rev. A, Rev. B, etc., and thus allowing the person to later come back to the same drawings and quickly judge if the drawing is the same as an older drawing, or different (e.g. suppose there are 4 drawings of the same floorplan of the White House from different architects in the 1700’s to early 1800’s, and each one was encoded mentally with “Rev. A.”, and then there is a drawing with a new floorplan, e.g. one from after the War of 1812, which was then mentally encoded with “Rev. B.” because there were design changes from the older drawings) – wherein such codes may readily be assigned at a more granular level to various portions of the drawing, e.g. writing down revision numbers for each room in the drawing, or each element in each room. In such a mental process, a computer may readily be used as a tool to automate the mental process.
- S1.1, taking out the first object from the old file or the new file: - S1.2, extracting data of a first category, a second category and a third category of data changes of the first object, the first category comprises a category of attribute data, the second category comprises a category of shape data, and the third category comprises a category of relationship data: - S1.3, computing a code for each of the first, second, and third categories, according to the first category, the second category and the third category of data changes of the first object; and - S1.4, integrating all codes for the first, second and third categories into an object code selected from one of a hash code, an object signature or an object fingerprint, comprising checking for change at a model level:– a mental process, akin to the ones discussed above. E.g. the person removes a paper from a folder of papers (a file), observes information on the paper so as to perform the extracting, mentally judging/evaluating to compute a piece of code for each category, and then mentally tabulating the results, or using pen and paper to do so (e.g. write down a table, wherein each row contains the category observed and the mental code representing the category, e.g. in the Dewey Decimal System, the code 101 is for the category Theory of philosophy. The integrating may readily be performed mentally, e.g. by appending the various codes onto each other using pen and paper, or any other means of integrating/combining the codes into one code. Similar for the checking for a change at a model level, e.g. compare the integrated/combined code with a prior code, such as in a mental evaluation/judgement, and if the code is the same then no change, else there is a change. E.g. comparing two random MD5 hashes of: 7c6a180b36896a0a8c02787eeafb0e4c and 7c6a180b36896a0a8c02787eeafb0e4c – to observe no change; or 7c6a180b36896a0a8c02787eeafb0e4c and 7c6a180b36896z0a8c02787eeafb0e4c – and mentally observing the change of “z”.
As one more point of clarity, see the instant disclosure, page 1: “However manual checking for design changes is time-consuming and error-prone, so research into automatic identification of design changes has great significance.” And page 6: “During a multi-discipline collaborative design, through helping identify changes in model files in a rapid and accurate manner and ensuring accurate, project-significant, and rapid design change identification, a number of benefits are brought into the collaborative design: for example, a tedious and omission-prone work that a designer searches for those changed portion manually is eliminated;” and to clarify, see Lin, Jia-Rui, and Yu-Cheng Zhou. "Semantic classification and hash code accelerated detection of design changes in BIM models." Automation in Construction 115 (2020): 103212 – this is a publication by the instant inventors related to the claimed invention (see the fig. 13, in comparison to instant fig. 6), wherein, in § 1 ¶¶ 1-2: “…Changes in design are inevitable, and come from multiple sources at any time, which lead to extensive impacts [2,3]. Over the past decade, Building Information Modeling (BIM) has increasingly been adopted as a digital representation, as a knowledge resource and as an integrated method for building lifecycle management [4–7]. However, it is challenging to detect design changes as they are often documented in meeting memos, mail correspondences, on a post-it on the project manager's table, or solely in the memory of the project participants [8–10]. Furthermore, substantial information losses occur whenever an employee leaves the project [11]… However, manually detecting or checking for design changes is time consuming and error prone. Therefore, automated design change detection is highly important. Design change detection began when 2D-based drawings were used to represent a facility…” – also see § 2 ¶¶ 1-3 – i.e. design change detection in the field of use of architecture/buildings is a historically manual process, resultant from human mental judgments, first performed with 2D-based drawings (e.g. blueprints), and nowadays computers, and generic computer components/software, are a tool used to automate said process.
See MPEP § 2106.05(a)(I): “iii. Mere automation of manual processes, such as using a generic computer to process an application for financing a purchase, Credit Acceptance Corp. v. Westlake Services, 859 F.3d 1044, 1055, 123 USPQ2d 1100, 1108-09 (Fed. Cir. 2017) or speeding up a loan-application process by enabling borrowers to avoid physically going to or calling each lender and filling out a loan application, LendingTree, LLC v. Zillow, Inc., 656 Fed. App'x 991, 996-97 (Fed. Cir. 2016) (non-precedential);”
See MPEP § 2106.05(f): “Similarly, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015)”
S2, determining whether the object code of the first object is equal to code of one or more second objects in the new file or the old file, if so, then the first object is not changed, if not, proceeding to a next step; - a mental observation/evaluation/judgement, e.g. a person mentally observing codes, such as those from the encoding discussed above (although the claim does not even require the use of the results of the encoding step), and comparing them to mentally judge/evaluate if the code was changed, e.g. does 101.101 = 101.100?
Even if “code of the object” was interpreted to be programming code (e.g. four lines of code for a computer program), this would still be a mental process, e.g. a person making an observation of two sets of code (e.g. the code printed onto paper), and judging/evaluating whether they are the same. E.g., see Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1147-49, 120 USPQ2d 1473, 1480-81 (Fed. Cir. 2016) as discussed in MPEP § 2106.04(a)(2)(III) and see the above discussed PersonalWeb.
S3, determining whether the first object matches one or more of the second objects in the new file or the old file, if so, the first object is a modified object, if not, the first object is a deleted or newly added object; -- a continuation of the mental process discussed above, wherein this is a mental judgement/evaluation based on a mental observation akin to the ones discussed above.
and S4, outputting an outcome of change identification and returning to the step S1 until the change identification has been applied on the all objects in the old file or the new file; - performing the mental process iteratively, e.g. a person going through every paper in a folder and performing the method repetitively.
wherein, the old file and the new file are building information model files, and the first object and the second objects each represent physical objects applied in the construction project related to the new file and the old file, - further limiting the mental process (e.g. to construction documents such as blueprints) but for the mere instructions to do it on a computer and/or generally linking to a particular technological environment (“BIM”), akin to being in the “context of XML” (MPEP § 2106.05(f)).
wherein, the method is able to obtain the outcome of change identification with referenceability in a case of an identifier, ID, of the first object or IDs of the second objects being changed incidentally, wherein the outcome of change identification with referenceability refers to considering a specific change of the first object as no change of the first object at a model level, - further limiting the mental process as discussed above, if this is to be given any patentable weight with a speculative interpretation (the speculative interpretation that this is merely claiming the “Model Level” checking for whether or not a change is “meaningless” as discussed on page 9 of the instant disclosure, also see page 13, ¶¶ 1-4)
Under the broadest reasonable interpretation, these limitations are process steps that cover mental processes including an observation, evaluation, judgment or opinion that could be performed in the human mind or with the aid of pencil and paper but for the recitation of a generic computer component. If a claim, under its broadest reasonable interpretation, covers a mental process but for the recitation of generic computer components, then it falls within the "Mental Process" grouping of abstract ideas. A person would readily be able to perform this process either mentally or with the assistance of pen and paper. See MPEP § 2106.04(a)(2).
To clarify, see the USPTO 101 training examples, available at https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility. In particular, with respect to the physical aids, see example # 45, analysis of claim 1 under step 2A prong 1, including: “Note that even if most humans would use a physical aid (e.g., pen and paper, a slide rule, or a calculator) to help them complete the recited calculation, the use of such physical aid does not negate the mental nature of this limitation.”; also see example # 49, analysis of claim 1, under step 2A prong 1: “Moreover, the recited mathematical calculation is simple enough that it can be practically performed in the human mind. Even if most humans would use a physical aid, like a pen and paper or a calculator, to make such calculations, the use of a physical aid would not negate the mental nature of this limitation.”.
As such, the claims recite a mental process.
Step 2A, prong 2
The claimed invention does not recite any additional elements that integrate the judicial exception into a practical application. Refer to MPEP §2106.04(d).
The claims do not even recite the use of a computer. MPEP § 2111: “In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969) (Claim 9 was directed to a process of analyzing data generated by mass spectrographic analysis of a gas. The process comprised selecting the data to be analyzed by subjecting the data to a mathematical manipulation. The examiner made rejections under 35 U.S.C. 101 and 35 U.S.C. 102. In the 35 U.S.C. 102 rejection, the examiner explained that the claim was anticipated by a mental process augmented by pencil and paper markings. The court agreed that the claim was not limited to using a machine to carry out the process since the claim did not explicitly set forth the machine. The court explained that "reading a claim in light of the specification, to thereby interpret limitations explicitly recited in the claim, is a quite different thing from ‘reading limitations of the specification into a claim,’ to thereby narrow the scope of the claim by implicitly adding disclosed limitations which have no express basis in the claim." The court found that applicant was advocating the latter, i.e., the impermissible importation of subject matter from the specification into the claim.).”
Even if one were to be recited, this would merely be merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f), including the “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more”
The recitation of “BIM” in the body of the claim is considered as merely instructions to do it on a computer with commonplace software (instant disclosure; page 1, ¶¶ 1-2), akin to MPEP § 2106.05(f): “Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), the steps in the claims described "the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’" 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of "collecting, displaying, and manipulating data." 850 F.3d at 1340; 121 USPQ2d at 1946. In addition to the abstract idea, the claims also recited the additional element of modifying the underlying XML document in response to modifications made in the dynamic document. 850 F.3d at 1342; 121 USPQ2d at 1947-48. Although the claims purported to modify the underlying XML document in response to modifications made in the dynamic document, nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents. The court thus held the claims ineligible, because the additional limitations provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words "apply it". 850 F.3d at 1341-42; 121 USPQ2d at 1947-48 (citing Electric Power Group., 830 F.3d at 1356, 1356, USPQ2d at 1743-44 (cautioning against claims "so result focused, so functional, as to effectively cover any solution to an identified problem")).”
The following limitations are generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h):
In the preamble, the recitation of “in a BIM [“Building Information Model” which is “widely used” as per page 1 of the instant disclosure]”, as well as the later recitation of specifying “BIM files” – this is akin to “Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017)…merely using the abstract idea in the context of XML document” as discussed in MPEP § 2106.05(f) and MPEP § 2106.05(h): “Intellectual Ventures I LLC v. Erie Indem. Co., 850 F.3d 1315, 1328-29, 121 USPQ2d 1928, 1939 (Fed. Cir. 2017) (limiting use of abstract idea to use with XML tags)”.
In addition, should it be found that step S1 and S1.1-S1.4 are not part of the abstract idea, then these would be insignificant extra-solution activities of mere data gathering of the codes for use in the later recited mental process of comparing codes (e.g. a person is readily able to mentally compare two simple hash values) as well as part of the mere instructions to do it on a computer, wherein this is merely using generic functions, as part of the mere instructions to do it on a computer, for creating a “code” (as recited in the claims)/”content-identifier” (see PersonalWeb Techs. LLC v. Google LLC as discussed above, include seeing: “So, "[w]hat else is there in the claims before us?" Mayo, 566 U.S. at 78 . As to the subject-matter question, not much. The district court had it right: there is "nothing 'inventive' about any claim details, individually or in combination, that are not themselves abstract ideas." PersonalWeb, 2020 U.S. Dist. LEXIS 20015 , [2020 BL 41760], 2020 WL 520618 , at *13. The district court was also right that "[u]sing a generic hash function, a server system, or a computer does not render these claims non-abstract." Id. "[O]ur precedent is clear that merely adding computer functionality to increase the speed or efficiency of the process does not confer patent eligibility on an otherwise abstract idea." Intell. Ventures I LLC v. Cap. One Bank (USA), 792 F.3d 1363 , 1370 (Fed. Cir. 2015);…”
In addition, should it be found that step S4 is not part of the abstract idea for its “outputting…” recitation, then this would be an insignificant extra-solution activity of mere data outputting.
“and feeding the outcome to an user;” is considered as a token post solution activity of mere data outputting, akin to the displaying of data in example 46 claim 1.
A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. See MPEP § 2106.04(d).
The claimed invention does not recite any additional elements that integrate the judicial exception into a practical application. Refer to MPEP §2106.04(d).
Step 2B
The claimed invention does not recite any additional elements/limitations that amount to significantly more.
The claims do not even recite the use of a computer. MPEP § 2111: “In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969) (Claim 9 was directed to a process of analyzing data generated by mass spectrographic analysis of a gas. The process comprised selecting the data to be analyzed by subjecting the data to a mathematical manipulation. The examiner made rejections under 35 U.S.C. 101 and 35 U.S.C. 102. In the 35 U.S.C. 102 rejection, the examiner explained that the claim was anticipated by a mental process augmented by pencil and paper markings. The court agreed that the claim was not limited to using a machine to carry out the process since the claim did not explicitly set forth the machine. The court explained that "reading a claim in light of the specification, to thereby interpret limitations explicitly recited in the claim, is a quite different thing from ‘reading limitations of the specification into a claim,’ to thereby narrow the scope of the claim by implicitly adding disclosed limitations which have no express basis in the claim." The court found that applicant was advocating the latter, i.e., the impermissible importation of subject matter from the specification into the claim.).”
Even if one were to be recited, this would merely be merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f), including the “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more”
The recitation of “BIM” in the body of the claim is considered as merely instructions to do it on a computer with commonplace software (instant disclosure; page 1, ¶¶ 1-2), akin to MPEP § 2106.05(f): “Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), the steps in the claims described "the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’" 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of "collecting, displaying, and manipulating data." 850 F.3d at 1340; 121 USPQ2d at 1946. In addition to the abstract idea, the claims also recited the additional element of modifying the underlying XML document in response to modifications made in the dynamic document. 850 F.3d at 1342; 121 USPQ2d at 1947-48. Although the claims purported to modify the underlying XML document in response to modifications made in the dynamic document, nothing in the claims indicated what specific steps were undertaken other than merely using the abstract idea in the context of XML documents. The court thus held the claims ineligible, because the additional limitations provided only a result-oriented solution and lacked details as to how the computer performed the modifications, which was equivalent to the words "apply it". 850 F.3d at 1341-42; 121 USPQ2d at 1947-48 (citing Electric Power Group., 830 F.3d at 1356, 1356, USPQ2d at 1743-44 (cautioning against claims "so result focused, so functional, as to effectively cover any solution to an identified problem")).”
The following limitations are generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h):
In the preamble, the recitation of “in a BIM [“Building Information Model” which is “widely used” as per page 1 of the instant disclosure]”, as well as the later recitation of specifying “BIM files” – this is akin to “Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017)…merely using the abstract idea in the context of XML document” as discussed in MPEP § 2106.05(f) and MPEP § 2106.05(h): “Intellectual Ventures I LLC v. Erie Indem. Co., 850 F.3d 1315, 1328-29, 121 USPQ2d 1928, 1939 (Fed. Cir. 2017) (limiting use of abstract idea to use with XML tags)”.
In addition, should it be found that step S1 and S1.1-S1.4 are not part of the abstract idea, then these would be insignificant extra-solution activities of mere data gathering of the codes for use in the later recited mental process of comparing codes (e.g. a person is readily able to mentally compare two simple hash values) as well as part of the mere instructions to do it on a computer, wherein this is merely using generic functions, as part of the mere instructions to do it on a computer, for creating a “code” (as recited in the claims)/”content-identifier” (see PersonalWeb Techs. LLC v. Google LLC as discussed above, include seeing: “So, "[w]hat else is there in the claims before us?" Mayo, 566 U.S. at 78 . As to the subject-matter question, not much. The district court had it right: there is "nothing 'inventive' about any claim details, individually or in combination, that are not themselves abstract ideas." PersonalWeb, 2020 U.S. Dist. LEXIS 20015 , [2020 BL 41760], 2020 WL 520618 , at *13. The district court was also right that "[u]sing a generic hash function, a server system, or a computer does not render these claims non-abstract." Id. "[O]ur precedent is clear that merely adding computer functionality to increase the speed or efficiency of the process does not confer patent eligibility on an otherwise abstract idea." Intell. Ventures I LLC v. Cap. One Bank (USA), 792 F.3d 1363 , 1370 (Fed. Cir. 2015);…” – wherein the remaining steps (S1.1, S1.2, S1.4) are akin to the WURC activities of “iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;” as discussed in MPEP § 2106.05(d)(II) given the generic nature of what is recited (i.e. merely specifying what data is to obtained in S1.1-S1.2, with no particular way of how it is obtained; and merely storing the data together for S1.4, as the claim recites no particular manner in how the integration/combination is performed). For additional evidence, see:
Lee, Suk-Hwan, and Ki-Ryong Kwon. "Robust 3D mesh model hashing based on feature object." Digital Signal Processing 22.5 (2012): 744-759. Abstract: “3D model hashing can be very useful for the authentication, indexing, copy detection, and watermarking of 3D content, in a manner similar to image hashing…” and § 1 ¶¶ 1-2, also see § 2 including the subsections
Martínez, Salvador, Sébastien Gérard, and Jordi Cabot. "Robust hashing for models." Proceedings of the 21th ACM/IEEE International Conference on Model Driven Engineering Languages and Systems. 2018.Abstract, § 1 including ¶¶ 1-3 incl. : “Indeed, robust hashing algorithms have been proved useful as a key building block for providing intellectual property protection, authenticity assessment and fast comparison and retrieval solutions in different application domains such as digital images [14], 3D models [20] or text documents [34].” – and § 2.1 for more details.
Yu et al., US 2017/0213395, ¶ 47: “Therefore, when authoring tool 101 has made a change in a 3D graphic object, it can be notified to identify the change. Alternatively, according to one of the embodiments of the present invention, hash codes are calculated for 3D graphic objects. When the hash code of a 3D graphic object changes, it implies that there is a change in the 3D graphic object. Therefore, content processor 102 can identify the change. There are many techniques to calculate a hash code, including using cyclic redundancy check (CRC) and Secure Hash Algorithm (SHA). The hash code is calculated based on the serialized data of the 3D graphic object or the file of the 3D graphic object.”
Oraskari, Jyrki, and Seppo Törmä. "RDF-based signature algorithms for computing differences of IFC models." Automation in Construction 57 (2015): 213-221. Abstract: “The capability to accurately detect changes between successive versions of the IFC representation of a BIM model would enable the development of generic change management functionalities for construction projects.” And § 1 ¶¶ 1-4, then § 3 ¶ 5, then § 4 ¶¶ 1-2
Shafiq, M., and S. Lockley. "Signature-based matching of IFC models." 35th International Symposium on Automation and Robotics in Construction (ISARC). 2018. § 4 ¶¶ 1-3.
Shi, Xin, et al. "IFCdiff: A content-based automatic comparison approach for IFC files." Automation in Construction 86 (2018): 53-68. Abstract, § 1, then see steps 3-4 on page 57.
Trzeciak, Maciej, and André Borrmann. "Towards registration of construction drawings to building information models using knowledge-based extended geometric hashing." Proc. of 26th International Workshop on Intelligent Computing in Engineering. 2019. Abstract, § 1, then § 2.3 including ¶ 3
In addition, should it be found that step S4 is not part of the abstract idea for its “outputting…” recitation, then this would be an insignificant extra-solution activity of mere data outputting, that is WURC in view of MPEP § 2106.05(d)(II): “iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;… iv. Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93;”
“and feeding the outcome to an user;” is considered as a token post solution activity of mere data outputting, akin to the displaying of data in example 46 claim 1; and WURC for similar reasons as example 46 claim 1, as well as “iv. Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93;”” in MPEP § 2106.05(d)(II).
As such, the claims are directed towards a mental process without significantly more.
Regarding the dependent claims
Claim 15 is adding additional steps to the mental process of a mental judgement of observing two or more codes, e.g. simple hashes on paper, and observing/judging if they are equal, wherein such a mental observation/judgement may readily be carried out for a plurality of objects, e.g. by using tabular representations with pen and paper.
As such, the claims are directed towards a mental process without significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 11, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shafiq, M., and S. Lockley. "Signature-based matching of IFC models." 35th International Symposium on Automation and Robotics in Construction (ISARC). 2018 in view of Weinstein et al., US 2015/0234848.
Regarding Claim 11.
Shafiq teaches:
A method for automatically identifying design changes in a building information model (BIM) regarding a construction project, comprising steps of: (Shafiq, abstract: “…The paper proposes a signature-based model matching approach for IFC models that use model object characteristics to define object signatures for object recognition and comparison.”)
S1, encoding all objects in an old file and a new file to obtain individual codes of the all objects, comprising: - S1.1, taking out the first object from the old file or the new file: - S1.2, extracting data of a first category, a second category and a third category of data changes of the first object, the first category comprises a category of attribute data, the second category comprises a category of shape data, and the third category comprises a category of relationship data: - S1.3, computing a code for each of the first, second, and third categories, according to the first category, the second category and the third category of data changes of the first object; S2, determining whether the … code of the first object is equal to code of one or more second objects in the new file or the old file, if so, then the first object is not changed, if not, proceeding to a next step; S3, determining whether the first object matches one or more of the second objects in the new file or the old file, if so, the first object is a modified object, if not, the first object is a deleted or newly added object; and S4, outputting an outcome of change identification and returning to the step Si until the change identification has been applied on the all objects in the old file or the new file and feeding the outcome to an user; wherein, the old file and the new file are building information model files, and the first object and the second objects each represent physical objects applied in the construction project related to the new file and the old file. (Shafiq, abstract, for the creation of the “IFC object signatures” – see § 1 last paragraph: “To address these issues, this paper presents a signature-matching approach that advocates using dynamic object identities, calculated from the value of its properties and attributes using hash keys that can create a unique signature for an object. In BIM collaboration operations, a change can be in (1) an object’s position, (2) its shape and its (3) properties. Therefore, an object’s position, shape and properties can be used to formulate partial, default or complete signature for an object, which would be useful in establishing candidates for IFC comparison process, independently from GUIDs, and would reduce the overall workload of the IFC compression process.” - and see §§ 4-4.1 for more details
e.g. page 5, ¶ 1: “For example, in versions A & B of the same IFC model, change in properties can have following scenarios Properties of object A (version 1 of a dataset) = P [A] Properties of object B (version 2 of a dataset) = P [B] P [A] = P [B] = No change in properties P [A] > P [B] = some properties have been deleted P [A] < P [B] = some properties have been added P [A] ~ P [B] = Properties have been updated/edited”
To further clarify, § 2 ¶ 1: “A critical issue in managing collaboration operations on a model server is the management of iterative changes during BIM collaboration operations. The shared data repository on the server must be updated with any changes because of modifications made in a check in/check out the operation, such as new data instances added, deleted or changed.”
In other words, this is a system that is for change detection in iterative design workflows with BIM models wherein each of the objects in the files are encoded with signatures for each category of the object (e.g. see table 1 for the “IFC object signatures definitions in XBIM signature exporter” wherein the “Signature Type” row provides examples of categories, and the right-most two columns in this table provide examples of the “Signature” of the objects “Door” and “Slab” in the BIM model for each of these categories, wherein as per examples 1-2 on pages 5-6 this checks/determines whether the signature codes are equal (the “=” resulting in an output of an “Potentially matching pair” with “Filter for further analysis”; i.e. steps S2 and S4), followed by when they are not equal determining that it is either a “New object [example of a newly added object]” or it’s a “Potentially changed object” for its output resulting outcome (step S3 and S4)
To clarify on the categories, Shafiq, as was discussed above, example 1 on page 5 provides an example of “Shape” as the design change to be detected; example 2 on page 6 provides an example of a signature from “Location placement” which is an example of relationship data – see Shafiq, example 2 to clarify: “The IfcLocalPlacement defines the relative placement of a product in relation to the placement of another product or the absolute placement of a product within the geometric representation context of the project (BuildingSMART, 2014).” – to clarify on the BRI, page 8, # 3 of the instant disclosure: “Relationship Data: represents the relationship between objects, such as the relationship between a wall and a door.”; and Shafiq, pages 4-5 the paragraph split between the pages provides an example of attribute data: “creating a signature from element properties is complex as it involves a degree of change in object properties… Therefore, it is important to determine what properties are important and if we can determine the degree of importance in IFC properties, then it can be used to create a signature based on the key properties…” – e.g. see table 1 for attribute data such as “model ID”, “Schema type” “DefinedTypeID”, “GUID”, “Name”, “MaterialId”: “This is the name of the material attached to an IFC building element., etc.
As to the outputting to a user, note in at least figures 2-3 that there is an output, and in fig. 1 note there is an “End User” – POSITA would have inferred, at least been suggested, to have output, e.g. by displaying the result, the result to the end user, especially where “…Typically, the IFC model comparison is a postrationalisation activity in a collaboration [i.e. between different users] operation where the data management system (i.e. model server or another comparison tool)…” (§ 3 ¶¶ 1-2) )
wherein, the old file and the new file are BIM files, and the first object and the second objects each represent physical objects applied in the construction project related to the new file and the old file, (Shafiq, as discussed above, including the abstract – this is for “IFC models” in a “BIM collaboration workflow” [i.e. BIM files]; and the objects correspond to physical objects in a construction project, e.g. table 1 for “a door” – see § 4.2 ¶ 2 for clarification
However, Shafiq does not explicitly teach integrating all of the individual signatures for each “Signature Type”/category into one signature, i.e. the feature of and - S1.4, integrating all codes for the first, second and third categories into an object code selected from one of a hash code, an object signature or an object fingerprint, comprising checking for change at a model level. and its use in the above comparisons, because Shafiq is comparing the codes individually as depicted in examples 1-2, i.e. the “Signature Type” is a “Partial Signature”.
However, Shafiq, in view of Weinstein teaches this feature: and - S1.4, integrating all codes for the first, second and third categories into an object code selected from one of a hash code, an object signature or an object fingerprint, comprising checking for change at a model level: (See Shafiq, as cited above, also see, page 2, col. 1, ¶ 2: “Therefore, an object’s position, shape and properties can be used to formulate partial, default or complete signature for an object, which would be useful in establishing candidates for IFC comparison process, independently from GUIDs, and would reduce the overall workload of the IFC compression process.” And § 4.2 ¶ 2: “The XBIM signature exporter has extracted serval signatures from the test model; however, only a few signatures are useful in IFC model comparison process.” And § 4.2 last paragraph: “The results suggest that the schema type, GUID, position and bounding box signatures are strong signature types. Considering the volatile nature of GUIDs, schema type, position and centroid signatures provide enough evidence to establish candidates for comparison in the first pass, even if the GUIDs are not matched. After establishing matching pairs for a comparison analysis, signature matching can also help to reduce the size data for detecting fine grain changes if there are any For example, if a matching pair has a different PropertyCount or PropertySetNamesKey, it means some properties have been added or deleted, and it should be checked for more detailed analysis. Thus, the signature types, such as NAME, Object Type, properties, can reduce the amount of workload to precisely detect changes in further analysis. It is not a brilliant way of calculating differences, but it reduces the amount of work required for further analysis.” And § 5: “This paper proposes that the characteristics of an IFC object can be used to create unique signatures for IFC elements, in addition to GUIDs, to effectively compare corresponding objects in a model comparison process. An object’s position, shape and properties can be used to formulate partial, default or complete signature for an object, which can be used as passes to establish candidates for comparison and to highlight changes in a comparable object pair. This approach is useful in establishing accurate candidates for comparison without GUID dependence and can reduce the workload of the overall model comparison process.” - i.e. Shafiq is teaching using a plurality of signatures/hashes, each corresponding to a category of the object, to do “model comparison”
As taken in view of Weinstein, abstract: “…The audit system creates element descriptors by identifying, for each respective identified element, one or more element component values and creating an element descriptor from the element component values. The audit system forms a string descriptor comprising an aggregation of the element descriptors and generates a signature for the string descriptor…” then see ¶ 80: “The "Deep Binary" signature is an aggregation of hash or digest values for each element in a file hierarchy [example of integrating multiple signatures into one]. Although each hash or digest value has some probability of collision (where two different input values result in the same hash or digest value), it is almost a certainty that if a scan of a real file hierarchy produced a Deep Binary signature equal to a Deep Binary signature for another file hierarchy, then the two file hierarchies are equivalent. The probability of a false positive for this type of comparison is substantially close to zero. In some implementations, Deep Binary signatures are not used either because this level of precision is not needed or desired or because the additional processing time is undesirable. In some implementations, Deep Binary signatures are used in special circumstances, such as to record confirmation of equivalence between two scanned file hierarchies.”
With respect to checking for a change at the model level, and the determining using the object code, See Shafiq, as was taken in view of Weinstein for the integrating, wherein Shafiq is already teaching checking for changes at the object level, type level, and model level in turn – i.e. see examples 1-2 for the object level detections, resulting in “Filter for further analysis as potentially matching pairs” and “Potentially matching pair, filter for further analysis, no change in position” - i.e.: “If two elements have same local placement and shape, it is quite strong to say that it is a potentially equivalent pair, and can be a candidate for comparison.” As discussed in example 2, last paragraph, which also discusses: “Similarly, signatures can be created from other IFC object characteristics (e.g. Schema type, Object Type, Name, Property Count- see Table 1) and can be used to support establish similar candidates for comparison. It is to be noted that GUID itself can be used as a signatures type as matching GUIDs would constitute a match but different GUIDs can be ignored (i.e. same objects can have different GUIDS). [example of an ID change that is meaningless/causes no change at the model level, as these are the “same objects”; see below to further clarify]” – then see § 4.2, last paragraph: “The results suggest that the schema type, GUID, position and bounding box signatures are strong signature types. Considering the volatile nature of GUIDs, schema type, position and centroid signatures provide enough evidence to establish candidates for comparison in the first pass, even if the GUIDs are not matched. After establishing matching pairs for a comparison analysis, signature matching can also help to reduce the size data for detecting fine grain changes if there are any… For example, if a matching pair has a different PropertyCount or PropertySetNamesKey, it means some properties have been added or deleted, and it should be checked for more detailed analysis…” and § 5 ¶ 1: “An object’s position, shape and properties can be used to formulate partial, default or complete signature for an object, which can be used as passes to establish candidates for comparison and to highlight changes in a comparable object pair. Thus, the signature types, such as NAME, Object Type, properties, can reduce the amount of workload to precisely detect changes in further analysis.” – i.e. this is suggesting using GUIDs, schema type, position, and centroid signatures for a “first pass” to detect “potentially matching pairs” at the object level, then checking additional signatures such as the “Object type” [example of a type level change] – wherein the results of these comparison ae suggested to be used in a “model comparison [model level] process”, wherein Weinstein ¶ 80 as discussed above teaches a method for “aggregation of hash or digest values for each element in a file hierarchy” such as to “record confirmation of quivalence between two scanned file hierarchies [example of a manner of doing model level comparison]”
as such, a skilled person in the art would have recognized/inferred that Shafiq’s system, in combination with Weinstein, would have provided for a model comparison wherein meaningless changes (e.g. a change in the GUID – to clarify, § 3 ¶ 2: “(3) it does not consider if GUIDs are changed but that the property values are maintained [example of a meaningless change];” - e.g. see Shafiq fig. 1 as discussed in § 2 to clarify: “Furthermore, support is required from the client-side application when submitting changes to the model server, for example, to maintain object owner history and the consistent preservation of GUIDs. However, the internal data storage structures of client-side BIM applications tend to be different from each other, with limited support for database level change management within proprietary BIM applications for server enabled collaboration. For example, if a structural engineer decides to change the position of 4 columns, there is no predefined standard workflow for executing this change. The engineer may change each column individually, leading to four changes in the model; or may decide to change one, delete the other three and then copy and paste the first one three times (Figure 1). This will result in one change, three deletions and three new columns in a model, but ultimately the design change would be the same in both cases… In such design modifications, when exporting the latest version of an IFC model, the IFC versioning can be different, as the two editing operations could result in different GUIDs for the same model elements… However, two objects can still constitute a comparable pair even if their GUIDs are different” – i.e. in fig. 1, option 1 “4 New Columns added (Different GUIDs)”, and option 2 has “1 Column changed” and “3 copies of A (New columns with same GUIDs)” – however, there is no difference/change that is meaningful in the output models of this, rather the only distinction is the meaningless change in “GUIDs”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from Shafiq on “a signature-based model matching approach for IFC models that use model object characteristics to define object signatures for object recognition and comparison” (Shafiq, abstract) wherein Shafiq already contemplates using multiple signatures per object “to formulate partial, default or complete [note the singular] signature for an object” (Shafiq, page 2, col. 1, ¶ 2) – e.g. “Likewise, the shape signature, the local placement signature cannot decide on its own for identification of corresponding element pairs in the comparison process, but it can be used in combination with other signature types, to detect potentially matching pairs or also to reduce the amount of work in calculating and identifying potential changes” (page 6, paragraph split between the columns) with the teachings from Weinstein on “The "Deep Binary" signature is an aggregation of hash or digest values for each element in a file hierarchy” (Weinstein, ¶ 80). The motivation to combine would have been that “Although each hash or digest value has some probability of collision (where two different input values result in the same hash or digest value), it is almost a certainty that if a scan of a real file hierarchy produced a Deep Binary signature equal to a Deep Binary signature for another file hierarchy, then the two file hierarchies are equivalent. The probability of a false positive for this type of comparison is substantially close to zero. In some implementations, Deep Binary signatures are not used either because this level of precision is not needed or desired or because the additional processing time is undesirable…”
Regarding Claim 15.
Shafiq as discussed above, teaches:
The method according to claim 11, wherein, the step S2 comprises a step of proofreading to avoid an encoding conflict, wherein in the step S2, when it is determined the code of said first object is equal to code of one or more second objects in the new file or the old file, determining whether said first object is completely identical with an object among those second objects having equal code with said first object, if so, then said first object is not changed, otherwise, it is determined that there is an encoding conflict, and proceeded to the step S3. (Shafiq, as was discussed above for step S1-2, include examples 1-2 for the “=” comparison between hash codes, as was taken in view of Weinstein, ¶ 80: “The "Deep Binary" signature is an aggregation of hash or digest values for each element in a file hierarchy. Although each hash or digest value has some probability of collision (where two different input values result in the same hash or digest value), it is almost a certainty that if a scan of a real file hierarchy produced a Deep Binary signature equal to a Deep Binary signature for another file hierarchy, then the two file hierarchies are equivalent. The probability of a false positive for this type of comparison is substantially close to zero. In some implementations, Deep Binary signatures are not used either because this level of precision is not needed or desired or because the additional processing time is undesirable. In some implementations, Deep Binary signatures are used in special circumstances, such as to record confirmation of equivalence between two scanned file hierarchies”
otherwise, it is determined that there is an encoding conflict, and proceeded to the step S3. (Shafiq, as was discussed above for steps S1-S2, as was taken in view of Weinstein, wherein in Shafiq when it is determined that they are not equivalent then it is determined that the object is a “changed object” (examples 1-2 of Shafiq, see the pseudocode and figures), which is an example of an encoding conflict
Conclusion
THIS ACTION IS MADE FINAL.
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID A. HOPKINS whose telephone number is (571)272-0537. The examiner can normally be reached Monday to Friday, 10AM to 7 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Pitaro can be reached at (571) 272-4071. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/David A Hopkins/Primary Examiner, Art Unit 2188