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 .
DETAILED ACTION
This office action is in response to communication filed 8/19/2025. Claims 12-19 and 24-30 are pending for examination, the rejection cited as stated below.
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 24-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter as follows. Claim 24 defines a “system”. However, while the preamble defines a “system”, which would typically be indicative of an “apparatus”, the body of the claim lacks definite structure indicative of a physical apparatus. Therefore, the claim as a whole appears to be nothing more than a “system” of software elements, thus defining functional descriptive material per se. Claims 25-30 are similarly rejected.
Claim Rejections - 35 USC § 112
4. 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.
5. 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.
6. Claims 12-19 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. Claim 12 recites “each with one or more blockchain nodes for storing data, such as for pinning transaction hashes and storing network or other configuration data, and for running smart contracts.” The scope of the claimed limitation cannot be definitely determine, because it is unclear how “such as” further limits the claimed limitations. Applicant is required to clarify. For the sake of the examination, Examiner interprets as any type of storing data. Claims 13-19 are similarly rejected.
Claim 13 is 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. Claim 12 recites “providing one or more collaboration services that includes an identity service for generating a unique identifier for each patient or health plan member, based on deterministic and/or probabilistic matching.” First of all, it is unclear what are matched with. Secondly, “deterministic and/or probabilistic” appears to cover all possibilities, as a result, the metes and bounds of the claimed scope cannot definitely determined. Applicant is required to clarify. For the sake of the examination, Examiner assumes based on any criterion.
7. Claims 18 and 29 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. Claim 18 recites “wherein the one or more decentralized applications in a landing zone share data using a FHIR Server or other database tables in the landing zone”, wherein “the one or more decentralized applications in a landing zone” lacks sufficient antecedent basis. Applicant is required to clarify. For the sake of the examination, Examiner interpretas as any decentralized applications. Claim 29 is similarly rejected.
8. Claim 27 is 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. Claim 18 recites “wherein a decentralized application is able to communicate directly with a similar instance of itself in any other landing zone”. It is unclear what is considered “a similar instance of itself”. An ordinary skilled in the art would understand that a decentralized application can have different instances performing different functions, or same instances, but it is unclear what is considered “a similar instance”. Applicant is required to clarify. For the sake of the examination, Examiner interprets as any other instance performing the same or different functions of the decentralized application.
Claim Rejections - 35 USC § 102
9. 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 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.
10. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
11. Claims 12-13, 15-19 and 24-30 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Witchey et al (US 12430463).
As to claim 12, Witchey discloses a method comprising:
providing a network of (i) a plurality of virtual machines (Figure 1; col. 3, lines 20-30, “The request may originate from one or more requestor devices ( e.g., cell phone, tablet, computer, web browser, cloud or virtualized computer, etc.)”; col. 15, lines 60-65, “The smart contracts can execute on Ethereum virtual machine (EVM) computing nodes”), and (ii) one or more blockchains, each with one or more blockchain nodes for storing data, such as for pinning transaction hashes and storing network or other configuration data, and for running smart contracts (Figure 1; col. 13, lines 25-35, “Record-keeping system 130 comprises a series of blocks where an existing block 155A is linked to a current block 155B, which in tum will be linked to a yet to be created new block 155C. The blocks in blockchains are typically "linked" via hash values. Thus, block 155B incorporates a hash value of block 155A into its own data structure”; col. 6, lines 3-25, “typically via transactions related to the NFTs as recorded on an underlying corresponding digital notarized ledger system. Management of NFTs can be achieved through use of existing token standards such as via Ethereum smart contract standards. These standards include ERC-20, which represents fungible tokens; ERC-721 defines interfaces by which one may manage NFTs (according to ERC-721, NFT minting, transfers, burning, or other operations are recorded on the Ethereum blockchain to retain a record-keeping system of all desired actions associated with the NFT); ERC-998 defines interfaces for creating tokens comprising sub tokens and vice versa; and yet further, ERC-1155 defines interfaces by which one can create token sets. As individuals interact with Ethereum tokens via one or more transactions (or, more generally, operations), the transactions (operations) are recorded on the Ethereum blockchain thereby forming a record-keeping system of the existence of such tokens in an immutable manner.”);
providing a data highway for accessing data stored in the network by participants who have a valid HIPAA reason to consume the data (see citation above, and col. 42, lines 55-60), wherein the participants are communicatively connected to the network via the plurality of virtual machines (see Figure 1; col. 3, lines 20-30, “The request may originate from one or more requestor devices ( e.g., cell phone, tablet, computer, web browser, cloud or virtualized computer, etc.)”; col. 15, lines 60-65, “The smart contracts can execute on Ethereum virtual machine (EVM) computing nodes); and
providing one or more data channels for defining and restricting access, via the data highway, to protected health information (PHI) based on specific use cases (col. 42, lines 55-60).
As to claim 24, see similar rejection to claim 12.
As to claim 13, Witchey discloses the method of claim 12, further comprising:
providing one or more collaboration services that includes an identity service for generating a unique identifier for each patient or health plan member, based on deterministic and/or probabilistic matching (see 112 rejection and Examiner’s interpretation stated therein. See col. 7, lines 50-55, “entity 102 is represented in the system via one or more of authorization identifiers 112, by which the system can recognize entity 102”).
As to claim 15, Witchey discloses the method of claim 12, further comprising:
providing one or more collaboration services that includes a workflow authorization service for performing authorization based on a plurality of levels of granularity, including data source, resource type and requesting entity (col. 3, paragraph 1).
As to claim 16, Witchey discloses the method of claim 12, wherein each virtual machine is configured to execute one or more decentralized applications sourced from a managed solution repository (see citation in rejection to claim 12, limitation1; and also col. 15, “such a distributed record-keeping system provides for tracking operations as well as for storing DAT 150 or other types of tokens ( e.g., NFTs, bearer tokens, tokens from a multi-token set, etc.) in a more efficient manner”; col. 17, lines 25-35, “The purpose of recording the operation in the record-keeping system rather than storing the actual token on the record-keeping system is to reduce the overall storage burden of the record-keeping system on the various participating nodes ( e.g., virtual machines…) in the record keeping system”. It is to be noted that the claimed “each virtual machine” does not limit to what virtual machines this each virtual machine is out of therefore Examiner interprets as any virtual machine).
As to claim 26, see similar rejection to claim 16.
As to claim 17, Witchey discloses the method of claim 16, wherein a first set of decentralized applications of the one or more decentralized applications provides one or more services to a second set of decentralized applications of the one or more decentralized applications (Figure 1; col. 3, lines 20-30, “The request may originate from one or more requestor devices ( e.g., cell phone, tablet, computer, web browser, cloud or virtualized computer, etc.)”; col. 15, lines 60-65, “The smart contracts can execute on Ethereum virtual machine (EVM) computing nodes”).
As to claim 28, see similar rejection to claim 17.
As to claim 18. Witchey discloses the method of claim 16, wherein the one or more decentralized applications in a landing zone share data using a FHIR Server or other database tables in the landing zone (see 112 rejection and Examiner’s interpretation therein. See col. 3, lines 20-35).
As to claim 29, see similar rejection to claim 18.
As to claim 19. Witchey discloses the method of claim 12, wherein each virtual machine is configured to store data in a common format with common access means (col. 15, last paragraph to col. 16, paragraph 1. It is to be noted that the claim does not limit among which entities the format is common or access means is common).
As to claim 30, see similar rejection to claim 19.
As to claim 25, Witchey discloses the system of claim 24, wherein the network is configured to:
receive a transaction from a first virtual machine of the plurality of virtual machines, wherein the transaction corresponds to a member of a participant (Figure 1; col. 3, lines 20-30, “The request may originate from one or more requestor devices (e.g., cell phone, tablet, computer, web browser, cloud or virtualized computer, etc.)”, wherein the request is a transaction; col. 15, lines 60-65, “The smart contracts can execute on Ethereum virtual machine (EVM) computing nodes”; col. 8, lines 6-20, “entity 104 may have a need or a desire to access records 114. To address the needs of entity 104 while also protecting the property rights or privacy of entity 102 (e.g., the owner of the private data or the user associated with the values shown in the private data, etc.) private data exchange server 120 can operate as an intermediary between the entities to broker access to records 114. In the example shown, entity 104 transmits request 124 over network 115 from a requestor device 105 to private data exchange server 120”, wherein a request is a transaction);
search for a member identifier and associated metadata for the member corresponding to
the transaction (col. 7, lines 50-55, “entity 102 is represented in the system via one or more of authorization identifiers 112, by which the system can recognize entity 102”; col. 8, lines 6-20, “entity 104 may have a need or a desire to access records 114. To address the needs of entity 104 while also protecting the property rights or privacy of entity 102 (e.g., the owner of the private data or the user associated with the values shown in the private data, etc..) private data exchange server 120 can operate as an intermediary between the entities to broker access to records 114. In the example shown, entity 104 transmits request 124 over network 115 from a requestor device 105 to private data exchange server 120. Request 124 includes one or more fields of interest 126 related to the fields in records 114. In response, private data exchanges server 120 causes one or more data access tokens (DATs) 150 to be instantiated or otherwise generated, possibly upon any required authorization of entity 102. Entity 104 may then become the token owner of DAT 150 and may also use DAT 150 to access the private data values corresponding to fields of interest 126”);
authorize the transaction to transmit using the data highway (see citation above); and
transmit data corresponding to the transaction to a second virtual machine of the plurality
of virtual machines, based on the authorization (see citation above, wherein the request is authorized to proceed; see col. 21, paragraph 1, “the private data exchange server could generate a new DAT 250 to service the request upon access of the original DAT 250 based on the corresponding smart contract requirements; see col. 15, lines 60-65, “The smart contracts can execute on Ethereum virtual machine (EVM) computing nodes”).
As to claim 27, Witchey discloses the system of claim 26, wherein one or more participants subscribe to the one or more decentralized applications (see citation in rejection to claim 25; and col. 6, lines 35-45, “by abstracting the right-to-access as a token, greater control of the interactions with the data may be achieved by enabling fine grained control of how the token may be used ( e.g., number of uses, enforced restrictions, subscriptions, exclusion periods, etc.)”), wherein the one or more decentralized applications are enabled in each subscriber's landing zone (see citation above, implied in order to provide private data service to the subscribers), and wherein a decentralized application is able to communicate directly with a similar instance of itself in any other landing zone (see 112 rejection and Examiner’s interpretation therein. See col. 15, lines 20-25, “such a distributed record-keeping system provides for tracking operations as well as for storing DAT 150 or other types of tokens (e.g., NFTs, bearer tokens, tokens from a multi-token set, etc.) in a more efficient manner”; col. 8, lines 20-30, “private data exchanges server 120 causes one or more data access tokens (DATs) 150 to be instantiated or otherwise generated, possibly upon any required authorization of entity 102. Entity 104 may then become the token owner of DAT 150 and may also use DAT 150 to access the private data values corresponding to fields of interest 126.” See col. 46, lines 28-48, “FIG. 4 is a block diagram of a distributed computer system 400 usable to implement embodiments of the present disclosure. Various aspects and functions described herein may be implemented as hardware, software executing on hardware, or a combination of hardware and software executing on one or more computer systems. Aspects in accord with the present disclosure may be located on a single computer system or may be distributed among one or more computer systems connected to one or more communication networks. For example, various aspects and functions may be distributed among one or more computer systems configured to provide a service to one or more client computers, or to perform an overall task as part of a distributed system. Additionally, aspects may be performed on a client-server or multi-tier system that includes components distributed among one or more server systems that perform various functions.”).
Claim Rejections - 35 USC § 103
12. 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 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.
13. 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 of this title, 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.
14. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
15. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Whtchey as applied to claim 12 above, and further in view of Bajwa (US 12456547).
As to claim 14, Witchey discloses the method of claim 13, wherein the one or more collaboration services include a data discovery service for identifying locations of data corresponding to a member (col. 30, lines 55-60), but does not expressly disclose for providing a FHIR resource-based directory service. Bajwa discloses a concept of providing a FHIR resource-based directory service (abstract).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Witchey with Bajwa. The suggestion/motivation of the combination would have been to enable contact tracing (Bajwa, abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HUA FAN/Primary Examiner, Art Unit 2458