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 .
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.
Claim Objections
Claims 1-2, 4-6, 8-9, 11-13, 15-16, and 18-20 are objected to because of the following informalities:
In claim 1 line 8, the limitation “the platform” lacks antecedent basis. The limitation should read “the one or more platforms” to refer back to how the limitation was introduced at claim 1 line 6.
In claim 2 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 4 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 5 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 6 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 8 line 6, “the platform” lacks antecedent basis. The limitation should read “the one or more platforms” to refer back to how the limitation was introduced at claim 8 line 4.
In claim 9 line 2, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 11 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 12 line 2, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 13 line 2, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 15 line 5, “the platform” lacks antecedent basis. The limitation should read “the one or more platforms” to refer back to how the limitation was introduced at claim 15 line 3.
In claim 16 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 18 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 19 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
In claim 20 line 1, the limitation “comprises:” should read “is configured to perform steps of:”. This wording reflects the nature of the additional limitations as steps/functional limitations rather than elements.
Appropriate correction is required.
Claim Interpretation
In claim 1 line 7 and the other corresponding independent claims (claim 8 and claim 15), “extended reality” is an element of the claims. The term is not defined in the specification either explicitly or through functional limitations. Therefore, a plain meaning definition applies. A plain meaning definition is: “Extended reality (XR), here jointly referring to virtual, augmented, and mixed (VR, AR, MR):” (see [Abstract] line 1 of Vasarainen, Minna, Sami Paavola, and Liubov Vetoshkina. "A systematic literature review on extended reality: virtual, augmented and mixed reality in working life." International Journal of Virtual Reality 21, no. 2 (2021): 1-28.
In claim 1 line 10 and the other corresponding independent claims (claim 8 and claim 15), “central features repository dashboard” is an element of the claims. The term is defined permissively at [0066] line 4 of the specification as being “a repository of all features”. This is not a limiting definition, so BRI applies (see MPEP 2111). The same paragraph provides a permissive, functional limitation, “the CFRD will allow the user... to view the features...”, (Specification [0066] line 8), which is more of a dashboard like aspect of the CRFD. Both aspects (the repository and the dashboard) will be considered when considering the BRI of the claim limitations.
The term “GINT module” is used in claim 1 line 12 and the other independent claims (claim 8 and claim 15). The term is not defined in the specification explicitly, but has a permissive explanation of the module at Specification [0008]:
In some embodiments, the GINT module comprises the feature tailor, wherein the feature tailor assigns properties to the features in the platforms operational layer based on the central features repository dashboard. In some embodiments, the GINT module comprises the feature integrator, wherein the feature integrator maps functions to the features in the platforms operational layer based on the central features repository dashboard. In some embodiments, the GINT module comprises the feature generator, wherein the feature generator generates functions in the features in the platforms operational layer based on the central features repository dashboard.
(Specification [0008]).
The term “module” is well known in the art, and may be similarly interpreted to the term “engine”, which is defined in the specification, (Specification [0024]). Thus, a module with a modifier “GINT” for purposes of distinguishing it from other modules is not indefinite by itself. For purposes of claim interpretation, GINT module will be interpreted only based on the limitations of the claim, and Applicant is welcome to amend if necessary to clarify the invention in light of the prior art.
The term “platforms operational layer” is used in claim 1 line 16 and the other independent claims (claim 8 and claim 15). The term is not defined in the specification explicitly, but has a permissive explanation with respect to FIG. 4:
As shown in block 406, the process flow 400 of this embodiment includes the platforms operational layer. In some embodiments, the platforms operational layer may include the features from the CFRD, virtual platforms, and/or the like. In some embodiments, the features may include features designed, developed, operated, and/or the like by an entity, wherein the entity's feature is stored in the CFRD. In this way, the entity may create (e.g., design, develop, operate, and/or the like) a specific feature that allows for additional user functionality.
(Specification [0101]).
The paragraph does not provide much in terms of claim definitions, but FIG. 4 at least shows pretty clearly how the software is organized in layers, and the layers interact with each other in a specific manner.
Thus, term “layer” with a modifier “platforms operational” for purposes of distinguishing it from other layers is not indefinite by itself. For purposes of claim interpretation, platforms operational layer will be interpreted only based on the limitations of the claim, and Applicant is welcome to amend if necessary to clarify the invention in light of the prior art.
As a last note, the term “transfer” is used in the claims specifically at claim 1 line 8, “transferring the platform...”, and claim 7 line 6, “transfer... the properties...”. The following definition applies:
As used herein, a "transfer," a "distribution," and/or an "allocation" may refer to
any transaction, activities or communication between one or more entities, or between the user
and the one or more entities.
(Specification [0032] lines 1-3).
This definition is broad, and could be used to include payment transfers, but the claim language does not specifically focus on that concept, and construing the claim language as focusing on that concept would be unreasonable at this time. The term “resource transfer” is defined in the specification (see Specification [0032]) as focusing on payments and other forms of payment transactions, but that term is not used in the claims. The term “transfer” will therefore be construed broadly in light of the specification definition, and not specifically focused on “Fundamental Economic Practices or Principles”, (see MPEP 2106.04(a)(2)(II)).
Claim Interpretations 35 U.S.C. 112(f)
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
In clam 3 line 2, “feature tailor, wherein the feature tailor assigns properties...”. Under (A), “feature tailor” is a generic placeholder; under (B), the generic terminology is modified by functional language “assigns properties...”; and under (C), the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Therefore, this limitation is interpreted under 35 U.S.C. 112(f). The specification does not provide an explicit definition. Therefore, the claim term is indefinite under 35 U.S.C. 112(b). Please see the 112(b) rejection below.
In clam 3 line 4, “feature integrator, wherein the feature integrator maps functions...”. Under (A), “feature integrator” is a generic placeholder; under (B), the generic terminology is modified by functional language “maps functions...”; and under (C), the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Therefore, this limitation is interpreted under 35 U.S.C. 112(f). The specification does not provide an explicit definition. Therefore, the claim term is indefinite under 35 U.S.C. 112(b). Please see the 112(b) rejection below.
In clam 3 line 6, “feature generator, wherein the feature generator generates functions...”. Under (A), “feature generator” is a generic placeholder; under (B), the generic terminology is modified by functional language “generates functions...”; and under (C), the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Therefore, this limitation is interpreted under 35 U.S.C. 112(f). The specification does not provide an explicit definition. Therefore, the claim term is indefinite under 35 U.S.C. 112(b). Please see the 112(b) rejection below.
Claims 4-6 are dependent on claim 3, and therefore the terms above are at least incorporated by reference, and a similar interpretation applies.
Claims 10-13 mirror claims 3-6, respectively, but in a different statutory class. Therefore, a similar interpretation applies.
Claims 17-20 mirror claims 3-6, respectively, but in a different statutory class. Therefore, a similar interpretation applies.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-6, 10-13, and 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
In claim 3 line 2, the limitation “feature tailor, wherein the feature tailor assigns properties...” invokes 35 U.S.C. 112(f).
In claim 3 line 4, the limitation “feature integrator, wherein the feature integrator maps functions...” invokes 35 U.S.C. 112(f).
In clam 3 line 6, the limitation “feature generator, wherein the feature generator generates functions...” invokes 35 U.S.C. 112(f).
Claims 4-6 are dependent on claim 3, and therefore the terms above are at least incorporated by reference, and a similar interpretation applies.
Claims 10-13 mirror claims 3-6, respectively, but in a different statutory class. Therefore, a similar interpretation applies.
Claims 17-20 mirror claims 3-6, respectively, but in a different statutory class. Therefore, a similar interpretation applies.
The claim limitations above invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The disclosure is devoid of any structure that performs the function in the claim. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 103
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) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Challenging the interoperability between computers in industry with MDA and SOA" (2006-Jardim-Goncalves) in view of "Cloud-Marketplaces: Distributed e-procurement for the AEC sector" (2013-Grillo) in further view of “Cross-platform Metaverse Data Management System” (2022-Chen)
With respect to claim 1, Jardim-Goncalves teaches A system for multi-platform interoperability in digital environments, the system comprising (see FIG. 4, FIG. 6, and FIG. 7, [pages 684-686]; and [Abstract], at a high level the system creates a platform independent model (PIM) that is a “model driven architecture” and registers various platform specific models (PSM) that are “service oriented architectures”, and achieves multi-platform interoperability in digital environments through PIM to PSM transformations: “Through available PIM to PSM transformations interoperability at SOA can be facilitated specially in digital dynamic business environments”, [page 685 col 2 paragraph 3 lines 7-9]): a processing device (one or more of the computer systems and applications that use the "open architecture" portrayed in the diagram of FIG. 6, and described in the abstract as "Together, these two architectures seem to provide a suitable framework to improve company’s competitiveness through the adoption of a standard-based extended environment, challenging and enhancing the interoperability between computer systems and applications in industry. The paper, after illustrating the general motivations the industrial SMEs have to adopt open architectures to achieve interoperability for extended and collaborative enterprise practices, presents the emerging model-driven and service-oriented architectures", [Abstract] lines 7-10; the computer systems are performing the processing defined by the arrows in FIG. 6 and FIG. 7, [pages 685-686]); a non-transitory storage device containing instructions when executed by the processing device, causes the processing device to perform the steps of (one or more of the computer systems and applications that use the "open architecture" portrayed in the diagram of FIG. 6, and described in the abstract as "Together, these two architectures seem to provide a suitable framework to improve company’s competitiveness through the adoption of a standard-based extended environment, challenging and enhancing the interoperability between computer systems and applications in industry. The paper, after illustrating the general motivations the industrial SMEs have to adopt open architectures to achieve interoperability for extended and collaborative enterprise practices, presents the emerging model-driven and service-oriented architectures", [Abstract] lines 7-10; the computer systems are storing instructions as shown by the boxes and cylinders in FIG. 6 and FIG. 7, [pages 685-686]): receive one or more platforms (in the PSM layer of FIG. 4, each PSM is represented as a collection of services, [page 684]; this limitation is taught by: "Within this scenario, the specifications of the execution platform will be an input for the development of the transformation between the MDA’s PIM and the targeted Web services platform", [page 682 col 2 paragraph 2 lines 1-4]; as shown in FIG. 6, this results in a single repository of PSMs, [page 684 col 1 paragraph 1 line 6]), and wherein receiving comprises transferring the platform to a platforms operational layer (receiving taught by “input” from, [page 682 col 2 paragraph 2 lines 1-4]; in FIG. 4, FIG. 6, and FIG. 7, the SOAs are shown as being in the PSM layer after the input, [pages 684-686]; prior to being in the PSM layer, the services are simply service descriptions provided by a service provider as shown in FIG. 2, [page 682]); receive a central features repository dashboard (the PIM layer of FIG. 4, Fig. 6, and FIG. 7, [pages 684-686], which is a product data repository as shown in FIG. 3, [page 683]; the limitation is taught by: "Thus, for a seamless integration of information and data in a construction or engineering project, a repository of the product data must be physically or virtually built", [page 682 col 2 paragraph 7 line 1]-[page 683 col 1 paragraph 1 line 1]; results in “creation of general PIMs for the construction sector” for the architecture described, [page 683 col 2 paragraph 2 line 4]), wherein the central features repository dashboard comprises one or more features (features are product data, [page 682 col 2 paragraph 7 line 1]-[page 683 col 1 paragraph 1 line 1]); create a generate, integrate, and tailor (GINT) module (the transformation engine in Fig. 6 and FIG. 7, [pages 685-686]; which is a combination of a service brokerage that gives access to the services, [page 684 col 2 paragraph 2], the STEP25 tool, [page 687 col 1 paragraph 3 line 3-6], and the mega suite platform, [page 687 col 1 paragraph 6 lines 1-6]), wherein the GINT module comprises a feature tailor, a feature integrator, and a feature generator (the integrator is the service brokerage which translates the information needs of the MDA format in the PIM layer (i.e., a feature) and integrates with a web service (i.e., a function) as shown in FIG. 6, [page 684 col 2 paragraph 2]; the commercial mega suite platform "automatically generates code", which is the generator, [page 687 col 1 paragraph 6 lines 3-4]; and the tailor that iterates through properties called the STEP25 tool, [page 687 col 1 paragraph 3]; an example input and output is shown in FIG. 8, [page 686], in the bottom left panel, each entity and attribute is in the original format; in the top panel, it each entity and attribute is translated into an interface format, and then in the bottom right panel, the entities and attributes are translated into a specific platform format); and aggregate, within the platforms operational layer, the one or more platforms, the central features repository dashboard, and the GINT module (collecting the PIM, the PSMs, and the transformation engine into a single "open architecture" (terminology used in [Abstract]), as shown in FIG. 6 and FIG. 7, [page 686]; the tools were tested on both examples, [page 687 col 1 paragraph 4 lines 1-3]).
Jardim-Goncalves does not teach wherein the one or more platforms comprise multi-platform virtual reality, augmented reality, and extended reality environments.
However, Grilo teaches wherein the one or more platforms comprise multi-platform virtual reality (the platforms are web-based collaborative platforms, BIM, and transactional e-marketplaces, [Abstract] line 1; where BIM refers to Building Information Model, which is a technology that "makes it possible to construct an accurate virtual 3D and parametric model of a building containing precise geometry and relevant data needed to support the construction, fabrication, and procurement activities necessary for the building process. It promotes collaboration, integration, and process automation; it makes virtual reality simulations possible and fosters visualization and project understanding...", [page 161 col 1 paragraph 3 lines 6-12]; an example service is clash detection, [page 164 col 1 paragraph 3 line 5]).
Jardim-Goncalves and Grilo do not teach augmented reality, and extended reality environments in the limitation wherein the one or more platforms comprise multi-platform virtual reality, augmented reality, and extended reality environments.
However, Chen teaches wherein the one or more platforms comprise multi-platform virtual reality, augmented reality, and extended reality environments (cross-platform metaverse data management system (CMDMS), [Abstract], using the same architecture as the primary reference as shown in FIG. 1, [page 146], where the data layer is the PIM, and the service layer are the SOAs; where “cross-platform” refers to platforms used for XR development such as the Unity3D platform, [page 1 col 1 paragraph 2 lines 1-4]; extended reality refers to both virtual reality and augmented reality by definition).
It would have been obvious to one skilled in the art before the effective filing date to combine Jardim-Goncalves with Grilo because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Jardim-Goncalves discloses a system and method that teaches all of the claimed features except for multi-platform virtual reality. The paper is written by the same authors, and states:
This paper is grounded on earlier research in which the concepts of SOA4BIM and interoperability within bounded project-based organizations have been developed...
(see Grilo [page 161 col 2 paragraph 3 lines 15-18]).
Thus, the paper gives a specific teaching that the new paper is based on the old paper, and the old PIM-PSM architecture now equates the PIM (platform independent model) to a BIM (building information model), which is a model used in virtual reality applications. A person having skill in the art would have a reasonable expectation of successfully increasing interoperability in the system and method of Jardim-Goncalves by modifying Jardim-Goncalves with the 3D models using in BIM of Grilo (Grilo [page 161 col 1 paragraph 3 line 7]). Therefore, it would have been obvious to combine Jardim-Goncalves with Grilo to a person having ordinary skill in the art.
It would have been obvious to one skilled in the art before the effective filing date to combine Jardim-Goncalves in view of Grilo with Chen because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Jardim-Goncalves in view of Grilo discloses a system and method that teaches an open architecture for platform interoperability. Jardim-Goncalves does not teach that this open architecture supports platforms that comprise “extended reality environments”, but instead provides a list of tested platforms:
The commercial mega suite platform is used to import the ARM model, described in XMI, into UML, and then the facilities of this platform are used to automatically generate code ready to assist in the implementation of the translators and repositories compatible with the reference model in specific platforms. The tool was also tested with subsets of ISO10303 AP214, AP225, AP236 and ISO13584 part 20 (automotive, building and construction, furniture, and parts library and product catalogues).
(Jardim-Goncalves [page 687 col 1 paragraph 6]).
In Grilo the concept is extended to BIM models:
For each project a PIM-BIM model is created in which many of the data structures can be reused by the agents involved, since it utilizes neutral formats. The integration of SOA with MDA will enable an engine for transformations and services that will automatically generate Platform-Specific Models (PSM) such as Web-services, to each of the agents (client, architect, specialist designer, etc.). Hence, each time a service is evoked by any agent, there will be an appropriate automated transformation of the PIM to the specific PSM, through mapping. Conversely, whenever a construction agent requires the PIM-BIM model to be enriched with new information generated by their applications (e.g., Specifications or Bill of Quantities), new services would be made available, transforming the new PSM requirements into the enriched PIM-BIM model.
(Grilo [page 161 col 2 paragraph 1 lines 7-20]).
Chen teaches “plug-ins” that handle translation/transformation to the Unity and Unreal Engine platforms, which are specific game development platforms that comprise extended reality environments (see Chen [page 145 col 1 paragraph 2] and [page 145 col 2 paragraph 2 lines 5-11]). A person having skill in the art would have a reasonable expectation of successfully increasing interoperability between platforms in the system and method of Jardim-Goncalves in view of Grilo by modifying Jardim-Goncalves in view of Grilo with the new plugins of Chen. Therefore, it would have been obvious to combine Jardim-Goncalves in view of Grilo with Chen to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 2, Jardim-Goncalves in view of Grilo and Chen teaches all of the limitations of claim 1, as noted above. Jardim-Goncalves further teaches wherein the central features repository dashboard (PIM layer shown in FIG. 3 and FIG. 4, [pages 683-684]) comprises: receiving, from a user device (HVAC consultant in FIG. 5, [page 684]; where each company uses its own platform, [page 683 col 2 paragraph 5 line 1]), a user feature, wherein the user feature comprises features specific to a user (“service definitions” that are re-used in the PIM layer, [page 684 col 1 paragraph 2 lines 1-5], example shown in FIG. 5, the service of SOA A has service definitions that include a.X_0, b.Y_0, and a.Z_0 in the definitions, and a.X_0 is a feature specific to the SOA A user, which in this case is in an HVAC consultant, [page 684]; note, the arrow from the HVAC consultant to the SOA, showing the SOA receiving the definition); receiving, from an entity device (Architect in FIG. 5, [page 684]; where each company uses its own platform, [page 683 col 2 paragraph 5 line 1]), an entity feature, wherein the entity features comprises features specific to an entity (“service definitions” that are re-used in the PIM layer, [page 684 col 1 paragraph 2 lines 1-5], example shown in FIG. 5, the service of SOA B has service definitions that include b.W_0, a.Z_0, and b.Y_0 in the definitions, and b.W_0 is a feature specific to the SOA B entity, which in this case is in an Architect/Architecture Company, [page 684]; note, the arrow from the HVAC consultant to the SOA, showing the SOA receiving the definition); and transmitting the user feature and the entity feature to the platforms operational layer (the services definitions are “decoupled” from the lower level platforms into the PIM layer to improve interoperability, see [page 684 col 1 paragraph 2 line 1]-[page 684 col 2 paragraph 1 line 3]) in response to the GINT module (reason or purpose is “improved interoperability”, [page 684 col 2 paragraph 1 line 3]; explained how this is done in the following paragraph: “technology on top of MDA and SOA” which includes the “service brokerage”, [page 684 col 2 paragraph 2]; the transformation engine is shown placed on top of these technologies in the next figure, FIG. 6, [page 685]).
With respect to claim 3, Jardim-Goncalves in view of Grilo and Chen teaches all of the limitations of claim 1, as noted above. Jardim-Goncalves further teaches wherein the GINT module comprises: the feature tailor, wherein the feature tailor assigns properties to the features in the platforms operational layer based on the central features repository dashboard (tailor that iterates through properties called the STEP25 tool, [page 687 col 1 paragraph 3]; an example input and output is shown in FIG. 8, [page 686], in the bottom left panel, each entity and attribute is in the original format; in the top panel, it each entity and attribute is translated into an interface format, and then in the bottom right panel, the entities and attributes are translated into a specific platform format; the central features repository dashboard is the PIM, which in this case is the XMI model, see “PIM to ISO STEP APs using XMI”, [page 687 col 1 paragraph 3 line 3]); the feature integrator, wherein the feature integrator maps functions to the features in the platforms operational layer based on the central features repository dashboard (the integrator is the service brokerage which translates the information needs of the MDA format in the PIM layer (i.e., a feature) and integrates with a web service (i.e., a function) as shown in FIG. 6, [page 684 col 2 paragraph 2]); and the feature generator, wherein the feature generator generates functions in the features in the platforms operational layer based on the central features repository dashboard (The commercial mega suite platform is used to import the ARM model, described in XMI, into UML, and then the facilities of this platform are used to automatically generate code ready to assist in the implementation of the translators and repositories compatible with the reference model in specific platforms, [page 687 col 1 paragraph 6 lines 1-6]; the features are the data models written in the PIM layer as shown in FIG. 4, and the “functions” are shown in FIG. 5, see “f1” and “f2”, [page 684]; which require the platform specific generated code).
With respect to claim 4, Jardim-Goncalves in view of Grilo and Chen teaches all of the limitations of claim 3, as noted above. Jardim-Goncalves further teaches wherein the feature tailor (tailor that iterates through properties called the STEP25 tool, [page 687 col 1 paragraph 3]) further comprises: iterating an object property associated with the feature; assigning a parameter based on the central features repository dashboard (iterating and assigning example input and output are shown in FIG. 8, [page 686], in the bottom left panel, each entity and attribute is in the original format; in the top panel, it each entity and attribute is translated into an interface format, and then in the bottom right panel, the entities and attributes are translated into a specific platform format; the central features repository dashboard is the PIM, which in this case is the XMI model, see “PIM to ISO STEP APs using XMI”, [page 687 col 1 paragraph 3 line 3]); and performing an object level interoperability (FIG. 8 shows the “object level” par to the limitation, and the transformation arrows in FIG. 6 and FIG. 7, show how this transformation leads to performing interoperability, [pages 685-686], “Through available PIM to PSM transformations interoperability at SOA can be facilitated specially in digital dynamic business environments”, [page 685 col 2 paragraph 3 lines 7-9]).
With respect to claim 5, Jardim-Goncalves in view of Grilo and Chen teaches all of the limitations of claim 3, as noted above. Jardim-Goncalves further teaches wherein the feature integrator further comprises: mapping a platform request based on the central feature repository dashboard (in the Architect-HVAC consultant example, determining a specific service/SOA using the PIM/MDA/central feature repository dashboard, “brokerage service of the SOA through the MDA approach can be determined by a CIM”, [page 684 col 1 paragraph 1 lines 1-3], in FIG. 5, this is the connection between SOA A and SOA B, facilitated by the PIM as shown, [page 684],”); mapping an object request based on the central feature repository dashboard (in FIG. 5, this is the connection between b.Y_0 in SOA_B and b.Y_0 in SOA A, facilitated by the the PIM as shown, [page 684]; the reason is “HVAC specialist needs the layout and properties of the rooms in the building i.e., service Y, in order to be able to produce the engineering analysis regarding air flows, coming from the service X”, [page 683 col 2 paragraph 7]; these are shown as variables in FIG. 5, but in the actual implementation they are objects as shown in FIG. 8, [page 686]); and performing a feature level interoperability (see FIG. 6, showing improved interoperability, [page 685]; this is a diagram depicting “translating common information transaction need between parties”, where the features are the information, [page 684 col 2 paragraph 2 lines 1-4]).
With respect to claim 6, Jardim-Goncalves in view of Grilo and Chen teaches all of the limitations of claim 3, as noted above. Jardim-Goncalves further teaches wherein the feature generator further comprises: generating, in response to the central features repository dashboard, a native platform characteristic, wherein the native platform characteristic comprises the one or more platform plugins, libraries, and packages; and performing a platform level interoperability (These independent service models can then be used as the source for the generation of platform specific models (PSM), [page 682 col 2 paragraph 1 lines 4-6]; the PSM generates code for a specific library, see [page 687 col 1 paragraph 6]).
With respect to claim 7, Jardim-Goncalves in view of Grilo and Chen teaches all of the limitations of claim 3, as noted above. Jardim-Goncalves further teaches wherein executing the instructions further causes the processing device to: receive the feature from the central feature repository dashboard (Any of the objects in FIG. 7 being received by the transformation engine as shown by the arrows passing through transformation engine, [page 686]; for example, the RFQ in FIG. 7 is received by the transformation engine, [page 686]; this is a specific type of “transaction” called a request for quote using the PIM/central features repository dashboard, see [page 686 col 2 paragraph 1 line 1] ); assign, using the GINT module, properties to the feature in a first platform (The commercial mega suite platform is used to import the ARM model, described in XMI, into UML, and then the facilities of this platform are used to automatically generate code ready to assist in the implementation of the translators and repositories compatible with the reference model in specific platforms, [page 687 col 1 paragraph 6 lines 1-6], where the commercial mega suite is the GINT module; and the resulting properties are shown in the DTD model in the bottom right panel of FIG. 8, [page 686]).
Jardim-Goncalves and Grilo do not specifically teach receive, from the user, a request to change to a second platform; and transfer, using the GINT module and the platforms operational layer, the properties from the first platform to the second platform.
However, Chen teaches receive, from the user, a request to change to a second platform (see FIG. 2, [page 148] this is the last step of “the client would request game models for the destination platform”, [page 148 col 1 paragraph 5 lines 4-5]); and transfer, using the GINT module and the platforms operational layer, the properties from the first platform to the second platform (Then the server would do message transforming, data packaging and return the URI of the model for the client plugin to download, and load it into the development environment, [page 148 col 1 paragraph 5 lines 5-7]; Table 1 shows all of the attributes/properties that are transferred, [page 147]).
It would have been obvious to one skilled in the art before the effective filing date to combine Jardim-Goncalves in view of Grilo with Chen because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Jardim-Goncalves in view of Grilo discloses a system and method that teaches an open architecture for platform interoperability. The papers are focused on interoperability between platforms, meaning there is no reason for user A to leave platform A for platform B. Therefore, Jardim-Goncalves and Grilo do not teach “receive, from the user, a request to change to a second platform”. Chen teaches the same type of platform (see FIG. 1, Chen [page 146]), but with a different use case of a single user switching between platforms (see FIGS. 2-4, [pages 148]). The TSM in Chen is stated explicitly:
CMDMS develops different plug-ins for various game development platforms (such as Unity, Unreal), so that users can realize dynamic metadata transfer between games produced by different game development platforms, so as to achieve the effect of cross platform metaverse data transfer, and provide solutions for the possible metaverse world communication in the future.
(Chen [page 145 col 2 paragraph 2 lines 5-11]).
A person having skill in the art would have a reasonable expectation of applying the interoperability between metaverse platforms in the system and method of Jardim-Goncalves in view of Grilo by modifying Jardim-Goncalves in view of Grilo with the new plugins of Chen that support this use case. Therefore, it would have been obvious to combine Jardim-Goncalves in view of Grilo with Chen to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 8, Jardim-Goncalves teaches A computer program product for multi-platform interoperability in digital environments (product is the software and architecture shown in FIG. 4, FIG. 6, and FIG. 7, [pages 684-686]; and [Abstract], at a high level the system creates a platform independent model (PIM) that is a “model driven architecture” and registers various platform specific models (PSM) that are “service oriented architectures”, and achieves multi-platform interoperability in digital environments through PIM to PSM transformations: “Through available PIM to PSM transformations interoperability at SOA can be facilitated specially in digital dynamic business environments”, [page 685 col 2 paragraph 3 lines 7-9]), the computer program product comprising a non-transitory computer-readable medium comprising code causing an apparatus to (one or more of the computer systems and applications that use the "open architecture" portrayed in the diagram of FIG. 6, and described in the abstract as "Together, these two architectures seem to provide a suitable framework to improve company’s competitiveness through the adoption of a standard-based extended environment, challenging and enhancing the interoperability between computer systems and applications in industry. The paper, after illustrating the general motivations the industrial SMEs have to adopt open architectures to achieve interoperability for extended and collaborative enterprise practices, presents the emerging model-driven and service-oriented architectures", [Abstract] lines 7-10; the computer systems are storing instructions as shown by the boxes and cylinders in FIG. 6 and FIG. 7, [pages 685-686]).
Regarding the rest of claim 8, incorporating the rejection of claim 1, claim 8 is rejected for a substantially similar rationale.
With respect to claim 9, incorporating the rejection of claim 2 and claim 8, claim 9 is rejected for a substantially similar rationale.
With respect to claim 10, incorporating the rejection of claim 3 and claim 8, claim 10 is rejected for a substantially similar rationale.
With respect to claim 11, incorporating the rejection of claim 4 and claim 10, claim 11 is rejected for a substantially similar rationale.
With respect to claim 12, incorporating the rejection of claim 5 and claim 10, claim 12 is rejected for a substantially similar rationale.
With respect to claim 13, incorporating the rejection of claim 6 and claim 10, claim 13 is rejected for a substantially similar rationale.
With respect to claim 14, incorporating the rejection of claim 7 and claim 8, claim 14 is rejected for a substantially similar rationale.
With respect to claim 15, Jardim-Goncalves teaches A method for multi-platform interoperability in digital environments, the method comprising (method is how the architecture is used as shown in FIG. 5, FIG. 6, and FIG. 7, [pages 684-686]; and [Abstract], at a high level the system creates a platform independent model (PIM) that is a “model driven architecture” and registers various platform specific models (PSM) that are “service oriented architectures”, and achieves multi-platform interoperability in digital environments through PIM to PSM transformations: “Through available PIM to PSM transformations interoperability at SOA can be facilitated specially in digital dynamic business environments”, [page 685 col 2 paragraph 3 lines 7-9]).
Regarding the rest of claim 15, incorporating the rejection of claim 1, claim 15 is rejected for a substantially similar rationale.
With respect to claim 16, incorporating the rejection of claim 2 and claim 15, claim 16 is rejected for a substantially similar rationale.
With respect to claim 17, incorporating the rejection of claim 3 and claim 15, claim 17 is rejected for a substantially similar rationale.
With respect to claim 18, incorporating the rejection of claim 4 and claim 17, claim 18 is rejected for a substantially similar rationale.
With respect to claim 19, incorporating the rejection of claim 5 and claim 17, claim 19 is rejected for a substantially similar rationale.
With respect to claim 20, incorporating the rejection of claim 6 and claim 17, claim 20 is rejected for a substantially similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230099431 A1 (Mullican) - The present disclosure relates to augmented reality, virtual reality, mixed reality, and extended reality systems, and more specifically, to systems and methods for connecting users on disparate platforms within the same virtual space while maintaining a consistent experience, [Abstract].
US 20200204649 A1 (Fowe) - Various aspects of a location-enabled AR platform system and a method for interoperability of augmented reality (AR) applications are disclosed herein. In accordance with an embodiment, the location-enabled AR platform system may include a memory and a processor. The processor may be configured to provide a protocol for communication between a first AR application and a second AR application. The processor may be further configured to receive, from the first AR application, a first set of functionalities of a plurality of functionalities for exposure. The processor may be configured to provide an accessibility of the received first set of functionalities of the first AR application to the second AR application. The processor may be configured to control the second AR application to manipulate the at least one AR object in the AR content of the first AR application, [Abstract].
US 2025/0007986 A1 (Hyun) - A method and system for controlling an interoperability architecture for a cross-platform metaverse are disclosed. According to an embodiment of the present disclosure, a method and system for controlling the architecture that manages the interaction and major components of the metaverse platform are provided, [Abstract].
US 12,200,065 B2 (Boudia) - The present specification provides a content normalization server and method. The specification can have particular application to client devices with augmented or virtual reality hardware that interact with different platforms with metaverse capabilities. Rich experiences are provided on client hardware while making efficient use of available processing, memory and communication resources, [Abstract].
US 2022/0157002 A1 (Gelencser) - A system and method for immersive telecommunications communication by tracking the movement of objects and/or persons with sensors. Movement tracking is then used to animate an avatar that represents the person or object. Movement may be tracked in real time, which at least reduces latency of communication. The sensors comprise any type of movement sensor which may be attached to a person and/or object for tracking motion, including but not limited to, an IMU (Inertial Measurement Unit), an accelerometer, a gyroscope or other such sensors, [Abstract].
“Virtual World Interoperability of Avatar Information” (2010-Kane) - As users create avatars to represent themselves in virtual worlds, the number of replicated user representations grows, in addition to the amount of independent data associated with that avatar. To reduce the amount of replication and increase a user's familiarity, one should be able to transfer one world's avatar information to a destination world. Additional business logic and data restrictions will also be required to ensure proper data identification and proper usage for the destination world, possibly utilizing the type of worlds involved in the transfer. This technique will allow users to bring their previous experiences and information with them to a new world, creating a more static entity that represents themselves in virtualized worlds, [Abstract].
“Avatars interoperability in Virtual Worlds” (Jovanova) - technologies related to avatars and introduces a new solution for interoperability of avatars in Virtual Worlds. A short examination of several standards, recommendations, markup languages and VWs presentation definitions addressing different aspects of avatars are provided. As a result of this analysis, a new standard, called MPEG-V, aiming to provide an interchange format for virtual worlds is presented. Providing the container of avatar properties/capabilities is the vision of MPEGV. By its descriptive format it aims to facilitate the deployment of VW recognizing that their success depends on maintaining acceptable development cost and one mechanism in doing so consists in ensuring interoperability between them at least at the level of avatars, [Abstract].
“XR collaboration beyond virtual reality: work in the real world” (2021-Lee) –
PNG
media_image1.png
248
402
media_image1.png
Greyscale
[page 761].
“Unified Representation for XR Content and its Rendering Method” (2020-Lee) - Virtual Reality (VR) and Augmented Reality (AR) have become familiar technologies with related markets growing rapidly every year. Moreover, the idea of considering VR and AR as one eXtended reality (XR) has broken the border between virtual space and real space. However, there is no formal way to create such XR content except through existing VR or AR content development platforms. These platforms require the content author to perform additional tasks such as duplicating content for a specific user interaction environment (VR or AR) and associating them as one. Also, describing the content in an existing markup language (e.g., X3D, X3DOM, A-frame) has limitations of that the content author should predefine the user interaction environment (i.e., either of VR and AR). In this study, a unified XR representation is defined for describing XR content, and the method to render it has been proposed. The unified XR representation extends the HTML so that content authored with this representation can be harmoniously incorporated into existing web documents and can exploit resources on the World Wide Web. The XR renderer, which draws XR content on the screen, follows different procedures for both VR and AR situations. Consequently, the XR content works in both user interaction environment (VR and AR). Hence, this study provides a straightforward XR content authoring method that users access anywhere through a web browser regardless of their situational contexts, such as VR or AR. It facilitates XR collaboration with real objects by providing both VR and AR users with accessing an identical content, [Abstract].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL MILLER whose telephone number is (408) 918-7548. The examiner can normally be reached on Monday-Friday from 11am to 5pm (PT).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young, can be reached at telephone number (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/D.M./Examiner, Art Unit 2187
/KEVIN L YOUNG/ Supervisory Patent Examiner, Art Unit 2194